3

バルクデータの永続性のためのACIDフレームワークはありますか?これにより、いくつかの基本的な検索機能も可能になりますか?私は本格的なDBMSを探しているのではなく、高速で軽量でシンプルなものを探しています停電の場合にこれを再発明することを避けるために、アトミックコミットを処理するだけの何かでさえ素晴らしいでしょう。

SQL Serverはこれには遅すぎてオーバーヘッドが多すぎますが、SQLiteはさらに遅くなります(オーバーヘッドが少なくなる可能性がありますか?)。

基本的に、毎秒大量のタイムタンピングされたデータを保存する必要があります。正規化されたデータとして、これは約10kのテーブル行に対応しますが、バイナリデータとしては、約200kbを使用して表すことができます。明らかに、200kbをディスクに書き込むことは、10k行をリレーショナルデータベースに書き込むことと比較して簡単です。

単純に1つ以上の大きなバイナリファイルに永続化してから、独自のインデックスを実装して特定のフィールドでの高速フィルタリングを可能にすることもできますが、私を怖がらせるのは非アトミックトランザクションと読み取り/書き込みロックシナリオだけです。

何かお勧めはありますか?私はC#btwを使用しているので、.NETラッパーを使用するものが優先されます。

[編集] ACIDに関して、私はこれを見つけました。たとえば、トランザクションNTFSのマネージラッパーTxFは「Vista以降」の機能ですが)。

4

1 に答える 1

1

従来のSQLベースのストレージはACIDを提供しますが、多くの一括更新は遅くなります。反対側から見ると、NoSQLソリューション/ Key-Valueストアは通常、信頼できるトランザクションを提供したり、単一のキー以外のものによる高速ルックアップのためにシームレスにインデックスを作成する方法を提供しません。したがって、両方のアプローチの利点を組み合わせたものが必要です。

CouchDB(NoSQL map / reduce document-based DB with RESTful API)の使用を検討し、次の戦略を採用します。CouchDBには、複数のドキュメントをアトミックに保存するという点でトランザクションがありませんが、単一のドキュメントを保存する場合は、超信頼性とアトミックで、マルチバージョンの同時実行制御も可能にします。

したがって、10000レコードのデータバルクがそれぞれ200〜300 kBの場合、単一のドキュメントとして保存できます。奇妙に聞こえるかもしれませんが、実際にはインクリメンタルインデックスであるドキュメントコレクションの上にビューを構築できます。また、1つのドキュメントで複数のビュー結果が生成される場合があります。ビューはjavascript(ドキュメントの作成/更新時に1回だけ評価されます)で記述されているため、キーワード、数値、日付など、javascriptで実行できる事実上すべての方法でビューにインデックスを付けることができます。ビューの結果の取得は非常に高速です。B+ツリーに事前にインデックスが付けられているためです。

このアプローチの利点:

  • CouchDBはデータ転送プロトコルとしてJSONoverHTTPを使用するため、任意のHTTPクライアントまたはRESTクライアント、あるいはネイティブC#ラッパーを使用できます(利用可能なものはいくつかあります)
  • その200kBドキュメントの一括挿入はアトミックであり、単一のHTTPリクエストを受け取ります
  • 挿入は単なるHTTPであるため、非同期になります。
  • MVCCがあります-CouchDBは同時実行性に非常に優れているため、ロックやsmthを忘れることになります。

チャンスを与えてください-それは私にたくさんの時間を節約しました。

于 2010-11-25T17:32:35.287 に答える