LDAP-lekérdezések száma, hatékonyság

Question

Üdvözlet!

Az a kérdés, hogy a lekérdeések számának csökkentését hogy kell elképzelni? Pl. egy D feladat esetén megfelelő az, hogy ha egy nagy feltételű query-t írok, hogy username vagy realname a csv fájhl első oszlopával egyezik-e. Utána visszakapom az összes usert aki benne volt az adatbázisban, persze úgy, hogy tudjuk hogy hol dolgoznak. Ezután lokálisan megnézem, hogy ki a gyanús és kiírom. Ennyi lenne a feladat? Vagy inkább soronként legyen ldapsearch (sokallom hogy 3000 soros fájl esetén 3000 ldapsearch van).

Kb már csak a lényegi része van hátra a házinak, viszont még nem nagyon sikerült megérteni, hogy pontosan mire is gondolt a feladat készítője. És csunyának tartom, hogy ciklusba lekérdezést rakunk. Vagy inkább sok kicsi legyen, és akkor tovább fut, de nincsen server timeout?

Köszönöm előre is a segítséget.

Üdv.:
Cseppentő Lajos

Answer 1

Az a kitétel, hogy próbáljuk csökkenteni a lekérdezések számát és méretét azért került bele, mert korábbi években voltak nagyon is pazarló megoldások. Például ugyanazt a részfát feleslegesen tízszer lekérdezte, ahelyett, hogy eltárolta volna helyileg. Vagy amikor egy attribútumra volt csak szükség, akkor is mindig külön lekérte az összeset.

Az elvárás az, hogy gondoljátok végig, hogy milyen lehetőségeitek vannak a feladat során.

• Van olyan feladat, ahol a teljes címtárhoz viszonyítva kevés adat kell. Ilyenkor érdemesebb lehet célzottabb lekérdezéseket használni.
• Van olyan, ahol a címtár egy nagy része biztos kell (mert pl. kell az összes aktuális városnév), ilyenkor azt valószínűleg érdemesebb egy nagy lekérdezésben lefuttatni.
• Érdemes még azt is figyelembe venni, hogy egy új ldapsearch keresés indítása költséges művelet, főleg, ha távoli LDAP-kiszolgálón keresünk (TCP kapcsolat nyitása, hálózati késleltetés...). Tehát lehet, hogy ezzal érdemesebb inkább takarékoskodni, és esetleg bevállalni, hogy néha kicsit túl sokat kér le a szkript.
• A legszebb megoldás nyilván az, hogy ha csináltok saját magatoknak pár mérést (pl. a time parancs segítségével a futási időt, Wireshark/tcpdump segítségével a forgalom méretét), és ez alapján döntöd el, hogy melyik variáns a jó. Természetesen ez a feladatban nem elvárás, de aki hatékony kódot szeretne írni, annak érdemes ilyet is megnéznie.
• Külön érdekes lehet egy olyan megoldás, ahol pl. a bemenet száma alapján valami heurisztika alapján másként működik a szkript (pl. 5 sor esetén egyesével kérdez, 1000 sor esetén leszed egyben). De ez már tényleg nagyon extra, ilyesmi nem elvárás a HF-ben.
• Amit viszont mindenképp érdemes megtenni az az, hogy a szkript elején valahol kommentben írsz egy-két sort a szkript főbb működéséről, és ott pl. az ilyen tervezői döntést megemlíted.

Answer 2

Ez a megjegyzés a kiírásban arra vonatkozik, hogy ha lehet, akkor minden szűrést végezzünk el a szerveren, ne kérdezzünk le felesleges adatokat. Nyilván, ha kapunk egy nagyon hosszú bemeneti fájlt, akkor sokkal lassabban fog lefutni a szkriptünk, ez nem baj.

Ami elvárható a szkriptől az tehát az, hogy a lefutási idő sokkal inkább függjön a bemenet méretétől, mint a címtár méretétől. Az tehát nem feltétlen baj, ha a bemenet minden sorához ldapsearch tartozik.