MongoDB が手に負えなくなった…次は何をすればいい?

Question 1

現在のパフォーマンスが遅すぎる、または限界に達している場合は、3 つのオプションがあります。これらは、どのような問題にも当てはまります。

垂直方向に拡大縮小: マシンのパワーを増やすことを意味します。CPU または RAM を増やします。
水平方向に拡大縮小: ワーカーの数を増やすことを意味します。プロセス、スレッド、マシンが増えます。
デザインの変更: 違うやり方でやってください。他のソフトウェア、他のアルゴリズム、他のストレージシステム、その他何でも。

1) と 2) をオプションから除外したので、残っている解決策は 3) だけです。それでは、それを実行してください...

Answer

現在のパフォーマンスが遅すぎる、または限界に達している場合は、3 つのオプションがあります。これらは、どのような問題にも当てはまります。

垂直方向に拡大縮小: マシンのパワーを増やすことを意味します。CPU または RAM を増やします。
水平方向に拡大縮小: ワーカーの数を増やすことを意味します。プロセス、スレッド、マシンが増えます。
デザインの変更: 違うやり方でやってください。他のソフトウェア、他のアルゴリズム、他のストレージシステム、その他何でも。

1) と 2) をオプションから除外したので、残っている解決策は 3) だけです。それでは、それを実行してください...

Question 2

同じ質問をMongoフォーラムに投稿したところ、MongoのCTOが、インデックスを最適化する方法に関するプレゼンテーションを見直すようにと返信してきました。

http://www.10gen.com/presentations/mongosf2011/schemascale

このプレゼンテーションで、Horowitz 氏は、シャーディング/水平スケーリングは多くの状況で過剰になる可能性があり、設計アプローチ (Mongo に特有の、かなり直感的ではないアプローチを含む) によって特定のサーバーのスケールを大幅に拡大できることを明確に述べています。

このプレゼンテーションでは、クライアント側のロジックを使用して、さまざまな「非正規化」方法でデータベースの使用方法を最適化するなど、興味深い概念がいくつか紹介されました。プレゼンテーションには、「マニュアルどおりに構築するだけでは、スケーリングに関連する望ましくない問題に簡単に遭遇する可能性がある」という明確なサブテキストがあります。たとえば、Horowitz 氏 (MongoDB のメーカーである 10Gen の CTO) は、「ハイブリッド」設計を提示しています。この設計では、「レコード」ごとに 1 つのドキュメントではなく、ドキュメントにおそらく 100 個の「レコード」を配置し、「バケット」のようなアプローチを実現します。これは、インデックスのフットプリントを減らすために明示的に行われます。これはクライアントでコード化されるものであり、MongoDB の「機能」ではありません。このハイブリッドアプローチは私たちにとって有効であり、インデックスサイズを 4 倍または 8 倍改善できる可能性があります。

彼はまた、「右バランス」の btree についても説明しています。これは基本的に、ほとんどのクエリがインデックスの「右側の部分」のみにアクセスするようにインデックス設計を最適化するものです (インデックス全体のランダムアクセスとは対照的です。インデックス全体のランダムアクセスでは、パフォーマンスを良くするために、インデックス全体が RAM に収まる必要があります)。このアプローチは、インデックス全体をクエリする必要があるため、役に立ちません。

私たちはこれらの概念をシステムの見直しの一環として活用するつもりです。

(興味深いことに、私がこの質問を投稿したすべての場所の中で、建設的な回答をくれたのは MongoDB の CTO だけです。)

アップデート (2017)

結局のところ、Mongodb は実稼働環境には適していないことがわかりました。数か月ごとに、データベース全体がダンプ/破棄され、すべてのデータが失われます。(主要なデータソースではないため、この問題は許容できますが、満足できるものではありません。)

現在、Elasticsearch スタックに移行するプロジェクトを完了し、現在、これを本番環境に展開しています。(Elasticsearch は長年にわたり、問題なく使用してきました。) Elasticsearch のデータは、たとえば Microsoft SQL Server ほど耐久性がありません (Elasticsearch クラスターが回復不能なデータ損失で失敗したことがあります) が、Elasticsearch は Mongodb よりも少なくとも 10 倍 (経験上、100 倍以上) 信頼性があります。(Elasticsearch は、Mongodb の大きな欠点の 1 つである、Windows を本番環境プラットフォームとしてサポートするふりをしません。)

今後数週間で、Mongodb の環境全体を消去する予定です。

前進！

更新 (2018-2019)

Elasticsearch スタックは成果を上げました。非常に信頼性が高く、拡張性に優れていることがわかり、まったく後悔していません。Mongo は当時は素晴らしいものでしたが、もう何年も前になくなってしまいました。もういい加減にしてよかったです。私たちは 2 つの Elastic クラスターを運用しています。1 つはログデータ用 (Mongo サーバーを置き換えたもの)、もう 1 つは実際のアプリケーションデータ用です。各クラスターには 1 ～ 2 TB のデータがあります。多く拡張性とパフォーマンスの両方において弾力性を得るには、アーキテクチャ作業（特にアプリケーション側）が不可欠ですが、それを実現するにはそれが必要です。

Answer

同じ質問をMongoフォーラムに投稿したところ、MongoのCTOが、インデックスを最適化する方法に関するプレゼンテーションを見直すようにと返信してきました。

http://www.10gen.com/presentations/mongosf2011/schemascale

このプレゼンテーションで、Horowitz 氏は、シャーディング/水平スケーリングは多くの状況で過剰になる可能性があり、設計アプローチ (Mongo に特有の、かなり直感的ではないアプローチを含む) によって特定のサーバーのスケールを大幅に拡大できることを明確に述べています。

このプレゼンテーションでは、クライアント側のロジックを使用して、さまざまな「非正規化」方法でデータベースの使用方法を最適化するなど、興味深い概念がいくつか紹介されました。プレゼンテーションには、「マニュアルどおりに構築するだけでは、スケーリングに関連する望ましくない問題に簡単に遭遇する可能性がある」という明確なサブテキストがあります。たとえば、Horowitz 氏 (MongoDB のメーカーである 10Gen の CTO) は、「ハイブリッド」設計を提示しています。この設計では、「レコード」ごとに 1 つのドキュメントではなく、ドキュメントにおそらく 100 個の「レコード」を配置し、「バケット」のようなアプローチを実現します。これは、インデックスのフットプリントを減らすために明示的に行われます。これはクライアントでコード化されるものであり、MongoDB の「機能」ではありません。このハイブリッドアプローチは私たちにとって有効であり、インデックスサイズを 4 倍または 8 倍改善できる可能性があります。

彼はまた、「右バランス」の btree についても説明しています。これは基本的に、ほとんどのクエリがインデックスの「右側の部分」のみにアクセスするようにインデックス設計を最適化するものです (インデックス全体のランダムアクセスとは対照的です。インデックス全体のランダムアクセスでは、パフォーマンスを良くするために、インデックス全体が RAM に収まる必要があります)。このアプローチは、インデックス全体をクエリする必要があるため、役に立ちません。

私たちはこれらの概念をシステムの見直しの一環として活用するつもりです。

(興味深いことに、私がこの質問を投稿したすべての場所の中で、建設的な回答をくれたのは MongoDB の CTO だけです。)

アップデート (2017)

結局のところ、Mongodb は実稼働環境には適していないことがわかりました。数か月ごとに、データベース全体がダンプ/破棄され、すべてのデータが失われます。(主要なデータソースではないため、この問題は許容できますが、満足できるものではありません。)

現在、Elasticsearch スタックに移行するプロジェクトを完了し、現在、これを本番環境に展開しています。(Elasticsearch は長年にわたり、問題なく使用してきました。) Elasticsearch のデータは、たとえば Microsoft SQL Server ほど耐久性がありません (Elasticsearch クラスターが回復不能なデータ損失で失敗したことがあります) が、Elasticsearch は Mongodb よりも少なくとも 10 倍 (経験上、100 倍以上) 信頼性があります。(Elasticsearch は、Mongodb の大きな欠点の 1 つである、Windows を本番環境プラットフォームとしてサポートするふりをしません。)

今後数週間で、Mongodb の環境全体を消去する予定です。

前進！

更新 (2018-2019)

Elasticsearch スタックは成果を上げました。非常に信頼性が高く、拡張性に優れていることがわかり、まったく後悔していません。Mongo は当時は素晴らしいものでしたが、もう何年も前になくなってしまいました。もういい加減にしてよかったです。私たちは 2 つの Elastic クラスターを運用しています。1 つはログデータ用 (Mongo サーバーを置き換えたもの)、もう 1 つは実際のアプリケーションデータ用です。各クラスターには 1 ～ 2 TB のデータがあります。多く拡張性とパフォーマンスの両方において弾力性を得るには、アーキテクチャ作業（特にアプリケーション側）が不可欠ですが、それを実現するにはそれが必要です。

Question 3

「スケーリング」の問題に対する答えが気に入らないかもしれません。それは、実際にはスケーリングの問題ではなく、設計と実装の問題だからです。インデックス作成が効率的に行われていません。

真剣に言えば、そのサイズのインデックスを絶対に保持する必要があると感じる場合は、どのデータベース製品を探しても、RAM に非常に大きなインデックスを保持するという同じ問題に直面することになります。それらのインデックスを格納するには、大容量のサーバー (DL380 G7 で実現可能で、ミッドレンジのコモディティサーバーであり、特別なものではありません) を購入する必要があります。

参考までに、「mongodb インデックスの最適化」を検索すると、役立つリンクがいくつか見つかります。

http://www.mongodb.org/display/DOCS/最適化

http://www.10gen.com/events/indexingmatters

http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/

http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer

あなたは調査を済ませたことについて防衛的になるかもしれませんが、MongoDB を本番環境で使用している私たちは、あなたが多くの点を見逃していることを知っています。

さらに、「要するに、MongoDB は FOSS ですが、それを実行するためのハードウェアに $$$$$$$ を費やす必要がありますか? むしろ商用ソフトウェアを購入すべきです!」というコメントは、無知と傲慢さを叫んでいます。

Answer