ksomemo · January 29, 2014 02:23 · Jan 29, 2014
diff --git a/mongodb.md b/mongodb.md
@@ -0,0 +1,77 @@
+# MongoDBまとめ
+
+##概要
+* インメモリ
+* クラスタ構成
+* スキーマフリー
+* ドキュメント指向
+* レプリケーション
+* シャーディング
+
+##スキーマフリー
+* リレーション概念はない
+* これは、集約できるものはドキュメントのサブドキュメントとする
+* マスタとのJOINのようなことはハイパーリンクのようなものでつなぐ
+* 配列に関するIndexを作成できる（どういうこと？
+* ドキュメントはディスク上で連続した領域に配置されるのでアクセスしやすい
+
+##インメモリ
+* オンメモリ
+* プログラムが扱いやすいデータが格納されているので便利
+
+##クラスタ構成
+* フェイルオーバー可能
+* レプリケーション構成から上記可能
+* クラスタ構成図（後で見たい
+* ルーティングサーバー（Mongosサーバー）が存在するのでまずここにアクセス（上記が死んだらどうなるのか？
+* 実際はプロセスなので、プロセス再起動・アクセス先変更などの仕組みを作ることで回避できる
+* 1プロセスだけなのでMongosサーバーに負荷がかかると思われるが、実際はそうでもないらしい
+* シャードをまたがる（チャンクをまたがる）検索でも、Mongosサーバーにキャッシュされている情報がある場合は早くなる
+* チャンクが小さすぎると、分割して各サーバーに読み込み・書き込みをかけるのでサイズに関してはチューニングしなきゃいけないかも（運用次第）
+* ローカルにMongosをたてれば、問題無いだろうけどアプリケーション・サーバーは複数あるとどうなるのか？
+* また、ローカルであればTCPでなくソケット通信にすればリソースの節約になる
+* Configサーバーには構成のメタデータが格納されている（ルーティングサーバーでキャッシュされる
+* 上記サーバーは3つらしい（これが死ぬとルーティングサーバーが動作しなくなる可能性がある
+* プライマリと複数のセカンダリ（プライマリからセカンダリに同期、同期されたセカンダリから残りのセカンダリに同期、以下同じ
+* プライマリが死んだら、セカンダリのいずれかがプライマリになる（プライマリ選挙のアルゴリズム？
+* 死んだプライマリが動作できるようになると、セカンダリとして復活することになる
+* 仲裁サーバー（Arbiter）は、レプリカセットの動作状況を把握しているので選挙等を行う
+* 上記より、MongoDBでは役割分担をよくしている
+* マスタスレーブ関係(読み込み書き込み)の設定を行える（MySQLのように決まっているわけではない）
+* シャーディングに対する動作はすべて自動で行う（設定変更不可能らしい）
+* 上記をどう捉えるか？
+* データはチャンクとして分割する（ドキュメント別ではない）
+* シャーディングの構成は、マスターシャードと各シャード複数の構成
+* シャードに割り当てられたチャンクを格納する番号がある（シャードキー）
+* どこに入れるかわからない番号はプライマリシャードに格納される（事前分割したほうが良い
+* シャードに格納されたチャンクが多くなりすぎると、自動でチャンクを別のシャードに移す
+* これは、パフォーマンスがとてもよくないし、移動中は実際移動ではなくコピーになるためデータを2倍として捉えられる
+* チャンク等の仕組みを覚えてチューニングで苦労する（シャードキー※変更不可、を探す訓練）
+* 物理構成
+* プライマリ・セカンダリは実際の処理が走るので高負荷
+* mmap()による実装がある（mmapよく見るので軽く調べてみる
+* 永続化の更新は60秒に一回
+* 上記の時間データが飛ぶのが嫌なときはジャーナリングシステム（よくあるらしい
+* ジャーナリングファイルに今までとの差分を調べるためのデータはとってあるということ？
+* ディスクとメモリのマッピングで、シェアドとプライベートがあり、完全にシェアされたらディスク更新して、プライベートに反映
+* このためメモリ量が2倍使っている欠点はあるので、それを考慮したスペック構成にしないといけない
+* レプリケーションはoplogというものを読み込んで行うので、処理ログは残っている状態
+* Fire-and-Forgetの精神（書き込みの確認をしないなどのトレードオフ、どこまで確認するかは後述の詳細
+* fsync（メモリの内容をディスクに直ちにフラッシュさせる
+* 上記によって、ジャーナリングがある場合はジャーナリングに必要なデータだけをフラッシュするだけでよい
+* 確認レベルについて、まったくしない
+* インフラレベル確認（ネットワークやリソースについての問題）
+* ほかいろいろ
+* マップリデュース機能あり（入れるときにはできない？読み込むとき？
+* 固定長コレクション（シャードできない欠点はある、一つのシャードにのみに置く
+* 2次元空間インデックス
+* MySQLとの比較
+* スキーマフリーを実装に落としこむときに、何を気をつけなければいけないのか？
+* 上記でどういうスキーマのときに利用しないほうがいいのかなど
+
+##memo
+* MongoDBはKVSではなく、RDBに近い
+* indexがある
+* 階層構造があるので、自由度が高い
+* JSON to BISONによりデータの圧縮
+
No results found