Hello from the Engine Yard Data Team! We wanted to let you know what we’ve been up to since the last time we blogged. When the team was formed earlier in the year, our first job was to expand our stack with MongoDB. However, we felt it would be a disservice to you, our customers, if we added a NoSQL datastore into the stack without first updating the relational databases that we support. So, we de
原文(投稿日:2011/11/07)へのリンク 最近、MongoDB に関して非常に好ましくない内容のかなり話題になった市場報告が2つあった。批判の大部分は、パフォーマンス問題とデータ損失の組合せに集中している。この話を続ける前に、これらは公式の事例研究でないことを肝に命じて欲しい。そうではなくて、最近 MongoDBを使った開発チームによる市場報告である。 まず Urban Airshipの Michael Schurter氏のレポートから始める。 Urban Airshipは既に、MongoDBの問題を経験しており、このレポートを書く前にデータのほとんどを PostgreSQLに移行を済ませていた。残ったデータはMongoDBにとって理想的のようだ。 短命-もしそれを失っても、短い間サービス低下を経験するが、 壊滅的ではない 小さい-容易にメモリーに収まる(~15 GB) 二次索引-キ
Hi,I run engineering for foursquare. About a year and a half ago my colleagues and I and made the decision to migrate to MongoDB for our primary data store. Currently we have dozens of MongoDB instances across several different data clusters storing over a TB of data and handling 10s of thousands of requests per second (mostly reads but the write load is reasonably high as well). Have we run into
データストアの新たなカタチとしてNoSQLがブームになっていますが、その中で異彩を放っているのがドキュメント指向データベースである「MongoDB」です。サイバーエージェントでは、このMongoDBを比較的早い段階から実サービスで活用しています。そこで今回はMongoDBの使いどころや利用時の注意点について、サイバーエージェントの3人の技術者にお話を伺いました。 分散処理のしくみを最初から備えるMongoDB リレーショナルデータベース(以下RDB)ほど煩雑ではなく、分散KVS(Key-Value Store)ほどシンプル過ぎない第三のデータストアの1つとして、ドキュメント指向型データベースである「MongoDB」が挙げられます。GNU AGPLv3を採用したオープンソースソフトウェアであり、パフォーマンスが高くスケーラビリティにも優れているという特徴があります。また、JSON(JavaS
一部の方から“SymfonyのMongoDBの人”などと呼ばれたりしますが、実はSymfonyもMongoDBも業務では使っていない、という痛い感じの @madapaja です。 大事なことは最初に言う。という事で、宣伝から始めます。 ここ1年で急伸している MongoDB。日本でもMongoDB JP(MongoDBの日本ユーザー会)が去年の11月18日に立ちあがって以来、勉強会やカンファレンス等も開かれ、盛り上がりは加速し続けています。 MongoDBをもっと知りたい、と思ったら、以下のGoogle グループや勉強会にもぜひ参加してください!みんなでMongoDBを楽しみましょう。 MongoDB JP | Google グループ 「第6回 MongoDB 勉強会 in Tokyo」 : ATND(すでに定員オーバーしてますね。。。) と大見得を切ったので、MongoDB
16. { "_id" : ObjectId("4dcd3ebc9278000000005158"), "timestamp" : ISODate("2011-05-13T14:22:46.777Z"), "binary" : BinData(0,""), "string" : "abc", "number" : 3, "subobj" : {"subA": 1, "subB": 2 }, "array" : [1, 2, 3], "dbref" : [_id1, _id2, _id3] } 17. { "_id" : ObjectId("4dcd3ebc9278000000005158"), "timestamp" : ISODate("2011-05-13T14:22:46.777Z"), "binary" : BinData(0,""), "string" : "abc", "num
CouchDBとMongoDBをしばらく使ってみて、その使い分けのポイントがわかってきたような気がするので、ちょっと書いてみたい。 CouchDBとMongoDBは、広く「NoSQL」と総称されている非SQL型データベースのうち、「ドキュメントデータベース」と呼ばれるカテゴリを代表する2つだ。ドキュメントデータベースとは、かんたんにいうと、JSONデータ(=ドキュメント)をそのままデータベースに保存できるというもので、従来のRDBのような「スキーマ」がない。複数のテーブルを結合(join)するという使い方をせず、一意キーの指定や比較的単純なクエリーでJSONデータを取り出す。 ここでは詳しい話には踏み込まず、2つのデータベースの違いを私の主観で、ごく大雑把にまとめてみる。 まず、それぞれの強みを私の印象で3つずつ書くと、こんな感じだ。 CouchDBの強み: 1)優れた管理画面「Futon
MongoDB is a document-oriented database that stores data in flexible, JSON-like documents. It supports features like replication, auto-sharding, and indexing. The document discusses using MongoDB with Ameba Pico's photo tagging service, including initial implementation with one shard, expanding to multiple shards as user numbers grow over time, and repairing and upgrading shards over time to suppo
というわけで訳してみました。 Master Detail Transactions in MongoDB RDBにおいて、トランザクションはデータのアトミックな更新を可能にしています。関係スキーマは高度に正規化されているために、ほとんどの論理的なトランザクションスパンは複数のテーブルにまたがります。それゆえ、複数の更新をアトミック(すべてか全部ダメか)に行えることが重要になっています。 MongoDBは複数ドキュメントのトランザクションを行うことができませんが、ドキュメント指向のデータモデルを通して多くのユースケースで埋め合わせをしています。このポストでは、Master-Detailデザインパターンについて語ります。 これは、RDBMSにおけるマルチステートメントトランザクションを常に要求するようなデータモデルでしばしば見られ、しかし、MongoDBにおいてはクロスステートメントなトランザ
At Highgroove, we build database-backed web applications. These days, there are many options when choosing a database backend. We normally start with relational database systems (e.g., PostgreSQL and MySQL) because they are very mature and feature niceties like ACID transactions and locks. On the other hand, we also work with newer NoSQL database systems that often trade features like transactions
Brian Ritchie has two posts (☞ here and ☞ here) covering three document databases: CouchDB, MongoDB, and RavenDB concluding with the matrix below: But before using this as a reference material there are a couple of corrections needed: They have some special characteristics that make them kick some serious SQL. Objects can be stored as documents: The relational database impedance mismatch is gone.
生まれ変わった「Days of Liris」。プログラミングのこと、Pythonのこと、気になったソフトウェアのこと、身の回りのこと、いろんなこと。など まず、MongoDBの負荷分散、もしくは、データの分散については、shardingという仕組みで行っています。shard自体は通常のmongodのプロセスです。各shardには、データがchunkの単位で保存されています。chunkは、キーに対してデータの連続性が確保されているので、連続したデータへのアクセスが高速化されます。一つのmongodのプロセスにchunk単位以上のデータがセットされたり、サーバの数が増加すると、他のshardにデータが自動的に移動します。この仕組みだけをみると、shardは増えることはあっても、減るのは苦手のように聞こえます。 shardが自動でデータの分散を行ったり、どこにデータがあるのかを見つけるためにco
生まれ変わった「Days of Liris」。プログラミングのこと、Pythonのこと、気になったソフトウェアのこと、身の回りのこと、いろんなこと。など 単純なキー・バリューの構造でパフォーマンスがどうなのか、memcacheと比較してみました。mongodbとmemcachedはそれぞれ、ローカルの一台のちびえあたんの中で動かしています。比較するためのコードは、次のところにあります。 MongoDB用のコード Memcache用のコード Javaのコードは恥ずかしいので公開しません。計測はちびえあたんでやっています。 やっていることは、MongoDBではnoとbodyというフィールドにデータを設定して、10000件登録しています。memcacheでも同様にキーにシーケンシャルな数、値にMongoDBでセットしたものと同じ値をいれてaddしています。 登録にかかる時間は、MongoDBでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く