45歳以上はMongoDBを使ったシステムが使えなくなる件 - Qiita
MongoDBを使うシステムが、最近多いと思います。 2.6系(安定版)の最新2.6.7ですが、Date型のインポート処理にバグがありそうです。 「1970/01/01」以前の Date型 を mongoexport すると、負の "$numberLong" として出力されるのですが、それを mongoimport すると、それ以降のフィールドが欠落してしまうのです。 例えば、ユーザマスタに「誕生日」フィールドがあると、45歳以上の人は「1970/01/01」以前の値が入っているわけで、マスタデータを移行したりでもすると、その人のフィールドがガッツリ無くなってしまいます。でも若手は大丈夫だから「どうせ部長の使い方がおかしいんでしょwww」といういつもの「偉い人に限って障害が発生する」パターンが展開されます。 大急ぎで調べた所、以下が判明しました。 2.6形式 "1965-11-17T00:
CappedCollectionのススメ - Qiita
Gunosyではログ解析周りや推薦エンジンでMongoDBを使っています。 ちょっと前に勉強会でMongoDBのMapReduceでログ解析やってるよって話をしたところ、 MongoDBのMapReduceって遅くない？ データ量増えるとリソース相当使わない？ とのツッコミを頂きました。 指摘自体は正しいと思っていて、データ増えるとすぐ計算時間やサーバのリソース使用量が大変なことになります。 それを避けつつ、節約して運用するためにGunosyのログ解析周りではCapped Collectionを使ってます。 Capped Collectionって？ ご存知の方も多いと思いますが、念のため本家から引用すると、 Capped collections are fixed-size collections that support high-throughput operations that i
Robo 3T | Free, open-source MongoDB GUI (formerly Robomongo)
3T is halting development work on Robo 3T and we are setting the code repository to read-only. Users can continue to download the application but we recommend that they download Studio 3T Free to evaluate it. Robo 3T is deeply based on the Mongo shell client. This older client has been deprecated in MongoDB 5.0 and is not expected to be maintained in the future. The new Mongosh client is a Node-ba
MongoDB製JOB Queue - 中年engineerの独り言 - crumbjp
お盆が暇だったので MongoDB製Job queue を作った。 名前はMONMOちゃん。 javascriptで手軽に使いたい部分があって個人用で考えていたが 結構マトモなモノが出来上がったので公開する事にする。 またMONMOちゃんを使って、自然言語処理も一式書いてみたが こちらは次回紹介する。 注意 Javascript製ではない。 MongoDB製だ！ 繰り返し言おう。 MongoDBは環境である！！ About Monmoちゃん github https://github.com/monmo/monmo 概要 全ての処理はMongoDB(mongod) 及び Mongo shell(mongo)上で動作する。 JobはJavascriptで記述する。 MongoDBへJob投入（制御データと実装）すると、予めどこかで起動したWorkerが処理する。 Job投入側にはスクリプトを
MongoDBの地理空間のインデックスを試してみる - 今日も適当ダイアリー
MongoDB面白いですね。 ドキュメントが親切なのでありがたいのですが、なかなか日本語の記事が無かったりするので、Geospatial Indexingについて試してみた事を投稿しますよ！ マニュアル：MongoDB internal corp site Geospatial Indexing は MongoDB ver1.3.3以上で使えます。 地理空間のインデックスとは 読んで字のごとくなのですが、MongoDBでは二次元地理空間情報（多くの場合、緯度経度情報）をインデックスとして検索をかけることが出来ます。 最近のガラケーやスマートフォンからは簡単にGPS機能を利用することもできますし、PCブラウザなどでも位置情報を取得出来るようになったり、html5のGeolocation API（厳密にはHTML5に含まれてはいない）の登場などで、今後、ますます位置情報の利用頻度は高くなるんじ
MongoDBのShardingを試してみた。その１ - matsuou1の日記
MongoDB勉強会で発表を聞いてきたので、早速Shardingの機能を試してみます。 環境構成 まずは、以下の構成をします。 本当は複数台のサーバを使用したいのですが、手元に自由に扱えるサーバがさくらVPSしかないため 1台に複数のmongodを立て、mongosとconfigも同居させています。 mongodbのバージョンは、1.8.0を使用しています。 shardサーバ起動 mongodをポート別に3つ起動します。 [matsuou1@testsvr mongodb]$ ./bin/mongod --shardsvr --port 10001 --dbpath /tmp/mongodb/shard1 --logpath /tmp/mongodb/log/shard1.log & [1] 14269 [matsuou1@testsvr mongodb]$ ./bin/mongod --
MongoDBのShardingを試してみた。その２ Migration中の挙動について - matsuou1の日記
Sharding環境にて、shard keyを使用しない以下のクエリに問題があることが知られている。 （第２回MongoDB勉強会の@doryokujinさんの発表参照。私の参加日記は ここ から） Chunk Migration中のcount 同時書き込み発生時のsingle-update() 同時書き込み発生時のunique index tmp_collectionが削除されないmapreduce 今回は、Sharding環境にて、chunkのMigration中の各クエリの挙動について検証します。 同時書き込みの発生再現は、難しいので今回は割愛します。 この検証では、mongodb 1.8.0を使用しています。 構成については、 MongoDBのShardingを試してみた。その１ を参照 Chunk Migration中のcount 現象 正しい値より大きい値が出力される可能性があ
Build Your First Project with Mule Studio - Mule iON - mulesoft.org
Skip to left navigation Skip to main content Skip to page navigation
nginxのGridFSブリッヂ
ここ数日サイトが非常に重たい状態となっておりご迷惑をおかけしております。エラーレポートが（メールで）送られてくるので問題は把握していたのですが、解決までに時間がかかってしまっています。 アプリケーション的、システム構成的、両面からのアプローチを検討し、2つの対策を行いました。 アプリケーションの見直し システム構成変更による改善 アプリケーションの見直しは、モバイル対応を行った際に変更した部分が関係すると考え、その点を中心に見直しを行いました。いくつか問題点があったため変更を行いリリースしています。 もう一点、システム構成を変更して、保存された写真の提供方法を改善しました。 写真の提供方式について少し掘り下げて解説したいと思います。 旧方式ではnginxからFastCGIによりdjangoへ接続し、そこからMongoDB GridFSのファイルを取得していました。pythonで処理が行える
バックエンド
MyBike.JPのバックエンドはLinux, nginx, PostgreSQL, Pythonという、いわゆるLAMPスタックに似たものになっています（ApacheとMySQLがないのでAとPがありません）。 画像の保存先はファイルシステムを採用していますが、ベータ版公開時にはよりスケーラブルで障害に強い他の仕組みへ切り替える予定です。現在候補に上がっているのはAmazon AWS Simple Storage Service (Amazon S3)とMongoDB GridFSです。 どちらのシステムもスケーリングが容易で、アプリケーションからは単一のアクセス先を指定するだけなので対応が簡単なことが理由です。 プロトタイピングはすでに済ませており、近いうちにGridFSを採用することになりそうです。これはコスト的な問題です。 これ以外のシステムではMogileFSが候補に上がりました
GridFS - Docs-Japanese - 10gen Confluence
based on v13 (2010-10-02追従) - オリジナル GridFS は、MongoDBに巨大なファイルを格納するための仕様です。 公式にサポートされているすべてのドライバで GridFS仕様 が実装されています。 原理 MongoDBは、バイナリデータの格納を BSON でサポートしています。 しかし、 MondoDBで、BSONオブジェクトは4MBのサイズに制限されています。このGridFSの仕様は、大きいファイルを複数のドキュメントに透過的に分割する方法を提供します。これは、巨大なファイルを効率的に格納したり、ビデオなどの巨大なファイルを様々な方法で(例えばファイルの最初のNバイトを取得とか)効率的に扱うことができます。 実装 これを実現するために、ファイルを分割する方法が標準化されています。それぞれのファイルは、"files"コレクションの中にメタデータオブジェク
GridFSを試す - スコトプリゴニエフスク通信
GridFSはMongoDBをファイルシステムのように使う機能。MongoDB supports the storage of large (file size) objects via a specification called GridFS.http://www.mongodb.org/display/DOCS/Storing+FilesまずはPythonクライアントで試してみる。 # -*- coding: utf-8 -*- from pymongo.connection import Connection import gridfs conn = Connection() fs = gridfs.GridFS(conn.gridfs_test_db) fp = fs.open("test.txt", "w") fp.write("Hello, GridFS") fp.close
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
(PDF) MongoDB に対する探索行為の増加について - 警察庁 (平成27年2月20日)
MongoDB: The Developer Data Platform
alphaWorks Services
Mongo DBを半年運用してみた
MongoDB Transport for Mule ESB
MongoHub - MongoDB GUI administration tool for mac by Prof.Syd.Xu