Ideen zu dieser Alternative zu ORM + RDBMS?

Question

Ich entwickle derzeit einen Proof of Concept für ein alternativer Datenspeicher . Der Grund dafür ist, dass ich eine überwiegend geclusterte Webanwendung verbessern muss, aber auch, weil ich mich von dem Schmerz der manchmal übermäßig komplexe ORM+RDBMS-Lösung .

Insgesamt ist die Idee einem verteilten Cache recht ähnlich mit Ausdauer (wobei der Cluster der SoR sein soll):

• ein beliebiges Objekt zusammen mit seinen Unterobjekten abrufen können, indem id (unter Angabe von Klasse und id) [nur das für den Anfang, da der Haupt Abfrage Teil ist bereits mit Lucene in meiner app gelöst].
• müssen Karten von Typen haben ( ~ Tabellen in der relationalen Welt) und darin verteilte Karten von "dehydrierten" gespeicherten Objekten (Abflachung des Objektgraphen durch Reflection Deep Cloning)
• ein Speicherprotokoll (wie z. B. Prevayler) für
  • eventuelle Wiederherstellung bei Ausfall des gesamten Clusters
  • Entwicklung (und Fähigkeit zum Refactoring von Code/zur Änderung der Struktur)
  • eventuell asynchrone Verarbeitung für andere Zwecke (Berichterstattung, was auch immer)
• eventuell später versuchen, einen statisch typisierten Abfragemechanismus zu integrieren, wie LINQ, Jaque oder JaQu von H2 / siehe ODBs / Lucene (?)
• es muss transaktionsfähig sein (allerdings ist der "JTA-Typ" nicht sicher)

Ich plane, diese Idee mit Hazelcast (ich liebe seine supereinfache API) oder Terracotta (das ich nie benutzt habe - aber ich bin mir ihres "Sweet Spots", der mittelfristigen Daten, bewusst) umzusetzen. Wenn Sie so wollen, ist mein Ziel, mehr oder weniger zu tun worüber Jonas einmal gebloggt hat . Bei der Verwendung eines solchen Systems müssten die gespeicherten Daten ungefähr in die Summe der JVM-Heaps des Clusters passen.

Dies sollte ziemlich einfach zu skalieren sein, würde die relationale Impedanzfehlanpassung (d.h. speichern wie bei einer ODB) und JDBC + E/A-Overhead vermeiden.

Kennen Sie andere Tools/Frameworks oder Kombinationen davon, die bereits ähnliche Funktionen bieten, die ich übersehe? Können Sie andere Wege vorschlagen, wie man dieses "Loswerden der DB" angehen kann? Welche Schwachstellen sehen Sie bereits in dieser Idee? Wäre es aus Sicht der Gleichzeitigkeit sinnvoll, Scala anstelle von Java in Betracht zu ziehen?

Was ist mit nicht-relationalen Datenspeichern wie Couch DB, Neo4j, HyperTable, HBase?

A ähnliche Frage wurde vor einem Monat gefragt, aber es gab keine konkrete Lösung.

Übrigens bin ich gerade über das Konzept der Enterprise Data Fabric in dem zu meiner Überraschung viele dieser Ideen beschrieben werden.

Answer 1

Auf jeden Fall geben Terrakotta einen Versuch. Es ist kostenlos (es sei denn, Sie entscheiden sich für Enterprise, das ein SLA und Support bietet). Es handelt sich sozusagen um einen Cluster auf JVM-Ebene, so dass Sie nicht die Probleme haben, die mit Sitzungen auf mehreren Boxen hinter verschiedenen JK Workern verbunden sind (vorausgesetzt, Sie verwenden dies für eine J2EE-Anwendung).

Ich schweife nur ab, also schauen Sie hier nach: http://en.wikipedia.org/wiki/Terracotta_Cluster

アップデイト zahlreiche Informationen über Terrakotta auch im Internet, z.B. http://blog.terracottatech.com/2007/12/fud_of_the_week_terracotta_doe.html

UPDATE2 Einige Hintergrundinformationen zu meinen Ansichten: Ich arbeite für ein Unternehmen mit einem ziemlich großen Publikum. Wir haben ein Enterprise-MySQL mit einem Master und etwa 5 Slaves (mal 2, wenn man bedenkt, dass wir 2 Kanäle haben, mit 4 Anwendungsservern pro Kanal), die den JDBC-Replikationstreiber von MySQL verwenden (für den wir bereits verschiedene Patches eingereicht haben). Wir verwenden Spring2.5/Hibernate3 mit Spring's deklarativem JTA-Transaktionsmanagement, so dass Read-Onlies an die Slaves gehen. Mit dem Aufkommen zahlreicher Ajax-Erweiterungen in einer zukünftigen Version unserer Website ist die Last unserer DB-Server gestiegen - wir erstellen Preiszusammenfassungen für Tausende von Produkten für alle Länder, unter Berücksichtigung von Zöllen/Steuerregeln für alle diese Länder (plus Werbeaktionen und Echtzeit-Auktionen, die die ganze Zeit laufen), dann haben die Ajax-Dienste die neuesten Preise im Handumdrehen. Terracotta entlastet die DB- und App-Server, indem es diese Preise allen App-Servern auf einer JVM-Ebene zur Verfügung stellt, wobei alle JVMs der Boxen miteinander verbunden sind. So kann Server A die Preise alle paar Minuten aktualisieren, und wenn Ajax auf Server B trifft, sind die Preise sofort verfügbar. Ich weiß, dass es Leute/Unternehmen mit ähnlichen Geschäften gibt, die wahrscheinlich bessere Ideen und Implementierungen haben, also bin ich immer offen für Diskussionen, aber das sind meine zwei Cents.

Ich lasse mich auch von den Jungs bei Facebook inspirieren, zum Beispiel von diesem sehr informativen Artikel: http://www.facebook.com/note.php?note_id=23844338919

Sie sprechen über memcached die Sie sich auch unbedingt ansehen sollten.

Answer 2

Als Neo4j in der Frage erwähnt wird, möchte ich mich mit ein paar Gedanken zur Verwendung einer Graphdatenbank in diesem Fall äußern. (Ich bin Teil des Neo4j-Teams)

• Das Abrufen von Kindern ist trivial in einem Diagramm-DB
• gibt es eine Implementierung der Karte für neo4j
• da Graphen in einer Graphen-Datenbank enthalten sind können Sie in Erwägung ziehen, nicht den Objektgraphen zu reduzieren, sondern die Daten in Knoten und Kanten/Beziehungen zu persistieren (dies gibt Ihnen mehr Flexibilität bei der Handhabung der Daten)
• neo4j ist vollständig transaktional

Mit den neuen DB-Technologien, die heute aufkommen, gibt es wirklich keinen Grund, bei einem RDBMS zu bleiben, wenn Ihre Daten nicht in das relationale Paradigma passen.

Answer 3

Mir scheint, dass Terracotta perfekt zu Ihren Anforderungen passt:

• eine Map clustern, um Kinder abzurufen über Schlüssel (z. B. geclusterte Map)
• Karte der Karten - kein Problem
• kein explizites Bin-Log - aber Terracotta speichert bereits alles auf der Festplatte, so dass ein vollständiger Neustart des Clusters bereits unterstützt wird
• bereits in Compass, Hibernate Search und Lucene für die Suche integriert
• Transaktionen? Zu langsam. Verwenden Sie den Cache als Datenspeicher. Mit Persistenz verlieren Sie keine Daten, wenn Sie in den (geclusterten) Speicher schreiben und zurück in die DB sickern.

Außerdem macht Terracotta die von Ihnen gewünschte "Spiegelung" - obwohl es die Spiegelung nicht verwendet, weil das viel zu langsam ist. Es verwendet BCM. Es werden nur Änderungen im Netz weitergegeben.

Hazelcast erfordert übrigens Serialisierung, so dass es langsam ist und mit einer Map-of-Maps-Datenstruktur überhaupt nicht gut zurechtkommt (jeder Put führt zu einer vollständigen Deep-Clone-Kopie über das Netzwerk), und es hat keine Art von Persistenz eingebaut.

Answer 4

Interessant.

Ich bin der Meinung, dass wir alle einen Zoo entwickeln, der alle Abstraktionsschichten umfasst, die wir gewöhnlich in unseren Projekten verwenden. Und jede Abstraktionsschicht ist ein völlig anderes Tier.

Mein Ziel ist es, den Zeitaufwand für die Pflege und Fütterung der Tiere so gering wie möglich zu halten, wenn ich dadurch von der Lösung des eigentlichen Problems abgelenkt werde - das sind Gemeinkosten - verschwendete Ressourcen. Je weniger und einfachere Abstraktionsebenen wir also verwenden können, desto produktiver sind wir.

Ich komme in der Regel gut mit zwei Ungeheuern aus - OOP und RDBMS, gekoppelt durch eine schöne, einfache, minimale, handgefertigte DAL. Für mich ist ORM vor allem Overhead - eine Abstraktion zu viel, und ein ziemlich hungrig ein.

Auch die Möglichkeit, Stored Procedures als Abstraktionswerkzeug zu verwenden, sollte nicht außer Acht gelassen werden. Wenn Sie sich mit SQL gut auskennen, kann es eine nützliche Ressource für die Implementierung einer leichtgewichtigen BL-Fassade sein, bei der Sie sich keine Gedanken über das ORM-Problem machen müssen.

Und dieser Beitrag deutet darauf hin, dass es für einige Anforderungen Alternativen zu RDBMS gibt.

Answer 5

Vielen Dank für Ihre Antworten.

Sie sprechen von DBs, die ich komplett aus dem Bild nehmen möchte.

Der Anwendungsfall, auf den ich abziele, ist eine kleine/mittelgroße geclusterte Webapp eines Startups (Boxen in einem LAN oder in der Cloud). Sie muss Objekte mit ~RAM-Geschwindigkeit abrufen und ziemlich leicht skalieren. Als Nebeneffekt müsste man sich keine Gedanken über DB-Server-Installationen, Impedanz-Mismatch, JDBC, Caches, Verschmutzung von Domänenmodellen mit Annotationen usw. machen.

Was ich erreichen möchte, ist wie folgt beschrieben aquí und ich würde mich über weiteres Feedback zu Ideen bezüglich der eigentlichen Implementierung freuen (warum Terracotta anstelle von Hazelcast, Serialisierung oder Deep Cloning via Reflection oder was auch immer, und auch die größten Nachteile eines solchen Ansatzes - z.B. warum würden Sie es nicht für Ihr aktuelles ORM/DB-Setup ändern).

Es muss super einfach zu integrieren sein, also wird es eine wirklich saubere Java-API haben, die die Lesbarkeit des Codes verbessert. Keine andere Software (DB, memcached wird erforderlich sein).