Twitter dropper NoSQL til tweets

Twitter skifter strategi og holder på MySQL i stedet for Cassandra, når mikroblog-indlæggene skal gemmes. Men der er masser af andre ting, som tjenesten kan bruge NoSQL-databasen til.

Rygterne om NoSQL-teknologiens forestående dødsdom hos Twitter er tilsyneladende en kende overdrevet.

Efter rygter om, at Facebook vil vende ryggen til sit eget NoSQL-hjertebarn, databasen Cassandra, og at databasen havde ansvar for et nedbrud hos tjenesten Reddit, er Twitter nu med på anti-NoSQL-bølgen i et vist omfang.

I et nyligt blogindlæg meddeler Twitter, at tjenesten ikke vil anvende Cassandra til at gemme tweets, men i stedet vil udvide sin eksisterende anvendelse af MySQL. Det betegnes af Twitter selv som »et skift i strategi.«

Men der er dog mange andre ting, som tjenesten kan bruge Cassandra til. Twitters geo-udviklere benytter databasen til at gemme geografiske data, og udviklingsholdet benytter den til dataanalyse på baggrund af Twitters samlede brugerskare, samt analyse af driften i stor skala.

For nylig har bagmanden for en anden open source-database, Voltdb, databaseprofessor Michael Stonebraker, givet den mening til kende, at det ikke er SQL-grænsefladen, som giver langsomme databaser, men en række andre forhold, som han mener at have kringlet.

Ifølge Michael Stonebraker kan Voltdb klare transaktioner væsentligt hurtigere end mange andre databaser: 13 gange hurtigere end Cassandra og 100 gange hurtigere end MySQL.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Louis Andersen

.. Hvis man tager sig sammen og laver noget ordentlig precompilation af sine SQL statements. Problemet, som Stonebreaker er inde på, er nærmere at de fleste databaser er designet til computere anno 1980. Det inkluderer PostgreSQL, Oracle, DB2, til dels MySQL etc.

Hvis man designer en SQL-baseret database omkring en mere moderne arkitektur så bliver det spændende. Måske VoltDB er svaret. Det er ihvertfald ikke noget dårligt bud.

Det eneste jeg måske kunne tænke mig var en opdatering af SQL-sproget fra dets Ada-lignende helvede til noget mere tidssvarende notation. Men notation er bare notation og kan fjernes af enhver person som har lidt færdigheder i compilere.

  • 0
  • 0
Per Olesen

Som altid skal man tage den slags med et gran salt, og så huske selv at overveje plusser og minusser ved nye teknologier ift. hvad ens egen problemstilling er.

I det omfang at man taler om et egentlig problem, så er det nok mere ACID end det er SQL, der er problemet. De garantier, som nuværende RDBMS-produkter giver os i form af transaktionsbegrebet giver nogle hårde grænser ift. hvor meget en RDBMS kan skalere.

Cassandra løser nogle meget store - og meget specifikke - skaleringsproblemer, som Oracle, MySQL osv ikke kan leve op til, når de også skal overholde ACID kravene. Men vi snakker altså en størrelsesorden, som få har behov for. Twitter mener så ikke de har behovet (til trods for, at vi ser hvalen lidt ofte :).

Til gengæld er cassandra absolut ikke en drop-in replacement for en RDBMS, og hverken kan eller skal være det. Den giver slip på nogle af ACID kravene, og giver så mulighed for nærmest lineær skalering på nogle områder.

  • 0
  • 0
Martin Bøgelund

Det eneste jeg måske kunne tænke mig var en opdatering af SQL-sproget fra dets Ada-lignende helvede til noget mere tidssvarende notation.

Kan du uddybe hvad du mener?

SQL's tilgang til datahåndtering er oprindeligt tænkt som mængdeoperationer. Det er nærmest hele SQL paradigmet. Så hvis det er det du finder problematisk, var det måske mere oplagt at starte fra scratch med et nyt query-sprog bygget op omkring et nyt paradigme?

  • 0
  • 0
Troels Henriksen

Det forekommer mig ret nemt at skrive en simpel oversætter, der omskriver f.eks. mængdeudtryk til SQL. Idet SQL alligevel altid bruges som en indre komponent i et større system, så forekommer det mig ikke svært blot at skrive sit eget sprog med en syntaks der passer bedre til ens smag, hvis man skulle have lyster i den retning.

  • 0
  • 0
Martin Bøgelund

Ja, men syntaksen i SQL er ret langt fra tradionelle mængdeoperationer.

For mig står f.eks. "contains", "exists", "union", "intersect", og "except" som helt klare pendenter til mængdeoperationer.

Mængdeudtryk oversættes nemt og direkte til en SQL query.

"Kartesisk produkt"...

Jeg synes båndende fra SQL over mod mængdeoperationer er temmelig tydelige.

  • 0
  • 0
Niels Elgaard Larsen

Og division?

Naturligvis er der mængdeoperationer i SQL, men også alt muligt andet.

I praksis har jeg ikke brugt en database, hvor det gik godt at nøjes med den slags mængdeoperatorer. Enten kan det ikke parses eller performance bliver håbløs.

Desuden opererer de ikke med rigtige mængder:

> select 'foo' from users;
+-----+
| foo |
+-----+
| foo |
| foo |
| foo |
| foo |
| foo |
| foo |
| foo |
| foo |
| foo |
| foo |
+-----+

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize