Vlákno názorů k článku Výkon databáze na různých souborových systémech od muf - Bývalo, v časech Informix-online, dobrým zvykem provozovat databáze...
-
muf (neregistrovaný)
Bývalo, v časech Informix-online, dobrým zvykem provozovat databáze na "raw devices." Každá lepší databáze to uměla a nejspíš pořád umí.
Nechápu, proč pořád ne Postgresql??
Hostovat data na běžném filesystému byla nouzovka, případně možnost pro šílence. Nevěřím, že od doby kdy jsem se tím zabýval, se tolik změnilo. -
Bob (neregistrovaný)
Jj presne.
Jinak nez pres raw device to nedelam a Informix na tom jen svisti. Vzhledem k tomu ze jsem byl nucen Informix spravovat na mixu OS jako AIX, Solaris i Linux, tak jsem to "nepouzivani" filesystemu ocenil mnohem vic, protoze ladit pro kazdy OS jeho vlastni FS by se mi fakt nechtelo.
Takhle clovek udela pro chunky znakove zarizeni na blokove (systemove) a neni treba nic dalsiho resit. -
muf (neregistrovaný)
IBM Informix pořád ještě vyvíjí nebo už spíš jen udržuje? Není o něm téměř slyšet...
Já ještě pamatuju časy existence samotné Informix Software a české pobočky v Prague City centre. Jó, to byly časy :-) Odtud někdy rovnou do pobočky Digitalu nebo HP......
Docela by mě zajímalo, jaký Informix db udělala od prodeje IBM pokrok a proč se o ní dnes už skoro neví. -
Bob (neregistrovaný)
Vyviji se a fest, IBM jej ma v main portfoliu a silne rozviji. Stavajici zakaznici Informixu totiz nebyli ochotni prejit k DB2, tak IBM nezbylo pred lety nic jineho, nez jej dal vyvijet, aby jim neutekli k Oracle.
Pravidelne se ucastnim CIDUG (Czech Informix & DB2 User Group) i za ucasti ceskych spicek Informixu jako pan Musil, Zahradnik atd. (ty jmena Ti asi neco budou rikat) :) -
muf (neregistrovaný)
:-) No jistě. Po tolika letech a pořád u té databáze jsou.... Vzpomněl jsem si na Musilův nechápavý výraz, když jsem se ho, kdysi v pravěku, ptal, jestli už Informix-online portují na Linux :) . "No možná, snad někdy, Standard Engine....," zněla odpověď.
Největší ikonou pro mě ale byl Zdeněk Mařík z Digitalu. Vlastně pořád je. Škoda, že už nemám možnost ho potkat. Po zrušení některých českých poboček naší firmy mě okolnosti odvály směrem k embedded systémům a zbyly jen ty vzpomínky :-/
-
Bob (neregistrovaný)
Dneska pochopitelne Informix je naportovany docela dlouho jak na Linux (osobne provozuji na RHEL 5,6 i 7), tak tusim MS (ale nastesti tohle peklo me v praci miji).
Rekl bych ze IBM dohnala co ztracela na Oracle pokud jde o "databazi", nastesti do toho necpe tolik sra*ek jako Oracle, Informix zustava hlavne databazi, vyuzivam v ramci enterprise edice i ruzne typy replikaci jak pro online backup, tak pro ruzne procesni veci, ja jsem spokojenej (pravda vyvojari by radi alespon materialized view co je v Oraclu). -
muf (neregistrovaný)
Můžu se zeptat pro koho pracujete?
Informix svého času masivně provozoval Český Telecom, ale pak od něj postupně upustili a co se tam dělo po prodeji Telefonice už nevím.... A byli pochopitelně i jiní zákazníci.
Třeba jsem se tam kdysi taky vyskytoval. Nedejbože, abych tam přímo školil adminy :-) -
Max Devaine (neregistrovaný)
Oracle to tak dělá. Máš dvě možnosti, mít datafile na klasickém FS, nebo je mít v ASM (Automatic Storage Management). Oraclu tedy předhodíš/vložíš do ASM RAW (disk/partition) a on se s tím už nějak popere.
ASM je u Oracle třeba nutnost pro použití RAC (více serverů, které mají společné uložiště/db data).
Oracle tedy preferuje ASM před použitím klasického FS. Jak na tom jsou jiní, to netuším.
Zdar Max -
muf (neregistrovaný)
Pořád to chápu v tehdejších mantinelech - nejde jen o rychlost, ale i o bezpečnost. Nemusel by se spoléhat na bezchybnost toho kterého souborového systému na různých platformách, vždy by to záleželo jen na něm, rozdíly platforem a souborových systémů by jej nemusely tolik zajímat, obešel by vyrovnávací paměti OS a dělal by to tak, jak je pro něj nejlepší.
Pochopitelně, že by to něco stálo v podobě implementace a údržby vlastních mechanismů. Nejspíš toto je ten důvod, proč se tomu vyhýbá, ač už zjevně, právem, pošilhává po pozici mezi "velkými" databázemi.
-
Režie FS bude pár procent - to nestojí za další kód, který samozřejmě může obsahovat další chyby (a to i bezpečnostní). U open source je docela dost dobře možné se spolehnout na bezpečnost základních komponent - taková Ext4 je prolezlá experty na bezpečnost skrz naskrz.
Navíc pro RAW musíte mít hromadu dalších nástrojů pro administraci - a i lidi, kteří by tu administraci dělali - porovnejte náročnost administrace Postgresu a Informixu.
Když už by se měl optimalizovat FS, tak proč ne správa virtuální paměti nebo scheduler, což jsou komponenty, které mají také podstatný vliv na výkon. Jsou určité hranice, za které se nevyplatí jít. Získáte pár procent výkonu, který potřebuje promile uživatelů za cenu napsání a odladění několika tisíc kriticky důležitých řádek. Když potřebujete výkon, tak je jednoduší škálovat horizontálně - zvlášť o open source, kde typicky náklady na instanci jsou 0.
-
jiný muf (neregistrovaný)
"rychlost souborových systémů šla výrazně nahoru"
Tohle mě vždycky fascinuje... Používáme výkonnější hardware, tak nám nevadí, že jeho výkon využíváme neefektivně a kilowatty pouštíme oknem kvůli neefektivním/zbytečným mezivrstvám ;-).
Pak vznikají takové věci jako Firefox. Většina lidí má velkou RAMku, tak nevadí, že v ní prohlížeč bobtná s každou nově otevřenou stránkou. Proč to napsat slušně a hlídat si korektní dealokace, když stačí, aby to uživatel jednou za 2 týdny zrestartoval nebo si koupil větší ram a restartoval po 3 týdnech...
Nebo máme výkonné stroje, tak nevadí, že 75 % výkonu sežere OS na animování menu a efekty průhledných terminálů apod.
-
j (neregistrovaný)
Sranda je o predevsim z uzivatelskyho pohledu - ma o 10 radu vykonejsi HW, ale ten word funguje porad stejne blbe a stejne pomalu, ne-li pomalejs nez kdy driv.
Tuhle sem instalil na soudobej HW win 98. Kvuli appce ktera jinak nez v tom proste nejede. A ty widle doslova litaly. Lepsi nez SSD.
-
Ale Pavel naopak poukazuje na to že výkon souborových systémů se natolik přiblížil RAW devices že už se prostě nevyplatí plýtvat silami na implementaci RAW devices. Kdyby se skutečně jednalo o desítky procent tak nepochybuji o tom že by se objevil např. nějaký fork PostgreSQL který by RAW devices uměl.
-
Zen (neregistrovaný)
Informix se prakticky nedal provozovat jinak nez na raw, proste neumel poradne pracovat s FS. Ten rozdil byl fakt brutalni - kdyz jsme to merili, tak na FS byl cca o 30% pomalejsi. U Oracle byl rozdil vyznamne mensi - nekde kolem 3-5%.
Ovsem prace s paw devices ma take vse musky. Kdyz je vicero rootu a jeden udela FS na raw device s primarni databazi ...
-
muf (neregistrovaný)
Zažil jsem i chunk omylem v oblasti disku, kde byl swap. Mašina měla na tehdejší dobu spoustu paměti, takže swapovala opravdu zřídka. Problém byl tedy zpočátku špatně reprodukovatelný. Velmi nepříjemná situace i když to způsobil admin zákazníka - my jsme ho školili...
Za to ovšem Informix ani raw device nemůže.
-
Ivan (neregistrovaný)
Jednak Postgresql ma trochu jinou filosofii. Nesnazi se duplikovat funkciolalitu kernelu tak jak to delaji "velke" databaze. Tablespace je adresar a tabulka je v jednou anebo vice souborech. Tam kde Oracle pouziva bitmapy/stromy/freelisty pro alokaci extentu tam Postgresql jednoduse vyuziva prostredku OS.
Navic dneska je pamet rychla a levna. Veskera metadata filesystemu ma kernel v cache, takze neni potreba kvuli nejake IO operaci donacitat metadata z disku. Ono je v podstate jedno jestli kernel sahne 5x anebo 20x do pameti metadat, kdyz musi provest jeden zapis na disk.
Vyhoda RAW devices uz neska neni tak velka. Dokonce se od toho upousti. Oracle 12c uz na "obycejne" raw devices nenainstalujete.
PS: raw devices maji jeste jeden side-efect. Na nekterych OS (treba na AIXu) operace na raw devices jsou automaticky v rezimu O_DIRECT, tzn. vsechno jde primo na disk a obchazi to buffer-cache kernelu. To muze byt vyhoda i nevyhoda.
-
Bob (neregistrovaný)
PS: raw devices maji jeste jeden side-efect. Na nekterych OS (treba na AIXu) operace na raw devices jsou automaticky v rezimu O_DIRECT, tzn. vsechno jde primo na disk a obchazi to buffer-cache kernelu. To muze byt vyhoda i nevyhoda.Tak AIX bude v drtive vetsine v korporatni sfere kde mate jine rozpocty na IT nez soukromnik s malymi projekty. Tim chci rict, ze "za tim AIXem" je vetsinou 8GB SAN, diskove pole s dostatecnou cache, SSD a SAS disky, kdy tiering resi ukladani dat dle cetnosti pristupu na rychlejsi/pomalejsi disky.
-
Trident (neregistrovaný)
Je to stale zvykem treba jeste u sybase,oraclu pokud si to admin zada a i ta pitoma MySQL to umi. Je to bezny enterprise setup. Dneska databaze i umi primo vyuzivat "raw ssd" disky v kombinaci s jinou raw storagi.
Pristup postgre nechapu. Prijde mi to jako takovy linuxismus. Zbytecne vrstveni a spolehani se na neco.
Vzdycky se smeju kdyz se linuxaci vytasi s Postgre+ext3/4+lvm a nedejboze k tomu jeste md. -
Dle mého osobního názoru to PostgreSQL nedělá v zásadě z následujících důvodů:
Zaprvé RAW devices vznikly v době kdy souborové systémy skutečně byly dost primitivní a výkon nic moc, ale od té doby došlo k celkem radikálnímů zlepšení. Srovnání která jsem viděl před pár lety dávaly RAW devices náskok maximálně pár jednotek procent, od té doby se rozdíl dál zmenšil. (Nepochybuji že lze zkonstruovat příklady kdy rozdíl bude značný i dnes, ale to jde skoro jistě i opačně.)
Zadruhé nepodléhám dojmu že implementace RAW devices je triviální - v zásadě to znamená zreplikovat celý stack souborového systému, a to pro všechny podporované platformy (kterých má PostgreSQL požehnaně). Vzhledem ke zmenšujícímu se rozdílu mezi RAW devices a souborovými systémy to není ekonomická volba - čas vývojářů se prostě lépe využije jinde.
Ale třeba se pletu.
