MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyoを終えて - albatrosary's blog
MEANとは、LAMP(Linux, Apache, MySQL, PHP)に変わる技術としてじわじわと注目されはじめているアーキテクチャです。このアーキテクチャMEAN(MongoDB, Express, AngularJS, Node.js)は、シンプルでかつ強力なアーキテクチャで、現在のJavaを利用したアプリケーション開発とは一線を画すところです。HTML5開発にとってJavaの役割が殆どなくなるというのも注目すべき点だと考えます。MEANで一般的に言われる注目すべき事項は次のところです： JavaScriptフルスタックである データモデルとしてクライアントからデータベースに至までJSON そして、この記事を書こうと思ったきっかけですが、2014/10/5(日) Mozilla Open Web Day in Tokyo | Mozilla Japan でのMEAN解説展示で、様
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
MongoDB 2.4 の性能 徹底評価 - 中年engineerの独り言 - crumbjp
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
RubyistのためのMongoDB入門
MongoDBとは 10gen社が中心となって開発している非リレーショナルデータベース。 特徴 MongoDBは("humongous"より)は、スケーラブル、ハイパフォーマンス、オープンソース、スキーマフリー、ドキュメント指向です。C++で書かれていて、機能としては: ドキュメント指向ストレージ (the simplicity and power of JSON-like data schemas) 動的な クエリー 組み込みのオブジェクトと配列をサポートした完全な Index のサポート。 クエリー プロファイリング 速い in-place アップデート バイナリデータの効率的な保存 large objects (例：写真や動画) レプリケーション とフェイルオーバーのサポート。 クラウドレベルのスケーラビリティな 自動的なsharding 複雑な集約のための MapReduce 商用
第31回 RubyistのためのMongoDB入門（1） | gihyo.jp
はじめに ここ最近、NoSQLというキーワードが注目を集めています。 リレーショナルデータベースは、一般的にスケールアウト（サーバの台数を増やして性能向上を図る手法）が難しく、特に大規模サービスにおいてパフォーマンス上のボトルネックとなりえます。また、タグやグラフ構造のようなデータは関係モデルに馴染みにくいため、それらを扱う際にはアプリケーションコードもぎこちないものになりがちです。 これらの問題を背景に、何にでもリレーショナルデータベースを使うのではなく、用途に応じてKVSなど他のデータストアを選択する流れが広まりつつあります。このムーブメントがNoSQL（Not Only SQL）と呼ばれているものです。 今回は、NoSQLなデータベースの1つであるMongoDBをご紹介します。 MongoDBとは MongoDBは高いパフォーマンスとスケーラビリティを特徴とするドキュメント指向型デー
非リレーショナルデータベースを選ぶ（私達がMySQLからMongoDBへ移行した理由） | taro-nishinoの日記 | スラド
先日のYuval Kogman氏のエッセイ″Why I don't use CouchDB″の私家版和訳（私は略して私訳と呼んでいます）が私の周辺のCouchDBファンに冷や水を浴びせたようです。どうも誤解もあるようで、Yuval Kogman氏は頭からCouchDBを否定しているのではないのです。氏のような一流のPerler（いや、Perlerでなくても）は野心的である反面、非常に現実的です。ですから、現時点においてはCouchDBがかなりスピード面で劣るのであるから、それを補って余りある野心的な（現にロードマップに載せていますよね）フィーチャーを早く見せなさいと、氏は言っているのです。これは叱咤激励でもあると思います。 私はたまたまMongoDBを選びましたが、夢を持ちたい人はCouchDBを選べばいいし、もっと現実路線の人は他のNoSQLデータベースを選べばいいのです。 そんなことよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
