moongodbにおけるデータ容量増加に対する考え方

447 views
Skip to first unread message

norist

unread,
Jul 13, 2017, 1:12:50 AM7/13/17
to MongoDB JP
皆様
お世話になります。

とても初歩的なことかもしれませんが少々教えてください。
mongodbを3台のレプリカ構成で運用しています。

当初サイジングは行ったもののシステムの利用用途も拡大し、
今のペースでいくと、今後ディスク容量が枯渇することが想定されてきています。

そこで当然容量確保に動きたいと思っているのですが、思いのほか悩んでいます。

例えばOracleの時はディスク追加して表領域割り当て。テーブルにより表領域割り当てをコントロールすれば
スケールアップできたのですが、mongoではコレクション単位、データベース単位にディスク領域の割り当てコントロールができず
ぬぬぬぬ、と。
そこで以下の検討をしてみていますが、、


検討案1:大きいディスクに乗せ換える
 ⇒単純ですがスケールアップ可能です。が、この先また想定容量よりも増えた場合、
  また乗せ換えするなどはかなりの手間がかかることが想定され、あまりスマートではなく感じます。
 (どこまであらかじめ大きい玉を用意しておけばよいのか、となりますし)

検討案2:シャーディング構成への切り替え
 ⇒シャーディング構成にすれば、容量的にも水平スケールできると思っています。
  が、言わずとしれた「キー設計」の難易度より、ましてや容量アップを目的にした
  シャーディング構成への移行はリスクのみが高過ぎであり、最良の選択肢とは思えませんでそた。
  
  またシャーディング構成はとるものの、コレクション自体をすべて「Non-Sharded」にしちゃえば行けるんじゃ!?
  なんても期待しましたが、すべてプライマリシャードに偏るということですので、目的は満たせないと理解してます。
  (プライマリシャードの切り替えもできるようですが、全部引っ越すだけなので意味はなしと判断)

検討案3:別のレプリカセットを構築し用途により用いるデータベース(インスタンス)を分ける
 ⇒単純に別のインスタンスを追加し、用途により利用を分ける方式。
  とてもダサいですが、そもそもmongodbはリレーショナルではなく、別々に分けていても利用側の手間こそあれ
  そこまで致命的ではないのかもと。。(3.4でviewが使えるようになったのであれですが、、、)

上記の通り、
思いのほかどれもしっくりこないなぁと。

どこでも考えそうな事象なのですが、皆様どう対処されているのでしょうか。
ご教示いただけましたら幸いです。

なにとぞよろしくお願いいたします

ノリ








Tetsutaro Watanabe

unread,
Jul 13, 2017, 9:10:27 AM7/13/17
to mongo...@googlegroups.com
渡部と申します

Linuxの前提でお答えします。

↓のオプションによりDB毎にデータファイルを格納するディレクトリを分けることは可能です。ですので、各データディレクトリ事にディスクを分けることができます。



あとは、LVMで複数ディスクを1パーティションにみせることが出来るので、これで容量拡張するという手もあります。


ご参考までに。


2017/07/13 14:12 "norist" <noriaki.ki...@gmail.com>:
--
このメールは Google グループのグループ「MongoDB JP」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには mongodb-jp+unsubscribe@googlegroups.com にメールを送信してください。
このグループに投稿するには mongo...@googlegroups.com にメールを送信してください。
https://groups.google.com/group/mongodb-jp からこのグループにアクセスしてください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

norist

unread,
Jul 14, 2017, 1:01:54 AM7/14/17
to MongoDB JP
渡部さん
お世話になります

ご教示ありがとうございます
いつも各所の記事参考にさせていただいております。

>↓のオプションによりDB毎にデータファイルを格納するディレクトリを分けることは可能です。ですので、各データディレクトリ事にディスクを分けることができます。
なんと。。。
勉強不足ですみません。
メモリ(パフォーマンス)ではなく容量問題だけならまずはこれ検討ですね。

LVMは初期構築段階で検討しておくべき内容ですね。
非常に勉強になります。

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

ノリ

2017年7月13日木曜日 22時10分27秒 UTC+9 Tetsutaro Watanabe:
このグループから退会し、グループからのメールの配信を停止するには mongodb-jp+...@googlegroups.com にメールを送信してください。

berlinbytes

unread,
Jul 27, 2017, 2:41:42 AM7/27/17
to mongo...@googlegroups.com
小林と申します。

現実的に、解決策として取れる手段として

- ディスクの追加を行う
- マシンの追加を行う
- データベースの容量を減らす

この3点だけかと思われます。

私であれば、マシンが増やせるのであればシャード化の後、水平分散させます。
マシンが増やせないのであればディスクのスケールアップ、
やり方としてはRSの1台を外してスケールアップ後戻してデータのsync後primaryに、、のように
1台ずつの作業になるかと思います。

別のRSを用意して、アクセス先を使い分けるやり方も可能ですが
使い勝手や運用の手間を考えると、シャード化を行い水平分散をするほうが後々楽ではないかな、、と思ってしまいます。

用途によりけりになってしまいますが、シャード化での水平分散のメリットは
DBに対して使用できるメモリ領域をシャードの分増やせることだと思っています。
なので、アクセスの処理に重きをおくのであればシャーディングへの移行を検討するべきであろうと思いますし、
ひたすらデータを収集するだけのような用途であれば、巨大なディスクを持つレプリカセットで事足りるのかなと。

とはいえ、mongodbが得意とするデータ容量もあると思うので、
レコードの削除運用も検討するべきだとは思いますが。。

参考になりますでしょうか。

2017年7月14日 14:01 norist <noriaki.ki...@gmail.com>:
このグループから退会し、グループからのメールの配信を停止するには mongodb-jp+unsubscribe@googlegroups.com にメールを送信してください。

このグループに投稿するには mongo...@googlegroups.com にメールを送信してください。
https://groups.google.com/group/mongodb-jp からこのグループにアクセスしてください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。



-- 
kentaro kobayashi
Reply all
Reply to author
Forward
0 new messages