Auswahl einer Datenbanktechnologie

Question

Wir wollen eine Online-Plattform (API, Server, Daten, Wahoo!) Erstellen. Stellen Sie sich zum Beispiel vor, dass wir etwas wie Twitter aufbauen müssen, aber mit den Kommentaren (Tweets), die um ein Live-Event herum organisiert werden. Informationen über das Live-Event selbst müssen den Kunden so schnell und konsistent wie möglich zur Verfügung gestellt werden, während Kommentare über das Event wahrscheinlich etwas länger warten können, bis es geliefert wird. Nach dem Live-Event werden wir lesenlastig sein.

Skalierbarkeit ist sehr wichtig. Wir wollen mit der Vermietung von VPS-Slices beginnen und von dort aus skalieren. Ich bin ein großer Fan der Cloud und möchte so lange wie möglich dort bleiben. Wir werden wahrscheinlich Ruby verwenden.

Ich bin überzeugt, dass ich einen Dokumentspeicher anstelle eines RDBMS versuchen möchte. Ich mag die Idee des schemafreien Speichers und die Versprechen einer einfacheren Skalierbarkeit durch Fokussierung auf Schlüsselwerte.

Das Problem ist, ich weiß nicht, welche Technologie für unsere Plattform am besten geeignet ist. Ich habe Couch, Mongo, Tokyo Cabinet, Cassandra und ein RDBMS mit Blobbed-Dokumenten angeschaut. Irgendeine Hilfe, die das richtige Werkzeug für diesen bestimmten Job auswählt?

Answer 1

Überprüfen Sie die NO SQL-Alternativen Vergleich von BJ Clark.

Skalierbarkeit ist sehr wichtig.

Dann müssen Sie die Auszüge aus seinem Blog berücksichtigen:

1. Tokyo Cabinet - Ist nicht maßstabs
2. Redis - Ist
3. Projekt Voldemort nicht maßstäblich - Waagen
4. MongoDB - limted (sharding ist implementiert)
5. Cassandra - Waage
6. Amazon S3 - s cales
7. Couch - skaliert nicht (Clustering & Replikation)
8. MySQL - Ist nicht maßstabs

Und HyperTable betrachten. Dies ist auch ein ernsthafter Konkurrent in No-SQL-Alternativen. Es ist eine Open-Source-Implementierung des BigTable-Konzepts von Google. Ich glaube, es skaliert gut, weil es weitgehend von der chinesischen Suchmaschine Baidu und Entertainment-Portal Rediff verwendet wird.

Sie sagten:

Informationen über das Live-Event sich Kunden als schnell und konsequent wie möglich geliefert werden müssen, während Kommentare über das Ereignis kann wahrscheinlich ein bisschen länger warten sein geliefert. Wir werden lesen-schwer nach das Live-Event endet.

Dies ist so etwas wie der Ansatz von Twitter.Ihre Programmiersprache Auswahl ist auch sehr wichtig, weil Twitter ging ursprünglich mit Ruby für Back-End-Nachricht Lieferung, aber they were saying ist es nicht eine richtige Wahl, und sie haben das gesamte Nachrichtenübermittlungssystem auf die Scala Sprache verschoben.

Sie verwenden immer noch Ruby für ihr Front-End. Wenn Sie ein sehr zuverlässiges, fehlertolerantes System verwenden möchten, das sich gut für skalierbare Umgebungen eignet, sollten Sie Scala oder Erlang in Betracht ziehen.

Answer 2

Ramesh hat eine gute Zusammenfassung. Ich würde hinzufügen, dass Cassandra ein reicheres Datenmodell als Vanille-Dynamo-Klone (wie Voldemort oder Dynomite) hat: Zeilen mit benannten, sortierten Spalten und nicht nur mit Schlüssel/Wert. Cassandra wird von Twitter, Mahalo, Ooyala, SimpleGeo, WebEx und anderen verwendet (http://n2.nabble.com/Cassandra-users-survey-td4040068.html), von denen mindestens einige Cassandra-Cluster auf EC2- oder Rackspace-Cloud-Servern ausführen.

Answer 3

Wenn Sie horizontal skalieren möchten (verteilen Sie Ihre Daten über mehr als einen Knoten), müssen Sie das CAP-Theorem berücksichtigen.

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

Es ist nicht einfach Sachen, aber Sie haben zu wählen, gibt es immer eine Art von Handel ab.