Hallo Habr!
Diese kleine Notiz entstand während der Diskussion des Artikels
„Verteilte Monolithen ...“ . Da das Thema weitere Überlegungen erfordert, habe ich beschlossen, sie in meinem Blog zu veröffentlichen. Der Autor des Artikels beschreibt tatsächlich eine verteilte Datenbank und beweist, dass das Ereignisprotokoll die einzig richtige Speicherstruktur darin ist. Die Argumente lauten ungefähr wie folgt:
- Da das Ereignis immer räumlich / zeitlich lokalisiert ist, kann es alle Daten in sich selbst speichern (manchmal in Form von Links zu früheren Ereignissen), wodurch das Ereignis serialisierbar wird, die Lokalität erhöht, die Konnektivität verringert usw.
- Sobald ein Ereignis aufgetreten ist, ändert es sich nicht mehr (Verfeinerungen werden durch andere Ereignisse dokumentiert), wodurch der Replikationsverkehr verringert wird.
- Das Ereignisspeicherformat kann mehr oder weniger einheitlich und von einem bestimmten Themenbereich getrennt sein.
- Ereignisprotokolle können relativ problemlos aufgeteilt / zusammengeführt werden. Sie können verschiedene Arten von Ereignissen auf verschiedenen Knoten speichern, dh es handelt sich im Wesentlichen um eine verteilte Datenbank.
- Ereignisse sind nach Zeit geordnet, und diese Reihenfolge spiegelt auch einen Kausalzusammenhang wider (auf das aktuelle Ereignis kann später nicht verwiesen werden).
- Bei der Aufzeichnung eines Ereignisses ist es nicht erforderlich, andere Daten transaktional zu aktualisieren (tatsächlich ist dies erforderlich, aber in einer begrenzten Anzahl von Fällen muss beispielsweise der Kontostand des Abonnenten im Abrechnungssystem sofort relevant sein, es müssen Linkzähler aktualisiert werden usw.).
- Die Berichterstellung kann direkt aus dem Ereignisprotokoll erstellt werden, ohne dass die Daten in eine normalisierte Form konvertiert werden müssen.
In Bezug auf den letzten Punkt zeigen zahlreiche Leistungstests (einschließlich meines Blogs), dass auf moderner Hardware die Verarbeitung von einer Milliarde Ereignissen (Fakten) mit einem Single-Pass-Algorithmus mit Kurzzeitgedächtnis Minuten dauert, was für die Berichterstellung durchaus akzeptabel ist. Und da die Verarbeitung von Ereignissen verschiedener Typen, die nicht über Links verbunden sind, einfach zu parallelisieren ist, kann die Berichtszeit auf mehrere zehn Sekunden reduziert werden, ohne dass der Aufwand für das Normalisieren von Daten / Indizieren / Sammeln von Statistiken / Debuggen und Andeutungen von Abfragen anfällt, wie dies bei regulären RDBMS der Fall ist. Das Erstellen von Berichten auf der Grundlage solcher Daten macht mir daher keine Angst. Betrachten Sie das Problem jedoch allgemeiner.
Eine typische Geschäftsanwendung kann als Datentransformationskette dargestellt werden:
"Eingabe => Modell => Ausgabe". Jedes Speicherschema ist ein Kompromiss zwischen drei Extremen:
- Wir speichern die Daten im Ausgabeformat. So funktionieren verschiedene Storefronts und OLAPs, bei denen die Reaktionszeit wichtig ist. Nachteile sind bekannt - übermäßiger Speicherbedarf und niedrige Aktualisierungsrate (normalerweise Batch).
- Wir speichern Daten im Format des Domänenmodells und vereinfachen so die Berechnungsalgorithmen. Es gibt viele Nachteile: Eine doppelte Datentransformation ist erforderlich (von der Eingabe zum Modell und vom Modell zur Ausgabe), die Transaktionskosten steigen, es ist schwierig, verteilten Speicher bereitzustellen, das Ändern des Schemas ist teuer usw. Dies ist jedoch die beliebteste Option.
- Wir speichern die Daten im Eingabeformat (tatsächlich bietet der Autor des Artikels ein Ereignisprotokoll an). In diesem Fall sind die Transaktionskosten minimal, Daten können leicht aufgeteilt und zusammengeführt werden, ein einfaches, klares und stabiles Speicherschema. Gewinn! Natürlich muss man wieder programmieren lernen.
In Bezug auf meinen Interessenbereich (Unternehmensinformationssysteme) ist eine Veranstaltung ein Hauptdokument, und das Nachschlagewerk kann als frühere Veranstaltung betrachtet werden. Ich habe die Tabellenstruktur eines typischen westlichen ERP bereits in dem Artikel
„NoERP oder ein neues Erscheinungsbild ...“ beschrieben , in dem ich vorgeschlagen habe, die übermäßige Normalisierung von Daten (mit Ausnahme von Registern für Sofortbilanzen) abzuschaffen und die meisten Berechnungen / Berichte in Einzeldurchlaufzyklen neu zu schreiben, in denen die primären direkt verarbeitet werden Dokumente. Ich werde die Argumente nicht wiederholen, alles ist im Artikel angegeben, aber das von mir vorgeschlagene Schema stimmte praktisch mit der These des Autors des ersten Artikels überein, nämlich dass das Ereignisprotokoll die Daten sind. Es ist schön, wenn jemand anderes in diese Richtung denkt.
Es ist klar, dass dieser Ansatz im Vergleich zu modernen intelligenten DBMS ein Rückschritt zu sein scheint, aber in der Highloid-Welt muss man manchmal auf populäre / abstrakte / universelle Tools verzichten - zugunsten einer brutalen und effektiven imperativen Programmierung, die darüber hinaus keine teure Lizenzierung für Knoten erfordert / kernels / users.
Ich möchte separat über die Methode zum Organisieren von Beziehungen innerhalb des Ereignisprotokolls sprechen - es muss in beide Richtungen erfolgen, dh jedes Ereignis muss einen Referenzzähler für sich selbst speichern. Dies ist für die Implementierung von Single-Pass-Algorithmen erforderlich. Wir wechseln von alten zu neuen Ereignissen, zwischenspeichern gleichzeitig jedes Ereignis mit einer Anzahl von eingehenden Links ungleich Null im Speicher und löschen es erst aus dem Cache, nachdem alle verweisenden verarbeitet wurden. Das Vorhandensein des Referenzzählers verringert unangenehm die Transaktionsleistung. Wenn beispielsweise das Gegenparteiverzeichnis in jedem Dokument verwendet wird, muss der Referenzzähler in der Gegenpartei jedes Mal aktualisiert werden, wenn ein Dokument hinzugefügt wird, manchmal auf einem anderen Knoten. Dieser Ort kann jedoch universell optimiert werden, wobei verteilte Transaktionen in allen anderen Fällen vermieden werden.
Auf der Ideenebene ist dies alles für den Moment, ich hoffe immer noch auf ein bestimmtes Projekt (zum Beispiel auf der Grundlage von Geldeingängen oder Rechnungen), und wenn sich diese Gelegenheit bietet, werde ich über die Ergebnisse berichten.