バックエンドが行う書き込みの一部を RDBMS から NoSQL に移行する予定です。これが主なボトルネックになると予想されるからです。
私たちのビジネス プロセスでは、95% ～ 99% の同時書き込みがあり、平均して同時読み取りは 1% ～ 5% しかありません。膨大な量のデータが含まれるため、インメモリ NoSQL DB は収まりません。
この場合、どの NoSQL DB オンディスクが最適ですか?
ありがとう！
質問する
4189 次
1 に答える
2
同時書き込みによって競合が発生し、データの整合性が問題になる場合、NoSQL はおそらく最適な方法ではありません。これは、「楽観的並行性」をサポートするデータ管理で簡単にテストできます。これにより、実際のロック競合を測定し、詳細に分析できます。
問題が発生することを期待している」と詳細を説明せずにあなたが言うと、少し驚きます。1 つ答えさせてください。あなたが私たちに提供してくれた事実に基づいて。スケーラブルな同時書き込みの処理など
何らかのユースケースや、問題を詳細に理解するのに役立つものを提供していただけると助かります。
2 つの例を挙げてみましょう。高度な書き込みディスパッチャ、データのバージョン管理などを備えたインメモリ データベースでは、1M の「ライター」を簡単に使用できます。ライターはネットワーク要素であり、アプリケーションは高度な NMS システムです。大量の書き込み、競合なし、楽観的な同時実行性、最大 16 GB のメモリ内書き込みバッファリング、200 以上の仮想スピンドル (SSD または磁気ディスク) への非同期並列書き込みなど。新しいデータを食べる真の「吸盤」です! パフォーマンスを限界まで拡張する優れた候補です。
2 番目の例: まばらな番号空間を持つ MSC。たとえば、モバイル番号は番号の「クラスタ」です。膨大な数のスペースですが、最大。2 億個の個別アドレス。競合する書き込みがある非常にまれな状況。RDBMS は、メモリ マップされたスパース ファイルに置き換えられました。そして、パフォーマンスの向上は 1000 倍に近く、最高の場合でも 1000 倍、最悪の場合でも 100 倍に「わずか」でした。置換コードは C の約 300 行でした。解決する問題にぴったりだったので、これは真の BigNoSQL でした。
要するに、詳細を知らなければ、あなたの質問に答える「特効薬」はありません。私たちはウェアウルフを追いかけているわけではなく、ただの「大きな悪いデータ」です。ワークロードが「トランザクション」であるかどうかがわからない場合。数または IO と遅延の影響を受けやすい、または「BLOB のような」別名。ストリーミング メディア、地理データなど、何かを約束しても 100% 間違った結果が得られます。帯域幅と io-rate/latency/transactions は、実生活では多かれ少なかれトレードオフです。
于 2012-10-06T17:02:01.753 に答える