大規模なデータセットで Tokyo Cabinet / Tokyo Tyrant を使用して成功した人はいますか? Wikipedia データソースのサブグラフをアップロードしようとしています。約 3,000 万件のレコードに達した後、指数関数的に遅くなります。これは、HDB データベースと BDB データベースの両方で発生します。bnum を、HDB の場合に予想されるレコード数の 2 ～ 4 倍に調整しましたが、速度はわずかに向上しました。xmsiz も 1GB 程度に設定しましたが、最終的にはまだ壁にぶつかっています。
Tokyo Tyrant は基本的にメモリ内データベースのようで、xmsiz または RAM を超えると、データベースがほとんど使用できなくなります。他の誰かが以前にこの問題に遭遇したことがありますか? 解決できましたか？
私はこれをクラックした可能性があると思いますが、このソリューションは他のどこにも見たことがありません。Linux では、一般に、東京が減速し始める理由は 2 つあります。いつもの犯人を見てみましょう。まず、bnum の設定が低すぎる場合は、少なくともハッシュ内のアイテム数の半分に等しくする必要があります。(できればそれ以上です。) 次に、xmsiz をバケット配列のサイズに近づけるように設定します。バケット配列のサイズを取得するには、正しい bnum で空のデータベースを作成するだけで、Tokyo がファイルを適切なサイズに初期化します。(たとえば、bnum=200000000 は、空のデータベースの場合、約 1.5GB です。)
しかし今は、少し進んでいますが、まだ減速していることに気付くでしょう。ファイルシステムのジャーナリングをオフにすることが秘訣であることがわかりました。何らかの理由で、ハッシュ ファイルのサイズが 2 ～ 3GB を超えると、ジャーナリング (ext3 で) が急増します。(私たちがこれを認識した方法は、ディスク上のファイルの変更に対応しない I/O のスパイクであり、kjournald のデーモン CPU バーストと並んでいます)
Linux の場合は、ext3 パーティションをアンマウントして、ext2 として再マウントするだけです。データベースを構築し、ext3 として再マウントします。ジャーナリングを無効にすると、180M キー サイズのデータベースを問題なく構築できました。
東京はスケールがスゴイ!! ただし、bnum と xmsiz を適切に設定する必要があります。bnum は、保存する予定のレコードの 0.025 ～ 4 倍にする必要があります。xmsiz は BNUM のサイズと一致する必要があります。また、2GB 以上を保存する場合は、opts=l を設定してください。
xmsiz のサイズの値を取得する方法については、上記の Greg Fodor の投稿を参照してください。xmsiz を設定する場合、値はバイト単位であることに注意してください。
最後に、ディスクベースのハッシュを使用している場合は、東京のデータが存在するファイルシステムでジャーナリングをオフにすることが非常に非常に重要です。これは、Linux、Mac OSX、およびおそらく Windows に当てはまりますが、まだテストしていません。
ジャーナリングがオンになっている場合、3,000 万行以上に近づくと、パフォーマンスが大幅に低下します。ジャーナリングをオフにし、他のオプションを適切に設定すると、東京は優れたツールになります。
Shardy と呼ばれる東京キャビネットにシャーディングを追加するソリューションに取り組み始めています。
東京キャビネットのキーバリューストアは本当に良いです。東京キャビネットのテーブル状の店舗を利用しているので、遅いと言う人もいると思います。
ドキュメント データを保存する場合は、mongodb またはその他の nosql エンジンを使用します。