Tokyo Otaku ModeではNode.jsからMongoDBにアクセスするのにODMとしてMongooseを採用しています。 Mongoose（ODM）を利用するメリットとしては、 collectionのSchema設計がコードに残る virtualなどデータ周りの機能がModelに集約できる populationが利用できる などが上げられます。 どれもサービスを効率的に作る上で助かる機能ばかりですが、とくにpopulationは別ドキュメントのreference（_id）を持っているだけで、自動的にドキュメントに展開してくれる強力な機能です。 一方で、DBロック回避の目的やある程度の規模になってDBを分割するようになると、別DBのcollectionをpopulateできないという問題がでてきます。 Mongooseの仕様上、特定DBへのconnectionとModel(col

MongoDBでReplica Setsを試した時のメモ 複数のDBプロセスをクラスタリングすることで、いざという時のマシンダウンに対応できる冗長性を確保する。フェイルオーバーとかってことです。 で、これが簡単でござった。mongoばんざい。nodeばんざい。JavaScriptばんざい。 マシンは、こないだのこれ http://qiita.com/items/4ea61f8ba0470ec3d5be を利用してみます。今回はルーターや仮想IP部分などは関係ないので図の下半分のオレンジ色のあたりだけ見てください。 レプリカマシンのリスト 当初3台の予定だったのだけれど、とりあえず先に下記2台のローカルLAN内PCで組みはじめることにする。あとで、1台追加します。 192.168.1.11 192.168.1.12 192.168.1.13(あとから追加) 各マシンへnpmとかインストール

MongoDBで特に重要なOSの設定は以下の３つ ulimitを大きくする readaheadを小さくする NUMAをきる ulimitを大きくする 理由はTCPコネクションの枯渇を回避するため。 MongoDBはレプリケーションやシャーディングを使って、構成するコンポーネント(mongod,mongos,config)の数が多くなると、利用するTCPコネクション数がどんどん増えていく。 シングル構成であればあまり気にする必要はないかもしれない。 readaheadを小さくする 理由は物理メモリを効率よく利用するため。 readaheadはファイルをmmapでメモリにマップするときのサイズだが、このサイズが大きいとクエリで利用するドキュメント以外のデータもメモリにマップされてしまうことが多く、物理メモリが効率よく使えないことが多い。 MongoDBのresで表される物理メモリ利用量が、搭載

こんにちは。Tokyo Otaku Mode CTOの関根です。 Tokyo Otaku Modeでは、2013年8月からotakumode.com上にカート機能を追加し、決済までをワンストップでできる海外向けECサイトをスタートしました。 どういうシステム構成でotakumode.comが運用されているかを聞かれた時、「Node.js + MongoDBです」と答えると、エンジニアの皆さんは一様にびっくりします。特に驚かれるのが、MongoDBをメインのDBに使用している点です。信頼性に定評があるわけでなく、またNoSQLに対するライトなイメージが一般的にあるため、ECサイトのプロダクションとして使うことに疑問を持たれている方が多いのでしょう。 しかし、十分実用に耐え、日々機能追加が入り成長し続けるスタートアップの環境で、実際に1年間運用してきたECサイトがここにあることも事実です。 そ

nginxのlog_formatを忘れないところにメモっておきたかったのでメモ。 nginx設定 nginx.confのhttpコンテキスト内にLTSV形式のログフォーマット定義を行う。$time_iso8601などの変数はnginx http_core_moduleのEmbedded Variablesを参照して適当に設定しています。 /etc/nginx/conf.d/log_format.confとして分離したファイルで設定して、nginx.conf内でconf.d/*.confを読み込むようにする。 log_format ltsv 'time:$time_iso8601\t' 'remote_addr:$remote_addr\t' 'request_method:$request_method\t' 'request_length:$request_length\t' 'requ

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

MongoDBを扱う上で避けては通れないmongo shell (mongo コマンド) 実はV8搭載の強力な実行環境です。 使い倒さなきゃ勿体無い！！！ MongoDBの小技を覚えておけばグンと使いやすくなりますよ。 １．各DBの負荷状況 運用では普通に使えます。 下記のloadで独自のユーティリティファイルを使いJSで解析してしまうと楽。 > use admin > db.runCommand({top:1}) { "totals" : { "note" : "all times in microseconds", "admin" : { "total" : { "time" : 7, "count" : 1 }, "readLock" : { "time" : 0, "count" : 0 }, "writeLock" : { "time" : 7, "count" : 1 }, "

勢いでtwiteしたついでに、軽く書いてみた。 MongoDBのfindAndModifyは物凄く便利で色々使い方があるのだが $setOnInsertと組み合わせると、お手軽セマフォになるので こんな感じで簡単にJOB管理に使える訳だ。 全ドキュメントを並列に処理する例 このスクリプトをmongo shell をいくつも立てて実行すれば、同一ドキュメントの重複処理を上手く回避して並列処理できるわけ。 foo 処理対照コレクション foo_job ジョブ管理用コレクション // そのドキュメントが処理中か否か判定する function isVacant(id){ var prev = db.foo_job.findAndModify({ query: {_id:id}, update:{ $setOnInsert:{ tm:ISODate()}}, upsert:true }); if (

Mogodb集計 MongoDBの集計機能が便利過ぎて泣けてくるお話し - Yuta.Kikuchiの日記 1月程前にMongoDBを使った集計機能の紹介をさせていただいた@yutakikucです。内容は全く大した事無かったのですが、タイトルで誘導を引っ張って200近いbookmarkを集める事ができました笑。みなさんの参考にしていただけたこと、大変嬉しく思います。今日はMongoDBの集計をもう一歩踏み込んだ内容を紹介して行きたいと思います。題材としてはAggregation FrameworkとMapReduceについてです。因に今回試してみたMongoDB-Versionは2.2.3です。Versionによって挙動が変わると思うので注意してください。 $ mongo --version MongoDB shell version: 2.2.3 Aggregation Framewor

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関数を独自に定義し、集計処理を

GridFSの概要 MongoDBに保存できるドキュメントのサイズは、16Mバイトまでという制限があります。一般的なテキストデータを保存するには十分なサイズですが、巨大なテキストデータや動画などのバイナリデータを保存する用途では、16Mバイトを超える場合が出てきます。MongoDBに16Mバイト以上のファイルを保存したい場合、GridFSというインターフェースを使用します。GridFSを使用することにより、データを複数に分割[1]して保存することが可能となります。 今回はMongoDBでサイズの大きなファイルを扱う仕組みである、GridFSについて説明します。 図1　GridFSの概要図 ファイルをデータベースで管理するメリット ところで、ファイルをデータベースで管理することでどのようなメリットがあるのでしょうか。 多くのシステムでは、画像／音声／動画などサイズの大きなバイナリファイルは、

MongoDB には、地理空間のインデックスが用意されていて、簡単に位置情報を操作することが出来ます。 今回は、つぶやきを HTML5 の Geolocation API から取得した位置情報とともに MongoDB に保存しておき、 現在地近くのつぶやきだけを検索して表示するという簡単なサンプルを作ってみます。 ありがたいことに、うえじゅんさんの作った Node.js + MongoDB のサンプルがあるのでこれをベースに作っていきましょう。 https://dev.classmethod.jp/server-side/node-socket-io-mongodb/ 位置情報を保存するフィールドを定義 つぶやきのモデルに位置情報の保存フィールドを定義します。 「message.coffee」 mongo = require 'mongoose' mongo.connect 'mongod