問題タブ [leveldb]

redhat マシンで leveldbjni を使用しようとしています。ubuntuで問題なく動作しました。しかし、redhat では次のエラーが発生します。

org.fusesource.leveldbjni.internal.NativeDB$DBException: IO エラー: <ファイルの場所>/LOCK: そのようなファイルまたはディレクトリはありません

( https://github.com/fusesource/leveldbjniの手順を使用して) redhat で leveldb C++ ライブラリを作成しようとしましたが、それでも同じ問題が発生しました。

現在、ActiveMQ でのメッセージの永続化に KahaDB ストアを使用しており、これまでのところ良好です。
ActiveMQ5.6 のリリース ノートに従って、LevelDB強化されたパフォーマンスを提供します。
誰かが LevelDB を使用しようとしたことがありますか?もしそうなら、長所と短所を教えていただけますか?

バックエンドの組み込みデータベース ライブラリとしてlevelDBを使用する分散キー値システム (またはデータ ストア) に取り組んでいます。

1 つのノード/マシンで複数のテーブルをホストしたい (レプリケーションと負荷分散の目的で)。levelDB にはテーブルの概念がないことを理解しているため、データをテーブルの形式で論理的に分割することはできません (したがって、これらのテーブルを分散の基本単位として使用することはできません)。

私の質問は: levelDB の単一インスタンスに複数の「論理テーブル」を持つ規定はありますか?

私の知る限り、ノード上で複数の levelDB インスタンスを実行して、それぞれが 1 つのテーブルを処理することができます。ただし、この場合、これらの複数の DB インスタンスに同時にアクセスすると、(ディスクで) 深刻な競合が発生するため、そうしたくありません。DB の単一インスタンスに複数の論理テーブルがあると、ディスク アクセスを最小限に抑えるための levelDB 最適化の利点が得られます。

LevelDB-Goは、Go言語のLevelDBの移植版です。LevelDB-Goは、Goアプリのネイティブ代替と呼ばれることがよくあります。ウェブサイトには例もドキュメントもありません。

ソースコードを読んで学ぶべきですか？または、例とドキュメントを掲載した別のWebサイトがありますか？

ライブラリは並行性をサポートしていますか？

leveldb で圧力テストを実行しています。

のutil/env_poisx.cc : NewRandomAccessFile()

300 万データ (各 100k) の挿入後。errno は言うCannot allocate memory。

なぜ？

詳細:

上：

フリー -m:

ulimit -a:

sysctl:

現在、owr のメイン アプリケーションで現在使用されている古い isam を置き換えるために、いくつかのキーと値のデータ ストアを評価しています (20 年間!) ...

問題は、現在の isam がクラッシュ リカバリをサポートしていないことです。

したがって、LevelDB は問題ないように見えました (BerkleyDB などもチェックしています)

しかし、ホット バックアップの問題に遭遇しました。LevelDB がサーバーではなくライブラリであるという事実を考えると、「ホット バックアップ」を要求するのは奇妙です。これは直感的に外部バックアップ プロセスを意味するからです。

おそらく、誰かがオプション (または既知の解決策) を提案したいと思いますか?

例: - メイン アプリケーションの内部スレッドを介したホット バックアップ ? - LevelDBのデータディレクトリをコピーするだけのホットバックアップ？

前もって感謝します

アプリケーションのデータベースとしての LevelDB の外観は気に入っていますが、問題が 1 つあります。

データベースにデータを保存したいのですが、データを読み取るときに、データの特定のセクションだけが必要な場合があります。同様に、leveldb_get(db, readOptions, key, keySize, &size, &err)私は何かleveldb_get_subsection(db, readOptions, key, keySize, offset, size, &err)が欲しいのですが、それは存在しません。

もちろん、データを小さなセクションにインデックス化することもできますが、より意味のあるレコード/値のサブセクションを読み取ることができる LevelDB に代わる良い方法があるかどうか疑問に思っていました。推奨事項はありますか？

データの整合性が重要であるため、ディスクに安全に同期されるアトミック操作が必要です。また、C インターフェイスが必要です。

ありがとう。

私は1億以上の文字列のセットを持っており、それぞれの長さは最大63文字です。ディスク容量が多く、メモリが非常に少ない（512MB）。存在のみを照会する必要があり、追加のメタデータは保存しません。

私の事実上の解決策はBDBbtreeです。望ましい選択肢はありますか？私はleveldbとKyotoCabinetを知っていますが、利点を特定するのに十分な知識がありません。

そのようなインターフェースはないようです。

カウントを取得するには、すべてのキーを繰り返す必要がありますか？

その設計目的は何ですか？または、この機能を実装する際の制限は何ですか？

以下は少し長くなったので：これがtl;drです。バージョン：永続的なインデックスを持つハッシュベースのセットのような、高速なキーと値のルックアップのための既存のキー/値のベストプラクティスはありますか？

私はKey-Valueデータベースの世界に興味があり、これまでのところ、次のユースケースを効率的に実装する方法を理解できていません。

一部のデータをシリアル化し、永続的で一意の整数インデックスによって別の場所でそれらを参照するとします。したがって、例：Key = unsigned int、Value=MyData。

データベースは高速キールックアップを備え、MyDataが一意であることを確認する必要があります。

これで、データベースに新しい値を挿入するときに、データベースの現在のサイズなどの新しいインデックスキーを割り当てたり、アイテムを削除した後の衝突を防ぐために、外部にカウンターを保持することができます。

しかし、同じMyData値をデータベースに挿入しないようにするにはどうすればよいですか？これまでのところ、これはKey-Valueデータベースでは効率的に不可能であるように見えます-これは正しいですか？つまり、MyData値がデータベースに存在しないことを確認するためだけに、データベース全体を反復処理したくありません...

では、これを実装するための最良の方法は何ですか？

背景として：私はKDevelopに取り組んでおり、コード分析キャッシュに上記を使用しています。実際には、上記のユースケース1のカスタム実装があります。内部に興味がある場合はBucketとItemRepositoryを検索し、ItemRepositoryの使用例については2を参照してください。

しかし、おそらくあなたは、このコードを理解するのが非常に難しく、したがって維持するのが難しいことに同意するでしょう。そのパフォーマンスを代替ソリューションと比較したいのですが、コードが単純になる可能性がありますが、パフォーマンスが大幅に低下しない場合に限ります。OpenLDAP MDB、Kyoto Cabinet、LevelDBなどのKey-Valueストレージのパフォーマンスに関する誇大宣伝を考慮して、ここから始めたいと思いました。

KDevelopにあるのは、私が理解している限り、基本的にはディスク上/メモリ内のハイブリッドハッシュマップの一種であり、定期的にディスクに保存されます（もちろん、クラッシュなどの場合にデータが大幅に破損する可能性があります。 ）。アイテムはハッシュ値に基づいた場所に保存されます。もちろん、ハッシュ関数が高速である限り、比較的高速な値のルックアップも可能です。追加されたひねりは、アイテムを非常に効率的に検索するために使用できる、ある種の永続的なデータベースインデックスも取得することです。

つまり、簡単に言えば、LevelDB、Kyoto Cabinet、OpenLDAPMDBなどのKey/Valueデータベースでそれをどのように行うのでしょうか。