RethinkDBはなぜ失敗したのか | Yakst
つまり、これらのマーケットは小さく、しかもデータベースのマーケット自体よりも小さいのです。とは言え、どれかが他よりもマシになりうるでしょうか？ マネージドホスティングは、本質的にはユーザのためにAWSでデータベースを動かすことで、そうすることでユーザたちは自分で動かす必要がなくなります。これらのサービスを使う代わりになるのは、AWSに自分でデータベースを立てることです。したがって、マネージドなデータベースホスティングサービスが課金できる額には、非常に厳しい上限があることになります。Compose.ioやmLabが、RethinkDBよりも1桁あるいは2桁多いユーザを抱えるMongoDBを提供していることを考えて、マネージドホスティングを提供することには少しの良い点もないという結論を下しました。 Database as a Serviceはマネージドホスティングの更に複雑なバージョンです。D
もう二度と、絶対にMongoDBを使うべきじゃない理由
MongoDBは悪だ。なぜならそれは… …データを無くす（ソース：1、2）。 …実際、長期間、デフォルトでエラーを無視し続け、何があってもすべての単一書き込みが成功したとみなした（ 32ビットのシステムで3GBかそこらを使用したら、MongoDBの制限によって何の警告もなしに全データを失うことになった）。 …宣伝していたユースケースでですら遅く、これが早いと主張するには完全に証拠に欠けている（ソース：3、4）。 …ほぼ全てのユースケースで、暗黙のスキーマという悪しき習慣を強要してくる（ソース：4）。 …ロッキングに問題がある（ソース：4）。 …セキュリティの問題になるくらい、応答時間が酷く遅い。求めてきた人全員に認証なしで全データをさらしてしまうという危険なデフォルト設定をパッチするのに2年かかった（ソース：5）。 …ACID特性に準拠していない（ソース：6）。 …拡張やメンテナンスをする
『もう二度と、絶対にMongoDBを使うべきじゃない理由』というのがあるらしい - 中年engineerの独り言 - crumbjp
記事 https://fa-works.com/blog/why-you-should-never-ever-ever-use-mongodb なかなか香しいな。 というよりコイツ他のブログも結構ヒドイｗ とりあえず不満をぶちまけるタイプのようだ。 で、、事の本質はプロダクトの設計がちゃんと出来ない人はどんな場合でも選択を間違えるという事だ。 実際MongoDBは使いどころがかなり限られている。 MongoDBが得意なケース"以外"では絶対MongoDBを使ってはならない WriteConcernはあくまでAdditionalな機能であって本来やりたい事では無い。（RDBMSなら２フェーズコミットだぜ？） 実際、最近追加されたReadConcernもヒドイ実装である。 殆どのケースではORMが完備してるフレームとMySQLを使うのが鉄板なのは間違いない。 じゃあ具体的にいつ使うのか？という
MongoDBの単体性能（前編）
はじめに MongoDBは使い始めるのが簡単で、インターフェースもJSONを出し入れするだけとシンプルなため、DBMSに関して知識が少ないアプリ開発者でも簡単にアプリを開発することができます。サクッとアプリを作り、サンプルデータで動作を確認し、いざ本番データで動かしてみたら「あれ？思った以上に性能が出ない」なんてことはないでしょうか？ 「MongoDBはNoSQLなんだから速い」という思い込みは危険です。MongoDBをはじめとするNoSQLは「水平分散(シャーディング)が得意で、水平分散すれば単体構成よりも速い」というのは事実ですが、単体構成が速いかどうかはチューニング次第です。また「NoSQLなんだからRDBMSより速い」という考えもよくありません。単体性能を比較した場合、どちらが速いかは単純には比較できません。 「じゃあ、性能を上げるために水平分散をしよう！」と考えるかもしれませんが
MongoDB 3.0のWired Tigerのデータ圧縮とメモリ使用量制限を検証してみた - Qiita
MongoDB 3.0から従来のmmapベースのストレージエンジンから、Wired Tigerというストレージエンジンが使えるようになった。 主な変更点は以下のとおり。 mmapベース MongoDB ver 3にはMongoDB ver 2にあったmmapベースに改良を加えたものが乗っている MongoDBはOSのmmap()システムコールを読んで、OSにデータファイルをメモリに載せてもらう。 MongoDBはメモリを管理しない。OS任せ。 メモリ使用量を制限できない。OSから与えられるだけ使う。 メモリがいっぱいになるとOSが適宜スワップさせる データ圧縮できない コレクションレベルロック（ver 2のころはデータベースレベルロック） インデックスとデータは分離できない（同一ファイル内に混在） Wired Tiger MongoDB ver 3からの新規 Wired Tigerというス
MongoDB 3.0 リリースノート斜め読み - 中年engineerの独り言 - crumbjp
遂にMongoDB 3.0 が正式リリースされました！！ 例によってリリースノートを斜め読みします。 http://docs.mongodb.org/master/release-notes/3.0/ が、、最初に一言で纏めると、まあ、、 目玉機能はロックレベルの話だけですよー でわ。。 Pluggable Storage Engine AP 以下の２つからストレージエンジンを選べる。 MMAPv1 これまでのストレージエンジン。デフォルト WiredTiger 3.0から追加されたストレージエンジン WiredTiger MongoDBの全ての機能をサポートしている。 MMAPv1とフォーマットが違うので既存のアップデートの場合、移行する際に色々必要。 ドライバも最新に上げないとダメ。 ドキュメントレベルロックが可能！！ touchコマンドはサポートしてない MMAPv1 Improve
月間10億pvを支えるmongo db
[DL輪読会]Reward Augmented Maximum Likelihood for Neural Structured Prediction
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
「演算子のインジェクション」と「SSJI」
「演算子のインジェクション」と「SSJI」：NoSQLを使うなら知っておきたいセキュリティの話（1）（1/2 ページ） ここ数年、大量データ処理時の高速性やデータ構造の柔軟性などから、「NoSQL」が注目を集めています。それと同時に、NoSQLを使うアプリケーションに対する攻撃手法も研究されるようになりました。この記事では、NoSQLを使ったアプリケーションの脆弱性と対策について解説します。 注目集める「NoSQL」 ここ数年、NoSQLと呼ばれる種類のデータベースが注目を集めています。NoSQLはSQL言語を使用しないデータベースの総称で、大量データ処理時の高速性やデータ構造の柔軟性などのメリットがあるため、従来のリレーショナルデータベース（RDB）を補完・代替するものとして、大規模なWebアプリケーションなどにおいてNoSQLを採用する事例が増えています。 このような新しい技術が普及し
MongoDB 2.4 の性能 徹底評価 - 中年engineerの独り言 - crumbjp
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
クラウド時代のアプリ開発(2) Apache+php+MongoDB編 | Web技研
前回、Amazon EC2にサーバーを立てたのでその続きです。 今回は、EC2のCentOS(64bit)に Apache php MongoDB MongoDBへ接続するためのPHPドライバ をインストールをしてみました。 １．yumでapacheとphpをさくっとインストール yum install httpd yum install php ２．httpd.confとphp.iniを適宜編集 ３．MongoDBインストール ４．10genのリポジトリを追加 下記ファイルを作って /etc/yum.repos.d/10gen.repo 下記内容を追加 [10gen] name=10gen Repository baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64 gpgcheck=0 詳細は本家
C10K on Mongo's sharding
3. Simple case client host httpd httpd httpd httpd httpd httpd httpd mongos server client mongod shard1 shard2 －3 － 4. Simple case client host httpd Give mehttpd httpd httpd DATA_A ! httpd httpd httpd mongos server client mongod shard1 shard2 －4 － 5. Simple case client host httpd Give mehttpd httpd httpd DATA_A ! httpd httpd httpd mongos server Where is the DATA_A ? client mongod shard1 shard2 －5
MongoDBのはじめての運用テキスト
2. ■はじめに ■概要／特徴 ■想定環境 ■運用項目 □インストール ・インストール手順 ・初期設定ファイル[mongod.conf] □レプリカセット ○レプリカセット構築 ・設定ファイル変更[mongod.conf] ・レプリカセット設定 ○ レプリカセット設定変更 ・設定確認 ・設定テンプレートの内容変更 ・設定変更適用 ○ レプリカセットステータス確認 ・ステータス確認 □シャーディング ○シャーディング構築 ・設定ファイル変更[mongod.conf] ・設定ファイル変更[mongoc.conf] ・設定ファイル変更[mongos.conf] ・シャーディング設定 ○データベース／コレクションのシャーディング有効化 ・データベースのシャーディング有効化 ・コレクションのシャーディング有効化 ○ シャード、Chunk状況確認 ・状態確認コマンド ・シャーディング状態確認[全件表示
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
荒ぶるmongos様 - 中年engineerの独り言 - crumbjp
Sharding構成で苦しんだ時の状況 現在mongosのコードを解析中なので、状況だけ。 ごく一般的な利用方法だと思うのだけどShardingは取扱いに注意が必要。 システム構成 実際はMongoDBサーバも沢山あってShardingを構成しているのですが 今回の現象は１台でも同じ事なので１台として表現します。 Webサーバ x いっぱい apache-prefork (httpd MaxClient=50) mongo-php-driver mongos MongoDBサーバ mongod WEB Servers | MongoDB Server ---------------------------------+ SERVER-1 | ※3 +----------+ | +-----------+ [httpd]-------->| |※2 | ※1 | | [httpd]-----
MongoDB is Fantastic for Logging | MongoDB Blog
We’re all quite used to having log files on lots of servers, in disparate places. Wouldn’t it be nice to have centralized logs for a production system? Logs that can be queried? I would encourage everyone to consider using MongoDB for log centralization. It’s a very good fit for this problem for several reasons: MongoDB inserts can be done asynchronously. One wouldn’t want a user’s experience
Mongo DB Casual Talksに参加してきました - TechTalkManiacs
渋谷のDeNAさんで開催されたMongo DB Casual Talksに参加してきました。業界用語で言うところのカジュアルにふさわしい、ガチの勉強会でした。 MongoDBのアレ MongoDBはクラスタリングやシャーディングが自動的なのが魅力 ただしシャード設定の不備があると、本当に突然パフォーマンスがダウンする バックアップはオートバランスを停止してから ロックがグローバルなのに注意 障害・ログ mogostat faultが多い場合はメモリ不足の可能性あり Locked%が高い場合は書き込みを分ける qr|qwもロックの可能性を疑うこと mongosniff 複雑なクエリなどを見るときに Loglevel変更は動的にできるので、何かあった時にあげるといい 「みんなもカジュアルに100シャード運用してみよう！」 Casual Compression onMongoDB 「今日はデータ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CyberAgentにおけるMongoDB
mongo_bench/README.md at master · MongoDB-JP/mongo_bench
MongoDB2.2の新機能
