MongoDB翻訳 - アップデートのところ開始

6th Mar, 2010 | mongodb

アップデートのところ始めた。これが終わると主だったクエリー終了かな。

ドキュメントの更新が激しくなってきて、既存のところの追従が微妙に大変になってきた。でも、ドキュメントが充実してるのもMongoDBのいいところだと思う。

MongoDBの翻訳全般については、 こちら参照。



MongoDB翻訳 - Replica Pairs

5th Mar, 2010 | mongodb

レプリケーションのところの残り。Replica Pairsという、レプリケーションを使いフェイルオーバーを自動化する仕組のドキュメント。

MongoDBの翻訳全般については、 こちら参照。



MongoDB翻訳 - レプリケーションのところ始めた

4th Mar, 2010 | mongodb

そういえば、大事なレプリケーションのところをまだやってなかったことに気がづいた。レプリケーションは、 Sharding と違い、単純に複数のサーバで同じデータを持つ機能。たん MongoDBは、機能はもちろんだけど、こういう設定がとてもシンプルというのもいいところだと思う。



MongoDB翻訳 - リムーブ他

3rd Mar, 2010 | mongodb

今日は2つ。と言っても1つは今まで最短。2つ目も短め。



「MongoDBをプロダクション環境で使ってみて」

2nd Mar, 2010 | mongodb

8ヶ月間、MongoDBをプロダクションで使っている人のブログ記事が面白かったので、興味深いところだけまとめてみた。 原文はこちら 。

  • 8ヶ月間使ってデータベースの規模は、
    • Collections (tables): 17,810
    • Indexes: 43,175
    • Documents (rows): 664,158,090
  • master/slaveのマニュアルでのフェイルオーバ環境で運用してきた。
    • masterは72GBのRAM
    • slaveは別のデータセンタ
  • ディスク的にきつくなってきたので、手動でShardingをし4つのDB(Master 2つ / Slave 2つ)に分けることにした。
  • namespaceの限界があるので、データを3つのMongoDB( これは物理的なサーバではなくてMongoDBのデータベースの単位)に分割している。
    • 現在のnamespaceの数は、 db.system.namespaces.count() で確認することができる。
  • MongoDBはデータベース単体でのDurabilityを持っていない(なぜ持たないかという公式の見解)。
    • そのため、必ずレプリケーションをし複数のデータベースで運用する必要がある。
    • もし、停電とかが起きDBがおかしくなった場合は、repairする必要がある。
      • これは私たちぐらいのサイズのデータを持っている場合、数時間かかることになる。
    • master/slave構成(そして理想的にはslaveは別のデータセンタ)を取ることができる。ただし、masterの問題があったら手動でfailoverする必要がある。
      • または、replica pairs(訳注: 複数のmasterを持ち動的に切替える機能)を使うと、その辺は自動的にできる。
  • とても巨大なデータベースなので、新しいslave(別のデータセンタでVPN接続)へのコピーは48-72時間かかる。
    • この間、slaveが最新のmasterと同期しなくなる、というリスクがある。
    • また、sync中に更新されれたデータを保持しておくためのop logのサイズには注意が必要。
      • 75GBのop logが必要だった。
        • これは–oplogSizeで指定できる
          • しかし、MongoDBが起動しコネクションを受け付ける前にファイルがallocateされ、この環境では5分くらいかかり、その間MongoDBは使えなくなる。
            • これを防ぐためには手動でファイルを前もって作成しておけばいい (訳注: やり方は原文参照)
  • 最初のsync中に”遅くなる”問題
    • 空のslaveにコピーする最中、アプリケーションの速度が遅くなった。
      • それでも十分な速度は出ていたので詳細の調査はしなかったが、データベースの接続とクエリーが少し遅くなっていたみたい。環境によっては問題になるかも。
  • daemon/forkプロセスとlogging
    •  –fork パラメータをつけてforkされたプロセスで動かしている。
      • –logpath を指定するとerrorを吐き出せる
      • --quiet オプションもつけてログが大きくなりすぎ内容にしている
      • 組み込みのlogローテーション機能はない
  • OSの調整
    • 最大のファイルオープン数に到達してしまった。
      • (ここの環境では)デフォルトで1024に設定されていて、これは小さすぎるかも。参照。
    • atimeをdisableにした。
  • インデックス作成でのブロック
    • 全部のインデックスを最初に作成してあったので即座に作成できたが、もし既存のコレクションに対してインデックスを作成する場合、作成中はデータベースがロックされる。
  • 効率的なディスクの再利用
    • 私たちが運用しているサーバーをモニターするというアプリケーションの特徴から、たくさんのデータを集める。
      • しかし、設定された期間を過ぎるとデータは削除される。
        • こういうことをしているとディスクを食うようだ。
          • 新しいSlaveへデータをコピーして気づいた。(コピーした後でmaster 900GB / slave 350GB だった)
    • MongoDBの有料サポートへ連絡済。
  • 素晴らしいサポート
    • gold commercial support service (有償サポートサービス)を使っている。上記のような色々な問題が起きたときとても便利だった。チケットを開くのは簡単だし、サポートもとても速い。また24時間対応の緊急の電話もできる。
  • まとめ - MongoDBを選択したのは正しかったか？
    • Yes
      • データベースの管理も簡単だし、スケールもよくする。
        • 今一番欲しい機能はauto sharding (訳注: 現在アルファバージョン)。
          • 今はmanualでshardingしているけど、それがあればもっといい！

こういう人柱的な人(会社)にはほんと感謝です。