Cassandra statt MySQL

[nepumuk]

Müsste es nicht eher heißen:

> NoSQL statt SQL
oder aber
> Cassandra statt MySQL

sonst fangen hier wieder die "MySQL ist lahm, SQL-Server bzw. Oracle ist viel besser weils Geld kostet"-Posts an.
Im Kern wird die Umstellung wohl eher weniger an MySQL gelegen haben, als daran, dass Relationale Datenbanken den Anforderungen von Web 2.0 Anwendungen nur bedingt gerecht werden.

[zustimmer]

"Im Kern wird die Umstellung wohl eher weniger an MySQL gelegen haben, als daran, dass Relationale Datenbanken den Anforderungen von Web 2.0 Anwendungen nur bedingt gerecht werden."

Genau, z.B. wegen der Skalierbarkeit usw...

[makler versicherung]

Skalierbarkeit kriegst Du bei Mysql über replikation und/oder mehr Cores.

Wenn Du 100 Kunden hast, die Twitter machen, müsstest Du eine SQL-Spalte extra für deren Tweet-Adresse machen. Dasselbe für Skype, SipGate, icq, M$-IM, usw. Oder einer hat zwei Email-Adressen für verschiedene Zwecke.

Du endest in einem Wust von Spalten mit 99% NULL-Feldern oder mit vielen kleinen Extra-Tabellen.
Da sind keyval-Banken besser.

Es ist ja wohl auch klar, das man die wichtigen Entitäten des Geschäftsmodelles wie Produkt:<Name, Preis, Verfügbarkeit,...> klassisch als SQL macht, und meist nur Zusatzschnickschnack per keyval-Banken.

0:1:* Null, Eins, Viele. Mit Viele kommen viele nicht klar. Und ihre kleine 1:1 1:*-Welt zerbricht oder wird nicht mehr kontrollierbar.
Man hat z.B. nicht eine Email-Adresse, man hat viele für verschiedene Zwecke. usw.
Oder man hat mehrere Adressen bei Amazon hinterlegt.
Usw.

[Tomanie Gigan]

makler versicherung schrieb:
--------------------------------------------------------------------------------
> Skalierbarkeit kriegst Du bei Mysql über replikation und/oder mehr Cores.

> Wenn Du 100 Kunden hast, die Twitter machen, müsstest Du eine SQL-Spalte
> extra für deren Tweet-Adresse machen. Dasselbe für Skype, SipGate, icq,
> M$-IM, usw. Oder einer hat zwei Email-Adressen für verschiedene Zwecke.

> Du endest in einem Wust von Spalten mit 99% NULL-Feldern

Bei den enormen Kosten pro Byte (mehrere Euro?) ist das allerdings ein Problem. Vielleicht sollte man mit 5Bittigen Codesätzen experimentieren um dieses Problem noch weiter einzudämmen?

[cass andra]

Bei Hostern oder EC2/S3 von Amazon bezahlst Du dann aber dasselbe für die Luft als wenn dort Nutzdaten drin wären.

Komprimieren geht auch nicht gut, weil anständige Records schliesslich eine Prüfsumme am Ende haben. Und die Nullen vielleicht gar nicht mit Nullen gefüllt werden sondern irgendwas drin steht. Deine FS füllen gelöschte Dateien ja auch nicht mit 0-Blöcken auf. Insbesondere bei SSDs ist das unerwünscht.

D.h. "mal eben" mit gzip ein Backup übers Netz schieben (was dann Traffic bei Google oder S3 kostet) ist auch nicht so optimal, als wenn man es zu Hause oder SOHO-Lan machen würde.

Und ab einem gewissen Level ist eine unnötige Aufblähung doch lästig.

[anon123]

makler versicherung schrieb:
--------------------------------------------------------------------------------
> Du endest in einem Wust von Spalten mit 99% NULL-Feldern oder mit vielen
> kleinen Extra-Tabellen.
> Da sind keyval-Banken besser.

Was ich hier nicht verstehe, was hindert mich denn daran eine simple Tabelle mit zwei Feldern (key, value) in einer relationalen Datenbank anzulegen?

Das Problem was Cassandra löst hat eigentlich nicht viel mit NoSQL und relationalen Datenbanken zu tun. Cassandra skaliert besser, weil dort nur "eventual consistency" garantiert wird. Also bei mehreren Datenbankservern heißt das, eine Änderung auf einem Server ist irgendwann auch auf den anderen Servern sichtbar. Im Gegensatz dazu bedeuted normale Konsistenz, dass eine Änderung auf einem Server sofort auf den anderen sichtbar ist. Bei Digg ist es nunmal nicht so entscheidend, ob ein paar Minuten vergehen, bis ein Artikel für alle sichtbar ist. Da ist es viel wichtiger, dass die Seite schnell aufbaut und viele Leute bedienen kann.

Auch der Begriff NoSQL ist sehr irreführend. NoSQL vs. SQL ist ungefähr eine so sinnvolle Gegenüberstellung wie "rote Dinge" vs. "nicht rote Dinge". Da gibt es schon so viele Unterschiede innerhalb der Gruppen, dass da keine gescheite Aussage rauskommen kann.

[DB Man]

@anon123
Das klingt so als wäre diese NoSQL-Db sowas ähnliches wie eine umkonfigurierte LDAP-DB. Stark optimiert für Lesezugriffe, sehr wenig bis gar nicht optimiert fürs Schreiben. Kein ACID, aber doch gut skalierbar und schnell, sehr schnell.

Kann das sein, dass die diversen Verzeichnis-DBs die Wurzel dieser NoSQL-DBs sind?

[Mindfuck]

anon123 schrieb:
--------------------------------------------------------------------------------
> Was ich hier nicht verstehe, was hindert mich denn daran eine simple
> Tabelle mit zwei Feldern (key, value) in einer relationalen Datenbank
> anzulegen?

Die Armselige Performance (im vergleich zu einer Optimierten Datenbank) und die ungenügende Abfrage-Unterstützung durch SQL.

[highrider]

makler versicherung schrieb:
--------------------------------------------------------------------------------
> Skalierbarkeit kriegst Du bei Mysql über replikation und/oder mehr Cores.

Aha, und das funktioniert auch mit 500 replizierten Datenbanken, die über die ganze Welt verteilt sind? Glaub ich nicht.

highrider

[anon123]

@DB Man
Wie gesagt ist NoSQL ein schlechter Begriff um irgendwelche Aussagen zu treffen. Da drin stecken die verschiedensten Datenbanken Da gibt es das dokumentenbasierte CouchDB, das objektbasierte db4o, die embedded key-value Datenbank BerkleyDB und vieles mehr. Die alle haben nur eine Gemeinsamkeit: sie können kein SQL. Sonst haben sie die unterschiedlichsten Eigenschaften, Ursprünge und Anwendungsfälle.

Cassandra ist gibt einfach die starke Konsistenz zugunsten von Lese- und Schreibperformance auf, garantiert aber immerhin "eventual consistency". Auf andere NoSQL Datenbanken trifft das nicht zu.


@Mindfuck
Ah ja und wenn man SQL unterstützt ist es ja verboten noch andere APIs anzubieten. Außerdem dürfen relationale Datenbanken keine Algorithmen optimiert für einfache key-value Tabellen benutzen.

[auch intel]

anon123 schrieb:
--------------------------------------------------------------------------------
> makler versicherung schrieb:
> ---------------------------------------------------------------------------
> -----
> > Du endest in einem Wust von Spalten mit 99% NULL-Feldern oder mit vielen
> > kleinen Extra-Tabellen.
> > Da sind keyval-Banken besser.

> Was ich hier nicht verstehe, was hindert mich denn daran eine simple
> Tabelle mit zwei Feldern (key, value) in einer relationalen Datenbank
> anzulegen?

Ich zitiere:
> > Du endest ... oder mit vielen kleinen Extra-Tabellen.

Viele kleine Extra-Tabellen sind sehr lästig. Z.b. eine Extra-Tabelle nur für Schulbuch-Preise. Oder eine Tabelle für ICQ-Nummern, eine für Email-Adressen, eine für Skype-Namen, eine für RIM-Adresse usw. .

Also würde man key/art/value als je eine Tabelle für Ziffern, eine mit Floats und eine mit Strings machen.
D.h. alle ICQ-Nummern usw. landen zusammen mit allen email-adressen und skype-namen in dieser tabelle:
id-des-Kunden / type = { skype, email, icq, rim } / value
Da kann man dann Kindle-IDs oder Ipad-IDs schnell nachtragen, wenn man das mal braucht.

Siehe auch ct-Bericht über patentierte Polizei-Datenbank vor 10 oder mehr Jahren. Die können alles mit 6-9 Tabellen OHNE weitere Zusatztabellen realisieren, wenn ich es richtig verstanden habe.

[anon123]

@auch intel
Also wenn ich dich richtig verstehe, dann ist das Problem die Typisierung der Felder. Das ist doch aber keine feste Eigenschaft von relationalen Datenbanken. Wie ist das denn bei NoSQL-Datenbanken gelöst?

Bei BerkleyDB sind zum Beispiel Key und Value einfach als Binärdaten gespeichert. Der Nutzer muss selbst wissen, wie er die zu interpretieren hat. Prinzipiell gibt es keinen Grund, warum man das mit ner relationalen Datenbank nicht auch machen kann. Die typischen SQL-Abfragen gehen dann natürlich nicht mehr sinnvoll, sondern nur noch das Finden eines konkreten Schlüssels. Aber das ist bei BerkleyDB genauso und ich kann mir nicht vorstellen, dass das bei anderen NoSQL-Datenbanken anders ist.

Entweder man macht bestimmte Einschränkungen an die Datenfelder ("nur Text", "nur Zahlen", "nur JSON", "nur Binärobjekte mit dieser festen Struktur") und hat dann entsprechend optimierte Algorithmen, oder man macht keine Einschränkungen und verwendet dann allgemeine Algorithmen. Ich seh nicht wo es einen Unterschied macht, ob die Software SQL und Relationen unterstützt.

[huai wei]

Die Records sind i.d.R. gleich lang, damit man genau ausrechnen kann, was wo ist. Genaues Springen geht z.B. bei mp2, aber nicht mehr bei mp3. Daraus ergeben sich bestimmte Eigenheiten.

Varchars sind sehr "unbeliebt". ICh weiss allerdings auch nicht, wieso es kein varchar(10:123) gibt wo man 10 in die Row schreibt und den Rest hinten dran hängt/auslagert.

Man muss also wissen, welcher Datentyp der größte ist, und entsprechend Speicher im gleichen Abstand reservieren.

Bei berkeley hast du den Key und den Record, den Du zerlegen kannst. Das ist schon sehr Grob-Granular. Soweit ich weiss, nutzen die dann 1 Festplatten-Block o.ä. pro Record. Das fällt meist halt nicht auf, weil es Sparse-Files sind.
perldoc AnyDBM_File
und dort "Size Limits" mal ansehen bzw. die C-Libraries bzw. (3)-Manpages zu Berkeley-DB und den anderen dbm u.ä. geben wohl mehr Infos.

Bei SQL-Tabellen hat man 512 oder 4096-Byte-Blocks und packt dann die Records dort rein. Ggf. bleibt Luft am Ende frei. In jedem Block! dieser Tabelle. Oder man packt varchar-Daten dort rein. Das geht manchmal, aber auch nicht immer. Also wird mans wohl generell auslagern.

Und wegen der anderen Fragen: Die Abfragesprachen wollen gelernt werden. Medien-Informatiker und SQL sind oft leider wenig befreundet.

[16Bitiges Bit]

DB Man schrieb:
--------------------------------------------------------------------------------
> @anon123
> Das klingt so als wäre diese NoSQL-Db sowas ähnliches wie eine
> umkonfigurierte LDAP-DB. Stark optimiert für Lesezugriffe, sehr wenig bis
> gar nicht optimiert fürs Schreiben. Kein ACID, aber doch gut skalierbar und
> schnell, sehr schnell.
>
> Kann das sein, dass die diversen Verzeichnis-DBs die Wurzel dieser
> NoSQL-DBs sind?

LDAP ist viel neuer :)

[16Bitiges Bit]

anon123 schrieb:
--------------------------------------------------------------------------------
> @DB Man
> Wie gesagt ist NoSQL ein schlechter Begriff um irgendwelche Aussagen zu
> treffen. Da drin stecken die verschiedensten Datenbanken Da gibt es das
> dokumentenbasierte CouchDB, das objektbasierte db4o, die embedded key-value
> Datenbank BerkleyDB und vieles mehr. Die alle haben nur eine Gemeinsamkeit:
> sie können kein SQL. Sonst haben sie die unterschiedlichsten Eigenschaften,
> Ursprünge und Anwendungsfälle.
>
> Cassandra ist gibt einfach die starke Konsistenz zugunsten von Lese- und
> Schreibperformance auf, garantiert aber immerhin "eventual consistency".
> Auf andere NoSQL Datenbanken trifft das nicht zu.

Auf Lotus Notes/Dominio trifft das schon zu.