a Cassandra és más NoSQL adatbázisok perzisztenciájával kapcsolatos további információkért nézze meg, mi az a NoSQL?
a perzisztencia jelentésének megértése fontos a különböző adattároló rendszerek értékeléséhez. Tekintettel az adattárolás fontosságára a legtöbb modern alkalmazásban, a rosszul tájékozott választás jelentős leállást vagy adatvesztést jelenthet. Ebben a bejegyzésben megvitatjuk a perzisztencia és az adattárolás tervezési megközelítéseit, és némi hátteret adunk ezekről a Cassandra összefüggésében.
a perzisztencia “a hatás folytatása az ok eltávolítása után”. Az adatok számítógépes rendszerben történő tárolásával összefüggésben ez azt jelenti, hogy az adatok fennmaradnak, miután a létrehozott folyamat befejeződött. Más szavakkal, ahhoz, hogy egy adattár tartósnak tekinthető legyen, a nem felejtő tárolóba kell írnia.
ha kitartásra van szüksége az adattárban, akkor meg kell értenie azt a négy man tervezési megközelítést is, amelyet egy adattár alkalmazhat, és hogyan (vagy ha) ezek a tervek biztosítják a kitartást:
-
tiszta memória, egyáltalán nincs kitartás, például memcaches vagy Scalaris
-
in-memory periodikus pillanatképek, mint például az Oracle koherencia vagy Redis
-
lemez alapú frissítés-in-place írások, mint például a MySQL ISAM vagy MongoDB
-
Commitlog-alapú, mint például az összes hagyományos OLTP adatbázis (Oracle, SQL Server stb.)
a memóriában lévő megközelítések lángoló sebességet érhetnek el, de annak árán, hogy viszonylag kis adatkészletre korlátozódnak. A legtöbb munkaterhelés viszonylag kicsi “forró” (aktív) részhalmaza a teljes adatnak; azok a rendszerek, amelyek megkövetelik, hogy az egész datset illeszkedjen a memóriába, nem csak az aktív rész, rendben vannak a gyorsítótárak számára, de a legtöbb más alkalmazáshoz rosszul illeszkednek. Mivel az adatok csak a memóriában vannak, nem fogják túlélni a folyamat befejezését. Ezért az ilyen típusú adattárolók nem tekinthetők tartósnak.
a memóriában lévő rendszerhez a perzisztencia hozzáadásának legegyszerűbb módja a periodikus pillanatképek lemezre konfigurálható időközönként. Így elveszítheti az adott intervallum értékű frissítéseket.
az Update-in-place és a commitlog alapú rendszerek azonnal tárolódnak a nem felejtő memóriába, de csak a commitlog alapú perzisztencia biztosítja a tartósságot-a D in ACID-minden írás fennmarad, mielőtt a siker visszatér az ügyfélhez.
a Cassandra megvalósítja a commit-log alapú perzisztencia tervezést, ugyanakkor beállítható tartósságot biztosít. Ez lehetővé teszi, hogy eldöntse, mi a megfelelő kompromisszum a biztonság és a teljesítmény között. Választhat, hogy minden írási művelethez megvárja, amíg a frissítés pufferelésre kerül a memóriába, lemezre írható egyetlen gépen, lemezre írható több gépen, vagy akár lemezre írható több gépen különböző adatközpontokban. Vagy, dönthet úgy, hogy elfogadja az írásokat a lehető leggyorsabban, nyugtázva azok átvételét közvetlenül azelőtt, hogy még teljesen dezerializálták volna őket a hálózatról.
a nap végén, te vagy az egyetlen, aki tudja, mi a megfelelő teljesítmény/tartósság trade off az adatokat. Az adattárolási technológiákkal kapcsolatos tájékozott döntés meghozatala kritikus fontosságú ahhoz, hogy ezt a kompromisszumot az Ön feltételei szerint kezelje. Mivel a Cassandra ilyen hangolhatóságot biztosít, logikus választás azoknak a rendszereknek, amelyeknek tartós, hatékony adattárolásra van szükségük.