Fejlövés

Vajon miért van az, hogy egyesek kb 0 gyakorlati tapasztalattal meg akarják váltani a világot, és közben csak magukat égetik?

Egyik kedvencem ez a gyöngyszem:

Én meggondolnám hogy egy iwiw szerű rendszer alá adatbázis kezelőt tennék -e, vagy simán csak egy fájlrendszert használnék -e hozzá.

Azért mert:
- sebesség és a teljesítmény a kritikus szempontok dominálnak,
- nem lehetnek (optimális tervezésnél) annyira öszetett adatszerkezetek amiket ne lehetne egyszerűen text fájlokban tárolni és onnan lekérdezgetni.

Kérem kapcsolja ki.

( Testa (nem ellenőrzött) | 2007. 03. 09., p – 13:12 )

Az az igazság az hogy ha sebbességre gyúrsz akor a ramdisk nél nincs gyorsabb és jobban backuppőlható megoldás....
A sql ok legtöbbje egy adat hívást min 50 ciklussal hív ;)
Ez 12 re redukálható...
Én is utálom az xml -t...

Hozzá teszem ez a megoldás egy ismerősőmnél se aratott osztatlan sikert ... (Attól függetlenül hogy gyakorlatilag egyik munkám 3.5 terranyi adatbázzissal dolgozik amit csak így tudtam egyedül hatékonyan lekezelni... (És bnagy valószinüséggel 2 hónapon belül eléri a rendszer a 6 terrat...) )de 4 rendszerem is üzemel így... Amit anyagi okokból kis hardware en kellett tartanom...

A másik az iwiw java függősége a kurva anyjába elmehet és a rengeteg bugos html code... Mit mondjak ha annyira kritikus a sávszélességük akkor ideje lene átgondolni a rendszert újra...

Na akkor le egyszerüsitve...
sql...
kliens hívás <-> sql <->azonosít
<->index olvas keress
<->lemez olvas adatbázis vagy cache olvass adat

Az én megoldásom egy egyszerű rendszerbe ami ram disk.
Kliens vált >könyvtár
<->olvas célfájl. (nem keres minden változó külön jegyzék)

Most komolyan, fogtad és ramdiskre tettél file-okat és abban tároltál adatot? És hagytad, hogy lerontsa a teljesítményt az oprendszer VFS rétege? Most gondold el, ha csak simán malloc()-olnál akkora memóriát ramdisk nélkül és abban tárolnád az adatot, az milyen qrva gyors lenne...

Épületes a hup ismét...

'98-ban csinált ilyet egy haver, ugyancsak perl + cgi-ben. Az elender bendeguz nevu szerveren futott a dolog kb 200 felhasznaloig, amikor akkora load-ot generalt, hogy leallt miatta a sendmail. Utana atirta C-be es mysql-be (sok ideje volt, asszem eppen nem vettek fel egyetemre), es azota ugy megy is, lassan egy evtizede.

Nekem sql mentes esetekre ami nagyon tetszik (de meg nem hasznaltam sehol) az a Prevayler.org-os persistance framework. Most eppen nem nagyon van info rola a honlapjan de van egy ibm-es cikk par evvel korabbrol ahol egesz jol leirjak, hogy mire lehet hasznalni.

Neked meg megsugom, hogy meg azzal mennyi turbot vihetnel a kis ramdiskes megoldasba, ha nem cgi-kent futna a programod, hanem sajat webservert irnal. Tudod, az Oracle is tul sokat tudott, a webserver is csak egy lomha nagy dog - tuti talalnal valami gyorsabb megoldast helyette...

( kukukk v | 2007. 03. 09., p – 13:15 )

0 gyakorlati es kb szinten ennyi elmeleti tapasztalatom van adatok tarolasa/kezelese teren (bar volt adatbazis kurzusom az egyetem, de 4-szer vizsgaztam belole :} igaz ebbol 2-szer a tanar is ludas volt :}})... ezert is kerdezem, hogy miert akkora baromsag az, hogy filerendszert/text file-t hasznalni erre a celra? Azt leszamitva, hogy adatbaziskezelo programnal egy insert vagy select 1 sornyi kod, es tenyleg eleg egyszeru (kisebb adatbazisoknal, komoly adatbazisoknal mar biztos nem ennyire egyszeru a dolog), addig a masik esetben ezt kulon le kell programozni, megirni hozza a "driver"-t. Vegul is az adatbaziskezelok is file-ban taroljak az adatokat, csak biztositanak egy keretrendszert ezek kezelesere/eleresere bizonyos plussz segedletek kisereteben. Ha most o nagyjabol egy ilyen adatbaziskezelo feluletet megir a textfile-ban tarolt adatokhoz, csak kihagyva belole az olyan plusszokat amire neki nincs szuksege a feladata megoldasaban, akkor elvileg meg gyorsabb is lehet mint egy adatbaziskezelo. Vagy nem?

Nem kotekedni akarok, vagy vedeni/tamadni valakit, barkit, akarkit... csak tenyleg kivancsi vagyok.

Az, hogy elmondasz annyit, hogy "x" emberke "y" kijelentese miatt hulye, anelkul hogy elmondanad, hogy azert hulye mert: ..., az kb nulla.

Mer a könyvbe az van hogy mennyivel jobb adatbázis kezelőn keresztül dolgozni ... De mekkora poén mikor rosszul lönnek be egy má(jkel)sql t ;) és net fele nyítja a portját :D És lehett turni :D mint az tvk ORACLE jébe ami alatt SÜSÜ volt annó :D
És másodpercenként ez álltal max 4000 csatlakozást vír ki :D Nesze :P

Azért mert a textfile-t tipikusan szekvenciálisan kezeljük. Tehát mondjuk egy keresés ideje arányos az adatok mennyiségével. Vagy képzelj el egy beszúrást, egy textfile eleje környékén. Nyilván úgy kell elvégezni, hogy hatalmas adatmennyiségeket mozgatsz köben (pl mindent, ami a beszúrás mögött van).
Erre találtak ki olyan adatszerkezeteket, amiken ilyen jellegű dolgokat sokkal (akár sok nagyságrenddel) gyorsabban lehet végezni. Pl mondjuk egy B-fában a keresés idejét egy logaritmusos függvény adja meg, de a többi művelet is gyorsabb.
Ráadásul egy textfile-t soronként kell feldolgozni egy parserrel, ami általában sokkal lassabb, mint egy fix szélességű adatot felolvasni valahonnan.

És ez még csak a kezdet :-)

Az adatbázis kezelők általában rengeteg olyan funkciót tartalmaznak, amiket az ember használni is szokott. indexelések, joinok, tranzakciókezelés, hogy néhány egyszerű és gyakran használt dolgot mondjak. Ezeket mind nem tudja a egy sima szövegfile, tehát nekem kellne megvalósítanom. Csakhogy a komoly adatbázis-kezelők mögött annyi tapasztalat és tudás és munka van, hogy velük versenyezni igencsak erőforrásigényes, és a legtöbb esetben értelmetlen.

huhh ha ezt el tudnám magyarázni a keresés kikerülhető egy logikus rendezéssel... De ezt nem tom elmagyarázni...
Meg próbálom ....
képzelj el egy 255 könyvtárat ami az adot word első karaktere... Azon belül mindegyikbe 255 ami az adott word második karaktere... Nem így oldottam meg de ez áll a legközelebb a magyarázathoz...
Végülis ja tudom az oracle felépítéséből indultam ki csak nekem túl sokat tudott...

( sj | 2007. 03. 09., p – 15:36 )

Nekem ez meg keves, hogy iwiw-szeru rendszer eseten db vagy fs. Assetudom, milyen azaz iwiw-szeru rendszer....

Egy szurohoz csinaltam egy olyan feature-t, hogy IP-cimeket tud ellenorizni egy adatbazisbol. Eloszor ez ugy tortent, hogy volt egy mysql tabla, ahol az IP-cim szerepelt egy timestamp-epl egyutt. De aztan meggondoltam magam, es az IP-cimeket egy konyvtarban tarolom, a timestamp-et pedig a nulla hosszu file inode-ja tartalmazza. Ez utobbi az en esetemben ugyanis sokkal gyorsabb es egyszerubb. Esetleg annyi gyorsitason meg gondolkodom, hogy az x/ konyvtarban csinalok [0-9a-f] konyvtarakat, es a cimeket ezek alatt tarolom hexaban, de meg nem tudom, megeri-e ez cca. 10k file bejegyzes eseten...

ASK Me No Questions, I'll Tell You No Lies

( tolmi | 2007. 03. 09., p – 15:50 )

Én is okos leszek:
Ha VALÓBAN tudták volna az iWiW-et tervező mérnökök, hogy mit csinálnak, akkor egy LDAP cluster köré építették volna a szoftvert. Persze relációs DB-t nem lehetett volna megúszni teljesen, de a teljesítménykritikus pontokon igen. Sőt, még olyan területeken nyertek volna egy komoly LDAP farmmal, amit így kézzel kellett megreszelni. (Csoportok kezelése - most fog jönni, valamint ismeretségi háló és még biztos jutna eszembe számos dolog erről...)
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

( ng | 2007. 03. 09., p – 18:47 )

Kicsinyebb koromban én is azt hittem elég egy kis chathez txt fájlokba tárolni az adatokat. Ment is a dolog úgy 20 felhasználóig, aztán jöttek az adatvesztések, iszonyatos lassulások. Ne találjuk fel újra a kereket - de ha lehetséges hogy jobb csapágyazást tudunk magunk készíteni, azzal helyezzük a tengelyre.. Vagyis néha inkább saját osztályokat érdemes készíteni a külsők helyett.