古き良き KVS たる DBM の最新実装である Tkrzwの連載記事 を愛読しています。実践的なアーキテクチャ選定・設計の手順と、現代の実装を学べて本当に素晴らしいです。
これまでの tkrzw 本体はローカルの DBM 機能（直接ファイルを読み書きするキーバリューストアのライブラリ機能）だけでしたが、9月になって、tkrzw-rpc として gRPC を利用したサーバ版アプリケーションが動き始めました。
生の Mac では依存管理が少々面倒になるので、手元の Docker で手軽に試せるように Dockerfile を書いてみました。最低限の get・set 手順を紹介します。
https://github.com/kawanet/tkrzw-docker/blob/main/tkrzw-rpc/Dockerfile
イメージのビルド
git clone https://github.com/kawanet/tkrzw-docker.git
cd tkrzw-docker
docker build tkrzw-rpc --tag tkrzw-rpc
ビルドは数分かかります。
ベースが ubuntu:focal なのは、とくに理由はありません。簡単そうなので。
ubuntu:bionic だと gRPC パッケージのバージョンが古くて、そのままではビルドできませんでした。
ビルド完了時に、もうちょっと不要ファイルを掃除した方がよいかも。
サーバの起動
tkrzw_server のデフォルトでは、オンメモリのハッシュの TinyDBM のサーバが 1978 番ポートで起動します。
docker run --name tkrzw-rpc -p 1978:1978 tkrzw-rpc tkrzw_server --log_level debug
テーブルごとにサーバを起動していきます。（1サーバで複数テーブル扱えないのかな？）
TinyDBM は揮発性インメモリ DBM なので、サーバが落ちるとデータも消えます。
本番環境なら、下記のような構成にするのかと思います。
- HashDBM か TreeDBM による永続化（ディスクに書き込む）
- マルチスレッド対応（CPUコア数が多ければ速くなる）
- シャーディング対応（テーブルを分割して速くなる）
- マスタ・スレーブのレプリケーション対応（read only レプリカで負荷分散できる）
- デュアルマスタ構成の相互レプリケーション対応（アクティブマスタが落ちてもサービス継続できる）
死活監視とかは自前で用意する必要があるようです。
とりあえずの get・set
gRPC クライアントの tkrzw_dbm_remote_util コマンドでサーバと通信できます。
デフォルトでローカル 127.0.0.1:1978 に接続します。
docker exec tkrzw-rpc tkrzw_dbm_remote_util set one first
docker exec tkrzw-rpc tkrzw_dbm_remote_util get one
これで first と表示されれば、成功です。
ネットワーク越しの get・set
別のインスタンスから接続する場合は、Docker for Mac なら host.docker.internal:1978 を指定します。
docker run tkrzw-rpc tkrzw_dbm_remote_util set --address host.docker.internal:1978 two second
docker run tkrzw-rpc tkrzw_dbm_remote_util get --address host.docker.internal:1978 two
これで second と表示されれば、成功です。