エンジニアの総意でMongoDBを採用――メール配信システム「Cuenote FC」11年の歩みを振り返る - はてなニュース
メール配信システム「Cuenote」シリーズを開発・提供するユミルリンクでは、独自のメール配信システムを開発した2002年以降、メール配信のノウハウを継続して蓄積してきた。メール配信システムに対する要求は時代と共に変化している。携帯電話のキャリアメールへの対応、多様なログ解析、そしてスマートフォン対応。メール配信システムの最新技術動向や、それを取り巻く環境の変化について、同社のエンジニアたちに聞いた。 （※この記事はユミルリンク株式会社によるPR記事です） メール配信システムはCuenote FC ■ メール配信の状況は大きく変わったユミルリンクのサービスが配信するメール総数は増え続け、一昨年の月間13億通から、2013年の現在では月間25億通に達している。顧客としても、クックパッド、カルチュア・コンビニエンス・クラブ（CCC）、楽天Edy、東急ホテルズ、サッポロビールなど有力企業が名前を
MongoDB 2.4 の性能 徹底評価（Memory vs DISK） - 中年engineerの独り言 - crumbjp
大体欲しいデータは揃ったのと、MongoDBの気持ちが解ってきたのでMongoDB2.4の性能調査は今回で最後の予定 実は前回MongoDB 2.4 の性能 徹底評価（レコード長による評価）のFETCHバイト数（1.5GB） 実は今回のOn-memoryデータ vs DISKリードに繋げる事を意図した大きさだった。 システムの2GBメモリに収まるだろう。と・・・ しかし、、測れど測れど、意図した通りの結果にならない・・・ それで気付いた。 インデックスの大きさを勘違いしていたのだ。 MongoDBのインデックスは単なるコレクションでは無いようだ！ 1億件の数値型インデックスは2.3GBにもなる。 という訳で、1億件のコレクションのインデックスはそもそもメモリーに入らない。。 １ドキュメント辺り25〜26byte インデックス数値型８バイト＋ドキュメントへのポインタ８バイト＋メタ情報？ _i
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
