Erősen feladatfüggő.
Az előző munkahelyemen vagy egy üzleti naplózás, amelybe naponta 10-15 millió bejegyzés kerül, amelyet meg kell őrizni 5 évig. Ez napi 30GB lazán struktúrált adatot jelent az öt évre ez nagyjából 50TB. Erre van egy jól bejáratott IBM-es stack, ami szerint a naplóbejegyzés MQ-n kerül bejegyzésre, ez replikált és perzisztált, innen dolgozódik be egy DB2 adatbázisba, amely szintén replikált, majd 5-10 nap után kikerül archiválásra TSM-be. Na, mindez csillagászati áron van...
Nyáron utolsó munkámként csináltam egy PoC-ot Cassandra alapokon, ahol is virtualizált környezetben egy cloud szolgáltatónál három datacenter-be tettem két-két rack-be három-három Cassandra node-ot (vagyis volt összesen 3*2*3 node, azaz 18 node) és WildFly node-ot, szépen bekonfiguráltam, és csináltam egy néhány órás tesztet kb. két tucat dollárért ($0.5/óra/gép a DO-nál). Annyi változott, hogy online elérhető volt minimális válaszidőkkel a teljes (generált) 1TB adathalmaz... de a Cassandra lineárisan skálázható, nem igényel különösebb karbantartást, nem igényel mentést, se archiválást és olcsó gép is elég neki olcsó storage-al, mert könnyen cserélhető egy döglött node.
Aztán nem lett belőle semmi, mert egyrészt az üzemeltetésen nem értették meg az elosztott adatbázis kezelés lényegét: mindenáron high end storage-t tettek volna alá virtualizált gépekkel és folyton a mentést meg az archiválást kérdezték... másrészt meg nem éreztem késztetést arra, hogy jól elmagyarázzam a Cassandra alapelveit és működésmódját, mert már igencsak eljöttem volna onnan... :)
Szóval lehet jó dolgokra használni, de például egy számlavezető rendszert nem lehet ilyesmire tenni... van viszont egy csomó lehetőség, amelyre sokkal jobban használható a NoSQL, mint az SQL.