EventSourcingDB 1.3.0 schreibt und liest deutlich schneller
EventSourcingDB 1.3.0 Is Available
EventSourcingDB 1.3.0 ist da: Schreiben und EventQL-Abfragen laufen erheblich schneller, auch das Lesen, und jede Anfrage ist zeitlich begrenzt. Mehr als sechzig Fixes sind eingeflossen. Die neue v2-API liefert das Ergebnis jeder akzeptierten Anfrage im Body und gibt jedem Fehler einen eigenen Code mit Link zur Erklärungsseite. Die v1-API bleibt bis 31. Januar 2027 unterstützt. Beim Upgrade sind ein Backup und das Stoppen des alten Servers Pflicht.
Sobald der Server eine Anfrage akzeptiert hat, steht ihr Ergebnis im Body.
- bythreads
Ich habe noch nie in einem IT-Betrieb gearbeitet, in dem die Fähigkeiten der Entwickler hoch genug waren, um Event Sourcing zu nutzen – gut auf dem Papier und für Neckbeards – kein Junior kann dagegen anprogrammieren.
- zbentley
EventQL scheint nett zu sein, aber
> Während eine EventQL-Vorbedingung ausgewertet wird, warten alle anderen Schreibvorgänge, sodass nichts dazwischenkommen kann; Lesevorgänge laufen derweil weiter. Damit kein Schreibvorgang die anderen lange aufhält, werden die EventQL-Vorbedingungen eines Schreibvorgangs für höchstens fünf Sekunden ausgewertet, alle zusammen, gerechnet ab dem Zeitpunkt, an dem der Schreibvorgang an die Reihe kommt: Ein Schreibvorgang, dessen Vorbedingungen länger dauern, wird abgelehnt, ohne dass etwas geschrieben wird, mit einem 400
(Aus https://www.eventfoundation.io/docs/eventsourcingdb/precondi...)
Das scheint eine riesige Fußangel zu sein. Klar, man muss keine Transaktionssemantik implementieren oder über Konsistenz/MVCC/Snapshots nachdenken. Aber um den Preis, dass „jedes UPDATE ... WHERE jeden anderen Schreibvorgang bis zu 5 Sekunden lang blockiert“? Wirklich?
Das scheint ein schlechter Kompromiss zu sein, unterlegen sowohl (mit massivem Aufwand) der Implementierung echter Transaktionalität, (mit mittlerem Aufwand, aber erheblich kompatibilitätsbrechend) dem Entfernen der Unterstützung für hierarchisch verschachtelte Subjekte, sodass die globalen Mutex-Beschränkungen für UPDATE-WHERE aufgehoben oder effizient auf ein Subjekt beschränkt werden können, oder (mit geringstem Aufwand) dem vollständigen Entfernen der Unterstützung für EventQL-Vorbedingungen. In jedem ausreichend großen System mit mehreren Entwicklern kann ich mir nicht vorstellen, dass „verwende keine EventQL-Vorbedingungen“ effektiv Bestand haben wird.
So wie es ist, habe ich das Gefühl, dass das Blockieren des Haupt-Event-Sourcing-Systems für bis zu 5 Sekunden durch eine langsame EventQL-Vorbedingung eines einzelnen Clients geradezu nach flächendeckenden Ausfallereignissen aus dem Nichts ruft.
Allerdings mag ich etwas übersehen, das dies mildert […]
- chaostheory
Das kann für persönliche Agenten nützlich sein, bei denen man Erinnerungen oder „Gedanken“ für das Leben und die Arbeit einer Person speichern möchte, die auf einer Maschine laufen, um Drift oder Halluzinationen zu verhindern … aber die Lizenzierung macht dies nicht machbar.