Dotaz: ktoru databazu?

[disposable]

Potrebujem pomoc s vyberom databazoveho systemu pre nasledovne - mam jednu tabulku, ktora vyzera takto:

phone - phoneservice0207xxxxxxx - 0207xxxxxxx@customername.sip.ourdomain.net

0207yyyyyyy - 0207yyyyyyy@othercustomer.sip.ourdomain.net

.

.

. .

celkovo ma 4 miliony riadkov a je to databaza aliasov pre OpenSER.

mam nasledovne poziadavky:

- databaza musi zvladnut az 30 000 READS behom jednej sekundy

- co sa tyka updatov, tie budu velmi zriedkave, na tie nemam ziadne poziadavky

a teraz otazky:

Zvladne toto MySQL s InnoDB? nemal by som radsej pouzit nejaku BerkeleyDB?

pobezi to na 4 jadrovom Xeone, 16GB RAM. RAID-5 uscsi 320. Viem ze to budem musiet aj otestovat, teda neocakavam odpoved po ktorej sa do toho vrhnem, staci nasmerovanie od ludi so skusenostami.

Odpovědi

[Martin Tůma]

Použil bych klidně MySQL ale s MyISAM, protože dle dostupných informací je MyISAM při takovýchto tabulkách mnohem rychlejší. Vlastnosti, který přináší InnoDB oproti MyISAM (např. transakce) při plánovaném využití nepotřebuješ.

[Zdeněk Burda]

A co zkusit zauvažovat nad adresářovým serverem?

[disposable]

no, kedze o berkeleydb neviem skoro nic, tak jedina implementacia ktora ma napadla by bol openldap. ale nevyguglil som ziadne porovnanie rychlosti ktore by bralo do uvahy viac nez 10.000 entries a uz vobec nic kde by niekto potreboval 30K pristupov za sekundu. mate podobnu skusenost?

[Roman DAVID]

IMHO je BerkeleyDB urcena presne pro Vas pripad -> jednoducha struktura DB, hodne selectu, malo insertu

[disposable]

vyzera to tak. tu ide skor o to, ze o berkeleydb neviem absolutne nic, teda otazka je skor polozena ci to mysql zvladne, alebo sa musim pustit do technologie ktoru nepoznam (proti comu nemam namietky, ale rad by som sa tomu vyhol ak mozem). v mysql sa viem aspon orientovat, aj ked niesom profesionalny dbadmin.

mam este tyzden kym to budem musiet implementovat, takze dost casu sa zorientovat, spustit 24 hodinovy test a porovnavat.

[razor]

Ahoj, možná by tě mohlo zajímat, že ve starších verzích mysql se dá použít jako storage engine právě berkleydb.

[AraxoN]

Ak tie updaty budú naozaj veľmi zriedkavé, ak tá databáza bude obsahovať naozaj len to čo si tu napísal a ak sa k nej bude pristupovať podľa celého kľúča, nie podľa LIKE, tak by som zvážil DB4. Len tak zo srandy som teraz skúsil v PHP vyrobiť skript, ktorý zapíše 4 mil. záznamov a ďalší, ktorý potom 30 tis. prečíta. Na notebooku Celeron 1.3, 768MB RAM, trvalo čítanie 30 tisíc záznamov 0.712 sekundy.

[disposable]

dakujem za ten test, aj ked si niesom isty ci je relevantny, kedze tych 30K reads nebude v jednej operacii, ale v 30K osobitnych. db4 je berkeleydb, nie? mohol by si mi prosim poslat ten skript nech sa nieco naucim?

[AraxoN]

Přílohy:

• db4_write.php (463 bytů)
• db4_read.php (490 bytů)

Viď prílohy.

[AraxoN]

Alebo ak to má byť SQL, tak na výbery (30k za sekundu) použiť medzičlánok memcached, tak aby sa do databázy liezlo až vtedy, keď výsledok nebude v cache.

[disposable]

dik ale to nebude treba. zatial vzdy ked som dobre nakonfiguroval dbms a velkost databazy bola mensia nez RAM, aj tak skoncila cela DB v ramke. a tato tabulka bude mat menej nez pol gigabajtu.

[core]

Co takhle CDB? i kdyz to neni moc databaze :) A proc RAID-5 - na databazi bych dal radsi RAID-10, i kdyz to asi bude vetsinout nacachovane v ramce..

[disposable]

jednoduchost tej CDB sa mi velmi paci, licencia je humus, uz stahujem freecdb a idem sa pohrat. a raid5 preto, lebo mam len 3 disky.

[antiVISTA]

No to je fajn, vela sa uz popisalo o "rychlosti databaz", mna by skor zaujimalo, ako by to bolo rychle s PostgreSQL. Povedzme najnovsia verzia na Freebsd a intel quad core, 8 GB RAM a SATA RAID 1 (mirroring). Uznavam, ze to bude asi tazke posudit...

[AraxoN]

Nemám síce na notebooku quad core ani raid1, ale dal som sa do testovania. Možno to večer ešte skúsim na nejakom lepšom produkčnom serveri...

Moje výsledky pre Postgres nevychádzajú príliš priaznivo - 4M záznamov, 30k náhodných čítaní, podľa jednotlivých druhov databáz, resp. úložísk:

BerkleyDB (db4) - 0.699s
memcached       - 2.585s
MySQL (MyISAM)  - 7.124s
sqlite          - 20.448s
PostgreSQL      - 96.241s

Z môjho pohľadu veľmi príjemne prekvapil db4 a MySQL, naopak Postgres a memcache boli značným sklamaním.

[antiVISTA]

Fuuuu, no az taky debakel som teda u Pg necakal. Velka vdaka.

[AraxoN]

Možno to chce vytunovať nejaké parametre, aj keď ten MySQL to zvládol v default inštalácii. Pravdepodobne bude zlý výsledok postgresu zapríčinený malou RAM na disk cache - keď som pozeral, tak v MySQL tabuľka zabrala nejakých 230MB, zatiaľčo v postgresi asi 300 + 150 index. Tým pádom sa celý súbor nevošiel do pamäte a mnoho času strávil čakaním na disk. Neviem prečo to zaberalo tak veľa, púšťal som na to aj VACUUM, ale bez výsledku.

[AraxoN]

Tak som to teraz testol ešte na inej mašine (Core2 Duo 2.66GHz, 64bit, 4GB RAM, RAID1), a výsledky sú:

BerkleyDB (db4) - 0.494s
sqlite          - 1.537s
MySQL (MyISAM)  - 2.002s
PostgreSQL      - 4.997s
memcached       - masked pre 64bit, t.j. netestované

T.j. nie až taký debakel, aj keď postgres z toho aj tak zvlášť dobre nevychádza. Na druhej strane, používame ho a ceníme si ho nie preto, že vie slúžiť ako rýchla hash-tabuľka, ale preto, že má aj nejaké tie funkcie naviac...

[fixinko]

bola ta databaza v pgsql vhodne oindexovana?

[AraxoN]

araxon=# \d speed_test
       Table "public.speed_test"
 Column |       Type        | Modifiers 
--------+-------------------+-----------
 num    | character(7)      | not null
 val    | character varying | not null
Indexes:
    "speed_test_pkey" PRIMARY KEY, btree (num)

Po inserte všetkých riadkov som ešte spravil VACUUM ANALYZE. Problém bol asi v tom, že súbor s databázou a indexom bol väčší než voľná RAM a tak sa do diskovej cache celý nezmestil - narozdiel od všetkých ostatných DB čo som skúšal. Je pravda, že miesto char som mohol použiť radšej numeric, ale char som použil aj vo všetkých ostatných DB...

[Radim Kolář]

Testnul jsem to na DB2 Express-C 9.5.1/linux ia32 a na stroji s 512MB RAM a jednim diskem dela 3263 random selectu/sec v default nastaveni databaze, coz je 4MB io buffer, takze je to CPU bound a vsechen CPU cas je pozran v sys time.

Vysledny cas je 9.1s. Vysledek plne srovnatelny s MySQL/ISAM a je to podnikova databaze (toho casu zdarma).

Oracle je o chlup pomalejsi nez Pgsql v tehlech workloadech, ale na tomhle stroji s 512mb ram by mne nebezel, takze jsem ho netestil.

zajimala by mne mysql/innodb

[AraxoN]

MySQL (MyISAM)  - 7.124s
MySQL (InnoDB)  - 9.293s

Rozdiel nijak zvlášť veľký... ale trvalo mi hodnú chvíľu, kým som to na InnoDB vôbec rozbehol. Defaultne je to nastavené tak, že InnoDB zaberá max. 128M a riadky, ktoré sa tam nezmestia majú proste smolu. Navyše pri OPTIMIZE TABLE to potrebuje ďalší priestor, lebo inak optimize zlyhá a rýchlosť výberu je potom nič moc. A ešte pri insertovaní v rámci transakcie som pozeral z druhej transakcie na počet riadkov, a ten sa priebežne menil - to by som nenazýval "transaction isolation". V postgrese toto chodilo predvídateľnejšie - kým som nedal commit, tak som videl počet riadkov nula...

[Ladicek]

pri insertovaní v rámci transakcie som pozeral z druhej transakcie na počet riadkov, a ten sa priebežne menil - to by som nenazýval "transaction isolation"

Tak buďto to nebyla transakce (autocommit), nebo jste měl isolation level nastavený na read uncommitted, to se stává i v lepších rodinách