Administrace komentářů

Zasadny rozdiel medzi LDAP, NIS a podobnymi databazami v porovnani s SQL je v ich rychlosti. V pripade SQL databaz by nemal byt velky rozdiel v rychlosti vkladania dat a ich vyberania. Naproti tomu databazy LDAP, NIS, atd. su primarne optimalizovane na citanie a rychlosti zapisu sa nedava velka priorita. Uz z principu sa neda spravit databaza, ktora bude rychla na citanie a nedotkne sa to rychlosti zapisu.

Velmi zalezi ako budu udaje pouzivane a ako sa bude k nim pristupovat. V pripade email servra a emailov vo virtualnych domenach bude stacit aj MySQL bez specialnej konfiguracie. Rychlost dorucovania emailov vacsinou nie je taka rychla, aby sa odrazila rychlost MySQL na ich dorucovani (samozrejme nemyslim nejaky obrovsky email server).

V pripade pouzitia databazy ako uloziska Unix accountov je situacia uplne ina. Kazdy jeden prikaz ps, ls, find a iny pracujuci s Unix login udajmi vyprodukuje celkom dost dotazov. Hoci to nie je uplne viditelne, tak uz len taky "ps -ef" prikaz potrebuje prelozit UID/GID na meno. To iste "ls -l" v nejakom adresari a samozrejme kazda jedna sluzba/prikaz pracujuca s pravami na systeme. Samotnemu jadru toto mapovanie nevadi, kedze pracuje len s cislami, ale aby system pracoval "svizne" tak aj app musia pracovat rovnako rychlo.

V tomto momente je presne na mieste spomenut LDAP. Tie obmedzenia a restrikcie su primarne na dosiahnutie rychlosti citania. Ked nastartujem nejaky file manager an pozriem sa napr do /tmp, tak ocakavam, ze a mi zobrazi obsah co najrychlejsie. Kedze suborovy system doda len UID:GID, tak je potrebne sa na kazdu jednu kombinaciu pozriet do zaznamov LDAP-u a to mozu byt tisicky dotazov, u ktorych ocakavame "okamzite" odpoved. Naproti tomu pridavanie uzivatelov, menenie hesla a inych parametrov je v porovnani s mnozstvom "citacich" dotazov zanedbatelne malo. Na zmenu hesla uzivatel pocka aj par sekund, ale na odpoved systemu pri "normalnej" praci nie.