古き良き 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 と表示されれば、成功です。