読者です 読者をやめる 読者になる 読者になる

おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

おがさわらなるひこ @naru0ga が技術系で興味を持ったりなんだりしたことをたまーに書くブログです。最近はてなダイアリー放置しすぎて記事書くたびにはてな記法忘れるのではてなブログに移行しました。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツは クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。

なんでMongoDBなのん?

AdventCalendar2013 MongoDB 与太話

この記事はMongoDB Advent Calendarの11日目が開いてたので急遽突っ込んだものです。ので、大して内容はありません。

MongoDB賛否両論ありますけど開発者は好意的で運用者は悲観的って感じなのかなあ。
で、開発者としての楽しさをちょっと書いておきます。

なんでMongoDBがいいのさ?

SQLも書けない情弱だからという意見は受け入れます。正規化がどうこうとかいうの理屈ではわかってるにしてもめんどくさい。せっかく宣言的に書いてるのに間にオプティマイザとかいろいろ挟まってるせいでそれぞれのRDBMSの中身をがっちり知らないと早いクエリー書けないっていうのもなんだかなって気がする。さらにORMがあると最悪。なんの制御もできない。だったらクエリーをJSONで組み立てて命令的に処理できる方がまだ見通しがいいよねと私レベルだと思うわけ。

同じような理由で特別な言語を覚える必要がなくてそれぞれの言語のドライバーだけみてればいいというのはやっぱいいですよ。

動的スキーマ ― 最近MongoDBの中の人はスキーマレスという言葉を避けてる気がする ― もやっぱり気軽。そりゃ全然スキーマ作らないで済むわけがないし、インデックスとかシャーディング考えたら逆にその時点ではきっちりスキーマないとだめなんだけど、とにかく最初はテキトーに始めてもなんとかなるカジュアルさは捨てがたい。

あとDBのシェルがまんまJSってのは覚えることが減っていいよね。いや、私はJS書けないんだけど、

レプリカセットの仕組みはすごいクールだと思う。自由度が高くていろんな構成が取れる。設計の自由度が飛躍的に高まるのは色々楽しい。まあ自由すぎて困ることもあるといえばあるけども。

賛否あるけど、コレクションをまるごとmmapしてオンメモリで速度を稼ぐとかそういう「あんまり凝ったロジックをやらない」ところは好きかな*1

ここはびみょいよねってところ

先日のMongoDB Tokyo 2013でも説明があったけど、「クエリーパターンに応じてスキーマを決めないといけない」ところはなかなか難しいやね。特に私の本業のようなSIerだと、そんなの案件始まってみないとわかんないので、それでサイジングとか出すのが非常に辛い。割とSIとしては使いにくいと思うところではあります。

ディスク食いなのも辛いかなあ。これはスキーマ次第でなんとかせいということなのかもしれないけど。CPU余ってるんだから圧縮とかすればいいのにって思ってたらやっぱ将来は考えてるみたい。なんとかならんかねえ。

運用辛いってのは百万回聞いてるけどぼくはそんな大規模運用したことないのでわかんないのでここは省略。

商用サポートが手厚いのは悪くないんだけど、エンプラ版の価格設定が高すぎる。台数並べてパフォーマンス稼ぎましょうというモデルなのに台数並べると札束が消えていくってのはひどくないかい。これじゃサポート買えないよ。もうちょっと考えてほしいです。それともSubscriptionってのはエンタープライズ版の購入価格でサポートは別に買える? だったらごめんなさい。

まとまってないまとめ

とりあえず開発者にとっては楽しいと思うんですよ。大規模でなければ運用もそんなめちゃくちゃしんどいかというと、今んところ私は単一レプリカセットでなんとかなってるからなあ。小規模な案件でぺろっと使えるところを探すのがいいと思うのです。ハイ。


12日の understeer さんと 13日の yuuna さんも書いてくれないかな―、とか。

*1:逆に最近、商品性を上げるためにどんどん凝った機能を追加してるところなんかは、ちょっとどうなんかなあという気がしないでもない。