Twitter verruilt MySQL voor Cassandra

Twitter vervangt zijn MySQL-backend door Cassandra, een opensourceproject van de Apache Software Foundation. Cassandra is ontwikkeld door Facebook en zou beter in staat zijn om grote datavolumes te verdelen binnen clusteromgevingen.

Met de geplande overstap van MySQL naar Cassandra volgt Twitter het voorbeeld van drukbezochte websites als Facebook en Digg, zo meldt InformationWeek. Ryan King, softwareontwikkelaar bij Twitter, stelt in een interview met het MyNoSQL-blog dat zijn bedrijf een database-omgeving nodig had die de snelle groei van Twitter kon bijbenen. Zo groeide de microbloggingdienst in 2009 van 2 miljoen naar 50 miljoen berichten per dag. Ook zou het database-systeem redundanter van opzet en daarmee robuuster moeten worden; downtime is voor Twitter een regelmatig terugkerend verschijnsel.

De distributed database Cassandra zou de groeistuipen van Twitter moeten opvangen. Cassandra werd oorspronkelijk door Facebook-ontwikkelaars gebouwd en moest vooral beter schaalbaar zijn dan MySQL. In 2008 werd de code via de Apache Foundation onder een opensourcelicentie beschikbaar gemaakt.

In tegenstelling tot MySQL-systemen kan een Cassandra-cluster zonder tussenkomst van een beheerder met nieuwe nodes worden uitgebreid. Daarbij zal een nieuwe node direct de bestaande databases repliceren, wat de kans op uitval verkleint. Andere voordelen zouden zijn dat Cassandra voor leesacties is geoptimaliseerd en dat het aantal velden in een record realtime kan worden aangepast.

Cassandra en andere distributed databases kennen ook de nodige nadelen ten opzichte van 'klassieke' databases. Zo worden transacties niet ondersteund, zodat niet met zekerheid kan worden vastgesteld of een transactie geslaagd is. Ook kan Cassandra niet overweg met joins, waarmee data uit meerdere tabellen dynamisch wordt gecombineerd.

Reacties (81)

[Verwijderd]

Om te beginnen kun je dit bericht andersom lezen: Twitter is groot geworden op MySql en heeft er tot nu toe goed op kunnen draaien. Dat je dan na een enorme groei opnieuw gaat kijken wat de beste keus is is slim. En ook dat is een feature van MySql in zekere zin: had je voor een closed source database gekozen dan zou je een enorme investering moeten afschrijven en mogelijk op aspecten ook last hebben van vendor lock in. Laat een Oracle DBA los in een project en het kan je binnen een week zomaar overkomen.

Ik denk niet dat het zozeer is dat MySql slecht is of zo, ik denk dat Cassandra een beter zakmes is voor de klus. In MySql kan ik ook op slimme manieren cachen met gegevens die vaak nodig zijn en met de huidige lage prijs van RAM geheugen kun je met een server van 64 GB RAM of zo heel veel gegevens in het geheugen houden. Alleen zul je daarvoor moeten gaan bouwen en krijg je het bij Cassandra kado.

Grappig om te zien hoe we nu omgaan met en deels afscheid nemen van consistentie - met name als je bedenkt dat voor bijna twee decennia dat de heilige graal was en een hele generatie dba's denkt in transacties.

[cariolive23]

Grappig om te zien hoe we nu omgaan met en deels afscheid nemen van consistentie - met name als je bedenkt dat voor bijna twee decennia dat de heilige graal was en een hele generatie dba's denkt in transacties.

Consistentie is nu juist een heel zwak punt van MySQL, alleen de innoDB-engine kent foreign keys en transacties. Komt bij dat vele programmeurs geen flauw idee hebben hoe ze hiermee moeten werken, er zijn dus hele generaties die nog nooit enige poging hebben ondernomen om consistente data af te (laten) dwingen.

Overigens is het relationele model al zo'n 40 jaar oud, bewezen technologie. Maar niet de technologie die Twitter nodig heeft voor hun site.

En MySQL? Dat nooit meer, er is al genoeg ellende in deze wereld

[Verwijderd]

Je mist m'n punt: jarenlang is consistentie hel erg belangrijk gevonden. Er is een generatie dba's die nergens anders aan kan denken. Maar er ontstaat nu een nieuwe serie toepassingen waarvoor consistentie helemaal niet belangrijk is.

Dat is bijvoorbeeld ook het geval bij Google. Voer twee maal dezelfde query uit en het kan gebeuren dat je andere resultaten krijgt. Het hangt er maar net vanaf welke server jouw request afhandelt.

[Melodic Metal]

Maar zou MSSQL, Oracle of PostGreSQL beter draaien dan MySQL bij deze belasting?
Gezien MySQL zover ik weet net zo goed is als MSSQL op het verschil in features na.

[YopY]

Ik denk dat je je eerder af moet vragen: willen ze die DBMSen gebruiken? Want, nu nergens om, qua data is Twitter eigenlijk dodelijk eenvoudg. De hoofdmoot van hun hele site is een enkele tabel met daarin 160 karakters aan bericht, een timestamp, een user ID, en een 'source' ('via web' etc).

Waarom zou je voor een site van twee tabellen tienduizenden euri per jaar spenderen aan een enorm groot uitgebreid DBMS, terwijl je eigenlijk alleen maar iets zoekt dat goed performt en makkelijk schaalbaar is?

[cariolive23]

Waarom zou je voor een site van twee tabellen tienduizenden euri per jaar spenderen aan een enorm groot uitgebreid DBMS, terwijl je eigenlijk alleen maar iets zoekt dat goed performt en makkelijk schaalbaar is?

PostgreSQL is gratis, zelfs nog ietsjes meer gratis dan MySQL (vrijere licentie), en levert uitstekende performance én is goed schaalbaar (vraag Skype maar).

Het is natuurlijk wel de vraag of ze uberhaubt wel een relationele database nodig hebben, je zegt het zelf al, het datamodel is zó simpel dat een RDBMS wellicht overkill is. Dat kan een hele goede reden zijn om Cassandra te kiezen.

[Reactie gewijzigd door cariolive23 op 23 juli 2024 19:15]

[cariolive23]

Gezien MySQL zover ik weet net zo goed is als MSSQL op het verschil in features na.

Laat een MSSQL-dba dat niet horen, je slaat hier een paar planken mis... MySQL kent zoveel gebreken en bugs, dat mag je echt niet vergelijken met SQL Server. En nee, ik ben geen MSSQL-dba, ik werk op PostgreSQL. Nog zo'n betrouwbaar werkpaard, m'n collega's doen SQL Server.

PostgreSQL schaalt in elk geval als een dolle, Skype draait standaard PostgreSQL-databases (met PL/Proxy) en dat schaalt in elk geval tot 1 miljard gebruikers. Zou voor Twitter ook genoeg moeten zijn...

[Verwijderd]

PostgreSQL lijkt mij wat zwaar voor Twitter, het bied veel meer functionaliteit dan ze nodig hebben, daardoor zou je meer resources nodig hebben. Dat het "schaalt als een dolle" zegt niet dat het schaalt naar het niveau Twitter.. Gezien het feit dat Twitter bewust kiest voor een niet-relationele database denk ik niet dat PostgreSQL ooit een optie is geweest. Skype heeft te maken met credits en natuurlijk euro's, dollars, roupies.. Daar wil je zowieso transacties gebruiken.

Maar zou MSSQL, Oracle of PostGreSQL beter draaien dan MySQL bij deze belasting?
Gezien MySQL zover ik weet net zo goed is als MSSQL op het verschil in features na.

Dit zijn op MySQL (InnoDB niet meegerekend) na ook relationele databases.

Oracle kan het wel aan maar het is GRUWELIJK duur.. We praten dan over een tonnetje per quad core (Intel Xeon) processor voor Oracle database 11g Enterprise + partitioning. Natuurlijk kan een Facebook of Twitter een betere deal maken dan dat (kortingen van 70% zijn in de VS geen uitzondering bij Oracle). Korting of niet, het is geen optie.

MySQL is the usual suspect, MyIsam tabel structuur is snel, er is ook een in-memory tabel structuur beschikbaar om de boel wat vlotter te laten lopen maar ook MySQL heeft een 'limiet', het is niet schaalbaar genoeg, replicate is IMO niet betrouwbaar genoeg.

MSSQL is veel betaalbaarder dan Oracle, redelijk betrouwbaar, heeft met een standaard licentie een rijkere feature set dan Oracle (bijv partitioning). Maar kost nog steeds veel geld voor een 'gratis' dienst, ook denk ik dat het nog niet schaalbaar genoeg is voor een Twitter of Facebook. Ik weet niet wat de eigenschappen van Firebird zijn, kan Firebird uberhaupt serieus genomen worden? Gezien de eenvoudige aard van de data op Twitter zou je denk ik al snel op een proprietary DBMS uitkomen.

Overigens kan ik je niets vertellen over de ontwikkeling van applicaties met deze databases t.o.v. elkaar, ik heb alleen met MySQL gewerkt en de ontwikkelaars waar ik mee werk gebruiken een Oracle database daartussen zit een wereld van verschil, dat wel.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:15]

[cariolive23]

Gezien de eenvoudige aard van de data op Twitter zou je denk ik al snel op een proprietary DBMS uitkomen.

Waarom dat dan? Weet je wel wat "proprietary" betekend? Ik zie niet in waarom het een gesloten database moet zijn, zeker niet wanneer het zulke eenvoudige data betreft. Twitter toont dat zelf al aan, ze gaan voor de open source...

En wanneer PostgreSQL goed genoeg is om Oracle te vervangen bij NTT, dan is het zeker goed genoeg voor Twitter. Maar wellicht overkill, ze hebben waarschijnlijk helemaal geen RDBMS nodig.

[Verwijderd]

Je hebt gelijk het klopt niet, ik bedoelde te zeggen dat het zelf ontwikkeld is, maar dat is niet zo, de Facebook ontwikkelaars hebben het gemaakt. En later open source gemaakt.. Vandaar mijn verwarring..

Oh en wat betreft PostgreSQL misschien onderschat ik het. Maar feit blijft inderdaad dat dit te zwaar is..

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:15]

[CyBeRSPiN]

Oracle kan het wel aan maar het is GRUWELIJK duur.. We praten dan over een tonnetje per quad core (Intel Xeon) processor voor Oracle database 11g Enterprise + partitioning. Natuurlijk kan een Facebook of Twitter een betere deal maken dan dat (kortingen van 70% zijn in de VS geen uitzondering bij Oracle). Korting of niet, het is geen optie.

Wat een onzin argument. Twitter is allang geen hobbyprojectje meer dat het nodig heeft om gratis software te gebruiken. Wat als ze door gebruik van Oracle af zou kunnen met minder of goedkopere hardware, of door een goede SLA beter en/of goedkoper uit zijn? Hardware is ook GRUWELIJK duur overigens, zeker als je onderhoud en energiekosten mee gaat rekenen..

[Verwijderd]

Het gaat natuurlijk uiteindelijk om de kosten per user. Het moet wel uit kunnen, voor de meeste databases die op Oracle draaien zou ik zeggen gebruik lekker MSSQL tenzij je een bijzondere feature nodig hebt van Oracle.

De kosten per user voor Twitter op een Oracle database zijn denk ik erg hoog. Hoewel je voor twitter waarschijnlijk weinig CPU kracht per user nodig hebt, verbruikt het logge (in vergelijking met cassandra) Oracle ook meer CPU resources dan nodig is. Dus.. hoge licentie kosten en extra hardware nodig..

Als je dit enigszins met gratis software kan doen lijkt me dat verstandig.. Of je laat iets in-house ontwikkelen zoals Facebook deed. Met een beetje verstand maak je het open source en gebruik je de toevoegingen van de gebruikers. Met andere woorden Oracle is geen optie, cassandra wel.

[PolarBear]

MSSQL is veel betaalbaarder dan Oracle, redelijk betrouwbaar, heeft met een standaard licentie een rijkere feature set dan Oracle (bijv partitioning).

Noem mij eens een ding waarin Oracle betrouwbaarder is dan MSSQL?

[The Van]

Oracle kan het wel aan maar het is GRUWELIJK duur

ONZIN! Kijk je even wat Standard Edition One kost?!?

[voodooless]

PostgreSQL schaalt zeker zeer goed met hardware resources. Als het echter gaat om grote tabellen, dan loopt je als nel tegen problemen aan. Dat kun je oplossen door te partitioneren (dat doen wij en dat gaat prima voor meerdere honderd GB's), maar dat maakt het wel best complex als je dit netjes met triggers e.d wil doen i.p.v handmatig.

[cariolive23]

Veel problemen worden veroorzaakt door slechte configuratie en ongelukkige queries, niet door de omvang. Wanneer je met een paar honderd GB al moet partioneren, dan heb je of een gebruikspatroon dat lastig is (heel veel data per keer uit de tabel) of een slechte configuratie. En het gebruikerspatroon van Twitter stelt niet veel voor, geen mens die álle data uit een tabel nodig heeft, het gaat altijd om één of enkele records en die worden door je indexen direct aangewezen. Partioneren lijkt in de Twitter situatie niet snel nodig te zijn.

Maar zoals reeds gezegd, ze hebben waarschijnlijk helemaal geen RDBMS nodig.

[voodooless]

't is heel simpel: zodra je indexen niet meer in het memory passen gaat het niet meer lekker lopen. Nu hebben we de luxe van een behoorlijke machine en flink wat memory. Dat gaat uitstekend ook met grote tabellen als je de config goed hebt gedaan.

En als je veel indexen hebt is partitioneren ook een voordeel bij een insert. Die heeft dan stukken minder overhead.

[Hydra]

Je kunt Skype en Twitter niet zondermeer vergelijken. Skype doet meer normale storage/retrieval waar RDBMSen voor ontwikkeld zijn. Netwerk sites bestaan uit netwerken, dus massa's N-N relaties. Een query als "geef me statussen van alle vrienden van m'n vrienden" wil je niet door je RDBMS op laten lossen; dat is de reden dat Hyves zo slecht schaalt met hun DB-farm.

[PolarBear]

Gezien MySQL zover ik weet net zo goed is als MSSQL op het verschil in features na.

Tja, heel misschien als je sic de database bekijkt komt MySQL in de buurt. Maar als je alleen al kijkt naar Reportin Services, Analysis Services en Integration Services dan gaat de vergelijking al helemaal mank. Ik ben trouwens benieuwd of MySQL ook zaken als spares colums, row level compression, backup encrytion en/of transparant encrytion, auditing, filestream (binairies op filesystem maar wel transactioneel) ondersteund.

Begrijp me niet verkeer voor heel veel websites is MySQL een prima keuze (kijk naar deze website). Maar voor LOB applicaties biedt MSSQL (en Oracle met hogere kosten) veel meer functionaliteit.

[Korben]

MySQL is ten eerste niet ACID-compliant, ondersteunt maar deels Unicode, geen materialized views, en zo zijn er nog meer dingen die MySQL niet heeft en SQL Server wel.

[Milt]

Is MySQL met InnoDB niet ACID compliant ? Ik dacht altijd van wel.

[cariolive23]

Ik dacht het niet, iedere gek kan foreign keys uitzetten, unique constraints even uitzetten, net wat "handig" lijkt te zijn... Dat je vervolgens met een corrupte database zit, so what?

http://dev.mysql.com/doc/...sysvar_foreign_key_checks

http://dev.mysql.com/doc/...html#sysvar_unique_checks

Geen idee wat jij verstaat onder ACID, maar dat heeft weinig met databases te maken.

Tuurlijk, Twitter zal dit niet nodig hebben, maar dat wil niet zeggen dat MySQL ACID is, dat is het zeker niet, dat staat gewoon in de MySQL-handleiding: je kunt het even uitzetten. Sterker, iedereen met een database connectie kan dit even uitzetten.

[R3veNG]

Zo worden transacties niet ondersteund, zodat niet met zekerheid kan worden vastgesteld of een transactie geslaagd is. Ook kan Cassandra niet overweg met joins

Seriously? Waarom niet? Als je een DBMS in elkaar kan boksen, dan lijkt me de toevoeging van deze operaties niet meer een groot struikelblok..

[Verwijderd]

Ik weet niet of je bekend bent met het CAP-theorema van Brewer. Dat toont aan dat gedistribueerde systemen (in dit geval dus databases) een afweging moeten maken tussen consistentie, beschikbaarheid en partitietolerantie. Gedistribueerde systemen kunnen hooguit twee van de drie hebben.

Cassandra maakt daar bij andere ontwerpkeuzes dan traditionele relationele databases. Het offert (onmiddelijke) consistentie op voor een hoge beschikbaarheid zelfs wanneer er veel node's zijn om de load op te vangen. Maar vanwege die gedistribueerde aard zijn joins zeer inefficiënt en worden ze dus meestal vermeden.

Het alternatief voor joins is ofwel werken geneste datastructuren, of, de logica voor joins afhandelen in de client.

[Blokker_1999]

Vergeet niet dat Cassandra ontwikkeld is geweest voor 1 website die wss zonder deze functionaliteiten kon.

[Verwijderd]

transacties zijn vrij common hoor. Ze zijn niet altijd nodig, maar wel heel nuttig. En wees er maar zeker van dat facebook transacties gebruikt...

[Verwijderd]

Denk je werkelijk dat de transacties die je op Facebook maakt de resources waard zijn om tranactions te gebruiken? Voor banken en administratieve applicaties zijn transactions een must maar wat gaat een gebruiker van Facebook nou doen als er een 'fout' ontstaat doordat een tabel gelockt was en een andere tabel niet? Dan onstaat er misschien een discrepantie maar dat boeit niet, de gebruiker doet zijn actie maar even opnieuw. Wat ik wel een interessant gegeven vind is dat je dit dus als gebruiker nooit merkt, op facebook tenminste niet, geen deadlocks, uberhaupt geen fouten. Ik heb ze nooit gezien in ieder geval.. Wel slimme jongens dan bij Facebook.. Hyves daarentegen...

[cariolive23]

Denk je werkelijk dat de transacties die je op Facebook maakt de resources waard zijn om tranactions te gebruiken? Voor banken en administratieve applicaties zijn transactions een must maar wat gaat een gebruiker van Facebook nou doen als er een 'fout' ontstaat doordat een tabel gelockt was en een andere tabel niet?

Een transactie zorgt niet voor locks, gelukkig niet. Daarnaast zijn table locks iets wat voor normaal gebruik niet nodig is, er bestaan ook nog row locks en je kunt de locks ook nog verschillend instellen.

Transacties kun je ook gebruiken voor betere performance per groep queries per connectie, kan flink schelen. Al zie ik dat bij Twitter niet zo, ik kan me niet voorstellen dat ze veel queries nodig hebben per webpagina.

Hyves daarentegen...

Dat is weer van die MySQL-rommel die niet schaalt en wat ook nog eens is opgebouwd door programmeurs en waar later dba's de boel in de lucht moeten proberen te houden...

Hyves (5 miljoen gebruikers?) heeft honderden MySQL-servers nodig, Hi5 (25 miljoen gebruikers) heeft slechts enkele tientallen PostgreSQL-servers nodig. Bij Hyves maken ze het zichzelf vrij moeilijk, zeker door (nog steeds?) MySQL te gebruiken.

[Verwijderd]

Een transactie zorgt niet voor locks, gelukkig niet.

Nee dat bedoel ik ook niet maar een wijziging die doorgevoerd moet worden kan geblokkeerd worden door een lock, table lock, row lock maakt niet uit. De transactie mislukt. Voor de integriteit van je database van belang stel je voor dat de helft van je queries wel slaagt en de andere helft niet.. Is de transactie niet gelukt dan kun je een rollback doen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:15]

[humbug]

Ik ken databases (bv DB2) waar record locks escaleren naar table locks als je teveel schrijfacties op een bepaalde pagina uitvoert. Niet leuk als je hoge performance wilt hebben. Table locks komen dus ook in "normaal" gebruik voor.

En ja, ik prefereer ook PostgreSQL boven mySQL. Maar de beschikbare tools voor MySQL zijn in mijn ervaring toch nog steeds beter. Als iemand een goede tool weet om een PostgreSQL cluster op te zetten en te beheren daarentegen...

[fdh]

Dat hangt af van de rdbms in kwestie.
Bij bv Oracle ga je zulke escallatie nooit hebben.

Vandaar dat ik blijf zeggen dat database independent applicaties niet bestaan.

[The Van]

Vandaar dat ik blijf zeggen dat database independent applicaties niet bestaan.

In theorie niet, nee.
In de praktijk zijn er een boel fabrikanten die de nodige rommel op de markt gooien, en trots vermelden, dat de db independent zijn.
Ik wil het niet hebben: ik betaal niet voor niets licentiekosten voor een RDBMS, om vervogens een app erop te zetten, die geen gebruik maakt van alle opties.

[Reactie gewijzigd door The Van op 23 juli 2024 19:15]

[Milt]

Hyves (5 miljoen gebruikers?) heeft honderden MySQL-servers nodig, Hi5 (25 miljoen gebruikers) heeft slechts enkele tientallen PostgreSQL-servers nodig

En dus is PostgreSQL beter ? Beetje kort door de bocht denk ik. Er zijn zoveel andere factoren die een rol kunnen spelen. Ik wil MySQL niet verdedigen maar je kan de ene website niet zo maar met de andere vergelijken.

Allereerst zegt het aantal accounts niet alles over het aantal actieve gebruikers. En als Hi5 internationaler gericht is dan komen die gebruikers misschien wel uit verschillende geografische gebieden waardoor de belasting ook automatisch wordt verspreid. Hyves heeft zijn gebruikers voornamelijk in Nederland en de piek dus met name in de avonduren.

Hyves heeft misschien wel meer mogelijkheden dan Hi5 waardoor er meer database queries nodig zijn. De ene applicatie is de andere niet. Aan de andere kant maakt Hi5 misschien veel meer gebruik van caching dan Hyves. Dit kan enorme performance winst opleveren en is misschien iets wat Hyves nog niet (genoeg) benut.

Hyves heeft daarintegen misschien wel meer geïnvesteerd in hoge beschikbaarheid en redundantie dan Hi5. Als er bij Hi5 één database server uitvalt ligt misschien gelijk (een deel van) de site plat. Er zijn veel mogelijkheden en architecturen mogelijk maar een database is wel gewoon het onderdeel van een website wat zich het moeilijkste laat schalen.

[arjankoole]

transacties zijn vrij common hoor. Ze zijn niet altijd nodig, maar wel heel nuttig. En wees er maar zeker van dat facebook transacties gebruikt...

dat transacties gebruiken wordt moeilijk als facebook zelf cassandra gebruikt (en ontwikkeld heeft). Dus ik snap niet goed waar je die stelligheid vandaan haalt.

[latka]

Als je maar 1 tabel raakt omdat alles gedenormaliseerd is heb je ook geen transacties meer nodig. En zo zeker ben ik er niet van dat facebook transacties gebruikt: wat is het risico als men ze niet gebruikt: nihil. Dus kosten/baten: als een transactie betekent dat je schaalbaarheid in het geding komt zorg en dan gewoon voor dat je ze niet nodig hebt.

Een andere reden om zonder transacties te kunnen: je kunt alleen je eigen pagina editen, dus why bother met moeilijke transactie strategieen: er is maar 1 writer...

[fdh]

Stel dat je een overschrijving doet van € 100 (in een gedenormaliseerde omgeving).
In dat geval moet je in de account tabel van rekening A € 100 aftrekken en bij rekening B € 100 bijtellen. Dit zijn dus 2 updates vanuit dezelfde writer, waarvoor je normaal een transactie zou gebruiken. Anders zou je een "ongeldig" resultaat kunnen zien.

Facebook en twitter kunnen zonder transacties, omdat ze er niet om geven dat zulke fouten kunnen optreden.

[elmuerte]

Zo worden transacties niet ondersteund, zodat niet met zekerheid kan worden vastgesteld of een transactie geslaagd is.

Die zin slaat nergens op. Als er transacties niet bestaan zal een transactie in eerste instatie niet kunnen, en dus ook nooit kunnen slagen. Het niet hebben van transacties is alleen een nadeel als je op de "ouderweste" manier data commit. En daar is geen sprake van in Cassandra, want ze gaan uit van het "eventually consistent" concept. Aan transacties heb je ook niet veel in een gedistribueerde database.

Ook kan Cassandra niet overweg met joins, waarmee data uit meerdere tabellen dynamisch wordt gecombineerd.

Views zijn beter dan joins. Er is een reden waarom een DBMS vaak een temporary view aan maakt voor een query met joins.

[Reactie gewijzigd door elmuerte op 23 juli 2024 19:15]

[cariolive23]

Views zijn beter dan joins. Er is een reden waarom een DBMS vaak een temporary view aan maakt voor een query met joins.

Hoe kan een view nu beter zijn dan een join? Is een appel beter dan een peer? Ik durf zelfs wel te wedden dat 99 van de 100 views bestaan uit queries met één of meerdere joins en die worden toch echt iedere keer uitgevoerd wanneer de view wordt aangeroepen.

Verder is er met een join ook niets mis, je moet ze alleen wel goed toepassen en goed afstemmen op je indexen. Een genomaliseerde dataset in bv. 3 tabellen, kan in een query met 2 joins sneller zijn dan dezelfde dataset in één tabel. It depends...

Of heb je het over materialized views? Dat is een ander verhaal.

[The Van]

Ik durf zelfs wel te wedden dat 99 van de 100 views bestaan uit queries met één of meerdere joins en die worden toch echt iedere keer uitgevoerd wanneer de view wordt aangeroepen.

Dat ga je verliezen. Heel veel views worden gebruikt om data af te schermen en zijn dus simpele queries met een where clause. En met "simpele query" bedoel ik een zonder joins, e.d.

[PolarBear]

Views zijn beter dan joins. Er is een reden waarom een DBMS vaak een temporary view aan maakt voor een query met joins.

Weet je ik laat in 99 van de 100 keer optimalisatie over aan de queryoptimizer van mijn DBMS. Oracle en MS SQL Server hebben dusdanig goede queryoptimizers aan boord dat het niet de moeite is zelf allerlei optimalisatie te gaan verzinnen. Van MS SQL Server 2008 weet ik dat deze zelfs voorstellen kan doen om indexen te maken vanuit de managmentstudio.

[Verwijderd]

The fear of Oracle ?

[ppl]

Sja, als je al een systeem hebt met MySQL waarbij je al tegen het plafond van je setup aan loopt dan ga je natuurlijk rondkijken wat je kunt doen om dat plafond weg te halen. Als je bij die zoektocht dan bij iets anders terecht komt die ook al door diverse anderen tot tevredenheid wordt gebruikt dan is dat dus ook een optie. MySQL biedt bepaalde opties niet die Cassandra wel biedt en vice versa. Kennelijk vindt men bij twitter de featureset van Cassandra beter passen dan MySQL. Als het "fear for Oracle" was geweest hadden ze net zo goed een MySQL fork kunnen pakken. Verder is het technische verhaal erachter ook gewoon heel plausibel en zie je dat vele anderen daar ook al eens over hebben lopen klagen. Met name replicatie gaat bij MySQL meer dan eens heel erg nukkig. Ik vind je vraag dan ook vergezocht en nou niet getuigen van inhoudelijke kennis. Niet iedere switch is er eentje uit angst voor de fabrikant/leverancier

[Xthemes.us]

Hij zij fear of oracle, maar goed ik denk ook niet dat Oracle zich druk maakt over een een database systeem dat geen joins en transacties ondersteunt.. lijkt me toch een andere markt.

[kmf]

Je verruilt functionaliteit voor snelheid en schaalbaarheid.

Net als mysql in het prille begin.

[mcdronkz]

Wanneer een DBMS niet overweg kan met joins, lijkt me dat toch ernstige consequenties hebben voor de functionaliteit.

[kmf]

Ik kan me voorstellen dat twitter hun database model juist geDEnormaliseerd hebben.

Dus data dubbel opslaan zodat er geen joins nodig zijn. Lekker snel lezen. Wel veel meer onderhoud.

(dus bv tweet(id, tweetmsg, author_id, author_name) )

[webkiller71]

Facebook doet alle joins in de PHP-laag en slaat dat resultaat op in memcache. Hoewel ik de internals niet ken, kan ik me goed voorstellen dat ze author_id daarna in memcache opzoeken. Wordt author aangepast, dan update de applicatie die de update doet, de DB en memcache.

Overigens, doordat facebook zoveel joins in PHP doet, hebben ze veel data in de PHP laag en daarom hebben ze ook HipHop geschreven. C(++) is nog steeds een van de snelste talen qua geheugen, maar het ontwikkelgemak van PHP is (in ieder geval volgens Facebook) erg goed.

Zie ook http://fosdem.org/2010/schedule/events/scalingfacebook. Had van mij wel wat dieper gemogen, maar daar hadden ze waarschijnlijk de tijd niet voor. Interessant genoeg melden ze daar (op 50:00) dat Digg en Twitter de grootste contributors zijn.

[mcdronkz]

Dat is zo ongeveer het beste recept voor inconsistente data.

[humbug]

Dat is waar. Echter, soms is het gewoon nodig. Je wilt niet altijd honderden records doorlopen om een som van een waarde te bepalen. Simpelweg die som opslaan is dan veel handiger.

Maar gelukkig denormaliseerd twitter niet alles. Ze doen alleen veel werk in de applicatie server. In plaats van (bv)

select order.productnaam, klant.klantnaam from order join klant on order.klantID=klant.klantID

Doen ze
select order.productnaam,order.klantID from order
select klant.klantnaam from klant where klant.klantID=:klantID

Dus twee selects met in de tweede een where clause die uit de eerste komt. Minder efficient maar de data is maar 1 keer opgeslagen. Dit gaat pas echt mis als je met ingewikkeldere queries gaat werken waar het tussenresultaat een redelijk grote dataset oplevert.

Maar goed, hoewel denormalisatie niet altijd slecht is, is het iets wat enkel toegepast moet worden om daadwerkelijke performance bottlenecks op te lossen en hoort er in mijn ogen ook functionaliteit bij ontworpen te worden die op data inconsistentie test.

[Korben]

Mits je database triggers ondersteunt is het niet zo'n ramp. Wat dan wel minder is is dat je code gaat verspreiden over meerdere locaties, zodat je een (klein) deel van je business logic in je database hebt zitten.

[YaPP]

Soms worden dingen zo groot, dat je andere aanpak moet kiezen. Voorbeelden:

* Als je wordt lid van een van een groep op Facebook, dat zie je direct in jouw profiel, en jij ziet dat op de groepspagina. Andere gebruikers mogen dat best pas 15 minuten later zien.

* Alle berichten van een account verwijderen op Digg kost meerdere uren. In de achtergrond draait een proces wat de database stap voor stap doorzoekt, om te voorkomen dat de hele site neergaat.

Transacties en correcte joins gaan op dit niveau niet meer werken.

[Huppie]

Klopt, maar soms kan je de afweging maken tussen consistentie/betrouwbaarheid v.s. schaalbaarheid/snelheid.

Hier een aardig artikeltje met een goede uitleg van de verschillen tussen SQL en 'moderne' datastores (die de principes van No-SQL volgen).

[sdevos13]

En wat als ze nou alleen de joins/transacties in mysql stoppen op een aantal aparte servers.

[mark184]

wat is eigenlijk het motief van de overgang???

[Luqq]

2e regel.."en zou beter in staat zijn om grote datavolumes te verdelen binnen clusteromgevingen."

[ppl]

Dat is niet de reden waarom ze bij Twitter zijn overgegaan, dat heeft te maken met schaalbaarheid, redundantie en robuustheid:

Ryan King, softwareontwikkelaar bij Twitter, stelt in een interview met het MyNoSQL-blog dat zijn bedrijf een database-omgeving nodig had die de snelle groei van Twitter kon bijbenen. Zo groeide de microbloggingdienst in 2009 van 2 miljoen naar 50 miljoen berichten per dag. Ook zou het database-systeem redundanter van opzet en daarmee robuuster moeten worden; downtime is voor Twitter een regelmatig terugkerend verschijnsel.

Wat je zelf citeert is 1 van de mogelijkheden die je kunt toepassen om dingen als schaalbaarheid, redundantie en robuustheid te verkrijgen. Het is dus niet het doel maar het middel om tot dat doel te komen.

[mkools24]

Ik denk ook dat de overname van MySQL door Oracle meespeelt. Dat zal niet de grootste reden zijn maar zeker wel van invloed zijn.

[Verwijderd]

Als het dan van enige invloed zou zijn: dan alleen als argument om toch met MySQL door te gaan. Oracle heeft zich vastgelegd op aanzienlijke investeringen in MySQL en ik vermoed dat het daar in betere handen is. Meer kennis om MySQL op het niveau Postgres te krijgen.

Ach, en Monty... hoorde ik daar een krokodil huilen?

[humbug]

Als Oracle die investeringen niet gewoon doet om de EU gelukkig te houden het geld nuttig besteed en daarna doorgaat met de ontwikkeling van MySQL. Feit is dat voor de verkoop van MySQL aan Sun, MySQL Oracle met alle geweld buiten de deur wilde houden omdat men geen vertrouwen had in de toekomst van MySQL bij Oracle. Feit is ook dat dankzij het Sun/Oracle gebeuren er verschillende forks van MySQL zijn gekomen. Dat is nooit een goed teken want de ontwikkelgemeenschap splitst zich en beide projecten zullen daar schade van ondervinden.

Ook is deze keuze van twitter natuurlijk gemaakt voordat Oracle zich op die investeringen heeft vastgelegd. De onzekerheid rondom de plannen van Oracle zouden alleen al genoeg kunnen zijn geweest. Maar uiteindelijk draait het natuurlijk gewoon om schaalbaarheid en betrouwbaarheid. Blijkbaar beviel MySQL op die punten gewoon niet. Best wel wrang dat men nu voor een systeem kiest wat net zoals oude versies van MySQL geen transacties, joins enz ondersteund. MySQL is eindelijk dat niveau ontgroeit, gaan mensen weer opnieuw zo'n project beginnen......

[Verwijderd]

Ik denk het niet.

Facebook is momenteel heel goed bezig op het gebied van OSS dat schaalbaar is voor het net en voor zeer grote volumes.

Voor deze toepassing is Cassandra gewoon beter.

Voor andere toepassingen zal MySQL beter zijn.

Bedrijven zoals bijvoorbeeld Facebook zijn een mooie opsteker voor OSS. Zonder Facebook zouden dit soort applicaties momenteel niet in de OSS wereld bestaan hebben.

[jip_86]

Gisteren gelezen toevallig:

We have a lot of data, the growth factor in that data is huge and the rate of growth is accelerating. We have a system in place based on shared mysql + memcache but its quickly becoming prohibitively costly (in terms of manpower) to operate. We need a system that can grow in a more automated fashion and be highly available.

link
Het kost te veel om te laten draaien. Volgens het artikel is Digg ook al op Cassandra over.

[Hoite]

Dit kan alleen maar goed nieuws zijn voor actieve twitteraars, alhoewel uiteindelijk het toch zo moet zijn dat de eindgebruiker hier niks van zou moeten merken.

[Verwijderd]

De grootste reden lijkt dat het stabieler zou moeten gaan werken. Dus als een gebruikers last heeft gehad van downtimes en dat wordt met deze software opgelost en is een doel bereikt

[RMX]

MySQL 5.4 of 5.5 heeft bij InnoDB joins een snelheidswinst van 80%..

Je kunt nu ook MySQL 5.3 incl de nieuwe Innodb 1.6 downloaden, en daar zijn al heel wat verbeteringen in doorgevoerd..

Verder verbaas ik me echt over het gebruik van STRAIGHT_JOIN in je query..
Sommige query's die 30 seconden duren, gebeuren nu in 1 sec

Probeer het eens..
Gaat een wereld voor je open

[cariolive23]

MySQL 5.4 of 5.5 heeft bij InnoDB joins een snelheidswinst van 80%..

Ja lekker, alfa/beta software gebruiken voor productie omgevingen... Versie 5.1.44 is de meest recente productie-versie (GA).

Je kunt nu ook MySQL 5.3 incl de nieuwe Innodb 1.6 downloaden

Waar dan? Op de site van MySQL wordt deze versie totaal niet genoemd, 5.0, 5.1, 5.4 en 5.5 zijn aanwezig, 5.2 en 5.3 lijken niet te bestaan. Zullen dus zeker geen productie versies zijn, waarschijnlijk zelfs geen beta's.

[Verwijderd]

Natuurlijk doet Cassandra geen joins, het is dan ook geen relationele database. Het is daarentegen wel mogelijk om geneste data in JSON-formaat weg te schrijven en op te halen, wat joins eigenlijk irrelevant maakt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:15]