4

次のパラメータを持つデータベースがあります。

  • 30k レコード、サイズ 7MB
  • 20回の挿入/秒
  • 1000 更新/秒
  • 1000 範囲選択/秒、セカンダリ インデックスごと、それぞれ約 10 行
  • 少なくとも 1 つのセカンダリ インデックスが必要です
  • キーが 75 秒間更新されない場合にキーを期限切れにする何らかのメカニズムが必要です (プログラムによるガベージ コレクターを介して実行できますが、追加の 'last_update' インデックスが必要になり、負荷が追加されます)。
  • 一貫性は必要ありません
  • 耐久性は必要ありません
  • db はメモリに格納する必要があります

今のところ Redis を使用していますが、セカンダリ インデックスがなく、keys index:foo:*遅すぎます。Membase にはセカンダリ インデックスもありません (私の知る限り)。MongoDB および MySQL メモリ エンジンには、テーブル レベルのロックがあります。ユースケースに適合するエンジンは?

4

4 に答える 4

2

http://tarantool.org/を使用してみてください 。セカンダリ インデックスがあり、完全にインメモリです。また、高速非同期 IProto プロトコルを使用します。

安定していて信じられないほど高速であることが証明されました。

于 2012-12-14T09:43:05.680 に答える
0

私は彼が7MB /レコードを意味していると思っていました. もう 1 つのオプションは、Scalable-SQL を使用する Cassandra の上にある PlayOrm です。より多くのマシンを使用すると、ディスクが範囲スキャンなどで並行して動作するため、パフォーマンスが向上する可能性があります。

于 2012-10-19T21:28:27.990 に答える
0

指定したパフォーマンス要件を達成できれば、DB がメモリ内にあるかどうかは関係ないと思います。

パフォーマンスの目標は、レプリケートされておらず、シャーディングされていない単一の MongoDB インスタンスの機能の範囲内です。Mongo はメモリ マップ ファイルを使用するため、すべてのデータはメモリ内にありますが、DB は継続的にディスクにフラッシュされます。デフォルトでは、Mongo は「安全でない」モードを使用します。これにより、ディスク I/O の負担が大幅に軽減されます。DB が行うべきことをアプリケーション コードで実行しようとするのではなく、ユース ケースを検討する価値があります。

レプリカ (Mongo のクラスタリングの用語) やシャーディングを追加すると、必要に応じてパフォーマンスを簡単に向上させることができます。複数のインデックス (複合インデックスを含む)、柔軟なクエリ、一括挿入、およびアトミック更新は、パフォーマンスを向上させ、アプリケーション コードの負担を軽減する優れた機能です。

于 2012-10-20T05:30:43.233 に答える