uu59のメモ | MongoDBでもSQLインジェクションできる
タイトルはわかりやすさ重視でつけたのでそれSQLじゃないよというのは承知の上です。 Attacking NoSQL and Node.js: Server-Side JavaScript Injection (SSJS) SSJS whitepaper(PDF) JSONをevalで作るようなのは論外として、NoSQL Injectionって項目が面白かったのでメモ。 まずMongoDBにはfind()っていうのがあるんですが、一般的にはdb.find({x: 42})のようにオブジェクトを渡してxプロパティが42のレコードを取得する、といった用途に使います。が、db.find("this.x == 42")のように文字列を渡しても同じ結果が返ってきます。これはMongoが受け取った文字列をevalしてるせいです。試しにmongoコンソールでdb.find("while(1){};retu
foursquareの11時間にも及ぶサービスダウンの原因を詳細に調査してみた。<a href="http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/doryokujin/20101014/1287000278" class="bookmark-count"><img src="http://b.hatena.ne.jp/entry/image/http://d.hatena.ne.jp/doryokujin/20101014/1287000278" tit
こんにちは、@doryokujinです。前回に引き続き、MongoDBに関するエントリーです。今回は10月4日にMongoDBが原因で起きた、foursquareのサービスダウンに関して、その原因や復旧に至る経緯を詳細に調査しました。TechCrunchJapanの記事、Foursquare：「対策を講じたはずなのですが、また6時間もダウンしてしまいました」にも紹介されていたのでご存知の方も多いと思います。MongoDBが原因で引き起こったとするならば、企業で実際に運用している僕にとっては放っておけない問題になります。実は5月にも長いサービスダウンがあったのですが、それはAmazonEC2の停電によるものでした。 本日のアジェンダです： foursquareにおけるMongoDB サービスダウン時の状況 本当にMongoDB自体の問題だったのだろうか サービスダウンの引き金となった出来事
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
Akka Scala Days 2010
Akka Scala Days 2010 - Presentation Transcript Akka: Simpler Concurrency, Scalability & Fault-tolerance through Actors Jonas Bonér Viktor Klang Tuesday, April 20, 2010 We believe that... • Writing correct concurrent applications is too hard • Scaling out applications is too hard • Writing highly fault-tolerant applications is too hard Tuesday, April 20, 2010 It doesn’t have to be like this We need
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
ヽ( ・∀・)ノくまくまー(2009-07-04)
千聖は明日菜を叱っていた。いつもの下らない姉妹喧嘩ではない。 CouchDBを用いた2009新人公演4月におけるあっすーの干され問題の検証 http://wota.jp/ac/?date=20090415 を見て気付いたのだ。妹の出番が年々減少している事を。
MongoDB : C++ で書かれた高速なドキュメント指向DB - ヽ( ・∀・)ノくまくまー(2009-07-02)
require 'rubygems' ###################################################################### ### ActiveRecord (PostgreSQL) require 'active_record' ActiveRecord::Base.establish_connection(:adapter=>"postgresql", :database=>"jpop", :user=>"maiha") module PG class Song < ActiveRecord::Base # Indexes: "index_songs_singer" btree (singer) end end # p PG::Song.count # => 64482 ##############################
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Riak at shareaholic
alphaWorks Services
Don't use MongoDB
Zarkov is an event logger
Blog Archives
GitHub - eliast/mongo-erlang-driver: erlang driver for mongodb
mongodb's mongo-appengine-connector at master - GitHub
PyMongo and mod_wsgi - MongoDB - 10gen Confluence
namlook / MongoKit / overview — bitbucket.org
Resources | MongoDB