フロントエンド クエリには、キー => 値の形式でそれぞれ約 1,000 個のレコードが使用されていますが、どのストレージ ソリューションがより適切でしょうか?

1 日 1 回ファイルからインポートする必要があるので、現在、mysql テーブル ストレージを使用することを考えています。

返信内容:

この小さな問題では、キーが比較的小さい場合、すべての key-pos をメモリに配置できます。pos はファイル内の値のオフセットであり、アクセスごとに必要なディスク シークは
protocol-buf または thriftrack を使用します。ネットワーク サービスとして、プロキシのレイヤーを追加し、キー ハッシュに従って異なるサーバーに分散して圧力を軽減することもできます。

まあ、beansdb はすでに実装しているようです。これをやった。 この場合、データ間に強い相関関係はなく、ホットスポットデータは redis に保持され、他のデータは複数の mongodb に分散されます。 > 拡張機能も便利 1. メタデータの総量は、主キーインデックスを含めると 100G ～ 120G になることが予想されます

2. 現時点では、1 日 1 回ファイルからインポートする必要があります。 mysqlテーブルストレージを使用することを考えていますが、それがより良い方法であるかどうかはわかりません。これは明確ではありませんが、現在すでに 1 億件のレコードがあるのか​​、それとも毎日合計すると 1 億件になる可能性があります

これは非常に重要です。 1 億レコードです。PK でクエリを実行する場合、テーブル



3 を分割する必要はありません。非常に重要な点は、クエリだけで次のような他の操作も提供できることです。 UPDATE、INSERT は必ず明確に確認してください

4. クエリの際、PK 単一エントリまたは大規模なバッチ読み取りに基づいているかどうか、キーポイントに GROUP BY 統計、ORDER BY ページングが必要かどうか


5. 主キーは単純ですか (1 または 2 つの整数フィールドのモードです)

6. MySQL を使用している場合、非常に単純なクエリである場合は、PK を使用することを検討できます。 Handlersocket モード。複雑なクエリの場合は、SQL プロトコルを使用することをお勧めします...


handlersocket に関する推奨技術記事:
HandlerSocket の原則とその他の一連の記事

http://www.
mysqlops.com/2011/10/19/handlersocket-principle.html 1. mongodb+redis
はよりクールで、あなたのシナリオではリスクがなく (データが 1 日失われた場合でも再インポートできます)、成熟していて信頼性の高い
mongodb はデータを保存します。マスター/スレーブまたはレプリケーション セットを使用する必要があります)、redis はキャッシュを行います。
2. mysql+memcached.
それがあなたのニーズを満たせることに疑いの余地はありません。 注ぐ後は読み取り専用ですか? Javaで書くだけです。インデックスはメモリに配置され、データはハードディスクに配置されます。アクセスが冗長な場合は、キャッシュを追加するだけです。 Redis+Mysql を使用する方が適切です。Mysql はテープとして使用され、Redis はフロントエンド クエリとして使用されます。安定して速い。 k-v データをメモリにキャッシュし、高性能で成熟した安定したテクノロジを備え、マスター/スレーブ同期をサポートする redis を使用することをお勧めします。
http://www.
thuir.org/thuirdb/Weibo で見たところ、あなたのニーズが非常に一致しています。
もちろん、未成熟なテクノロジーの使用はお勧めできません。 マーク Mysql はデータの保存に使用され、redis はクエリに使用され、純粋なメモリ操作が非常に高速です。

欠点は、ハードウェア投資が大きく、1 億個のデータをすべて Redis サーバーのメモリに保存する必要があることです。redis で利用できない機能はすべて使用されません。