Názory k článku Výkon databáze na různých souborových systémech
-
V oboru databází jsem naprostý laik, takže se rád nechám poučit. Představoval jsem si (možná naivně), že integritu dat, zápisů a transakcí řeší samotná databáze a na garance na úrovni souborového systému de facto nespoléhá, neboli v tomto konkrétním případě má smysl používat systém, který je co nejjednodušší a nejrychlejší?
-
Databáze zajišťuje datovou integritu (jako cizí klíče, unique, etc). Jenže pak se musí toto všechno reálně zapamatovat.
Představte si klasickou transakci. Když dáte commit, tak tak nějak očekáváte, že tam ty data opravdu budou. Ne, že zmizí, protože někdo vypnul počítač dřív, než db engine stihl zapsat data na disk, nebo než se provedl sync.
Samozřejmě, vždycky je tam nějaká důvěra, db věří, že když skončí sync, tak že data jsou zapsaná. sync věří, že když mu FS řekne ok, tak že jsou zapsaná. FS věří, že když zapíše data, tak že se ty data opravdu propíšou na plotnu. A nakonce všichni věří, že někdo neflákne do hdd kladivem.
-
Pokud by filesystém negarantoval bezpečný zápis, tak databáze sama nezmůže nic ohledně bezpečnosti dat. Navíc zapsat data bezpečně na médium je dost pomalá operace, takže ACID databáze se snaží optimalizovat zápis - a to jak minimalizací random IO operací, tak minimalizací operací fsync (čekání na zápis na médium). Design ACID databází předpokládá hloupý FS (v 90letech žádné jiné běžně nebyly k dispozici), od kterého se nechce nic jiného než spolehlivě číst a zapisovat data do souborů (a pokud možno stabilně co nejrychleji). Což je pravděpodobně ten důvod, proč v Tomášových benchmarcích jsou ext4 a XFSko výrazně lepší než COW filesystémy, které se trochu s tím, co dělají databáze, překrývají. A tudíž jednodušší (rychlejší) je lepší (pokud je možné se na něj spolehnout).
-
b.f.u (neregistrovaný)
to je pěkná blbost. stačí sebemenší chyba diletantského programátora (což je u her naprosto běžný čas především kvůli šíleným termínům) a rozesere to i data cizích aplikaci (potažmo i samotný HW na němž to běží).
nicméně mi to připomělo závěr jisté povídky se Score (už nevim jak se to jmenovalo) od Andreje: "Brain boot sector failed" :D
-
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.
-
Prosím o odkaz na oficiální dokumentaci Intelu kde se doporučuje nepoužívat TRIM.
Ve specifikaci k S3700 o tom není ani zmínka (http://download.intel.com/support/ssdc/hpssd/sb/Intel_SSD_DC_S3700_Product_specification.pdf).
-
Kolemjdouci (neregistrovaný)
https://downloadmirror.intel.com/23929/eng/Intel_Linux_NVMe_Driver_Reference_Guide_330602-002.pdf
Filesystem Recommendations
IMPORTANT:
Do not discard blocks in filesystem usage.
Be sure to turn off the discard option when making your Linux filesystem.
You want to allow the SSD manage blocks and its activity between the NVM (non-volatile memory) and host with more advanced and consistent approaches in the SSD Controller.
Core Filesystems:
•ext4 – the default extended option is not to discard blocks at filesystem make time, retain this, and do not add the “discard” extended option as some information will tell you to do.
•xfs – with mkfs.xfs,add the –K option so that you do not discard blocks. -
Jan Schermer (neregistrovaný)
No offense, ale to je tedy benchmark...
1) nobarrier zapne jenom sebevrah (neverte pohadkam o konzistenci s persistentni write cache) - navic to s Intel S3700 ani neni potreba, protoze cache je zalohovana a flush se vicement ignoruje.
2) discard je uplne zbytecny a zpomaluje vsechny zapisy - porovnavat filesystem s discard a bez discard je uplne k nicemu
S3700 je velice dobre SSD, tim se tyto problemy trochu smazou, ale vezmete cokoliv jineho a vysledky budou _dost_ jine
3) Na zacatku prezentace se zminuje alignment na SSD, ale uz neni receno jaky teda pro ten benchmark byl
4) jak se vytvarely filesystemy? Jake jsou completni pouzite mount options (neni default jako default).
4) kde je graf CPU a IO po dobu tech benchmarku? Bez nich chybi podstatna cast pohadky...
-
ByCzech (neregistrovaný)
2) discard je uplne zbytecny a zpomaluje vsechny zapisy - porovnavat filesystem s discard a bez discard je uplne k nicemu
U nového PRÁZDNÉHO disku možná, ale u když už disk nemá prostor kde zapisovat do nepoužitých oblastí, tak je provedení trimu (i jednorázově) jako injekce adrenalinu.
-
Jan Schermer (neregistrovaný)
U opravdu levnych SSD pomuze obcas udelat fstrim. Snad na nich ale nikdo neprovozuje databaze - jejich vykon je v tomhle smeru klidne nizsi nez u obyc disku.
U modernich SSD, zvlast tech urcenych do serveru (DC rada Intel, Samsung...) fstrim vykonu nepomuze vubec a zivotnosti take spis marginalne (a az na konci zivota tech SSD). Dulezite to muze byt ve chvili, kdy potrebuju aby disk s 3 DWPD ratingem prezil o neco vic.
Discard a fstrim je ale neco jineho, a discard zapinat je jednoznacne kontraproduktivni.
-
Jan Schermer (neregistrovaný)
Pokud je ten NCQ Trim opravdu funkcni (co je to za SSD?) tak se nebude blokovat jine IO po dobu discardu a o vykon neprijdete - ja jsem takove SSD ale zatim v ruce nemel a ani jsem nevidel/nehledal benchmarky. Nulovy overhead tam nebude, ale v realu to bude opravdu neviditelne.
Ano, pak ma cenu discard pouzivat misto fstrim - ja ale radeji jeste chvili pockam aby mi to kvuli nejake chybe tise nesezralo data.
-
1) nobarrier
Prosím o nějaké odkazy nebo reference s informacemi - vždycky slyším akorát výkřiky jak je to špatně, ale žádné relevantní informace které by usvědčovaly nobarrier jsem zatím neviděl.
Tvrzení že nobarrier na S3700 není potřeba (protože se stejně ignoruje) mi nedává smysl, protože vypnutím write barrier (tj. použitím nobarrier při mountu) vzroste výkon o ~30%. Což naznačuje že ono to s tím ignorováním nebude až tak úplně pravda.
2) discard
Pokud tvrdíte že TRIM zpomaluje všechny zápisy, bylo by fajn doložit to nějakými daty. V testech které jsem dělal já je dopad TRIM zanedbatelný - víceméně plus/minus 1% (alespoň na EXT4 a XFS). Takže jaké zpomalení?
To že na různých SSD může být dopad různý - moje hypotéza je že to závisí mimo jiné na množství volného místa (ať už nevyužité místo na fs nebo overprovisioning od výrobce). Provedené benchmarky pracovaly s relativně malým objemem dat (vzhledem ke kapacitě disků) a moje očekávání je že při zaplnění bude mít TRIM větší význam (plánuji to otestovat).
To že na nekvalitních consumer-level SSD se TRIM chová divně mne nijak nevzrušuje protože na OLTP databázi bych je nepoužil.
3,4) alignment, mount options apod.
Veškerá data jsou tady: https://bitbucket.org/tvondra/fsbench-i5
Je to trochu hromada, ale v každém adresáři by měly být informace o alignmentu i mkfs volbách. Je fakt že "default" znamená různé věci podle kernelu, v tomto případě to znamená "jako ve 4.0.4 na gentoo".
5) CPU a I/O
Tohle nemám (ano, není to ideální) nicméně obecně platí že kromě small a medium r/o benchmarků je všechno I/O bound. V dalších testech napravím a mám v plánu sbírat i další metriky.
-
Jan Schermer (neregistrovaný)
Diky za reakce.
1) nobarrier (mimochodem, barriery uz nikde nejsou, dokonce ani v RHEL6 kde je odstranili tusim pocatkem 2014, dnes je to FUA/explicit flush).
Primou referenci nemam, ale v SSD se velice intenzivne hrabu posledniho pul roku (benchmarky, chovani pri vypnuti za chodu, TRIM).
U nobarrier jsem dospel k nazoru, ze si nikdo neni jisty jestli to je 100% bezpecne - prosel jsem hromadu diskuzi na mailing listech (xfs, ext4, lkml) a udelal par vlastnich testu ze kterych jsem nezjistil v zasade nic. Nejzajimavejsi debata byla tusim kolem ext4 option journal_checksum - obcas se jeste divim ze mam data.Ano, vetsinou to funguje a i vendori databazi (treba Oracle) tvrdi ze se muzou barriers vypnout, jenze ty databaze si taky resi dost veci samy pres O_DIRECT* a filesystem je jim sumak. Ono totiz nejde jen o to, jestli disk flushne data z cache (to nas u S3700 netrapi), ale hlavne o to, ze bez barier neni zarucene poradi tech operaci co tam posila OS. A zatimco s barierami se o poradi stara pagecache/scheduler, tak bez barier za to neruci vlastne nikdo.
"Dokazat" ze se to chova nebo nechova jak ma je temer nemozne - je potreba vyrobit IO pattern a k tomu odpojit napajeni, a i kdyz to udelate 1000x bez problemu tak to neznamena jistotu. Me se nepovedlo rozbit filesystem bez barier ani na disku ktery zalohovanou writecache nema (nutno podotknout ze to byl dost podivny SSD disk...), protoze vyrobit takovy IO pattern bylo moc prace. Jednim procesem v jednom threadu (nebo databazi, ktera ma jako bottleneck jeden transakcni log) se to hned nerozbije.Navic to, ze vypnuti barrier zrychli IO, muze byt krasnym dokladem ze jsou potreba** - S3700 rozhodne nepise data z writecache pri kazde bariere, ale zaroven je to s nimi pomalejsi - proc? Mimochodem tohle zrovna dost zavisi i na radici (zkuste LSI a XFS a bude to nejspis pomalejsi, a to i v IT rezimu kdy to ma byt jenom hloupy adapter. A taky nemusi fungovat spravne TRIM...).
Efekt barier se nejlepe testuje (tedy spis netestuje) pres FIO a je to velika divocina protoze IO muze hnit nekde v kernelu 5ms aniz by disk neco delal, a jiny filesystem to delat nebude nebo bude jindy.
(to je ale na jinou debatu, pokud vas to zajima tak si muzeme nekde pokecat mimo Roota).* mimochodem O_DIRECT si hodne lidi vyklada jako synchroni blokujici operaci ale tahle zaruka v linuxu take neni - v praxi se to tak chova a nikdo to neresi.
** nemusi to byt diskem ale radicem, ktery nestiha tolik IO operaci . V pripade barrier jich tam tece proste vic (napriklad 2x tolik kdyz se testuje pres fio) a samotny pocet saturuje CPU radice. U 4KiB IO se to nepozna protoze tech ~140K IO operaci (=550MB/s) to pro benchmark da, jenze bariera je NOOP a hned je jich 280K... Da se pak rict, ze je pomala bariera?
2) mkfs defaultne dela TRIM celeho block device, filesystem pri prepisu souboru alokuje pouze nove (clean) bloky takze neni co TRIMovat. Jenze zkuste ten filesystem zaplnit a pak se zapnutym discardem psat do tablespace - zpomali se to zasadne.
Zalezet bude ale take na velikosti IO operace, protoze ne kazda spusti discard.Starsi data zde:
http://people.redhat.com/lczerner/discard/ext4_discard.html(dnes to bude o neco rychlejsi protoze disky podporuji NCQ/TRIM - pokud tedy mate spravny firmware, jinak vam to ani sezere data :))
3,4) diky - je videt ze jste na to myslel. Erase block size bude IMO mnohem vetsi nez 1MB, ale v realu je to uplne jedno.
5) takovy tip - zkuste sar. Na ad-hoc veci to uplne staci (a defaultne je to casto zapnute a nikdo o tom nevi).
Par zajimavosti co si muzete zkusit (a pak premyslet wtf, dopredu nelze rict co to udela a na cem to zavisi)
1) pouzit cfq scheduler s rotational=1 na SSD disku - nektere benchmarky vyjdou lepe :-) proc?
2) vypnout write cache na disku - nektere veci budou paradoxne rychlejsi
3) vyrobit RAID 1 na jednom disku - na starem kernelu to bude rychlejsi (a s nekterymi disky...)
4) pohrat si s rq_affinity scheduleru
5) predalokovat (zero, ne fallocate, pokud databaze umi) misto pro tablespace -
Ivan (neregistrovaný)Vykon v tomhle pripade neni jediny rozdil. Vykonostni rozdil je par procent a to uz dneska nikoho nezajima. Dalsi rozdil je v
- "Manageability", tzn. jake dalsi administracni prostredky vam to poskytne. A naopak jake nastroje uz nemuzete pouzit. Napr. potrebujete vlastni monitoring volneho mista
- "Specialni pripady", tzn. jak se to bude chovat pri velke zatezi, vypadku jednoho z disku apod.
To co je lepsi, to se da tezko rozhodnout. Dneska bych ale mozna vice veril filesystemum, Oracle ASM melo (alespon z pocatku) ruzne divne neduhy.
-
gustopn (neregistrovaný)
pokal som to dobre pochopil, tak tie testy boli robene na Linuxe, no a potom, ze ZFS na Linuxe sklamal, tak to neni nist nove. ZFS je ale dobre podporovana na FreeBSD, tam by som skor isol.
a potom HAMMER FS ma pod DragonflyBSD nejake tie PostgreSQL optimalizacie.
ten by som vyskusal ako druhy, a ne BTRFS.
Linux a XFS a EXT4 nie je ziadne prekvapenie, ze prave to dobre islo. to je ako oznamenie, ze windows spolupracuje dobre s NTFS, to setci vieme.
ČLÁNKY DO MAILU