Persistenz-Strategie für niedrige Latenz Lese- und Schreib

Question

Ich baue eine Anwendung, die eine Funktion Bulk-Tag Millionen von Datensätzen, mehr oder weniger interaktiv umfasst. Die Interaktion mit dem Benutzer ist sehr ähnlich wie Google Mail, wo Benutzer einzelne E-Mails markieren können, oder Bulk-Tag große Mengen von E-Mail. Ich brauche auch einen schnellen Lesezugriff auf diesen Tag Mitgliedschaften als auch, und wo das Lesemuster ist mehr oder weniger zufällig.

Im Moment sind wir mit Mysql und Einfügen einer Zeile für jeden Tag-Dokument Paar. Schreiben Millionen von Zeilen zu Mysql dauert eine Weile (hohe I / O), auch mit Bulk-Einfügungen und schwerer Optimierung. Wir brauchen dies ein interaktiver Prozess zu sein, nicht ein Batch-Prozess.

Für die Daten, dass wir Speichern und Lesen, Konsistenz und Verfügbarkeit der Daten sind nicht so wichtig wie Leistung und Skalierbarkeit. So im Fall eines Systemausfalls, während die Schreibvorgänge auftreten, so kann ich mit einem gewissen Datenverlust beschäftigen. Allerdings muss die Daten auf jeden Fall in dem Sekundärspeicher an einem gewissen Punkt beibehalten werden.

Also, um es zusammenzufassen, hier sind die Anforderungen:

• Niedrige Latenz bulk schreibt von potentiell Millionen von Datensätzen
• muss Daten in irgendeiner Weise beibehalten werden
• Niedrige Latenz zufällig liest
• Durable schreibt nicht erforderlich
• Eventual Consistency ist in Ordnung

Hier sind einige Lösungen, die ich geschaut habe an:

• Schreiben hinter Caches (Terracotta, GigaSpaces, Coherence), in der Datensätze in den Speicher geschrieben werden und entleert asynchron in die Datenbank. Diese schrecken mich ein wenig, weil sie scheinen eine gewisse Komplexität der App hinzufügen, dass ich wollen würde vermeiden.
• Hoch skalierbare Schlüsselwert speichert, wie MongoDB, HBase, Tokyo Tyrant

Answer 1

Wenn Sie das Budget haben Coherence verwenden dafür, empfehle ich dies zu tun. Es gibt eine direkte Unterstützung für Schreib hinter, Eventual Consistency Verhalten in Coherence und es ist sehr Überleben sowohl in einer Datenbank Ausfall und Coherence Cluster-Knoten Ausfälle (wenn Sie> = 3 Coherence Knoten auf separaten JVMs, vorzugsweise auf separate Hosts). Ich habe implementiert diese hochvolumigen CRM für ein Fortune 100-Unternehmen E-Commerce-Website zu tun und es funktioniert fantastisch.

Einer der besten Aspekte dieser Architektur besteht darin, dass Sie Ihre Java-Anwendung Code zu schreiben, als ob keine der Schreib hinter Verhalten stattfänden, und stecken Sie dann in der Coherence-Topologie und Konfiguration, die es macht passieren. Wenn Sie später das Verhalten oder die Topologie von Coherence ändern müssen, wird keine Änderung in der Anwendung erforderlich. Ich weiß, dass es wahrscheinlich eine Handvoll vernünftiger Möglichkeiten, dies zu tun, aber dieses Verhalten in Coherence direkt unterstützt wird, anstatt zu erfinden oder Hand-Rolle einen Weg, es zu tun.

Um einen wirklich feinen Punkt zu machen - Ihre Sorge über das Hinzufügen von Komplexität der Anwendung ist ein guter. Mit Coherence Sie einfach schreiben Updates auf den Cache (oder wenn Sie Hibernate verwenden kann der L2-Cache-Provider sein). Je nach Ihrer Coherence Konfiguration und Topologie, haben Sie die Möglichkeit, Ihre Anwendung zu verwenden Schreib hinter bereitstellen, verteilt, Caches. Also, Ihre Anwendung ist nicht komplizierter (und, ehrlich gesagt nicht bewusst) aufgrund der Merkmale des Cache.

Schließlich implementiert ich die Lösung oben und von 2005-2007 erwähnt, als Coherence von Tangosol gemacht und sie hatten die bestmögliche Unterstützung. Ich bin nicht sicher, wie die Dinge sind jetzt unter Oracle -. Hoffentlich noch gut

Answer 2

Ich habe an einem großen Projekt gearbeitet, dass verwendete asyncrhonous schreibt althoguh in diesem Fall war es nur handgeschriebene Hintergrund-Threads verwenden. Man könnte auch so etwas umzusetzen, indem der db Schreibvorgang an eine JMS-Warteschlange Offloading.

Eine Sache, die sicherlich db schreibt beschleunigen wird, ist sie in den Reihen zu tun. JDBC Batch-Updates um Größenordnungen schneller als einzelne schreibt sein können, und wenn Sie tun, sie asynchron kann man ihnen nur 500 zu einer Zeit schreiben.

Answer 3

Je nachdem, wie Sie Ihre Daten organisiert ist, vielleicht würden Sie in der Lage sein, sharding , wenn die Leselatenz nicht niedrig genug ist, können Sie auch versuchen Caching hinzuzufügen. Memcache ist eine beliebte Lösung.

Answer 4

Berkeley DB hat eine sehr hohe Performance Disk-basierte Hash-Tabelle, dass Transaktionen unterstützt und integriert mit einer Umgebung Java EE, wenn Sie das brauchen. Wenn Sie in der Lage, die Daten als Schlüssel / Wert-Paare zu modellieren, ist dies eine sehr skalierbare Lösung sein können.

http://www.oracle.com/technology /products/berkeley-db/je/index.html

. (Hinweis: Oracle kaufte berkeley db etwa 5-10 Jahren, das Original-Produkt ist seit 15-20 Jahren schon)