A történet teljességéhez azért hozzátartozik, hogy az iodepth=1 egy nagyon speciális használati eset. Ez gyakorlatilag tisztán a latency-t méri, nem az áteresztőképességet. Nyilván, ha meg kell mutatni, hogy miben jobb az Optane egy NAND alapú SSD-nél, akkor ezt érdemes elővenni.
A legtöbb gyakorlati alkalmazásnál (főleg szerveren) egyidejűleg több művelet is lesz folyamatban és a NAND-alapú SSD-k elég jól tudják kezelni a párhuzamosan zajló műveleteket. A latency akkor számít, ha minden írásművelet után azonnal barrier van (valami patologikus journal használat és/vagy nagyon buta tranzakciókezelés miatt). Nem állítom, hogy nem fordulhat elő ilyen DB-nél, de nem ez a tipikus. Szarul megírt alkalmazás persze bármilyen hardvert és DB engine-t képes kétvállra fektetni :)
"Illetve akkor az nem világos nekem, egy konzumer ssd pl. samsung evo 860 / 870 csak a dram kess telítésig gyors? Utána leesik annak a sebessége is ilyen 5-10 MB/sec-re?"
Nem, a DRAM cache valójában nagyon pici az SSD méretéhez képest, és írásnál user adat pufferelésre nem is nagyon merik használni a PLP nélküli drive-okban. Pár perc nagyon intenzív random write után a desktop SSD-k teljesítmény visszaesése két fő okra vezethető vissza (benchmark grafikonon általában két külön töréspont látszik):
- Az SLC cache megtelése. Az üres flash-t gyorsan felzabálja, ha cellánként 1 bites módban írják, ezért a kontroller idővel el kell kezdje az SLC-s blokkokat TLC vagy QLC-re összepakolni. Ez jellemzően az SSD üres kapacitásának negyede-harmadánál üt be.
- A blokk-fragmentáció miatti garbage collection. Ez jellemzően nagyon hamar, az első pártíz GB írása után beüt. A flash erase blokkja sokkal nagyobb (16+MB), mint a logikai blokk (512byte vagy 4kB), fizikailag felülírni flash-t nem lehet, csak erase blokkot egyben törölni és az egészet újraírni. De az SSD vezérlőnek úgy kell tennie a host fele, mintha kis blokkokat tudna felülírni. Ilyenkor a kontroller annyit tud tenni, hogy a régi adatot meghagyja az eredeti helyen (mert óriási blokkot kéne törölni és újraírni). Egy új helyre (tipkusan valami journal-szerű sorfolytonos naplóba) bekerül a felülírt a blokknak frissebb tartalma. Ehhez extra hely kell és ez idővel kifogy. Ilyenkor a kontroller kénytelen garbage collectolni, a régen megírt, már sok elavult adatot tartalmazó erase blokkot törölni és a naplóból friss adatokkal berendezve újraírni. A garbage collection stratégia a desktop és az enterprise SSD-k között nagyon eltérő. A desktop SSD-k végletekig halogatják a garbage collection-t, hogy a csúcsteljesítmény szép nagy szám legyen. Viszont ha már muszáj, akkor nagyon lelassulnak. A szerver SSD-k meg igyekeznek transzparensen folyamatosan csinálni, így a csúcsteljesítményük kisebb lesz, de legalább azt konstans tudják tartani akármennyi ideig.