Wäre es eine gute Idee, Terracotta als Persistenzlösung zu verwenden (eine Datenbank zu ersetzen)? Ich frage mich speziell über Datenintegritätsprobleme und die Unterstützung von Transaktionssystemen.Terrakotta als Persistenzlösung verwenden
Terrakotta ist transactional (synchronisierte Blöcke bilden Transaktionen von modifizierten Objekten), ist aber nicht und will nicht JTA-konform sein. Es gibt eine ziemlich lange Diskussion über Transaktionen und einige verbreitete Missverständnisse über Terracotta here.
Ich schrieb eine blog post about data lifetimes und wie sollte dies Ihre Überlegungen über die Identifizierung von Möglichkeiten für die Verwendung von Terrakotta umrahmen. Kurz gesagt, Terracottas Sweet Spot ist der Anwendungsfall, in dem Sie Ausdauer und Verfügbarkeit benötigen (Ihre App könnte abstürzen, aber Sie benötigen immer noch die Daten), aber wo die Daten nicht unbedingt langfristig kritisch sind.
Ein kanonisches Beispiel sind Daten, die im Kontext einer Benutzersitzung in einer Webanwendung wichtig sind, z. B. Einkaufswageninformationen. Sie möchten diese Daten persistent behalten, damit Sie bei einem Absturz Ihrer Web-App den Einkaufswagen verwalten. Aber der Wagen selbst kann oder darf nicht gekauft werden. Also, speichern Sie es in Terracotta, bis es gekauft wird, und speichern Sie es in der Datenbank als "System of Record" -Daten.
Historisch gesehen waren die Daten, die Sie in einer Datenbank gespeichert haben, immer "System of Record" -Daten, die für den langfristigen Erfolg Ihres Unternehmens entscheidend waren: Kunden, Aufträge usw. Mit den heutigen "zustandslosen" Architekturen (die wirklich aren 't zustandslos) schieben wir alle mittelfristigen Daten in die Datenbank. Dies bedeutet, dass wir unnötig unsere Datenbank (mit zusätzlicher Arbeit und Speicherung) und unsere Entwickler (die die objekt-relationale Impedanzfehlanpassung handhaben müssen, selbst wenn sie ORM verwenden) bestrafen. Ein besserer Ansatz besteht darin, es in Objekten zu belassen und es mit Terrakotta zu verbinden. Eine Reihe von neuen Terracotta-Nutzern hat diese Technik genutzt, um ihren Datenbank-Footprint signifikant zu reduzieren (sie sparen Millionen von Dollar) und erhöhen gleichzeitig ihre Skalierbarkeit.
Es stellt sich die Frage nach dem Integrationspunkt mit der Datenbank und wie die Übergabe zuverlässig erfolgen soll. Wir sahen dies als einen Anwendungsfall in der kürzlich veröffentlichten (eine Spring/Terracotta/Tomcat/MySql-Referenz-Webanwendung). Wenn Prüfungen durchgeführt werden, wird der Status (Antworten auf Fragen, zufällige Auswahlreihenfolgen, zur Überprüfung markierte Fragen) in Terracotta gespeichert. Wenn die Prüfungen abgeschlossen sind, wird die resultierende Punktzahl berechnet und langfristig in der Datenbank gespeichert.
Um dies sicher zu tun, verwenden wir eine Hibernate-Schlüssel-Strategie, die zuerst die Datenbankzeilen-ID in dem Objekt in Terracotta generiert, dann speichert die Daten in der db und entfernt dann von Terracotta. Dieses Szenario hat eine potenzielle Race-Bedingung, wenn die App nach dem Speichern in der Datenbank, aber vor dem Entfernen von Terracotta abstürzt. In diesem Fall könnte die Anwendung versuchen, die Daten erneut in der Datenbank zu speichern und möglicherweise zwei Zeilen zu erstellen. Aber aufgrund der vorgenerierten ID können wir feststellen, ob die Zeile zuvor erfolgreich geschrieben wurde oder nicht und dieses Problem vermeiden.
Zusammenfassend glaube ich nicht, dass Terracotta Ihre DB in absehbarer Zeit ersetzen wird. Es ist zu neu, um in den meisten Geschäften überhaupt als solches betrachtet zu werden. Das Nutzungsmodell ist anders. Es gibt keine Abfrage- oder SQL-Fähigkeit in den Heapspeicher (Ihre Abfragemöglichkeit ist durch Ihr Objektmodell definiert). Ich denke, es kann und wird beginnen, die mittelfristige Datennutzung zu ersetzen, wo es eine viel billigere und einfachere Alternative ist. Einige Leute fangen jedoch an, damit für die Langzeitspeicherung zu experimentieren.
Terrakotta ist nur Java. Wenn es für Sie in Ordnung ist, in diese Technologie eingesperrt zu sein, ohne die Möglichkeit zu haben, nur einige Skripte (ohne die JVM) in anderen Sprachen zu schreiben, dann gehen Sie mit.
Der Artikel Kill Your Database with Terracotta war wirklich nett.