Apache kondigt nosql-database Cassandra 1.0 aan

De Apache Software Foundation heeft de 1.0-release van Cassandra aangekondigd. Deze gedistribueerde nosql-database werd oorspronkelijk ontwikkeld door Facebook en wordt al door veel grote internetbedrijven gebruikt.

Cassandra is een schaalbare, gedistribueerde nosql-database die ontwikkeld is om op grote clusters van servers te draaien zonder al teveel resources op te snoepen. Het grootste cluster waar de database momenteel op draait zou 300 servers omvatten en meer dan 300TB data bevatten. De databases zouden 5000 requests per seconde per servercore kunnen afhandelen. De snelheidswinst van de nieuwe versie 1.0 ten opzichte van de 0.6-versie van vorig jaar zou bij schrijfsnelheden 40 procent bedragen en bij leessnelheden maar liefst 400 procent.

Volgens Jonathan Ellis, president van Apache Cassandra, is de betrouwbaarheid van de Cassandra nosql-database een van de krachten en dit zou geïllustreerd worden door de hoeveelheid internet- en ict-bedrijven die er al gebruik van maken, zoals Cisco, RackSpace, Reddit en Twitter. Cassandra 1.0 wordt beschikbaar gesteld onder de Apache License v2.0. De database is in 2008 ontwikkeld door Facebook maar werd een jaar later onder de hoede van de Apache Software Foundation gebracht.

Reacties (38)

[badboyqxy]

betekend dit dat in toekomste webservers mysql uit gefaceerd gaat worden?

[Rob Coops]

Nee absoluut niet

Dit is een NoSQL database waar je dus zo als de naam al zegt geen SQL gebruikt om mee te kletsen. Het is een database die geen relaties kent en in dat op zicht goed te vergelijken is met bijvoorbeeld BerkelyDB of een Google BigTable. BerkelyDB bestaat al in ieder geval al vele tien tallen jaren. Het voordeel van dit soort systemen is omdat je geen relaties hebt en omdat je vrijwel geen indexes hebt (veel al maar 1per table op 1 column) dat deze dingen belachelijk snel zijn in het vinden van data (onder voorbehoud dat je natuurlijk wel de indexed column gebruikt om de data te vinden)

Een SQL en dus normaal gesproken relationele database heeft als voordeel dat je relaties kunt leggen tussen tabellen en op die manier bijvoorbeeld een veel "mooiere" weergave kunt maken van je data structuur. Je kunt data groeperen en veel makkelijker dingen als normalisatie toe passen.

Juist dankzij deze relaties, je kunt bijvoorbeeld een tabel met munt eenheden maken en een tabel met landen en deze vervolgens linken aan elkaar zodat je als de Euro in 15 landen wordt gebruikt je maar 1x euro en alle bijbehorende data hoeft weg te schrijven.
Een NoSQL database daar in tegen zal eerder een tabel bevatten met alle landen en hun munt eenheid met alle gegevens en dus schrijf je Euro niet 1 maar wel 15x in de database.

Om die reden zie je ook dat vrijwel alle bedrijven die NoSQL databases gebruiken ook SQL databases gebruiken om op die manier het beste uit beide werelden te hebben. NoSQL is belachelijk snel zeker met hele grote data sets. Maar SQL is zo veel handiger met complexe data waar je vele relaties hebt maar relatief weinig data.

De simpelste regel die je kunt opstellen is een SQL database waar je tabellen hebt met enkele miljoenen records is nog te doen. Als je naar de tientallen miljoenen records gaat dan moet je serieus gaan kijken naar een NoSQL database omdat deze simpel weg veel beter werkt met dat soort hoeveelheden data.
Je moet niet vergeten dat de wereld van SQL en NoSQL heel erg anders zijn en dat de developers niet even binnen een paar minuten over kunnen stappen omdat alles voor mensen die jaren lang om de oren geslagen zijn met SQL erg vreemd lijkt.

Om je een goed voorbeeld te geven van waar Cisco bijvoorbeeld NoSQL voor gebruikt, denk aan DHCP servers met tientallen miljoenen leases en alleen een MAC om de juiste record te vinden.
Facebook gebruikt dit voor het identificeren van waar data te vinden is voor die gebruiker. De data zelf staat in SQL databases, maar welke van de vele duizenden databases is in Casandra te vinden.

[P_Tingen]

Als je naar de tientallen miljoenen records gaat dan moet je serieus gaan kijken naar een NoSQL database omdat deze simpel weg veel beter werkt met dat soort hoeveelheden data.

Ten dele waar. De crux zit hem meer in de complexiteit van de data, gecombineerd met de hoeveelheid. Een beetje relationele database wordt niet koud of warm van een paar tientallen miljoenen records. Ik werk er dagelijks mee. Zolang er maar goede indexen op liggen is het een fluitje van een cent om de goede records eruit te vissen.

Als je veel, niet al te complexe data hebt, dan werkt een NoSQL database beter dan een RDBMS
_edit:typo

[Reactie gewijzigd door P_Tingen op 24 juli 2024 13:53]

[Ford Prefect]

Daar ben ik het niet helemaal mee eens, heel veel NoSQL databases voldoen niet aan het ACID principe, maar hebben iets van eventually consistent. Dus de complexiteit van de data is 1 ding maar het belang van de data is een 2e.

[Milt]

Om het nog wat ingewikkelder te maken, diverse NoSQL databases hebben wel alle ACID eigenschappen op node niveau (bijv. CouchDB) maar als cluster zijn ze dan toch niet consistent. Het is daarom ook beter om naar de CAP (Consistency, Availability, Partition Tolerance) eigenschappen te kijken van een database. De theorie (en de praktijk ) is dat een database (cluster) maar slechts twee van deze drie eigenschappen kan hebben.

[Remus]

In een relationele database is een tabel de relatie (in de wiskundige zin!), niet de foreign key constraint die veel mensen incorrect relationeel zien als het geen dat relationeel is.

[GateKeaper]

Een tabel is geen relatie, twee tabellen kunnen een relatie hebben. De foreign key contraint is de relatie tussen twee tabellen. Deze relatie wordt gelegd met een foreign key.

Een persoon is immers ook geen relatie, twee personen kunnen echter wel een relatie hebben ;-)

[nst6ldr]

Een tussentabel is op zichzelf een relatie: het praktische nut van een dergelijke tabel bestaat niet zonder de twee (of meer) tabellen die aan elkaar gehangen worden.

[bbc]

De simpelste regel die je kunt opstellen is een SQL database waar je tabellen hebt met enkele miljoenen records is nog te doen. Als je naar de tientallen miljoenen records gaat dan moet je serieus gaan kijken naar een NoSQL database omdat deze simpel weg veel beter werkt met dat soort hoeveelheden data.
Je moet niet vergeten dat de wereld van SQL en NoSQL heel erg anders zijn en dat de developers niet even binnen een paar minuten over kunnen stappen omdat alles voor mensen die jaren lang om de oren geslagen zijn met SQL erg vreemd lijkt.

Tenzij je in een bank werkt. Dan is het no to Nosql, ongeacht het aantal records.

[well0549]

Wat is dat nu weer voor een rare stelregel.......

Wil jij nu gaan zeggen dat het CMS van een bank op NO-SQL draait......

Geloof ik nix van

[Yoozer]

Volgens mij heb je niet goed gelezen. Er staat "no to NoSQL" - en dat is omdat ACID heilig is voor transacties. "Eventual consistency" is niet goed genoeg (terwijl dat bij bijv. Facebook niet uitmaakt als je toevallig bij die page refresh een berichtje mist).

Een CMS past makkelijk in een SQL database, daar ga je eerst caching voor gebruiken om de load te verminderen, geen NoSQL db.

[Reactie gewijzigd door Yoozer op 24 juli 2024 13:53]

[netman]

Ook een systeem met cassandra is consistent te maken.

Op de Cassandra client kan je namelijk een consistency level instellen. Als je dit bijv instelt op "Quorum" zal het systeem (Cassandra + Client ) zich wel degelijk consistent gedragen. Dit gaat overigens ten koste van de performance.

[Reactie gewijzigd door netman op 24 juli 2024 13:53]

[Korben]

De simpelste regel die je kunt opstellen is een SQL database waar je tabellen hebt met enkele miljoenen records is nog te doen. Als je naar de tientallen miljoenen records gaat dan moet je serieus gaan kijken naar een NoSQL database omdat deze simpel weg veel beter werkt met dat soort hoeveelheden data.

Wat een onzin. Het probleem is dat developers tegenwoordig waardeloos zijn in het werken met SQL en de ACID-concepten, en geen fatsoenlijk idee hebben van hoe een database nou precies werkt. Zelfs op een consumenten-pc kun je een RDBMS met honderden miljoenen records fatsoenlijk draaien. Zie http://www.yafla.com/dfor...x_of_Data_Explodification.

[Tarabass]

NoSQL staat niet voor no sql, maar voor Not Only SQL. Daarnaast is volgens mij niet elke noSql db zonder relaties, enkel de join-operations worden vermeden. Er zijn ook erg veel verschillende NoSql db's, zo geven sommige sets terug of alles in documents

Dus dat je geen relaties hebt of geen sql gebruikt is volgens mij gewoon niet waar. Je uitleg is duidelijk en voor het grote gedeelte waar, maar niet alles..

[himlims_]

er zit een 'klein' verschil tussen mysql en cassandra. de toepasbaarheid van die twee is dat ze een andere doelgroep/functionaliteit voor ogen hebben.
mysql = simpel/stand alone
cassandra = grootschalig/cluster

voor duidelijke beschrijving en verschillen;
http://www.25hoursaday.co...VsManualTransmission.aspx

[Reactie gewijzigd door himlims_ op 24 juli 2024 13:53]

[-=bas=-]

Mysql kan ook gerust in enorme clusters gedistribueerd draaien voor zware zakelijke toepassingen dus het verschil heeft echt niets met simpel of stand-alone te maken.

Er zit een heel ander verschil tussen Mysql en Cassandra :
Cassandra is een hele specifiek dataopslag die wel heel snel is maar ten koste van een heel hoop zaken die voor sommige applicaties wel belangrijk zijn.
Je kan bijvoorbeeld geen JOIN tussen 2 tabellen doen met Cassandra.
Verder kan je Mysql bijna overal aan hangen terwijl Cassandra een Java-only oplossing is. Zo zijn er nog wel wat verschillen...
Voor het loggen van berichten voor Google en Facebook is het een fantastische oplossing maar voor de gemiddelde CMS is het een waardeloos product.

Hier is een leuke vergelijking tussen een aantal van dit soort specifieke datastorage engines :
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

[Mellow Jack]

Je kan bijvoorbeeld geen JOIN tussen 2 tabellen doen met Cassandra.

Klopt je hebt ook geen relaties, geen relaties geen JOIN

Voor het loggen van berichten voor Google en Facebook is het een fantastische oplossing maar voor de gemiddelde CMS is het een waardeloos product.

Daar is het ook helemaal niet voor gemaakt

Stuk over BigTable van Google, ik geloof dat de theorie aardig overeenkomt met Cassandra alleen is het iets meer specifiek ingericht voor Google

http://storagemojo.com/20...uted-storage-system-pt-i/

[Intrepidity]

Uiteraard heb je geen JOIN. Dat is ook helemaal niet relevant, want je kunt in 1 keer een heel object inclusief subobjecten in je database gooien. Waarom je zou willen joinen op een NoSQL-achtige database weet ik niet.

[squeez]

Verder kan je Mysql bijna overal aan hangen terwijl Cassandra een Java-only oplossing is. Zo zijn er nog wel wat verschillen...

Dat is niet waar. Cassandra is geschreven in Java, maar er zijn drivers voor Python, Java, .Net, Ruby, PHP en C++. Cassandra maakt gebruik van Thrift, dus het is heel gemakkelijk om drivers voor extra talen te ontwikkelen.

[naikon]

Mysql kan ook gerust in enorme clusters gedistribueerd draaien voor zware zakelijke toepassingen

Dit wil ik toch wel even nuanceren, want dat "gerust" gedeelte geld alleen als je een 3rd party backend en 3rd party replicatie gebruikt. Standaard MySQL + InnoDB is hier helemaal niet voor geschikt om de volgende redenen:
- InnoDB compact nooit, met andere woorden de hoeveelheid data op disk neemt alleen maar toe.
- Alleen reads schalen lineair met het aantal nodes, writes schalen helemaal niet
- Alle data is aanwezig op elke node, dus als je een dataset hebt die niet op 1 node past dan ben je de sjaak.
- Niet alle nodes zijn gelijkwaardig, als je master node in de fik vliegt heb je een probleem. (Of je moet je applicaties automatisch laten connecten naar de hot standby of je moet een of andere load balancer dr voor hebben staan. In elk geval voegt een goede afhandeling hiervan complexiteit aan het systeem toe).

Deze problemen zijn allemaal niet aanwezig met Cassandra:
- Elke node is gelijkwaardig
- Reads en writes schalen lineair met het aantal nodes
- Dataset kan veel groter zijn dan wat er op 1 node past
- Dataset word automatisch gecompact. Je kan zelfs data automatisch laten "expiren".

[Reactie gewijzigd door naikon op 24 juli 2024 13:53]

[wha]

Als cassandra voor grootschalig gebruik is waarom gebruikt facebook dan nog mysql icm memcache.... Als dat zo zou zij dan was facebook al overgestap naar cassandra voor de complette database omgeving?

[Keiichi]

Ik ga er niet vanuit. Elke database-engine heeft z'n zwakkere en sterkere punten.

[tes_shavon]

Facebook? Die iets weggeeft aan de community? het moet niet gekker worden.

meer info

[Reactie gewijzigd door tes_shavon op 24 juli 2024 13:53]

[Niemand_Anders]

Zo gek is het anders niet want ze worden er zelf veel beter van. Facebook is niet het enigste bedrijf dat te maken heeft met veel informatie en deze snel opvraagbaar te maken.

Bij Facebook zitten een aantal zeer goede developers, Facebook is vooral op zoek naar nieuwe technieken. Het doorontwikkelen van een product kan zeer kostbaar worden, zeker als je de performance wilt verbeteren.

Door het product open source te maken kunnen ook developers van o.a. Twitter en Cisco meewerken aan het project. De participatie in Cassandra is uiteraard niet zo groot als bij de Apache webserver, maar dat is ook niet nodig. Stel dat Facebook 4 developers op het project heeft en dat je via de open source movement vier andere developers weet aan te trekken, dan heb je op een eenvoudige manier je development verdubbeld.

Facebook verdient zijn geld niet met het maken van een database. Echter heeft de Facebook systemen zelf wel een (high performance) database nodig. En nu drie jaar later heeft Facebook een (nog) veel betere database engine..

[bbob]

Klopt facebook verdient geen geld met software het is een middel om hun model draaiende te houden. Als anderen de software voor dat model kunnen verbeteren komt dat ook weer facebook ten goede.

[DeTeraarist]

Uhm, dit is verre van de eerste keer dat Facebook iets "weggeeft". Het zijn geen dingen waar jan-en-alleman wat aan heeft, maar wel een enorme invloed kunnen hebben.

https://github.com/facebook
http://facebook.com/opensource/
Kijk zelf maar eens.

[netman]

Dat weggeven door Facebook is al een tijdje terug (2008). Sindsdien zijn er al vele opensource versies uitgebracht. Toevallig heet deze release 1.0.0

[Verwijderd]

Om over na te denken: welke producten zijn al door de Nederlandse overheid of aan de overheid gelieerde organsiaties als open source weggegeven? Welke organisaties binnen de Nederlandse overheid dragen actief bij aan open source communities? Zelfs vanuit de universitaire wereld si het minimaal. Buiten Wietse Venema (Postfix) kan ik me niet veel bedenken.

[netman]

De overheid ontwikkelt wel software maar dat is maatwerk gericht op het uitvoeren van nederlandse wetgeving. Het heeft weining zin een systeem voor nederlandse belasting wetgeving vrij te geven....

Verder worden er bij de overheid veel pakketten gebruikt en die mag je niet weg geven.

[Verwijderd]

Facebook? Die iets weggeeft aan de community? het moet niet gekker worden.

meer info

Het framework is Free software ja..

[silentsnake]

Facebook heeft buiten Cassandra ook veel werk verricht voor Apache Hadoop, HDFS en HBase. Zie
http://borthakur.com/ftp/RealtimeHadoopSigmod2011.pdf over hun Hadoop & Hbase implementatie en wat ze er aan verbeterd hebben (en dit tevens ook terug hebben gegeven aan de community). Een aantal commiters van Hadoop & HBase zijn ook fulltime in dienst bij Facebook.

In een notendop hebben ze hun MySQL clusters vervangen met Hadoop & HBase voor hun messaging platform. Dat document beschrijft het wat, hoe, waarom, hoeveel enz enz.

[Reactie gewijzigd door silentsnake op 24 juli 2024 13:53]

[hiekikowan]

Toch goed om te zien dat grote, winstgevende en succesvolle bedrijven ook flink bijdragen aan de ontwikkeling van dit soort open software. Komt Facebook ook een keer positief in het nieuws

[tweakerbee]

Met ongeveer 2000 werknemers is het redelijk groot, maar niet heel groot. Google heeft er bijv. meer dan 30.000... De winstgevendheid lijkt met meer dan $4 miljard omzet inderdaad wel goed te zitten.

[Verwijderd]

De winstgevendheid lijkt met meer dan $4 miljard omzet inderdaad wel goed te zitten.

winstgevendheid heeft niets met omzet te maken. Bedrijven genoeg die enorme omzetten maken maar jaar na jaar de verliezen opstapelen om uiteindelijk overkop te gaan

Omzet is de som van alle verkoopfacturen. Als de kosten groter zijn maak je verlies, zo simpel is het.

[Navi]

Hoge omzet != Veel winst, kijk maar naar Philips..

[Marc050]

Dit ongewenst maken en weg-editen Dit is UITLEG!!!

[Reactie gewijzigd door Marc050 op 24 juli 2024 13:53]

[engelbertus]

maar je kunt dus wel meer omzet maken dan winst, maar andersom niet!

overigens, inderdaad, not only sql, dus het is wel mogelijk. het is alleen ook mogelijk om het zonder sql te doen, en dan vloeien daar een aantal voordelen uit voort.

het is maar net wat je zelf wilt met casandra.