go-mysql-server - MySQL互換の純粋なGo言語製データベースエンジン

• 純粋なGoで書かれたMySQL互換データベースエンジン
• データソースに依存しないSQLエンジンであり、MySQLの構文とプロトコルを使って提供されたデータソースに対してクエリを実行
• シンプルなインメモリデータベース実装が含まれており、独自のバックエンドを実装して任意のデータソースをクエリできる

互換性

• 特定の制限事項を除けば、go-mysql-serverはMySQLの代替として利用可能
• MySQLで動作するクライアントライブラリ、ツール、クエリ、SQL構文、SQL関数などは、go-mysql-serverでも動作するはず
• 機能差異を見つけた場合は、Issueの報告を歓迎

プロジェクトの範囲

• データソースをクエリするためのSQLサーバーおよびエンジン
• テスト用途に適したインメモリデータベースバックエンド実装
• 独自データソースをクエリする新しいバックエンド実装に利用できるインターフェース
• いくつかの注意点を踏まえ、完全なデータベース実装を使えばMySQLデータベースの代替にもなり得る

go-mysql-serverの主なユースケース:

1. 組み込みのmemoryデータベース実装を使い、Goのテスト環境でMySQLの代わりに利用する
2. いくつかのインターフェースを実装し、任意のデータソースにSQLクエリでアクセスできるようにする

インメモリテストサーバーの利用

• インメモリテストサーバーは、テストにおいて実際のMySQLサーバーを置き換えられる
• 提供されているサンプルコードを使ってサーバーを起動できる
• サーバー起動後は、MySQLクライアントやGo MySQLコネクタ、mysqlシェルなどで接続可能

インメモリデータベース実装の制限事項

• 同梱されているインメモリデータベース実装は、テスト用途での利用を想定したもの
• 既知の制限事項:
  • スレッドセーフではない。同時実行の問題を避けるには、DDLとDML文を単一のgoroutineに制限する必要がある
  • トランザクションをサポートしない。START TRANSACTION、ROLLBACK、COMMIT などの文は動作しない
  • 非効率なインデックス実装。インデックス参照とJOINは、内部テーブルに対してフルテーブルスキャンを実行する

カスタムバックエンドの実装

• いくつかのインターフェースを実装することで、独自データソースをクエリするバックエンドを作成できる
• 詳細な手順はバックエンドガイドを参照

go-mysql-serverで動作するプロジェクト

• dolt
• gitbase（開発終了）
• go-mysql-serverでデータベースバックエンドを構築しているなら知らせてほしい

ライセンス

• Apache License 2.0

GN⁺の見解

• go-mysql-serverは、Goで書かれた軽量なMySQL互換データベースエンジンであり、テスト環境でMySQLを置き換えたり、独自データソースをSQLでクエリしたりする用途に有用そう
• MySQL互換性を目指しているため、既存のMySQLベースのアプリケーションを大きく修正せずに導入できると期待される
• ただし、まだ実験的なプロジェクトであり、特にインメモリ実装はテスト用途にとどまるため、本番適用時には性能と安定性の面で注意が必要そう
• バックエンド開発者にとっては、インターフェースを自ら実装して任意のデータソースを接続できる点が魅力になりそう。Doltのような実際のプロジェクト事例を参考にするとよい
• 類似のMySQL互換データベースとしては、TiDB、CockroachDB などがある。go-mysql-serverはこれらと異なり、バックエンドを自由に実装できる利点がある一方で、バックエンド開発に追加コストがかかるという欠点もある

[GN⁺]

Hacker Newsの意見

• Doltを支えるクエリエンジンとして、go-mysql-serverが最も重要
• Doltのコードの大半を書いたが、元の作者ではない。プロジェクトが始まった経緯の話が興味深い
• Doltのアイデアは魅力的だが、あまりにも異なり、重要な永続化レイヤーでもあるため、ビジネスを構築するには不十分。ただし、主要なDBが採用してくれるとよい
• MySQLからPostgreSQL、SQLiteへの対応が進めば、WordPressなどで複数DBエンジンのサポートが可能になるはず
• MySQLからSQLへのwire-protocol proxyのように見える。既定のproxied DBはDoltで、Doltから切り出されたものだと推測される
• Goのほうがよいかもしれないが、C#開発者の立場では、GC言語でDBを実装することには懸念がある。GCと格闘し、多くの一見して分かりにくい低アロケーションコードを書く必要があるだろう。小規模チームには問題ないかもしれないが、適切なスキルを持つ開発者の採用は難しいはず
• 互換性と機能が非常に限定的で、プロダクションで使うのは難しい（トランザクション非対応、非効率なインデックス実装など）。トリガーやストアドプロシージャなどをサポートしているかも気になる
• Railsプロジェクトのテスト向けに、MySQLのin-memoryな代替として使うのがどれほど難しいのか気になる。DBレイヤーは重要なので本番利用には注意が必要だが、テスト速度を上げられるなら興味深い
• TiDBはGoとRustで書かれた分散型のMySQL互換DBで、StarRocksはJavaとC++で書かれたOLAP向けのMySQL互換DB。ただ、このプロジェクトは別の観点を扱っているように思える。VitessのMySQLライブラリは使いにくいため、ORMのような抽象化レイヤー構築に使えるかもしれない
• こうした実装を見ると驚かされるが、実際に用途があるのかは疑問
• MySQLではなく、標準SQLに準拠するのはどうかという提案