なぜMongoDBではそれほど単純ではないのですか

過去数年間で、MongoDBは開発者の間で絶大な人気を得ています。 別の若い人気のあるプロジェクトが通常のRDBMSを歴史のゴミ箱に投げ入れ、MongoDBをメインデータベースとして、その周辺のインフラストラクチャを構築し、その後すべてがうまくいったように、インターネット上では、あらゆる種類の記事が時々登場します。 完全にMongo（ Meteor.jsなど）でアーキテクチャを構築する新しいフレームワークやライブラリも表示されます。



約3年間、私は、MongoDBをメインデータベースとして使用するいくつかのプロジェクトを開発およびサポートしてきました。この記事では、MongoDBの私の意見では、マニュアルに書かれているほど単純ではない理由と、あなたが突然MongoDBをあなたの新しいファッショナブルなスタートアップのメインデータベースとして採用することに決めた場合、準備ができているはずです:-)



以下に説明するすべては、Pythonプログラミング言語のMongoDBを操作するためのPyMongoライブラリを使用して再現できます。 ただし、他のプログラミング言語で他のライブラリを使用している場合、同様の状況が発生する可能性が最も高くなります。

PyMongo、フェイルオーバーとAutoReconnect例外の問題

ほとんどすべてのマニュアル、およびインターネット上の多数の記事で、Mongoは組み込みのレプリケーションメカニズムにより、すぐにフェールオーバーをサポートすると言われています。 いくつかの記事では、 10genの公式コースであっても、1つのホストに複数のmongodプロセスをデプロイし、それらの間でレプリケーションを構成し、プロセスの1つを強制終了すると、レプリケーションは失敗せず、新しいマスターが再選され、すべてが大丈夫です。 そしてそれは本当に動作します...しかしローカルホストでのみ！ 現実には、状況は少し異なります。



Amazonで仮想マシンを試しているとしましょう。 5台の小さなマシン（ベース用に3台、ライターとリーダー用のテストプロセス用に2台）を上げてみましょう。1台は継続的にデータベースに値を書き込み、もう1台は値を読み取ります。



CentOS 6.xを使用し、標準の担当者からmongodbを配置し、スーパーバイザーを配置します。 スーパーバイザ内の各mongodプロセスの構成は次のとおりです。

# touch /etc/supervisord.d/mongo.conf [program:mongo] directory=/mnt/mongo command=mongod --dbpath /mnt/mongo/ --logappend --logpath /mnt/mongo/log --port 27017 --replSet abc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

レプリケーションを構成します。

 # mongo --port 27017 > rs.initiate({ _id: 'abc', members: [ {_id: 0, host:'db1:27017'}, {_id: 1, host:'db2:27017'}, {_id: 2, host:'db3:27017'} ] })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

writer.pyプロセスは次のようになります。

 import datetime, random, time, pymongo con = pymongo.MongoReplicaSetClient('db1:27017,db2:27017,db3:27017', replicaSet='abc') cl = con.test.entities while True: time.sleep(1) try: res = cl.insert({ 'time': time.time(), 'value': random.random(), 'title': random.choice(['python', 'php', 'ruby', 'java', 'cpp', 'javascript', 'go', 'erlang']), 'type': random.randint(1, 5) }) print '[', datetime.datetime.utcnow(), ']', 'wrote:', res except pymongo.errors.AutoReconnect, e: print '[', datetime.datetime.utcnow(), ']', 'autoreconnect error:', e except Exception, e: print '[', datetime.datetime.utcnow(), ']', 'error:', e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リストからわかるように、上記のスクリプトは毎秒値をデータベースに保存しようとします。



そして、これがreader.pyプロセスです。

 import datetime, time, random, pymongo con = pymongo.MongoReplicaSetClient('db1:27017,db2:27017,db3:27017', replicaSet='abc') cl = con.test.entities while True: time.sleep(1) try: res = cl.find_one({'type': random.randint(1, 5)}, sort=[("time", pymongo.DESCENDING)]) print '[', datetime.datetime.utcnow(), ']', 'read:', res except Exception, e: print '[', datetime.datetime.utcnow(), ']', 'error' print e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、このスクリプトは毎秒データベースから値を読み取ろうとします。



writer.pyとreader.pyのプロセスを並行して開始し、Amazonコンソールのプライマリノードでマシンを取得および停止します。







論理的に何が起こるべきですか？ MongoDBドキュメントによると、「abc」レプリケートは新しいウィザードを再選択する必要があり、これはスクリプトwriter.pyおよびreader.pyに対して透過的に発生する必要があり、ロケールでテストする場合（つまり、3つのプロセスすべてを同じホストにデプロイする場合）、これは本当にそうですそして続いています。 私たちの場合、スクリプトwriter.pyとreader.pyは 、中断信号を送信するまで（新しいプライマリがすでに選択されアクティブになっている場合でも）単にハングし、そのような一時停止状態のままになります。

 [ 2015-08-28 21:57:44.694668 ] wrote: 55e0d958671709042a4918b5 [ 2015-08-28 21:57:45.696838 ] wrote: 55e0d959671709042a4918b6 [ 2015-08-28 21:57:46.698918 ] wrote: 55e0d95a671709042a4918b7 [ 2015-08-28 21:57:47.703834 ] wrote: 55e0d95b671709042a4918b8 [ 2015-08-28 21:57:48.712134 ] wrote: 55e0d95c671709042a4918b9 ^CTraceback (most recent call last): File "write.py", line 18, in <module> 'type': random.randint(1, 5) File "/usr/lib64/python2.6/site-packages/pymongo/collection.py", line 409, in insert gen(), check_keys, self.uuid_subtype, client) File "/usr/lib64/python2.6/site-packages/pymongo/message.py", line 393, in _do_batched_write_command results.append((idx_offset, send_message())) File "/usr/lib64/python2.6/site-packages/pymongo/message.py", line 345, in send_message command=True) File "/usr/lib64/python2.6/site-packages/pymongo/mongo_replica_set_client.py", line 1511, in _send_message response = self.__recv_msg(1, rqst_id, sock_info) File "/usr/lib64/python2.6/site-packages/pymongo/mongo_replica_set_client.py", line 1444, in __recv_msg header = self.__recv_data(16, sock) File "/usr/lib64/python2.6/site-packages/pymongo/mongo_replica_set_client.py", line 1432, in __recv_data chunk = sock_info.sock.recv(length) KeyboardInterrupt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、すぐにフォールトトレラントとしてシステムを配置するシステムに適した状況ではないことに同意しますか？ もちろん、この例は少し誇張されています-たとえば、WebプロジェクトでPyMongoとMongoDBを使用している場合、Pythonファーム全体がuwsgiの下で実行され、 タイムアウトでスクリプトを無効にする何らかのハラキリモードが uwsgiで構成されている可能性があります- y ...しかし、それでも、コード内のこの種の状況を何らかの方法でインターセプトしたいと思います。 これを行うには、スクリプトを変更する必要があります。 reader.pyスクリプトでは、 次のものを置き換える必要があります 。

 con = pymongo.MongoReplicaSetClient('db1:27017,db2:27017,db3:27017', replicaSet='abc')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

に

 con = pymongo.MongoReplicaSetClient('db1:27017,db2:27017,db3:27017', replicaSet='abc', socketTimeoutMS=5000, read_preference=pymongo.ReadPreference.SECONDARY_PREFERRED)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトwriter.pyで ：

 con = pymongo.MongoReplicaSetClient('db1:27017,db2:27017,db3:27017', replicaSet='abc')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

に

 con = pymongo.MongoReplicaSetClient('db1:27017,db2:27017,db3:27017', replicaSet='abc', socketTimeoutMS=5000)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最終的には何が得られますか。 プライマリノードを削減して実験を繰り返した後 、 reader.pyプロセスは何も起こらなかったように動作し続けます（この例では変更されていないセカンダリノードを参照しているため）が、 writer.pyプロセスはスロー中に約1分間アストラルプレーンに移動しますAutoReconnectのようなエラー：

 [ 2015-08-28 21:49:06.303250 ] wrote: 55e0d75267170904208d3e01 [ 2015-08-28 21:49:07.306277 ] wrote: 55e0d75367170904208d3e02 [ 2015-08-28 21:49:13.313476 ] autoreconnect error: timed out [ 2015-08-28 21:49:24.315754 ] autoreconnect error: No primary available [ 2015-08-28 21:49:33.338286 ] autoreconnect error: No primary available [ 2015-08-28 21:49:44.340396 ] autoreconnect error: No primary available [ 2015-08-28 21:49:53.361185 ] autoreconnect error: No primary available [ 2015-08-28 21:50:04.363322 ] autoreconnect error: No primary available [ 2015-08-28 21:50:13.456355 ] wrote: 55e0d79267170904208d3e09 [ 2015-08-28 21:50:14.459553 ] wrote: 55e0d79667170904208d3e0a [ 2015-08-28 21:50:15.462317 ] wrote: 55e0d79767170904208d3e0b [ 2015-08-28 21:50:16.465371 ] wrote: 55e0d79867170904208d3e0c
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しになりますが、フォールトトレラントに設定されたシステムを1分間停止するのはそれほどクールではありません（ロケールでテストする場合、タイムアウトはありません-すべてスムーズです）が、これは避けられない悪であり、ドキュメントにも記載されています ：

さまざまですが、レプリカセットは1分以内に新しいプライマリを選択します。

レプリカセットのメンバーがアクセスできないプライマリを宣言するのに10〜30秒かかる場合があります。 これにより、選挙がトリガーされます。 選出中、クラスターは書き込みに使用できません。

選挙自体はさらに10〜30秒かかる場合があります。

ただし、例とAutoReconnectエラーに戻ります。 おそらくご想像のとおり、ソケットに5秒のタイムアウトを設定します。 5秒後にPyMongoドライバーがデータベースから応答を受信しない場合、接続をリセットし、エラーを吐き出します。 最もクールなソリューションではありません-突然データベースが過負荷になるか、要求が非常に大きくなり、完了するまでに5秒以上かかります（データベース全体に影響を与える何らかの集約機能）。 最も重要な質問は、AutoReconnect Errorが発生したことがわかると、ドライバー自体がリクエストの再起動を試行しない理由です。 最初の理由-ドライバーは実際に何が起こったのかわからない-突然1つのプロセスが「レイダウン」されたのではなく、レプリケート全体が。 2番目の理由は重複です！ AutoReconnectエラーが発生すると、ドライバーはデータを書き込むことができたか失敗したかを知りません。 これは世界的に支配的であると主張するベースにとっては少し奇妙に聞こえますが、実際には正しく動作するためには、 writer.pyスクリプトを次のように書き換える必要があります。

 import datetime, time, random, pymongo from pymongo.objectid import ObjectId con = pymongo.MongoReplicaSetClient('db1:27017,db2:27017,db3:27017', replicaSet='abc', socketTimeoutMS=5000) cl = con.test.entities while True: time.sleep(1) data = { '_id': ObjectId(), …. } # Try for five minutes to recover from a failed primary for i in range(60): try: res = cl.insert(data) print '[', datetime.datetime.utcnow(), ']', 'wrote:', res break except pymongo.errors.AutoReconnect, e: print '[', datetime.datetime.utcnow(), ']', 'autoreconnect error:', e time.sleep(5) except pymongo.errors.DuplicateKeyError: break
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、PyMongo開発者の1人のブログにこのトピックに関する記事があり、 JIRA MongoDBでの小さな議論もあります。

グローバルロックの問題

MongoDBの大きな落とし穴。 これはおそらくMonguが最も批判されているものです。 ドキュメントのグループに対して実行される大規模な操作は、攻撃にさらされます。 つまり、大まかに言えば、大規模なドキュメントグループに対するいくつかの重い更新操作により、パフォーマンスの問題が発生し、他のリクエストの実行がブロックされる可能性があります。 もちろん、 バージョン2.2から 、ロックを下げること（ロックの譲歩）を学ぶと状況はわずかに改善し、mongodプロセスレベルから選択したデータベースのレベルにロックを転送しました。 新しいバージョン3.0では、作成者は、代替のWiredTigerエンジンへの移行により、MMAPv1エンジンのようにドキュメントレベルでロックを使用し、データベースを完全にブロックしないため、状況を改善する必要があると主張します。



グローバルロックの状況を視覚化するための小さなベンチマークを作成しました。 必要に応じて、git pullを実行して、これらすべてのテストを自分で実行できます。

• 1,000人のユーザーを考慮します（値は構成によって変更できます）
• 各ユーザーには5,000のドキュメントがあります。 つまり、データベース内の文書はわずか500万です。 各ドキュメントには、ブール値を格納するフィールドが含まれています。
• テストプロセスは、各ユーザーに1つずつ、1,000タスクの並列実行です。 各タスクは、5,000のすべてのユーザードキュメントのブールフィールドを更新しています。
• テスト中に、1から30に増加します（ここでも、設定を使用して値を変更できます）。タスクプールを同時にキャプチャする競合プロセスの数を増やします。
• 各タスクの実行時間を節約します。 グラフィックを構築しています。 MongoDBの異なるバージョンのテスト結果を比較します。
• 別の方法として、MySQL 5.5（InnoDB）で同様のタスクを検討してください。 そして結果を比較します。

テストは、c3.2xlargeタイプ（vCPU 8、15 Gb RAM）のAmazonインスタンスで、データベース用に追加で接続されたSSDドライブ（500 Gb、4000 iOPS）で実行されました



テストの結果、次のことが起こりました。



MongoDB 2.6のバージョンとMongoDB 3.0のバージョン（WiredTigerではなくMMAPv1）を比較すると、結果に大きな違いはありませんが、MongoDB 3.0を使用する30の同時ワーカープロセスの場合、クエリの実行時間はまだ少し短くなります。 ところで、テスト中に、mongostat ユーティリティでロックの割合を調べると、 屋根を通過します 。







MongoDB 3.0 MMAPv1とMongoDB 3.0 WiredTigerを比較すると、結果は劇的に異なります。これは、WiredTigerを使用する場合、ロックが大量操作の速度に与える影響が実際にははるかに少ないことを示しています。







次に、MongoDB 3.0 WiredTigerとMySQL 5.5を比較します。 MySQLデータベースは、個々の設定からのみ選択されました。 誰かが欲求がある場合は、PostgreSQLで同様のテストを行うことができます。 データベースを操作するすべてのロジックは、特別なアダプターでカプセル化されます。 そのため、クラスを記述し、AbstractDBAdapter抽象クラスから継承し、PostgreSQLを操作するためのすべての抽象メソッドをオーバーライドするだけです。

ご存じのように、箱から出してすぐにベースをテストすることは恩知らずで無意味な練習です。 MongoDBについては、残念ながら、すべてが悪いです。 ベースは実際には調整されておらず、設定は最小限です。 MongoDBの主な原則は、データベースに別のサーバーを割り当てることです。その後、データベース自体が、メモリに保存するデータとディスクにダンプするデータを決定します。 いくつかのソースでは、サーバーにインデックスを収めるのに少なくとも十分な空きメモリが必要だという意見を聞きました。 MySQLの場合、多くの設定があり、ベンチマークを開始する前に、次の設定が行われました。

 max_connections = 10000 query_cache_limit = 32M query_cache_size = 1024M innodb_buffer_pool_size = 8192M innodb_log_file_size = 512M innodb_thread_concurrency = 16 innodb_flush_log_at_trx_commit = 2 thread_cache = 32 thread_cache_size = 16
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして結果はここにあります。

MySQLでテストを実行するときに最初に注目するのは、ワーカープロセスの数が増えてもすべてのタスクの合計実行時間が変わらないことです。

 ... Run test with 5 proceses Test is finished! Save results Full time: 20.7063720226 Run test with 6 proceses Test is finished! Save results Full time: 19.1608040333 Run test with 7 proceses Test is finished! Save results Full time: 19.0062150955 … Run test with 15 proceses Test is finished! Save results Full time: 18.5613899231 Run test with 16 proceses Test is finished! Save results Full time: 18.4244360924 … Run test with 29 proceses Test is finished! Save results Full time: 16.8106219769 Run test with 30 proceses Test is finished! Save results Full time: 19.3497707844
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目-これはもちろんグラフィックです。 MySQLの場合、クエリの実行時間は0.001〜0.5秒で変動し、15の処理プロセスと30の両方で常に変化しますが、MongoDB WiredTigerの場合、15のプロセスではクエリの実行時間が1.5秒に達し、最大2.5秒：





これからどのような結論を導き出すことができますか？



個人的に、プロジェクトでMongoDBを使用できる場合、私は次のパターンを見ます：

• データスキーマは、「厚い」疎結合ドキュメントの概念によく適合します
• トランザクションの不足は、ドキュメント操作の原子性によって補われます
• アプリケーションのビジネスロジックは、ドキュメントに対する多数の大規模な操作を意味するものではありません。

また、ドキュメントは頻繁に削除しないことをお勧めします。 別の小さな問題がこれに関連しています（別の段落に入れないことにしました）。 ドキュメントを削除するとき、空きディスク容量は解放されません。 MongoDBはディスク上のブロックを空きとしてマークし、機会があれば、このブロックを新しいドキュメントに使用します。 私の観察によると、バージョン2.6より前では、この戦略は非常に非効率的でした。なぜなら、 repairDatabaseが長寿命データベースで実行された後、データとインデックスのサイズを2倍（！）以上削減することができたからです。 バージョン2.6以降、新しいコレクションでは、デフォルトで、新しいドキュメント用にディスクを事前に割り当てるために新しい戦略が使用され始めました（ usePowerOf2Sizesオプション）-その使用の結果、新しいドキュメントに割り当てられたスペースのサイズは以前よりも少し大きくなりましたが、ドキュメントを削除した後の空きスペースはより多くなりました効果的に。 そして、MMAPv1エンジンのバージョン3.0では、さらに進んで、 展開前の戦略をもう一度変更しましたが、実稼働環境での有効性をまだ評価できていません。 ディスクの事前展開に関してWiredTigerエンジンに何が起こるか、正直なところ、私も知りません。 これに関する情報があれば-コメントに書いてください:-)