5 ポイント 投稿者 GN⁺ 2025-03-18 | 1件のコメント | WhatsAppで共有
  • DiceDBは、オープンソースの高性能で応答性の高いインメモリ(in-memory)データベース
  • 主にキャッシュとして使用され、クエリサブスクリプション(query subscription)を通じてリアルタイムデータ更新を提供
  • 最新のハードウェア向けに最適化されており、高スループットと低レイテンシを提供
  • 使いやすく親しみやすいインターフェースを備えたオープンソース
  • 性能ベンチマーク
    • Hetzner CCX23マシン(4 vCPU、16GB RAM)で、他のインメモリデータベースと比較したスループットおよび GET/SET レイテンシ
    • スループット(ops/sec): DiceDB 15655、Redis 12267
    • GET p50(ms): DiceDB 0.227327、Redis 0.270335
    • GET p90(ms): DiceDB 0.337919、Redis 0.329727
    • SET p50(ms): DiceDB 0.230399、Redis 0.272383
    • SET p90(ms): DiceDB 0.339967、Redis 0.331775

1件のコメント

 
GN⁺ 2025-03-18
Hacker Newsの意見
  • このコードには多くのバグがある

    • 例えば、ExpandID 関数は cycleMap から読み取る際にパッケージ全体のミューテックスをロックしていない
    • NextID 関数は cycleMap に書き込む際にパッケージ全体のミューテックスをロックする
    • 書き込み同士は同期されるが、読み取りとは同期されないため、ExpandIDNextID を同時に呼び出すと競合状態が発生する可能性がある
    • 趣味プロジェクトとしてはよいが、本番運用可能なシステムとは程遠い
  • DiceDB のコードベースを見て、設計についていくつか質問がある

    • このプロジェクトの目標と設計上の論理を理解したい
    • メインメモリストアはロック付きの標準 Go マップに見える
    • これは反復的な開発のための暫定的な選択なのか、それともより最適化されたデータ構造への長期的な計画があるのか気になる
    • DiceDB のリアクティブ機構、特に監視コマンド全体の再実行が興味深い
    • Eval 関数がクライアント側コマンドを実行しているように見え、これはより複雑な監視コマンドの基盤を築くものに思える
    • コマンド全体を再実行する主な動機は何なのか気になる
    • 再実行は計算コストの高い処理になり得るが、性能ボトルネックをどのように解決しているのか気になる
    • この「再実行」アプローチが、スケーラビリティと一貫性の面で他の方法と比べてどうなのか気になる
    • GET.WATCH 以外に、より複雑な監視コマンドをサポートする計画があるのか気になる
    • この設計選択のトレードオフと、プロジェクトの目標との整合性について気になる
  • この技術が実際に何なのかを説明する一文があるのか気になる

  • 偶然の道具をデータ保存技術の名前に使うのは面白い

  • DiceDB はランダムな結果を返すジョークのようなデータベース名に聞こえる

  • 4vCPU、num_clients=4 でのベンチマーク結果に大きな差がない

    • リアクティブ機能は有望に見えるが、キャッシュとしての実用性は低そうだ
    • 例えば、クライアントが購読中にマシンがダウンした場合、リアクティブ性はどうなるのか気になる
  • DiceDB と Redis の性能比較

    • DiceDB のスループットは毎秒 15655 ops、Redis は 12267 ops
    • GET の p50 と p90、SET の p50 と p90 の応答時間比較
  • GET リクエストに 20ms かかるのが理解できない

    • 既存のオープンソース実装の経験はあまりないが、以前の職場でのインメモリ応答時間は数十〜数百マイクロ秒だった
    • io_uring を使えばもっと良い数値が出ると予想される
    • NVMe から読み込み、6 ノードで復旧を行えば数十ミリ秒かかることはある
    • 単一ノードの RAM DB でこのような数値が出るのは理解できない
  • 低レイテンシ・高スループットのオープンソース key-value ストアについて経験があるか気になる

    • 特定の実装を推薦できるか気になる
  • PubSub の配信セマンティクスについて知りたい

    • ベストエフォート/最大 1 回配信なのか、再試行があるのか気になる
    • メッセージが配信される、または失敗し得るシナリオが何か気になる
  • Hetzner CCX23 マシンで毎秒 15655 ops は、インメモリデータベースとしては遅い

    • ネットワーク遅延のせいにはできない
    • supermassivedb.com は Go で書かれており、はるかに高い性能を出している
    • Dice のボトルネックを調査すべきだ
  • Nubmq よりずっと遅い