go-mysql-server – Eine in reinem Go geschriebene MySQL-kompatible Datenbank-Engine

• Eine MySQL-kompatible Datenbank-Engine, geschrieben in reinem Go
• Eine SQL-Engine, die nicht an eine bestimmte Datenquelle gebunden ist und Abfragen auf bereitgestellten Datenquellen mit MySQL-Syntax und -Protokoll ausführt
• Enthält eine einfache In-Memory-Datenbankimplementierung; durch Implementierung eines eigenen Backends lassen sich beliebige Datenquellen abfragen

Kompatibilität

• Abgesehen von bestimmten Einschränkungen kann go-mysql-server als Ersatz für MySQL verwendet werden
• Client-Bibliotheken, Tools, Abfragen, SQL-Syntax und SQL-Funktionen, die mit MySQL funktionieren, sollten auch mit go-mysql-server funktionieren
• Falls Funktionsunterschiede entdeckt werden, bitte ein Issue melden

Projektumfang

• SQL-Server und -Engine zum Abfragen von Datenquellen
• Eine In-Memory-Datenbank-Backend-Implementierung, die sich gut für Tests eignet
• Schnittstellen, die für die Implementierung neuer Backends zum Abfragen eigener Datenquellen verwendet werden können
• Unter Berücksichtigung einiger Hinweise und bei Verwendung einer vollständigen Datenbankimplementierung kann MySQL ersetzt werden

Wichtige Anwendungsfälle von go-mysql-server:

1. Ersatz für MySQL in Go-Testumgebungen mithilfe der eingebauten memory-Datenbankimplementierung
2. Durch Implementierung einiger Schnittstellen kann auf beliebige Datenquellen per SQL-Abfrage zugegriffen werden

Verwendung des In-Memory-Testservers

• Der In-Memory-Testserver kann in Tests einen echten MySQL-Server ersetzen
• Der Server kann mit dem bereitgestellten Beispielcode gestartet werden
• Sobald der Server läuft, ist eine Verbindung über MySQL-Clients, Go-MySQL-Connectoren oder die mysql-Shell möglich

Einschränkungen der In-Memory-Datenbankimplementierung

• Die mitgelieferte In-Memory-Datenbankimplementierung ist für den Einsatz in Tests gedacht
• Bekannte Einschränkungen:
  • Nicht threadsicher. Um Nebenläufigkeitsprobleme zu vermeiden, sollten DDL- und DML-Anweisungen auf eine einzelne Goroutine beschränkt werden
  • Unterstützt keine Transaktionen. Anweisungen wie START TRANSACTION, ROLLBACK und COMMIT funktionieren nicht
  • Ineffiziente Indeximplementierung. Index-Lookups und Joins führen bei internen Tabellen vollständige Tabellenscans durch

Implementierung benutzerdefinierter Backends

• Durch Implementierung einiger Schnittstellen kann ein Backend erstellt werden, das eigene Datenquellen abfragt
• Detaillierte Anweisungen finden sich im Backend-Guide

Projekte auf Basis von go-mysql-server

• dolt
• gitbase (eingestellt)
• Falls Sie ein Datenbank-Backend mit go-mysql-server entwickeln, lassen Sie es uns wissen

Lizenz

• Apache License 2.0

Meinung von GN⁺

• go-mysql-server wirkt wie eine leichtgewichtige, in Go geschriebene MySQL-kompatible Datenbank-Engine, die sich gut als MySQL-Ersatz in Testumgebungen oder zum Abfragen eigener Datenquellen per SQL eignet
• Da das Projekt auf MySQL-Kompatibilität abzielt, dürfte es sich voraussichtlich auch in bestehende MySQL-basierte Anwendungen integrieren lassen, ohne dass große Änderungen nötig sind
• Es handelt sich jedoch noch um ein experimentelles Projekt; insbesondere die In-Memory-Implementierung ist auf Tests beschränkt, daher ist beim Einsatz in Produktion in Bezug auf Leistung und Stabilität Vorsicht geboten
• Für Backend-Entwickler dürfte attraktiv sein, dass sich durch eigene Implementierung der Schnittstellen beliebige Datenquellen anbinden lassen. Reale Projekte wie Dolt sind dabei eine gute Referenz
• Ähnliche MySQL-kompatible Datenbanken sind etwa TiDB und CockroachDB. go-mysql-server hat ihnen gegenüber den Vorteil frei implementierbarer Backends, allerdings auch den Nachteil zusätzlichen Entwicklungsaufwands für das Backend

[GN⁺]

Hacker-News-Kommentare

• Als Query-Engine, die Dolt antreibt, ist go-mysql-server am wichtigsten
• Ich habe den Großteil des Codes von Dolt geschrieben, bin aber nicht der ursprüngliche Autor. Die Hintergrundgeschichte zum Projektstart ist interessant
• Die Idee von Dolt ist reizvoll, aber die Persistence Layer ist zu anders und zu wichtig, um darauf ein Business aufzubauen. Es wäre aber gut, wenn Mainstream-Datenbanken das übernehmen würden
• Wenn die Unterstützung von MySQL zu PostgreSQL und SQLite weiter ausgebaut wird, könnte das Multi-DB-Engine-Support in WordPress und ähnlichen Projekten ermöglichen
• Es wirkt wie ein Wire-Protocol-Proxy von MySQL zu SQL. Die standardmäßig proxied Datenbank ist Dolt, und vermutlich wurde es daraus herausgelöst
• Go mag besser geeignet sein, aber aus Sicht eines C#-Entwicklers ist es bedenklich, eine Datenbank in einer GC-Sprache zu implementieren. Man müsste gegen den GC ankämpfen und viel nicht offensichtlichen Code mit geringen Allokationen schreiben. Für kleine Teams mag das in Ordnung sein, aber es dürfte schwer sein, Entwickler mit den passenden Fähigkeiten zu finden
• Kompatibilität und Funktionsumfang sind sehr eingeschränkt, daher ist ein Einsatz in Produktion schwierig (keine Unterstützung für Transaktionen, ineffiziente Index-Implementierung usw.). Ich frage mich auch, ob Trigger, Stored Procedures und Ähnliches unterstützt werden
• Ich frage mich, wie schwierig es wäre, das als In-Memory-Ersatz für MySQL zum Testen eines Rails-Projekts zu verwenden. Da die DB-Schicht wichtig ist, wäre in Produktion Vorsicht geboten, aber wenn es Tests beschleunigen könnte, wäre es interessant
• TiDB ist eine verteilte, zu MySQL kompatible Datenbank, die in Go und Rust geschrieben ist, und StarRocks ist eine zu MySQL kompatible OLAP-Datenbank in Java und C++. Dieses Projekt scheint aber eine andere Perspektive zu verfolgen. Da die Nutzung der Vitess-MySQL-Bibliothek schwierig ist, könnte es vielleicht zum Aufbau einer Abstraktionsschicht wie eines ORM verwendet werden
• Solche Implementierungen sind beeindruckend, aber ich frage mich, ob es dafür echte Anwendungsfälle gibt
• Es wird vorgeschlagen, statt MySQL lieber standardkonformes SQL zu unterstützen