Jepsen: MongoDB stale reads
Please note: our followup analysis of 3.4.0-rc3 revealed additional faults in MongoDB’s replication algorithms which could lead to the loss of acknowledged documents–even with Majority Write Concern, journaling, and fsynced writes. In May of 2013, we showed that MongoDB 2.4.3 would lose acknowledged writes at all consistency levels. Every write concern less than MAJORITY loses data by design due t
MongoDBもサーバレスプラットフォーム提供開始、「MongoDB Stitch」正式リリース
NoSQLデータベースとして知られるMongoDBの開発元であるMongoDB社は、6月27日にニューヨークで開催された同社のイベント「MongoDB World'18」において、サーバレスプラットフォームの「MongoDB Stitch」が正式リリースされたことを発表しました。 MongoDB Stitchは、1年前のMongoDB World 2017でモバイルBaaSとして発表され、RESTful API経由でのMongoDBデータベースへのアクセスやユーザー認証機能などを提供するものでした。 MongoDBベースのモバイルBaaS「MongoDB Stitch」ベータ公開。JavaScript/iOS/Android対応。MongoDB World 2017 － Publickey 発表以来、MongoDB StitchはJavaScriptで記述したファンクションの実行やトリガー
「MongoDB 4.0」正式リリース。マルチドキュメントに対するACIDトランザクションをサポート
MongoDBはオープンソースとして開発されているドキュメント指向データベース、いわゆるNoSQLデータベースのひとつです。データの形式として柔軟にデータを格納できるJSONライクな形式を採用し、1つのJSONライクな形式のデータを1つのドキュメントとして保存します。 MongoDBの開発元であるMongoDB社は6月27日、ニューヨークで開催された同社のイベント「MongoDB World'18」において、最新のMongoDBとなる「MongoDB 4.0」の正式リリースを発表しました。 MongoDB 4.0の最大の特徴は、マルチドキュメントの操作に対してACIDトランザクションがサポートされたことです。 マルチドキュメントのトランザクションでは、「start_transaction」によりトランザクションの開始を宣言したあとで、複数のドキュメントに対する操作を行い、そのいずれかが失敗
Why You Should Never Use MongoDB
Disclaimer: I do not build database engines. I build web applications. I run 4-6 different projects every year, so I build a lot of web applications. I see apps with different requirements and different data storage needs. I’ve deployed most of the data stores you’ve heard about, and a few that you probably haven’t. I’ve picked the wrong one a few times. This is a story about one of those times —
Goodbye MongoDB, Hello PostgreSQL
Olery was founded almost 5 years ago. What started out as a single product (Olery Reputation) developed by a Ruby development agency grew into a set of different products and many different applications as the years passed. Today we have not only Reputation as a product but also Olery Feedback, the Hotel Review Data API, widgets that can be embedded on a website and more products/services in the n
MongoDBの$150M調達で色々考えさせられたこと - ワザノバ | wazanova.jp
http://www.bloomberg.com/news/2013-10-04/mongodb-becomes-king-of-nyc-startups-with-1-2-billion-valuation.html 10genが社名もMongoDBに変えてたことは知りませんでした。さて、同社が$1.2BのValuation (企業価値)で$150M調達ということですが、昨年、Githubが$750Mのvaluationで$100M調達したのに続き、オープンソースがベースになってる会社で大型資金調達が成功する事例が続いてますね。 MongoDBはHacker Newsで取り上げられる度に驚くほどネガティブコメントを集めてるのですが、今回も例にもれず、この資金調達のニュースには219件のコメントがつき、トップに掲載されてる（おそらく掲載順ロジックはUpvoteの数なので、一番人気のコメン
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
当社の時系列グラフを支える技術 – 一日に20億、月に30TBに及ぶドキュメント
Server Density(サーバーデンシティ)社は月に30TBに及ぶサーバからの受信データポイントを処理し、単純なLinuxシステムのロードアベレージから18カ国からのウェブサイトレスポンスタイムまで多岐にわたる顧客データ監視しています。これらすべてのデータはMongoDBにリアルタイムに入力され、顧客がグラフを閲覧したり、ダッシュボードのアップデートやレポート作成時に出力されます。 当社では MongoDBを2009年半ばから使用しており これまでデータベースのスケーリングに関して多くのことを学んできました。当社は複数のMongoDBクラスタを使用していますが、本記事ではこれまでの履歴データを保存しているクラスタに注目し、当社がどのようなスケーリングを行なったかを解説致します。 1. 専用ハードウェア及びSSDの使用 当社のMongoDBインスタンスはすべてソフトレイヤー社の２つのデ
SQLに対するMySQLと、NoSQLに対するMongoDBは似ている――主に有害な意味で | Yakst
MySQLのジョインが遅いことでSQL全般のジョインが遅いと思われることがあるように、NoSQLの中でもMongoDBが比較的広く使われるようになってきた今、MongoDBの欠点がNoSQLの欠点だと勘違いされるようになってきているのではないか。「SQL Performance Explained」著者Markus Winand氏の指摘。 昨日(9/30)の夕方、私は「SQLに対するMySQLのように、NoSQLに対するMongoDBにはよくない面がある」とツイートをした。あいにくそのツイートには説明が欠けていた。とはいえ1つのツイートに全ての必要な説明を含むことはできないだろうから、この記事で説明しよう。ツイートへの返事として受け取ったいくつかの疑問に答えられればと思う。 まず最初に、私は多言語永続化の考え方に賛同はするが、NoSQLの熱狂的支持者ではないということを知っておいてほしい。
10分で理解するMongoDBのパフォーマンス - (ﾟ∀ﾟ)o彡 sasata299's blog
2010年04月25日00:16 NoSQL MySQL 10分で理解するMongoDBのパフォーマンス MongoDBってスキーマレスなDBで、カラムが決められないような場合に使うと効果的なんだと思うんですが、「そういうデータはハッシュにして、JSON 形式で MySQL に保存すれば良いのでは？」という意見をいただいたので、その場合とのバフォーマンス比較をしてみました。 ※最初は MySQL として innodb でしか評価していなかったため、myisam の結果についても追記しました。(2010/04/25追記) ベンチマーク環境の準備 試した環境としては、MySQL 5.1.45, MongoDB 1.2.4 です。MySQL側はこんな感じ。 mysql> desc blogs; +------------+--------------+------+-----+---------
第13回 MongoDBの性能 | gihyo.jp
はじめに 前回、前々回とMongoDBの非機能面に着目してきましたが、今回も非機能に着目して、MongoDBの処理性能について説明します。まず前半では、MongoDBの動作の中で処理性能に影響を与える動作を説明します。それをふまえた上で、後半では処理性能をどのように上げるかを説明します。 なお、今回はMongoDBを単体で使った場合の処理性能を考えています。レプリケーションやシャーディングを行った状態の処理性能については対象外とさせていただきます。 処理性能にかかわるMongoDBの動作 データアクセス MongoDBがどのようにデータにアクセスするかは、MongoDBの処理性能を考える上で非常に重要です。 MongoDBではデータファイルを仮想メモリにマッピング（Linuxではmmapという機能を利用）し、MongoDBのプロセスは仮想メモリにアクセスします。図1のように、アクセスするデ
時系列データとMongoDB2.4の新機能Hash based sharding - 中年engineerの独り言 - crumbjp
実は数年前（MongoDB 1.6〜1.8の時期）にログをリアルタイムに全てmongodbに叩き込んで期間毎に解析する仕組みを作ろうとして挫折した事がある。 理由は幾つかあったのだが主に cappadコレクションでは解析時の負荷とログ投入負荷が重なってしまう。 → 最終的には書き込みが負けてoplogが溢れる。 時系列カラムをshard keyにするとchunk migrationが辛すぎる。 そもそもshardingの信頼性が・・・ という理由だった。 今ならストレージエンジンが早くなったし再挑戦しても良いかもしれない。 ログは非同期に準リアルタイムに拾って投入。 出力元＋時間でshard key。 なるべくグループコミットの効率が上がる塊を作る。 とか、、 お題 ともかく、今回は 時系列データを投入した時chunk migrationがどう動くのか？ の話。 そもそも時系列カラムをsh
ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
mongodbの真の売りは性能にあらず
主にfacebookにつぶやきまくる毎日。 noteとかzenn.devにも書いてるので、こっちはあんまり更新してません。 最近あんまりmongodb触ってません。 以前の案件でのmongodbは近日停止しちゃうし、現在従事してる案件はredisです。 なんでredis？っと思いましたが、半年も前から決めちゃってる話で、 性能で選んだらしい。色々調べてみるとそれなりには納得。 http://blog.brandonc.me/2011/11/memcached-vs-redis.html 色々まとまってるのは上記ですね。中国語ですが。 #自分で測定する時間と元気は今はありません。済みません。 性能測定上は、redisはmongodbより3倍速いってことなのでしょう。 実際そうなのでしょう。 ただしmongodb経験者からみると、redisは機能が低すぎてビビります。 「データベース番号」とか
仙人掌世界: Memcached vs Redis vs MongoDB vs MySQL 效能比較
"記憶體是新一代的硬碟"在高流量網站內已是稀鬆平常的事情，像是採用 Memcached 做分散式快取服務即是典型的應用模式，Memcached 使用概念簡單且相關應用情境、文件、工具、演算法都已相當成熟，許多知名網站都運用 Memcached 提升scalability，像是GAE、Heroku 等PaaS 環境也有提供 Memcached 的收費服務，這些市場訊息已說明大規模的使用記憶體是可以合乎成本效益的。 Redis 是近年隨著 NoSQL 熱潮出現的 Key-Value store，其功能涵蓋了 Memcached 並且提供許多高階功能，在許多應用情境下相較 Memcached，能降低開發與營運複雜度，比如： 豐富的資料結構(strings, hashes, lists, sets and sorted sets) 更易於設計適當的資料粒度增進資料重用的機會，且可依不同的資料結構特
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
Time-series data in Redis
For Insanity, I’ve been working on some of the support services that are built into the website that provide our staff with information from ancillary services and tools and bring it into a clear and useful format for decision making and monitoring. Latest on the agenda has been listener figures from our Icecast streaming servers. While this isn’t a perfect benchmark of our performance since we br
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - torodb/torodb: The old repository used to store ToroDB related products and libraries
Inside pixiv's infrastructure〜application cluster side〜
後悔しないもんごもんごの使い方 〜サーバ編〜
