Dotaz: php - Seřadit uživatele podle klíčů a zobrazit jich omezenýc počet

[v4it]

Dobrý den, mám výpis uživatelů, kde spojuju informace o jedněch uživatelích ze 2 zdrojů: z ldapu(pokud má daný uživatel založen emailový účet, jinak se vrací null) a z mysql(pokud mají ftp účet, jinak se vrací null). Tyto informace spojím v jednom poli a povoluji řazení podle jména uživatele, emailové adresy, ftp kvóty apod. Je možnost řadit podle více klíčů najednou. Také omezuju výpis uživatelů třeba 15 najednou. Toto hezky funguje, ale poslední dobou, co narůstá počet uživatelů, se to stává hrozně pomalým. Není čemu se divit - musí se přečíst všichni uživatelé z obou zdrojů, v poli seřadit a pak na nich nasadit limit zobrazení. Potřeboval bych poradit s vhodnějším algoritmem na zpracování dat. Logicky se naskýtá možnost získat třeba 3 uživatele už rovnou seřazené z mysql, ale to nejde z následujícího důvodu:

username | sql/email | ldap/kvota
-----------------------------------------
usr1 | e@email.com | 500
usr2 | d@email.com | 500
usr3 | c@email.com | 500
usr4 | b@email.com | 500
usr5 | a@email.com | 500

Teď se rozhodnu seřadit je podle kvóty a pak podle emalu, tzn. ldap vrátí první 3, ty pak se ty tři seřadí jako c@..., d@..., e@... Správně by ale měl výpis vypadat takto:
usr5 | a@email.com | 500
usr4 | b@email.com | 500
usr3 | c@email.com | 500

Doufám v nějakou dobrou duši, která mi s tím pomůže

Odpovědi

[Josef Kufner]

Tak načti už z databáze/ldapu omezený počet, spoj to v programu a následně omez ještě jednou na požadovaný počet. Takže pokud chceš N záznamů, načteš max N z databáze, max N z ldapu a v programu seřadíš max 2N záznamů.

Pokud potřebuješ načítat data z databáze k položkám z ldapu i pokud nemají ftp účet, načítej ldap jako první a požadovaná ID z ldapu připiš do selectu (id IN (...)).

Pokud je situace ještě horší, zjisti si ID požadovaných záznamů z obou zdrojů v první sadě dotazů a vlastní seznam načti až napodruhé.

[v4it]

Ono je to ve skutečnosti malinko jinačí, uživatele už znám podle centrální databáze a jejich username, pak mi akorát teoreticky stačí najít odpovídající záznamy v ostatních zdrojích podle username, které se tady používá jako takový klíč, jenže tímto přístupem se odříznu od možnosti seřadit záznamy. Takové je schéma:

(-------PHP APLIKACE--------)--(centrální db v mysql)
  |           |           |
(ftp/mysql) (mail/ldap)  (*/*)...

[Josef Kufner]

V tom případě přidej vrstvu.

(-------PHP APLIKACE--------)--(centrální db v mysql)
                                        ||
                          (-------Backend manager-----)
                            |           |           |
                         (ftp/mysql) (mail/ldap)  (*/*)...

A v centrální DB si kešuj všechny potřebné informace. Update centrální DB pak spouštěj buď periodicky nebo občas při dotazu či nejlépe ať si každá služba aktualizuje svá data sama (pár scriptů to obstará; = backend manager).

Krom toho, že se ti výrazně zrychlí "PHP APLIKACE", tak si ušetříš starosti s přílišnou různorodostí služeb, resp. je vytlačíš stranou, kde nestraší.

[v4it]

To s tou aktualizací nebude tak jednoduché. Dejme tomu že se rozhodnu z centrální aplikace změnit emailovou adresu nějakého uživatele, tzn. musím nejdříve aktualizovat cílovou databázi a při úspěchu aktualizovat i cache. Problém nastane z druhé strany kdy se třeba uživatel rozhodne že si změní heslo nebo se aktualizuje v db informace o využité kvótě - tam nemohu nijak zajistit, aby si sama ldap připojila k centrální databázi a tam informace aktualizovala. Zároveň nevím o žádném mechanismu, který by kontroloval, zda cache potřebuje aktualizaci (procházení všech zdrojů a porovnávání není dobrý mechanismus).

[Josef Kufner]

Tak nemusíš procházet vše, stačí jen co se změnilo od poslední aktualizace. Obvykle bývá dostupný čas poslední změny, tak to snad nebude problém.

Jinak pokud něco změníš v nějaké službě, tak by to mělo být udělané tak, aby jsi se nemusel o aktalizaci kešovaných dat starat -- tedy ono se to postará samo při dalším zobrazení a dočasná nekonzistence nevadí.

Ale pokud s tímhle bude víc problémů než užitku, pořád můžeš rozdělit původní jedno kolo dotazů na dvě (viz první komentář).

[v4it]

Ono je to tak půl na půl - pokud bych vyřešil ten cache, tak mi odpadne starost se řazením záznamů (to obstará sql), odpadne starost s dočasnou nedostupností některých služeb, ale zase přibude starost jak aktualizovat záznamy (ne všechny služby si ukládají modified položku u uživatelů). Taky nevím jak bych ten cache měl tvořit. Logicky to vychází tak, že co služba, to tabulka v mysql, jenže bude problém u indexů a u datových typů v sql pokud se bude jednat o konverzi třeba z ldapu. Co se týče tvého prvního příspěvku - mohl bys to rozvést? Nějak jsem to úplně nepochopil - dejme tomu že mám X služeb, N uživatelů a M uživatelů u každé služby, kde M<=N.

[Josef Kufner]

Starost s nedostupností služeb bych viděl jako celkem podstatný argument pro kešování. K updatům může pomoct i sledování logů (tail -f | ...). Navíc updaty budou jediný problém k řešení, zbytek je víceméně triviální. Také poznámka, že hodnoty označené hvězdičkou se aktualizují kadých 5 minut, nikoho nezarmoutí. A pokud uzavřeš aktualizaci do transakce, tak si nikdo ani nevšimne, že zrovna běží (místo skutečné transakce stačí použít nějaký příznak nový/starý).

To první jsem myslel tak, že v prvním kole uděláš dotaz na každou službu a získáš seznam max L uživatelů, kteří by se mohli objevit ve výsledném výpisu. (Kde L je počet položek na výpisu.) V druhém kole pak z této sady výsledků vytáhneš seznam ID uživatelů a zeptáš se centrální DB na tyto uživatele (select ... where id in (1, 2, 3, ...)). Výsledek nebude mít více než X×L položek a v PHP to pak celé spojíš a seřadíš. V lepším případě to seřadíš ještě v centrální DB a v PHP pak uděláš něco jako left join.

[v4it]

Starost s nedostupností služeb bych viděl jako celkem podstatný argument pro kešování.

I jako argument proti. Třeba služba ftp je nedostupná pro aplikaci php z důvodu částečného výpadku spojení, ale uživatelé ftp normálně používají a můžou si měnit hesla. PHP aplikace ale ftp službu nevidí a tak veškeré úpravy bude provádět lokálně. Ve chvíli kdy bude služba dostupná i pro php aplikaci nastane konflikt: aktualizovat cache podle služby nebo službu podle cache.

Jinak to s těmi částečnými dotazy je výborný nápad, asi to udělám tak, děkuju.

[v4it]

Ještě bych měl otázku: jakým způsobem řadit a vybírat uživatele, pokud bude více řazení nad stejnou službou? Např. řadit vzestupně s limitem 2 podle služeb(zde pro přehlednost uvádím přímo databáze) v tomto pořadí: mysql/email, mysql/maildir, ldap/uid, mysql/kvota. Musím použít 4 dotazy nebo mohu dotaz na mysql spojit v jeden? Bude to tak fungovat?

[Josef Kufner]

PHP aplikace ale ftp službu nevidí a tak veškeré úpravy bude provádět lokálně.

Cache bude z pohledu aplikace read-only, takže nic takového nemůže nastat. Úpravy se udělají normálaně přímo s danou službou, jakoby žádná cache nebyla. Uživatel dostane potvrzení o úspěšnosti přímo od služby. Je to takové kolečko, které se otočí s každou provedenou úpravou.

[v4it]

Tato cache u mě nemá šanci. Ta php aplikace je primárně určená k editaci uživatelů a pokud jí nebude schopná nemá cenu mít ani readonly cache. Nicméně k mé předchozí otázce: jakým způsobem řadit a vybírat uživatele, pokud bude více řazení nad stejnou službou? Např. řadit vzestupně s limitem 2 podle služeb(zde pro přehlednost uvádím přímo databáze) v tomto pořadí: mysql/email, mysql/maildir, ldap/uid, mysql/kvota. Musím použít 4 dotazy nebo mohu dotaz na mysql spojit v jeden? Bude to tak fungovat?