使うべきでない場合もあります。ここでは、実際に判断する順番どおりに並べます。そもそもキーバリューという形が正しいのか。データはどこに置かれる必要があるのか。そして、何を差し出すことになるのか。
キーが分かっているなら、kevy を使ってください。セッション ID、ユーザー ID、キューの名前、キャッシュキー。読み取りは問い合わせではなく参照です。これは思われているよりも広い範囲を覆います。さらにセカンダリインデックスとマテリアライズドビューが、問い合わせのいくつかも参照に変えます。TABLE レイヤーはその先へ行きます。型付きカラムとインデックスを一度宣言すれば(あるいは PG/MySQL のスキーマファイルを kevy-sql でコンパイルすれば)、単一テーブルの読み取りパス——インデックスされた WHERE、残りのフィルタ、ORDER BY、ページング——は参照のままです。
読み取りが本当にクエリなら、kevy を使わないでください。5 つのテーブルにまたがる結合、アドホックな分析、無関係な行にまたがり本物の分離レベルを要求するトランザクション——それは PostgreSQL の仕事であり、PostgreSQL に留めておくべきです。リレーショナルな各ワークロードが、ここでいくらかかるかを書いてあります。答えが「やめておきなさい」になるものも含めて。
1 台で足りないなら、kevy を使わないでください。クラスタモードはなく、今後もできません。1 台の kevy は毎秒数百万回の操作をこなし、RAM 予算を与えればデータセットは RAM より大きくできます(コールドな値はディスクへ退避します——RAM がキー数を、ディスクがデータ量を決めます)。それでも 1 台のスループットを超えたら、シャーディングするものが必要です。kevy は、それではありません。
これが形を決めます。どの行でも、コマンドは同じです。
| 状況 | 選ぶもの | 理由 |
|---|---|---|
| 複数のサービスがデータを共有する | サーバー | 1 プロセス、ポートで RESP。既存の Redis クライアントが、そのまま接続できます。 |
| 1 つのプログラムがデータを所有する | 組み込み | ソケットも、2 つ目のプロセスも、シリアライズも要りません。ラウンドトリップではなく、関数呼び出しです。 |
| データはユーザーの端末のもの | ブラウザ | 481 KB の WebAssembly。本物の TTL と pub/sub があり、ブラウザのファイルシステムに永続化されます。オフラインでも動きます。 |
| リクエストごとに、エッジで動く | エッジ | 暖機するものも、張りにいく接続もありません。ストアは、コードと同じ isolate の中にあります。 |
| OS もヒープもないデバイス | ベアメタル | kevy-store は no_std です。固定 arena のみ、アロケータなし。CI が push のたびに Cortex-M で起動させています。 |
選んだら固定される、というものではありません。組み込み API とワイヤプロトコルは同じ操作を公開しているので、プロセス内ストアで手狭になったプログラムは、データベースの開き方を変えるだけでサーバーに移れます。使い方を書き直す必要はありません。
ワイヤの上では、なります。RESP2 と RESP3、206 個のコマンドに対応し、クライアントライブラリは違いに気づきません。挙動もおおむね同じですが、その例外こそが要点です。シャードをまたぐ RENAME は原子的ではありません——複数キーの書き込みは shard 単位でのみ原子的です。また SCAN のカーソルは発行したサーバーでのみ有効で、これは Redis Cluster のノード単位の性質と同じです。206 個すべてのコマンドに、本当の差異と本当のコストを併記してあります。Redis の文書から書き写したものではなく、実装から読み出したものです。
もう、ありません。ティアリングをオンにして、ストアに RAM 予算を与えてください。最もコールドな値はディスク上の使い捨て value log へ退避し、アクセスされたときに戻ります。コールドキーの上でもすべてのコマンドは厳密に同じ意味を保ち、追記専用ログの永続化コントラクトは無変更です——RAM が保持できるキーの数を、ディスクがデータの量を決めます。正直な限界も述べます。既定ではオフで、v1 で退避するのは文字列とハッシュ(リスト、セット、ソート済みセット、ストリームはホットのまま)、64 バイト未満の値は決して退避されません。ティアリングのガイドに、どの数字が実測で、どれがベンチマシンの実行待ちのターゲットなのかを明記してあります。
書き込みはすべて、まず追記専用ログに入り、起動時にログが再生されます。既定の everysec の fsync なら、強制終了で失うのは最大 1 秒分の書き込みです。appendfsync = "always" にすれば失うものはありませんが、スループットを代償に払います。スナップショットは、再生にかかる時間を抑えるためだけに存在します。永続化のガイドに数字があります。
はい。プライマリ 1 台とレプリカ N 台で、本物のフェイルオーバーがあります。計画的な引き継ぎ、エポックによるフェンシングを伴うクラッシュ時の選出、そして任意で選べる一貫性の段階(WAIT、read-your-writes トークン、上限つきの遅延)。得られないのは、マシンをまたぐデータのシャーディングです。レプリカはコピーであって、切片ではありません。可用性のガイドに、フェイルオーバーでどの書き込みが生き残り、どれが生き残らないのかを明記してあります。
ありません。今後もありません。AUTH も ACL も TLS も、恒久的に対象外です。kevy はプライベートなネットワークで動かすか、それらを正しく行うプロキシの後ろに置いてください。中途半端な認証層は、正直に何もないことよりも悪いものです。人に信頼させてしまうからです。
kevy-cli export がキースペースをプレーンな RESP ファイルに書き出し、Redis 互換のサーバーなら、どれでもそれを取り込めます。そして kevy-cli digest が、何かを捨ててしまう前に、コピーが忠実であることを証明します。移行ガイドは、入ってくる手順と同じ丁寧さで、出ていく手順も扱っています。
playground を開いてください。WebAssembly にコンパイルされた本物の kevy エンジンが、あなたのタブの中で動いています。キーを書き、TTL が切れていく様子を眺め、自分のディスクに置かれた追記専用ログを覗いてみてください。録画ではありませんし、サーバーも介在しません。
