NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
moco(beta)'s backup: KVS性能比較 - memcached / Couchbase / MongoDB / Redis
手軽なKVSとして使えるNoSQL系データベースは沢山あるわけなのですが、単体サーバのset/getの性能に注目して性能比較を行いました。memcachedをベースラインとして、どの程度その性能に追いつくかを調べるのが主目的です。（揮発性のキャッシュでよければmemcached + Consistent Hashing 最強なのですが、永続化できるとうれしい場合があります。。。） [2014.03.21 追記] ベンチマーク系のエントリって、少ないもんだから適当に書いても検索上位にきてしまうらしい、こわい。反省している… [追記ここまで] 計測対象プロダクト memcached v1.4Couchbase v2.0 MongoDB v2.2 (*1)Redis v2.6(*1) MongoDB はRDB並にクエリが書けるくらい機能豊富で、本来こういう比較でもってくるのは不公平なのですが.
td-agent のメモリバッファとファイルバッファでどんな違いが発生するか観察してみた - ようへいの日々精進XP
はじめに 先日、DevOps 向け Fluentd 勉強会 at IPROS で聞いた話の中で Ouptput プラグインのバッファの関して下記の点について気になったので調べたくてウズウズ。 Output プラグインのメモリバッファとファイルバッファの性能はほとんど差異は無い デフォルトはメモリバッファだがファイルバッファがオススメ また、fluent-logger を使ってサーバーの負荷が激しく上がってしまった件について質問させて頂いたがよくよく考えるとこのバッファについて全く考慮しないままの利用だったので、この件でも解決への糸口になるのではということでメモリバッファとファイルバッファで何が違うのかを調べてみた。 構成 検証環境 以下のような検証環境を用意した。 役割 バッファタイプ / Output / アプリケーション OS td-agent バージョン スペック 備考 Forwar
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
MongoDBとMySQLでのスキーマデザインの違い | Yakst
MySQL Performance Blogの翻訳。MySQLのようなリレーショナルデータベースと、ドキュメント志向データベースMongoDBでのスキーマデザインの違いについて。 2013/08/01 by Stephane Combaudon リレーショナルデータベースに慣れている人がMongoDBのようなNoSQLのソリューションを使うのは、面白いチャレンジになるだろう。そのうちのひとつが、スキーマのデザインだ。リレーショナルな世界では、正規化がいいとっかかりだが、新しくMongoDBのアプリケーションを作るときには、データ保存についてどうデザインすべきだろうか？ 簡単な例を挙げて、MySQL(というかあらゆるリレーショナルデータベース)でデータ構造をどう作るか、そしてMongoDBではどうかを見てみよう。個人情報(名前)とその人のパスポートの詳細(国籍と有効期限)を保存したい、という
MongoDBにおける関連（Relation）のスキーマ設計 - masa_wの日記
前回、MongoDBでSNSつくるぞという記事を書いてから随分時間がたってしまいました。単に私がだらけていたということもあるのですが、一番ひっかかって時間を取られていたのが、MongoDBにおけるスキーマ設計の考え方です。 いまだに試行錯誤中ではありますが、現時点において私がこうあるべきと理解しているところをアウトプットしてみたいと思います。 １．One to Many のケース たとえば注文と注文明細のケースを考えてみます。RDBで1対多のリレーションを設計する場合、 というように、注文明細を別テーブルにするのが普通かと思います。しかし、ドキュメント指向のMongoDBにおいては、RDBと違ってオブジェクト内に柔軟なデータ構造を実現できるため、 というように一つのCollection内にデータを埋め込んでしまうのが、パフォーマンスの点からも良しとされています。 ただし、以下の2点について
MongoDBと位置情報 ～地理空間インデックスの紹介
The document demonstrates various geospatial queries in MongoDB including indexing locations, saving a document with a location, and queries to find documents within a distance, box, or circle of a point. It shows how to find the nearest document to a point, limit the maximum distance, and use spherical geometry for more accurate distance calculations over large areas.Read less
RethinkDBをちょっと触ってみた感想 | Ore no homepage
なんか負荷試験やってて疲れた。その合間にRethinkDBを触ってみた。いわゆる「やってみた」系のゆるい記事。 そうそう、snapchatちょっと面白くなってきたw オッサン同士でクソくだらない10秒動画とか送って遊んでるw RethinkDB http://www.rethinkdb.com/ つい最近登場したわけではなく、どうやら2009年〜2010年当たりに生まれたようだ。 感想など 画像が多くなってしまったので、先に結論というか感想を書く。 データの操作感はMongoDBっぽい。データもまんまjsonだし。 管理WebUIがイケメン。データ操作、クエリのプロファイル、クラスタ管理、モニタリングなどいろいろできる。 どこで使おうかな、まずは簡単なツール用のデータストアとかにはいいんじゃない？ 公式ドキュメントは割と充実している。こういうときに使ったらいいよって説明もある↓ http:
PHP環境で発生するMongoDB Request Injection攻撃
はじめに SaaS型WAF「Scutum（スキュータム）」では、最近バックエンドのDBにMongoDBの導入を進めています。私も個人的にPHPのフレームワークであるCakePHP向けにMongoDBを扱うプラグインCakePHP-MongoDB Datasourceを開発し、公開しています。 https://github.com/ichikaway/cakephp-mongodb/ 今回は、PHPからMongoDBを扱う際の注意点として、RequestInjection攻撃に関して書きたいと思います。この問題は、phpマニュアルのMongoドライバーの章でも扱われています。 この記事では、はじめにPHPでMongoを操作する方法、PHPの基本を書き、最後にInjection攻撃の仕組みと対応方法を書きます。 PHPでMongoDBを扱うには PHPでMongoDBを操作する場合、10gen
第10回 MongoDBでの集計処理 | gihyo.jp
MongoDBでの集計処理の概要 一般的なNoSQLプロダクトは、RDBのSQLでいうGroup By句やSum関数などの集計機能がありません。集計を実施するには、アプリケーション側で独自にコードを書くことになります。 しかし、MongoDBは、NoSQLのパフォーマンスを維持しながら、RDBライクな機能を実装することを開発方針として掲げており、集計機能に関してもいち早く実装してきました。MongoDBで集計処理を行う方法は3つあります。 1. Aggregationフレームワーク SQLでいうGroup By句やSum関数を提供します。Mongo Shellからクエリと同じように実施できます。一部の処理（$groupと$sort）はシャーディングに対応しており、各シャードで処理します。 2. MongoDBのMap/Reduce機能 Map関数/Reduce関数を独自に定義し、集計処理を
MongoDBのCapped CollectionとTailable Cursorを使ったRealTimeAccess集計 - Y's note
Index RealTimeAccess集計 Capped Collection Tailable Cursor まとめ RealTimeAccess集計 RealTimeAccess集計をするためにMongoDBの利用を考えます。サーバーの構成は上図のようなイメージで各種ApplicationServerからFluentdでLogAggregatorにRealTimeでLogデータを転送し、LogAggregator MasterがMongoDBにFluentdで書き込んで行きます。ここで言うRealTimeAccess集計の機能要件を整理すると以下のようになります。 Access発生後、1分以内で集計結果をWebツール上で確認したい。集計区間も1分単位など。 複数条件が指定可能で、柔軟なCross集計がしたい。 RealTimeAccess集計のSystem負荷を出来る限り抑えたい。
PythonでWebアプリ開発入門のススメ Flask/MongoDB - mizchi log
TwitBlogin! http://twitblogin.com/ とか作ったことだし、そこそこ開発環境整って、今なら思いつく限りのサービスはさっくり実装できそうだったのでPython初心者向けに書いておく。 少しでもPythonユーザが増えれば幸い。 対象は Python の基本的な構文程度はわかるけど、具体的に何から手をつけていいかわからない人 目次 Apache/WSGI/MongoDBの環境構築 flask [ Sinatra風ウェブアプリケーションフレームワーク] pymongo [ MongoDBラッパー ] werkzeug [Web Application デバッガ] jinja2 [ HTMLテンプレートビルダー ] pyquery [ jQuery風HTMLパーサ ] nose [ TDD ] 細かいライブラリの使い方とかPython本体の言語仕様とかは適当にぐぐって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TokutekがMongoDB用の新コンセンサスアルゴリズムを発表
Can't get mongo.so extension to load after updating PHP to 5.3
PHPの高速フレームワーク FuelPHP を試してみました。入門版サンプルと、MongoDBの設定方法まとめ
MongoDB Developer Center