ZenClerkが月間10億PVを支えるまでの 過程で経験したアンチパターンを紹介

MySQLのジョインが遅いことでSQL全般のジョインが遅いと思われることがあるように、NoSQLの中でもMongoDBが比較的広く使われるようになってきた今、MongoDBの欠点がNoSQLの欠点だと勘違いされるようになってきているのではないか。「SQL Performance Explained」著者Markus Winand氏の指摘。 昨日(9/30)の夕方、私は「SQLに対するMySQLのように、NoSQLに対するMongoDBにはよくない面がある」とツイートをした。あいにくそのツイートには説明が欠けていた。とはいえ1つのツイートに全ての必要な説明を含むことはできないだろうから、この記事で説明しよう。ツイートへの返事として受け取ったいくつかの疑問に答えられればと思う。 まず最初に、私は多言語永続化の考え方に賛同はするが、NoSQLの熱狂的支持者ではないということを知っておいてほしい。
前回のMongoDB 2.4 の性能 徹底評価の反響が大きかったので続編。 今回の調査対象 ドキュメントサイズ毎の性能を評価する。 今回の検証用にベンチを書いた。 性能見積りにも使えると思うので、紹介しておきます。 MongoDB-JP/mongo_bench 今回の検証も、Sakura VPS 2G で行った。 専用環境ではないので、ある程度まわりの影響を受けている。(何度もベンチを取って極力排除はしたが、、) また、記事に載せた以外にも色々と検証しており、その結果も少し混ざっていたり。。 オンメモリデータの処理が高速な事は解っているので 今回の検証の肝は『ディスクアクセス』 MongoDBはメモリ以上のデータを扱う為のプロダクトなのでなるべく性能が出ない様な条件=ワーストケースを狙った。 2GBメモリに対して40GBのデータを扱い、データ全体を万遍なく使うようなクエリーを発行する。 評
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。(overSecondsはまあ良い) mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。(何を測ってるんだ?) カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
Hello, I’m Kristof, a human being like you, and an easy to work with, friendly guy. I've been a programmer, a consultant, CIO in startups, head of software development in government, and built two software companies. Some days I’m coding Golang in the guts of a system and other days I'm wearing a suit to help clients with their DevOps practices. While SQL databases are insanely useful tools, their
最近 Fluentd をプロジェクトで導入しようと考えています。 Fluentd は、あらゆるデータのログを json を使ってシンプルに転送、集約させることができるツールです。 クラウド環境やビッグデータを扱う上で、今後需要が高くなりそうです。 ソーシャルゲーム業界などではかなり実績があるみたいですね。 今回お試しとして、Node.js のエラーログを Fluentd を使って MongoDB に保存するサンプルを作ってみます。 こんな感じ。とてもシンプルです。。 Input Output +------------------------------------------------+ | | | Node.js --------> Fluentd --------> MongoDB | | | +-------------------------------------------
分散パフォーマンステスト関係を書こうと思っていたんですが,よくよく考えたらMongoプラグインについて日本語でまともな記事を書いたことなかったので書きます. このエントリはウィークリーFluentdユースケースエントリリレーの参加エントリです. 概要 MongoプラグインはMongoDBに対するInput/Outputプラグインを提供します.またユーティリティとして,MongoDBのcappedコレクションに対してtailを行うmongo-tailコマンドも付属しています. リポジトリ: https://github.com/fluent/fluent-plugin-mongo MongoDBは内部はBSONですが,API的にはJSONでやりとりしており,また明示的なスキーマもいらないため,Fluentd周辺では集計サーバやテンポラリサーバとして広く利用されています. td-agentには
この度、1年10ヶ月ほど勤務した会社を退社*1することになりました。会社や一緒に働いた仲間達への謝辞の気持ちを表すとともに、今までのプログラマとしての人生を振り返って自分語りをしてみる、いつもと違った少し長めのエントリです。なお、ここに書かれていることは個人の見解であり、所属する(していた)組織の意見を代表するものではありません。 文学部書道学科卒という、ちょっと変わった学部をでてすぐに、新卒で、ある会社に就職しました。今年で社会人4年目の1986年生まれです。 もともと、学生時代にプログラミングはほとんど経験がなく、高校から大学はずっと書道に明け暮れる日々でした。*2 初めてプログラミングを勉強したのは大学3年の就職活動が始まる少し前です。文学部書道学科という経歴では、高校や中学の教師になるくらいしか学部時代の経験を直接活かすことができる道がなく、教師になる気がなかった自分は、なんとなく
Most UNIX-like operating systems, including Linux and macOS, provide ways to limit and control the usage of system resources such as threads, files, and network connections on a per-process and per-user basis. These "ulimits" prevent single users from using too many system resources. Sometimes, these limits have low default values that can cause a number of issues in the course of normal MongoDB o
はじめに WAF「Scutum(スキュータム)」ではサービス開始時より、データストアとしてmemcachedとpgpool II+PostgreSQLを利用しています。これらはどれも安定して動いており満足しているのですが、最近になってより柔軟にデータを取っていきたいというニーズが高くなってきたため、MongoDBの導入を行いました。まだ完全なリプレースまでは至っていませんが、元々のデータベースのスキーマ構造がシンプルであることもあり、数ヶ月以内にはpgpool II+PostgreSQLの部分をMongoDB(Replica Sets)で置き換えることができるのではないかと思っています。 MongoDBにとっての「メモリ使用量」 MongoDBを導入するにあたり、Linux(X86_64)上でMongoDBを動作させたときのメモリの消費について、簡単にですが調べてみました。まず参考にしたの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く