問題タブ [wiredtiger]

WiredTiger でインデックス キーの制限をどこで変更できますか? mongodb バージョン 3.0.4 を使用します。

バージョン 2.6.7 では、/db/structure/btree/btree.h を 1024 から 2048 に変更し、より大きなインデックス キーをサポートするようにコードをコンパイルしました。

Wired Tiger ストレージ エンジンを使用して MongoDB をローカル マシンにインストールしようとしていますが、問題が発生しています。バイナリをダウンロードし、ガイドに従って C:\MongoDB にインストールしました。これはデフォルトのエンジン MMAPV1 を使用してインストールされましたが、これを Wired Tiger に変更したいと考えています。これを行うには、次のコマンドを使用するだけです。

ホットフィックスもインストールしましたが、同じ問題が発生します。

WiredTiger上記の指定したフォルダーにstorage.bson、、WiredTiger.turtleなどのファイルの束を作成するため、このコマンドは機能しているようです。

これがボールをプレーしていない理由はありますか？これをWindowsサービスとしてインストールしましたが、シェルを使用してコマンドを使用すると、正常に起動します

価値mmappv1を取り戻します。

新しいストレージ エンジン WiredTiger を搭載した MongoDB がデータを BTree に格納するようになったことを読みましたが、それが何を意味するのか知りたいです。次のいずれかですか？

データファイルのページについて話し、それらをツリー (ルートページ、内部ページ、リーフページ) として配置したウェビナーを見たことがありますが、階層が何に基づいているかについては言及していませんでした。彼らはまた、データファイルはキーと値のペアで構成されているとも言いました。各キーは _id で、値はドキュメント全体ですか? ドキュメントは BSON としてではなく、BTree として保存されるようになったと誰かが私に言いましたが、それは正しいですか?

前もって感謝します。

WiredTiger エンジンで MongoDB 3.0.6 を使用しています。毎日、ログにスロー クエリが多数表示されます。このように：

このクエリはインデックスを使用し、IXSCANを実行していることがわかります。しかし、それはとても長いです。このクエリを高速化する可能性はありますか?

ここに私のインデックス統計があります：

サーバーには 30Gb のメモリがあり、その半分が WiredTiger キャッシュに使用されています。それは十分ではないようですか？

約 2.4MM レコードのコレクションに対して findAndModify クエリを実行しています。クエリ内のすべてのフィールドにインデックスが付けられていますが、コマンドの実行に一貫性がありません。ログには、実行に 0.1 秒未満から 5 秒かかることが示されています。過去 4 か月間で、これはかなり急速に進みました。この 1 週間で本当に問題になりました。MongoDB 3.0.4 を実行しています

詳細については、これは 3 つのメンバーの replicaSet、1 つのプライマリと 2 つのセカンダリです。プライマリは十分なディスク容量を使用してwiredTigerを実行しており、セカンダリはMMAPv1で実行しています。これは、このコレクションに書き込む唯一のプロセスであり、このデータソースのすべてのクライアントは、読み取り設定が secondaryPreferred に設定されているため、これはトラフィック/負荷の問題ではないと確信しています。

編集: getIndexes() からの出力

編集: Explain('queryPlanner') からの出力を追加しました

私は、wiredTiger ストレージ エンジンを使用してサーバーを実行していますが、圧縮をグローバルに有効化していません。ここで、単一のコレクションの「block_compressor」オプションを「snappy」を使用するように変更したいと考えています。mongoDB のドキュメントによると、これは「db.createCollection()」を使用して新しいコレクションを作成するときに可能ですが、既存のコレクションに対してこの手順を実行するにはどうすればよいですか? (初期同期前の新しいレプリカ セット メンバーの場合)

レプリカ セット内の非wiredTigerメンバーとwiredTigerメンバー間の初期同期は、(ファイルをコピーするのではなく)ドキュメントごとのレベルで実行されるため、これは可能であるはずです...

http://docs.mongodb.org/manual/reference/method/db.createCollection/#specify-storage-engine-options

私は奇妙な問題を抱えています。同様のインデックスを持つ同様のデータセットでパフォーマンスを測定しています（実際には、mognodumped/mongorestored だけです）。

1 つのインスタンスは vagrant でローカルに実行されています (1 コア、4 ギガなど...)。別のインスタンスはサーバー上で実行されています。

MongoDB のバージョンは 3.0.6 です。

そのため、そのインポートを vagrant サーバーで実行したところ、パフォーマンスが著しく異なる結果が得られました。実際、vagrant インスタンスは、実サーバーよりも 3 倍から 5 倍速く同じクエリを実行します。

ということで出力チェックdb.stats()。違いは次のとおりです。

現実のサーバー:

そして、ここに浮浪者のインスタンスがあります:

ライブ サーバー コレクションの統計は次のとおりです: http://pastebin.com/9vipBmQm

vagrant の場合も同じです: http://pastebin.com/HbbSi0Pu

ご覧のように。ライブ サーバーは、wiredTiger データ ストレージを実行します。そして、(MMAPv1 と比較して) 非常にタイトにデータが圧縮されていることがわかります。

さらに懸念がある場合は、両方の環境での同じクエリの説明出力を次に示します。

• 放浪者: http://pastebin.com/8h3iL5Fh
• ライブ: http://pastebin.com/2DjX4YTg

ワイヤードタイガーのパフォーマンスを向上させるにはどうすればよいですか? それとも MMAPv1 に戻す必要がありますか?

どんなヒントも役に立ちます！

ありがとうございました！

ワイヤードタイガー ストレージ エンジンを使用して、MongoDB3.0 でドキュメント レベルのロックを実現しようとしています。

私が達成したいのは 、->ドキュメントを読む->ロックする->データに対して何らかの操作を実行する->結果を新しいドキュメントに保存する->前のドキュメントのロックを解除することです。

pymongoでそれを行うことは可能ですか??