1

私は、通常30文字を超える長さの数百万の文字列(ヌクレオチド塩基、AGCTによって形成される)を生成する生物学ソフトウェアに取り組んでいます。それはCと書かれました。

このデータをディスクに保存するのに十分な速度でデータベースが必要です。これにより、ソフトウェア全体の速度が低下するボトルネックが発生せず、RAMを過度に消費することもありません。さらに、アプリケーション内で完全にリンクする必要があります。ユーザーにSQLサーバーなどを強制的にインストールさせたくありません。

私はすでにhamsterDB、SQLite、Kyoto Cabinet、MapDBを試しましたが成功しませんでした。問題は、データベースから少なくとも5万回/秒でデータを挿入または更新する必要があることです。いくつかの最適化により、SQLiteがより高速になりました。18k操作/秒に達します(同期オフ、journal_modeオフ、トランザクション、ignore_check_constraintsオン、500.000のcache_size、およびプリコンパイルされたステートメントを使用します)。

各シーケンスはAまたはBに分類され、それぞれの種類がいくつあるかを知る必要があります。現在、シーケンスをキーとして使用し、Aタイプ用のカウンターとBタイプ用のカウンターを追加しています。SQLiteデータベースでは、次のような列とコマンドを使用しています。

INSERT OR REPLACE INTO events (main_seq,qnt_A,qnt_B) VALUES (@SEQ,COALESCE((SELECT qnt_A FROM events WHERE main_seq=@SEQ)+1,1),(SELECT qnt_B FROM events WHERE main_seq=@SEQ))

これは単純なINSERTINTOよりも低速ですが、seqがDBにすでに存在する場合は、列の1つをインクリメントする必要があります。

京都内閣で私は本当に高速になりましたが、それは文字列レコードしかサポートしておらず、整数を追加および更新して、AとBの数を数える必要があります。

レコードの書き込み速度と柔軟性に関する私のニーズを満たす可能性のある別の優れたDBを知っている人はいますか?

4

2 に答える 2

3

このBerkeleyDBホワイトペーパーによると、理論上の制限は1秒あたり70,000トランザクションです。実際のパフォーマンスははるかに低くなり、理論上の制限は、あなたの場合には当てはまらないいくつかの仮定に基づいています。しかし、彼らは依然としてBerkeleyDBがSQLiteよりも大幅に高速であると主張しています。

1つのBDBライターが約700TPSのスループットを測定すると考えると、理論上の制限は70,000 TPSであり、100の競合しない同時実行スレッドがあります。

于 2013-02-26T20:01:03.347 に答える
3

次のベンチマーク

OpenLDAPMDBを探す

提出されたケースに合わせて、特に大規模なランダム書き込みの場合

MDB。13,215エントリ/秒
KyotoTreeDB。5,860エントリ/秒
LevelDB。3,138エントリ/秒
SQLite3。2,068エントリ/秒
BerkeleyDB。1,952エントリ/秒

于 2014-06-14T11:00:04.547 に答える