VirtualboxでMongoDBを試していると、あるときディスク容量がほぼ100%になってしまった。ディスク全体は8.0GBで、そのうちルートは5.7GB。 調べたところ、/var/lib/mongodb/journal/ 以下のファイルのサイズが、2.0GBほどになっていた。 サイズを小さくする方法を探していたが見つからず、journalディレクトリ以下のファイルを削除して再起動することに。 具体的な手順は以下。 1. MongoDBを停止する $ sudo serivce mongo stop 2. journalディレクトリ以下のファイルを削除 $ sudo rm /var/lib/mongodb/journal/* 3. /etc/mongodb.confにsmallfilesを追加 $ sudo vi /etc/mongodb.conf … # Enable journali
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
Redisを利用したセッション管理について書こうと思っていましたが、MongoDBのjournal機能で生成されるファイルのサイズが大きすぎてサーバが正常に起動できない問題に遭遇したので、そのことを先に書こうと思います。 MongoDBはNoSQLなDBで最近話題です。node.jsとの相性も良いとのことでnodeとあわせて話題に出ることもしばしば。 そのMongoDBのv.1.8から追加された機能としてjournalがあります。 詳しくはわかってないのですが、MongoはリクエストがあるたびにDBに書きこみをしているわけではなくて、スタックに貯めておいてある間隔でDBに書きこむらしい。なので、スタックにあるデータがDBに書き込まれる前にクラッシュしても、journalを使うとそのスタックにあるデータを保管しておいて、次の起動時にリカバリできるっていうことらしいです。 次のページが詳しいで
「演算子のインジェクション」と「SSJI」：NoSQLを使うなら知っておきたいセキュリティの話（1）（1/2 ページ） ここ数年、大量データ処理時の高速性やデータ構造の柔軟性などから、「NoSQL」が注目を集めています。それと同時に、NoSQLを使うアプリケーションに対する攻撃手法も研究されるようになりました。この記事では、NoSQLを使ったアプリケーションの脆弱性と対策について解説します。 注目集める「NoSQL」 ここ数年、NoSQLと呼ばれる種類のデータベースが注目を集めています。NoSQLはSQL言語を使用しないデータベースの総称で、大量データ処理時の高速性やデータ構造の柔軟性などのメリットがあるため、従来のリレーショナルデータベース（RDB）を補完・代替するものとして、大規模なWebアプリケーションなどにおいてNoSQLを採用する事例が増えています。 このような新しい技術が普及し
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
MongoDB 2.4 released を和訳（＆少々所感）しました。 和訳 The MongoDB Engineering Team is pleased to announce the release of MongoDB 2.4. This is the latest stable release, following the September 2012 release of MongoDB 2.2. This release contains key new features along with performance improvements and bug fixes. We have outlined some of the key features below. For additional details about the release: 2.4 release
本記事は英語版ブログで2011年12月20日に公開された記事の翻訳版です。 Engine Yard のデータ チームからご挨拶申し上げます。今回は、当チームで前回のブログ(英語版)以来どのような努力をしてきたかをお知らせしたいと思います。 今年当チームが編成された当初、最初に与えられた仕事は MongoDB を使ってスタックの機能を拡張することでした。しかし、NoSQL データストアをスタックに追加するだけで、当社がサポートするリレーショナル データベースを更新しないのでは、かえってお客様に迷惑をかけることになると私たちは感じました。そのため MongoDB の開発を一時中断し、MySQL と PostgreSQL の両方を更新することにしたわけです。今日現在、MySQL 5.5 はベータ版が公開されており、PostgreSQL 9.1 のベータ版も近日中に公開されます。両方とも 2012
MongoDBを使っているので、自分でも組めなければと思い勉強中。オライリーでスケーリングMongoDBが電子書籍で売っていたので迷わず購入。 とりあえずはReplicaSetをせずに1台のSharding構成でいってみましょう。 まず、Shardingというのはなにか？というと データを複数サーバへ分割する データの分割はMongoDBがよしなにやってくれる 分割したデータは状況に応じて各Shardを移動する MongoDB利用者(アプリ)は複数サーバを意識しなくてよい ということです。 レプリケーションが同じデータのコピーを複数DBへ持つのに対して、Shardingは違うデータを複数DBへ持ちます。よって、普通の運用はSharding＋ReplicaSet(レプリケーション)の構成となります。 で、今回の構成は下のようにしました。これをAWSのマイクロインスタンス1台で組んでいます。新
開発者が知っておくべき、ドキュメント・データベースの基礎：特集：MongoDBで理解する「ドキュメント・データベース」の世界（前編）（1/3 ページ） ドキュメント・データベースの最大の特長は、「パフォーマンス、大量データ、スケーラブルといった課題を克服するためのシンプルなセットを提供している」という点だ。 もちろん既存の多くのリレーショナル・データベース（以下、RDB）でも、ドキュメント・データベースが備えている特徴的な各機能に類似することが実現可能だし、さらに広範な概念や機能性を提供している。例えばシャーディング（Sharding。詳細後述）についても、既存の多くのRDBでデータの分散化が可能だ。しかしドキュメント・データベースでは、「そもそもデータ構造がこうした構成に適している」という点と、「それに付随して、考え方もシンプルである」という点が優位な特徴である。 万人が、データベースが
前回、MongoDBでSNSつくるぞという記事を書いてから随分時間がたってしまいました。単に私がだらけていたということもあるのですが、一番ひっかかって時間を取られていたのが、MongoDBにおけるスキーマ設計の考え方です。 いまだに試行錯誤中ではありますが、現時点において私がこうあるべきと理解しているところをアウトプットしてみたいと思います。 １．One to Many のケース たとえば注文と注文明細のケースを考えてみます。RDBで1対多のリレーションを設計する場合、 というように、注文明細を別テーブルにするのが普通かと思います。しかし、ドキュメント指向のMongoDBにおいては、RDBと違ってオブジェクト内に柔軟なデータ構造を実現できるため、 というように一つのCollection内にデータを埋め込んでしまうのが、パフォーマンスの点からも良しとされています。 ただし、以下の2点について
node.js から MongoDB にアクセススためのライブラリに Mongoose があります．今回はこれを紹介しようと思います．O/R Mapper っぽく使えるように設計されており，既存の O/R Mapper を使ったことがある人にとっては，比較的わかりやすい仕様です． 見出し Mongoose とは？ インストール 何はともあれ使い方を Schema 定義について ドキュメント生成 (保存) ドキュメント読み取り ドキュメント更新 ドキュメント削除 Embedded Document 終わりに Mongoose とは？ node.js 向けに開発された MongoDB アクセスライブラリです． 公式：http://mongoosejs.com/ GitHub：https://github.com/learnboost/mongoose/ Mongoose is a MongoD
「第3回 MongoDB 勉強会 in Tokyo」 : ATND 先週土曜日（2011年5月14日）にフューチャーアーキテクトさんのセミナールームにて行われたMongoDBの勉強会に行ってきました。 MongoDBの仕様・機能などの体系的な話からチューニングの話、開発に利用する話、プロダクションとして運用している話と、バランスよくまとまっていてとても勉強になりました。 RDBとの違いや特有の挙動をきちんと把握して利用すれば、十分プロダクションで利用出来るというビジョンが見えました。 詳細は各発表者の方のスライドを見るとわかると思いますが、当日会場でメモしたものでダイジェスト的にまとめました。 MongoDB勉強会は毎月開催（予定）しているそうなので、興味を持たれた方は是非参加して見てください。 MongoDBコミュニティー：MongoDB JP | Google グループ 【発表1】Mo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
