Ampbase nutzt Tigris statt Postgres und baut die Datenbank selbst
Object storage is all you need
Ampbase verwendet Tigris Object Storage direkt als Datenschicht und implementiert die vier wichtigsten Datenbankfunktionen – Unique Constraints, Transaktionen, Indizes und Historientabellen – auf Basis von Conditional Writes und starker Read-after-Write-Konsistenz. Der Artikel zeigt, wie das in der Praxis funktioniert, wo die Grenzen liegen und warum Isolation bereits in der Infrastruktur verankert ist.
Wenn man zu einer Datenbank-Engine greift, greift man eigentlich zu vier grundlegenden Funktionen: Unique Constraints, Transaktionen, Indizes und Historientabellen.
- dullcrisp
Dieser Artikel liefert nicht viel Motivation dafür, warum man das tun sollte.
Für mich liest er sich ein bisschen wie: Wie wir unser Büro ohne Schreibtische gebaut haben: Es stellt sich heraus, dass man, wenn man zwei Stühle aufeinanderstapelt, den Laptop auf dem oberen balancieren kann und unten auch noch ein Regal für seine Sachen hat.
- ryanbrunner
Artikel wie dieser erinnern mich an den Innovation Tokens-Artikel.
Deine Zeit und Aufmerksamkeit sind als Entwickler kostbar. Ich bin mir absolut sicher, dass es möglich ist, Eindeutigkeitsbeschränkungen, Transaktionen, Indizes und Historie selbst zu implementieren, aber ist das wirklich die wertvollste Verwendung deiner Zeit? Wahrscheinlich besteht kein Bedarf an einer einzigartigen Lösung, also erfindest du buchstäblich etwas neu, das jemand bereits hatte, ohne großen Nutzen.
Wäre deine Zeit nicht besser damit verbracht, die Probleme zu lösen, die das, was du baust, eigentlich lösen soll?
- arpinum
Das ist frustrierend zu lesen. Tigres basiert auf FoundationDB, stellt aber nicht alle FoundationDB-Operationen wie Transaktionen, Range-Reads und Get-Mapped-Range bereit. Sie gehen alle möglichen Umwege, um diese Probleme zu bewältigen, einschließlich einer Datenbank zum Caching (und sie berücksichtigen keine Thundering-Herd-Probleme).
Was wäre, wenn du einfach FoundationDB betreiben würdest?
- agentultra
> In der Praxis greift man, wenn man zu einer Datenbank-Engine greift, eigentlich nach vier grundlegenden Funktionen: Eindeutigkeitsbeschränkungen, Transaktionen, Indizes und Historientabellen.
Das könnte eine sehr spezifische Annahme sein. Was ist mit Serialisierbarkeit? Replikation? Materialisierten Ansichten? Prozeduren? Locking? Zugriffskontrolle?
Es ist cool, zu experimentieren und neue Ansätze auszuprobieren. Ein netter hier.
Könnte trotzdem am Ende zu Postgres wechseln.
- shrubble
"Der Hauptnachteil dabei ist die Tatsache, dass Objektspeicher keine Transaktionen hat, sodass man nicht sicherstellen kann, dass sowohl das Anhängen des Events als auch das Aktualisieren des Zustands der Welt in einer atomaren Einheit geschehen. Wir schreiben zuerst den Zustand und dann das Event, sodass ein Prozess, der dazwischen stirbt, den Zustand korrekt hinterlässt und im Verlauf einen Eintrag fehlen lässt. Nichts erkennt das, denn es zu erkennen würde bedeuten, dass etwas das Log liest und es mit dem Zustand vergleicht, und der ganze Sinn ist, dass nichts das tut. Also ist jeder Eintrag im Log wirklich passiert. Was man nicht bekommt, ist die Garantie, dass alles, was passiert ist, darin steht."
Also haben sie ein Ding gebaut, das vorgibt, Transaktionen zu handhaben, es aber nicht wirklich richtig tut?
Ich schätze, ich sollte froh sein, dass sie kein Fintech-Startup sind...