エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント2件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
MongoDB 2.4 の性能 徹底評価(Memory vs DISK) - 中年engineerの独り言 - crumbjp
大体欲しいデータは揃ったのと、MongoDBの気持ちが解ってきたのでMongoDB2.4の性能調査は今回で最後の予... 大体欲しいデータは揃ったのと、MongoDBの気持ちが解ってきたのでMongoDB2.4の性能調査は今回で最後の予定 実は前回MongoDB 2.4 の性能 徹底評価(レコード長による評価)のFETCHバイト数(1.5GB) 実は今回のOn-memoryデータ vs DISKリードに繋げる事を意図した大きさだった。 システムの2GBメモリに収まるだろう。と・・・ しかし、、測れど測れど、意図した通りの結果にならない・・・ それで気付いた。 インデックスの大きさを勘違いしていたのだ。 MongoDBのインデックスは単なるコレクションでは無いようだ! 1億件の数値型インデックスは2.3GBにもなる。 という訳で、1億件のコレクションのインデックスはそもそもメモリーに入らない。。 1ドキュメント辺り25〜26byte インデックス数値型8バイト+ドキュメントへのポインタ8バイト+メタ情報? _i
2013/12/28 リンク