GoatDB は、計算処理をクライアント側に移行することで、従来のクラウドアーキテクチャを根本から覆す斬新なデータベースソリューションとして登場しました。この軽量でリアルタイムな Deno と React アプリケーション向けデータベースは、データ管理と同期に対する従来とは異なるアプローチにより、開発者コミュニティで議論を呼んでいます。
従来のデータベースアーキテクチャの転換
GoatDB は従来のデータベースシステムと比較して根本的に異なるアプローチを取っています。重いバックエンド、複雑なデータベース、一時的なデータキャッシュを持つ薄いクライアントという標準的なクラウドファーストモデルに従うのではなく、GoatDB は Git に似たアーキテクチャを使用してアプリケーションデータの大部分の計算処理をクライアントに移行します。作成者はこの設計哲学について次のように説明しています：
「複雑なDBを持つ厚いバックエンド、一時的なデータキャッシュを持つ薄いクライアント、そしてその間でデータを移動するAPIレイヤーを持つ現代のクラウドファーストアーキテクチャを考えてみてください。これは従来の設計を根本から覆し、Gitが使用しているものに似たアーキテクチャを使って、実際のアプリケーションデータに対して計算処理の大部分をクライアントに移行する実験です。」
この転換により、リアルタイムコラボレーション機能、安全なデータ監査、そして本番環境で異なるブランチ上で複数のアプリケーションバージョンを同時に維持する能力など、興味深い副産物が生まれています。
GoatDBの主な特徴
- 専用インフラストラクチャが不要（クライアントサイドで実行）
- オフラインファースト機能による回復力
- エッジネイティブアーキテクチャ（クライアントでの処理）
- 組み込み同期機能によるリアルタイムコラボレーション
- Gitのようなコミットグラフによるデータのバージョン管理
- 暗号化検証によるセキュリティ
- 自動競合解決
クエリパフォーマンスと実装
GoatDB はソートやフィルタリングを行うためのプレーンな TypeScript 関数を通じてクエリを処理します。サーバー側のインデックス作成に依存する従来のデータベースとは異なり、GoatDB はUIスレッドのブロックを防ぐためにコルーチンで線形スキャンを実行します。システムはバージョン管理の基盤を活用してクエリ結果を段階的に更新し、大量のデータニーズを持つアプリケーションに適しています。
ドキュメントで共有されているベンチマークによると、GoatDB は複数のユーザーによってリアルタイムで編集される数十万のアイテムを処理できるとのことです。パフォーマンスメトリクスによれば、読み取り操作はアイテムあたり0.001ミリ秒未満で、10万アイテムのセットから約3,000アイテムをフィルタリングするクエリは約100ミリ秒で完了するとされています。
GoatDB ベンチマーク結果 (2018年 MacBook Pro 上)
- 書き込み: アイテムあたり約0.25ms
- 読み込み: アイテムあたり0.001ms未満
- クエリ: 10万アイテムのセットから約3千アイテムをフィルタリングするのに約100ms
- リポジトリの開封: 10万コミットあたり1.5秒未満
ランタイム要件と互換性
現在、GoatDB はランタイム環境として Deno を必要としますが、React との統合はオプションです。この要件はアクセシビリティについていくつかの議論を引き起こしています。プロジェクトは現在 Deno に限定されていますが、開発者たちは将来的に他のフレームワークやランタイムのサポートに取り組んでいると示唆しています。
GoatDB はクライアント側とサーバー側の両方で動作する対称的な設計を特徴としています。クライアント側のストレージには、OPFS（Origin Private File System）と IndexedDB の両方のバックエンドを提供し、ブラウザ環境でのデータの永続化方法に柔軟性を持たせています。
既存のソリューションとの比較
このデータベースのアプローチは、PouchDB や SQLite のような確立されたソリューションと比較されています。CouchDB と同期する PouchDB に対する利点について質問されたとき、GoatDB の作成者はスケーラビリティが主な差別化要因であると強調しました。一部のコミュニティメンバーは、SQLite（WASM モジュールとして）のような既存の技術が同様の目的を果たす可能性があるのに、新しいデータベースソリューションを作成することがパフォーマンス上のメリットで正当化されるかどうかという疑問を投げかけています。
注目すべき違いは、GoatDB が従来のデータベースとしてラップされた B ツリー構造ではなく、Git に似た分散型レプリケーションコミットグラフとして実装されていることです。このアーキテクチャにより、クライアントはサーバーが利用できない場合でも作業を継続でき、再接続時にサーバーの状態を復元できるオフラインファースト機能が可能になります。
メモリに関する考慮事項と制限
GoatDB のクライアント側アプローチの実用的な制限はメモリ使用量です。データは主にメモリ内で処理されるため、アプリケーションはクライアントデバイスの利用可能なメモリによって制約されます。しかし、開発者たちは GoatDB がデータの一部を明示的にディスクにアンロードすることを許可していると指摘しており、これはデスクトップアプリケーションでファイルを閉じるのと同様に、メモリ制約を管理するのに役立ちます。
データベースの小さなフットプリント（パッケージサイズはわずか8.2KB）は、JavaScript ランタイムがすでに利用可能なウェブアプリケーションにとって特に魅力的であり、アプリケーションに不必要な重さを追加することへの懸念に対応しています。
サーバー中心のデータベースソリューションが支配する環境において、GoatDB は現代のウェブアプリケーションのためのデータアーキテクチャを再考する興味深い実験を表しています。すべてのユースケースに適しているわけではありませんが、クライアント側のデータ管理に対する革新的なアプローチは、リアルタイムコラボレーションとオフライン機能を必要とするアプリケーションにとって魅力的な利点を提供します。