Cometサーバーによってサービスされる(AJAXベースの)インスタントメッセンジャーをデプロイします。法的な保持要件を満たすために、送信されたメッセージを長期アーカイブの目的でDBに保存する必要があります。
このwrite-once、read never(まれな例外を除く)要件で最高のパフォーマンスを提供するDBエンジンはどれですか?
少なくとも5000インサート/秒が必要です。 MySQLもPostgreSQLもこれらの要件を満たすことができないと思います。
より高性能なソリューションの提案はありますか? HamsterDB、SQLite、MongoDB ...?
データをクエリする予定がない場合は、データベースにまったく保存しません。フラットファイルに書き込むだけのパフォーマンスに勝るものはありません。
考慮したいのは、スケーリングの問題、フラットファイルへのデータの書き込みが遅い場合に何が起こるか、より高速なディスクなどに投資するかどうかです。
考慮すべきもう1つのことは、各サーバーのログを調整して手動で統合しなくてもサーバーを追加できるように、サービスをスケーリングする方法です。
編集:あなたはそれをデータベースに入れたいと書いた、そして私はまたデータをオンラインにすることに関するセキュリティの問題、あなたのサービスが危険にさらされたときに何が起こるか、あなたの攻撃者がの履歴を変更できるようにしたいですか?何が言われましたか?
一時的にファイルに保存してから、インターネットの前面がハッキングされた場合にアクセスできないオフサイトの場所にダンプする方が賢明かもしれません。
バグがあった上記のベンチマークは無視してください。
次の列を持つInsert1Mレコードがあります:id(int)、status(int)、message(140 char、random)。すべてのテストは、500GBのSATAディスクを搭載したデスクトップPCi5のC++ドライバーを使用して行われました。
MongoDBのベンチマーク:
1Mレコード挿入インデックスなし
time: 23s, insert/s: 43478
1Mレコード挿入インデックス付き ID
time: 50s, insert/s: 20000
次に、インデックスと100万レコードを含む同じテーブルに100万レコードを追加します
time: 78s, insert/s: 12820
そのすべてがfs上で4GB近くのファイルになります。
MySQLのベンチマーク:
1Mレコード挿入インデックスなし
time: 49s, insert/s: 20408
1Mレコード挿入インデックス付き
time: 56s, insert/s: 17857
次に、インデックスと100万レコードを含む同じテーブルに100万レコードを追加します
time: 56s, insert/s: 17857
まったく同じパフォーマンス、成長時にmysqlを失うことはありません
このテスト中にMongoが約384MBのRAMを消費し、CPUの3コアをロードしたことがわかります。MySQLは、14 MBに満足し、1コアのみをロードしました。
Edorianは彼の提案で正しい方向に進んでいました、私はもう少しベンチマークを行います、そして私たちは2xクアッドコアサーバー50Kインサート/秒で到達できると確信しています。
MySQLが正しい道だと思います。
クエリを実行する必要がない場合、データベースは必要なものではありません。ログファイルを使用します。
法的な理由でのみ保存されます。
そして、詳細な要件はどうですか? NoSQLソリューションについておっしゃっていますが、これらはデータが実際にディスクに保存されていることを保証するものではありません。 PostgreSQLでは、すべてがトランザクションセーフであるため、データがディスク上にあり、利用可能であることが100%確実です。 (fsyncをオフにしないでください)
速度は、ハードウェア、構成、およびアプリケーションに大きく関係しています。 PostgreSQLは、適切なハードウェアに1秒あたり数千のレコードを挿入でき、正しい構成を使用すると、同じハードウェアを使用しても非常に遅くなる可能性がありますが、アプリケーションで単純な愚かな構成や間違ったアプローチを使用します。単一のINSERTは低速であり、単一のトランザクション内の多くのINSERTははるかに高速であり、プリペアドステートメントはさらに高速であり、COPYは速度が必要なときに魔法をかけます。それはあなた次第です。
テーブルにインデックスがない場合、Firebirdは5000挿入/秒を簡単に処理できます。
なぜMySQLを除外するのかわかりません。 1秒あたりの高いインサートを処理できます。本当に高い挿入が必要な場合は、レプリケーションでBLACKHOLEテーブルタイプを使用します。基本的にはログファイルに書き込んでおり、最終的には通常のデータベーステーブルに複製されます。挿入速度に影響を与えることなく、スレーブにクエリを実行することもできます。
システム設定に応じて、MySqlは1秒あたり50.000を超える挿入を簡単に処理できます。
私が取り組んでいる現在のシステムでのテストでは、1秒あたり20万回以上の挿入が行われました。 10個のテーブルに100個の同時接続があります(一部の値のみ)。
Couchのような他のシステムはレプリケーション/バックアップ/スケーリングを容易にする可能性があるため、これが最良の選択であるとは言えませんが、非常に少量のデータを処理できないためにmysqlを却下します。
私はそこにもっと良い解決策があると思います(読んでください:より安く、管理しやすい)。
イベントストア( https://eventstore.org )を使用すると、( https://eventstore.org/docs/getting-started/which-api-sdk/index)を読むことができます。 html )TCPクライアントを使用すると、1秒あたり15000〜20000の書き込みを達成できます。データで何かを行う必要がある場合は、プロジェクションを使用するか、に基づいて変換を行うことができます。ストリームを使用して、必要な他のデータストアにデータを入力します。クラスターを作成することもできます。
お金が何の役割も果たさない場合は、TimesTenを使用できます。 http://www.Oracle.com/timesten/index.html
驚異的な速度で、完全なインメモリデータベース。
これにはログファイルを使用しますが、データベースを使用する必要がある場合は、 Firebird を強くお勧めします。速度をテストしたところ、かなり平均的なハードウェア(3年前のデスクトップコンピューター)で1秒あたり約10,000レコードが挿入されます。テーブルには1つの複合インデックスがあるので、それがないとさらに高速に動作すると思います。
milanb@kiklop:~$ fbexport -i -d test -f test.fbx -v table1 -p **
Connecting to: 'LOCALHOST'...Connected.
Creating and starting transaction...Done.
Create statement...Done.
Doing verbatim import of table: TABLE1
Importing data...
SQL: INSERT INTO TABLE1 (AKCIJA,DATUM,KORISNIK,PK,TABELA) VALUES (?,?,?,?,?)
Prepare statement...Done.
Checkpoint at: 1000 lines.
Checkpoint at: 2000 lines.
Checkpoint at: 3000 lines.
...etc.
Checkpoint at: 20000 lines.
Checkpoint at: 21000 lines.
Checkpoint at: 22000 lines.
Start : Thu Aug 19 10:43:12 2010
End : Thu Aug 19 10:43:14 2010
Elapsed : 2 seconds.
22264 rows imported from test.fbx.
Firebirdはオープンソースであり、商用プロジェクトでも完全に無料です。
答えは、ハードディスクの種類(SSDかどうか)や挿入するデータのサイズにも依存すると思います。デュアルコアUbuntuマシンのMongoDBに単一のフィールドデータを挿入していて、1秒あたり100レコードを超えていました。非常に大きなデータをフィールドに導入したところ、約9psに低下し、CPUは約175%で実行されていました。箱にはSSDが入っていないので、もっと良くなったのではないかと思います。
私もMySQLを実行しましたが、20mレコード(約4つの適切なインデックスも含む)のテーブルに50レコードを挿入するのに50秒かかったので、MySQLでも、配置しているインデックスの数によって異なります。