"A mentés/archiválás részét valószínüleg jogosan kérdezték."
A jelen megoldás sincs mentve vagy archiválva azon a módon, ahogy gondolod.
"Archiválás: 5 évig megőrzésből szokott következni olyan követelmény is, hogy olyan módon legyen tárolva, amit kifejezetten nehéz utólag módosítani-> offline adathordozón."
Az egyes Cassandra node-ok fájlrendszer szintű mentéséről és archiválásáról volt csak szó. Offline és read-only archiválás nincs.
"Backup: szintén kellhet (akár offline adathordozóra) backupolás, mert hiába replikált az adatbázis, ha van egy frontend szoftver/üzemeltetői hiba, az egész megy a levesbe. Kb "raid nem helyettesíti a backupot" elv."
NoSQL esetén egyébként a törlés a legköltségesebb művelet, nem is gyakori, hogy a törlést használják a felsőbb rétegben, inkább megmarad a régi adat is. Gyakori az is, hogy módosítások sincsenek, minden módosítás új sorként kerül letárolásra és a felsőbb szoftverréteg dolga a legfrissebbet használni, illetve a több módosítás összefésülése egy újabb sorrá. Nehéz olyan hibát ejteni, hogy mentésből kelljen visszaállítani bármit is, ha sikerült megérteni a működésmódot.
Ha nem sikerül megérteni a működésmódot, akkor fejlesztőt és üzemeltetőt kell cserélni.
"High-end storage, virtuális gépek: ez meg gondolom azért, mert saját datacenterben már bevezettek egy ilyen rendszert, ahol lehet live migrálni, illetve hoszt lehalás esetén van HA/auto-restart. Egyszerűen azt akarják, hogy minden szolgáltatás egységes módszerrel legyen kezelve, még akkor is ha valamelyikre teljesítmény vagy költséghatékonyság szepontjából nem a legoptimálisabb."
Az egész kérdéskör ebből indult ki. Egy high end storage esetén a többszörösen replikált 50TB igencsak drága dolog, ahogy a sok nagy méretű node virtualizációja és a mindenféle hardveres és alacsony szintű HA megoldása is drága. Nagyon drága.
A NoSQL rendszerek viszont nem erre a környezetre vannak kitalálva, hanem arra, hogy olcsó, egyszerű gépekre és szinte fájdalmasan egyszerű hardveres architektúrára kerülnek, mert a HA-t maga a NoSQL szoftver oldja meg. Felesleges a high-end replikált storage, felesleges a virtualizáció, felesleges a host migrálása... egy Casssandra cluster-t alapvetően úgy kell definiálni, hogy datacenter-rack-node, ha ebbe a topológiába beleszól egy virtualizációs szoftver automatikus mozgatása az nem csökkenti, hanem növeli az üzemeltetési kockázatot. Ha ebbe beleszól a high-end storage replikálása, az nem növeli, hanem csökkenti a teljesítményt.
A NoSQL nem csak a fejlesztőktől igényel homlokegyenest más gondolkodást, hanem az infrastruktúra üzemeltetőktől is, pláne őket nehéz arról meggyőzni, hogy a mindenféle drága játékszer használata helyett csak a fizikai vasakat kell cserélgetniük, mert szakmailag erősen visszaesésnek gondolják (és ez így van, de ez egy ilyen világ).
A PoC oka az OPEX csökkentési nyomás volt a felsővezetés irányából, és ezzel a lépéssel jelentős OPEX lett volna megtakarítható azonos, illetve néhány paraméter tekintetében magasabb funkcionalitás mellett:
- a teljes öt év kereshető online, nem kell megvárni az automatikus és a kézi visszatöltést szalagról
- a hardver cserén kívül közel zéró adminisztráció kell, nem igényel azonos hardvert, "ami éppen a polcon van" az jó
- leállás nélkül frissíthető
- igények szerint bővíthető és csökkenthető a cluster mérete
- nem igényel host szintű mentést
Azon külön csodálkozom, hogy azért is küzdeni kell (mind itt, mind akkor és ott), hogy nagy mennyiségű idősoros adatok tárolására kitalált elosztott adatbázist használjunk nagy mennyiségű idősoros adatok tárolására... :)