Show HN: LearnDB – ein von Grund auf in reinem Python implementiertes RDBMS (SQLite-Klon)

• LearnDB ist ein relationales Datenbankmanagementsystem (RDBMS) und SQLite-Klon, das von Grund auf implementiert wurde, um die internen Strukturen von Datenbanken besser zu verstehen
• In reinem Python geschrieben, daher ohne Build-Schritt, standardmäßig mit Zero-Config und einer Struktur, in der Konfigurationen überschrieben werden können
• Bietet learndb-sql mit Unterstützung für select, from, where, group by, having, limit, order by sowie einen benutzerdefinierten Lexer und Parser auf Basis von lark
• Besteht aus einer Engine, die SQL-Anweisungen entgegennimmt und Tabellen sowie Daten der Datenbank manipuliert, sowie einer festplattenbasierten btree-Datensicherungsstruktur
• Unterstützt die Nutzung per REPL, durch Import als Python-Modul und durch Übergabe von Befehlsdateien an die Engine
• Die Codebasis eignet sich gut zum Tüfteln, hat aber wesentliche Einschränkungen und sollte nicht als echte Speicherlösung verwendet werden
  • Gleitkommaarithmetik ist im Vergleich zu IEEE754 stark vereinfacht implementiert
  • Allgemeine Utility-Funktionen wie die Erweiterung von Wildcard-Spalten wie select * ... werden nicht unterstützt
• Für die Ausführung in der Entwicklung werden Linux/macOS und Python 3.9 oder neuer benötigt; für exklusiven Lesezugriff auf Datenbankdateien wird fcntl verwendet
• Als Referenzmaterial wurden das Datenbank-Tutorial von cstack, SQLite Database System: Design and Implementation, die SQLite-Dateiformatdokumentation und die PostgreSQL-Dokumentation verwendet

[GN⁺]

Meinungen auf Hacker News

• Ein solches System in einer Sprache wie Python zu schreiben, halte ich eher für eine hervorragende Wahl. Datenbanken werden normalerweise in C++ oder C geschrieben, aber für mich ist Python viel lesbarer und zugänglicher.
  Wenn man es ernsthaft auf Performance anlegt, kann man es später in eine Low-Level-Sprache portieren; in der jetzigen Form ist es als Lernprojekt nützlich.
  Ich habe auch eine verteilte, quasi multimodale Datenbank gebaut, die SQL/Graf-Cypher/Dokumente/DynamoDB-Stil mischt, um zu lernen, wie Datenbank-Engines in verteilten Umgebungen funktionieren können: https://GitHub.com/samsquire/hash-db

  • Deshalb scheint es wohl eine Community rund um reine Java-relationale Datenbanken zu geben. Wie Hypersonic, H2, Derby und Ähnliches: Wenn man keine Größenordnung für Großrechner braucht, sind Datenbanken leicht bereitzustellen und zu nutzen und lassen sich bei Bedarf auch einfach In-Memory einbetten.
  • Stimme völlig zu. In dieser Hinsicht war die ugit-Serie, in der Git von Grund auf in Python gebaut wird, wirklich gut: https://www.leshenko.net/p/ugit/
  • Ich weiß nicht recht. Python ist genauso schlecht wie C/C++, aber wenn man lernen will, wie man eine Datenbank baut, hat es den Nachteil, dass man in Python viele der interessanten Teile, mit denen man sich beschäftigen sollte, kaum berührt.
    Sowohl C als auch Python wirken zugänglich, wenn man schlechtes Sprachdesign, Inkonsistenzen und diverse Fallstricke ignoriert und nur auf die einfachen Teile schaut. Mit C hat man aber immerhin die Chance zu lernen, wie man es richtig macht; mit Python erfährt man womöglich nicht einmal, wie die reale Welt aussieht.
  • Tolle Arbeit. Mir ging es ähnlich, und dank Python konnte ich mich auf die High-Level-Konzepte konzentrieren. Allerdings gab es zwischendurch auch Momente, in denen ich mir gewünscht hätte, es wäre mit statischer Typisierung und in einer kompilierten Sprache umgesetzt.

• Vor sehr langer Zeit hat jemand SQLite einmal von C nach C# neu geschrieben/portiert: https://code.google.com/archive/p/csharp-sqlite/wikis/Letter...
  Es ist auch sehenswert, wie sehr Dr. Richard Hipp diese Arbeit begrüßt hat.
  Auf GitHub ist es vermutlich hier zu finden: https://github.com/CsharpDatabase/CsharpSQLite und es könnte inzwischen noch weitere Klone geben.

• Großartig. Das war sicher eine interessante und lohnende Erfahrung.
  Ich weiß, dass es nicht darauf ausgelegt war, schnell zu sein, aber ließen sich aus Spaß ein paar Benchmarks erstellen?

  • Etwas off-topic, aber kennt jemand gute Materialien, Vorträge oder Blogposts darüber, wie man nützliche Benchmarks schreibt?
  • Es wäre wohl auch eine interessante Übung, so etwas wie TPC-C in learndb zu implementieren und zu sehen, was passiert.

• Durch diesen Beitrag habe ich von Lark erfahren, einer ziemlich gut aussehenden Parser-Bibliothek für Python.
  Das JSON-Tutorial auf der Website ist hervorragend. Es zeigt erst, wie man einen einfachen Parser für JSON baut, und behandelt dann recht ausführlich, wie man die Performance verbessert: https://lark-parser.readthedocs.io/en/latest/json_tutorial.h...
  Die im RDBMS-Projekt verwendete Grammatik ist hier: https://github.com/spandanb/learndb-py/blob/master/learndb/l...

  • Für Python-Projekte kann ich Lark sehr empfehlen. Es ist einfach zu benutzen.
    Beim Debuggen der Grammatik war die IDE sehr nützlich: https://www.lark-parser.org/ide/
    EvaDB verwendet Lark für eine SQL-ähnliche Sprache, die auf die Nutzung von AI-Modellen zugeschnitten ist: https://github.com/georgia-tech-db/evadb/blob/master/evadb/p... https://github.com/georgia-tech-db/evadb/
    Wenn euch Lark gefällt, lohnt es sich auch, ein Sponsoring in Betracht zu ziehen: https://github.com/sponsors/lark-parser
  • Eine DSL in einem String — ist das wirklich ein guter Ansatz? Mir fällt nicht ein, dass ich so etwas in Python schon einmal verwendet oder gebraucht hätte, aber ich frage mich, ob nicht ein besserer Weg möglich wäre.
    Allein mit dicts mit erwarteten Schlüsseln und Komposition über den bitweisen OR-Operator könnte man viele Grammatikformen grob abbilden; wäre das nicht besser? Imports könnten Imports bleiben, und man könnte das vermutlich irgendwie kombinieren.
    Das war nur mein erster Gedanke beim kurzen Draufschauen, vielleicht übersehe ich etwas.
  • Ich will nicht unhöflich klingen und erkenne an, dass diese Arbeit großartig ist und eine Methode, etwas Neues zu lernen. Aber wenn die Parser-Generierung nicht das Endziel ist, sondern ein Mittel, um den AST in der Datenbank auszuführen, frage ich mich, was man allein durch den Parser-Teil lernt.
    Gibt es Stellen, an denen man weiter optimieren muss, um den generierten Parser effizienter zu machen?
    Wäre der logische nächste Schritt, aus dem AST den optimalen Query-Plan zu erzeugen?

• Sehr gut
  SQLite ist sehr schwer zu lesen, aber diese Implementierung ist ziemlich gut verständlich. Besonders der Teil mit der virtuellen Maschine: https://github.com/spandanb/learndb-py/blob/master/learndb/v...
  Man kann sie mit dieser Datei vergleichen: https://github.com/sqlite/sqlite/blob/master/src/vdbe.c
  Ich frage mich allerdings, wie vollständig dieses LearnDB ist. SQLite ist nicht nur deshalb schwer zu lesen, weil es alt ist, sondern auch, weil es viele Teile von SQL abdeckt und durch das Einhalten der SQL-Spezifikation komplex wird
  SQLite hat eine hervorragende Test-Suite; es wäre daher wohl gut, diese Tests gegen diese Implementierung laufen zu lassen

• Wirklich gut, und es wirkt wie eine gute Methode für Leute wie mich, Datenstrukturen und Algorithmen besser zu lernen. Ich kann erklären, wie ein B+-Baum funktioniert, aber wenn ich ihn selbst programmieren sollte, würde ich wohl ins Stocken geraten
  Da ich Datenbanken und Python mag, war das Durchsehen wirklich interessant

  • Definitiv. Die Implementierung des B-Baums war die erste Motivation, dieses Projekt zu starten. Besonders die Details rund um das Rebalancing und Splitten von Knoten waren wichtig
    Außerdem fügte die Tatsache, dass die Struktur auf der Festplatte gespeichert wird, beim Nachdenken über die Implementierung eine weitere Komplexitätsebene hinzu

• Wie viel von der SQLite-Test-Suite könnte es wohl bestehen?

• Unterstützt es ACID-Garantien oder Query Planning/Optimierung?
  Ich frage nicht, weil es das können müsste, sondern weil ich wissen möchte, wie weit du es über B-Bäume und SQL hinaus versucht hast
  Ich würde so etwas auch irgendwann gern einmal ausprobieren. Tolle Arbeit

  • Was ACID-Garantien angeht: Das Konzept, mehrere Statements atomar zu bündeln, also Transaktionen, gibt es nicht
    Ansonsten ist es aber eine Single-File-Datenbank, und es kann auch nur eine learndb-Instanz den Datenbank-File manipulieren. Daher erhält man Konsistenz und Isolation insofern, als es eine Datenbank mit nur einer Verbindung ist
    Dauerhaftigkeit bekommt man in dem Maße, in dem das Dateisystem Dauerhaftigkeit bereitstellt. Es liegt also irgendwo im Bereich der ACID-Eigenschaften
    Query Planning/Optimierung ist noch nicht implementiert, aber ich habe darüber nachgedacht, wo ein Optimierungsmodul hineinpassen könnte. Der Parser gibt einen AST aus, und dieser AST oder eine daraus abgeleitete Zwischenrepräsentation könnte optimiert werden
    Mit anderen Worten: Bevor die VM den AST ausführt, könnte sie den AST umschreiben oder Knoten löschen

• Etwas anderes Thema, aber gibt es in Python etwas wie mapDB?
  https://mapdb.org

• Großartiges Projekt. Der Code ist sehr gut lesbar, und auch die Kommentare sind hervorragend