Kubernetesを用いたMongoDBクラスタの構築と運用 - OPTiM TECH BLOG
はじめまして。プラットフォーム事業本部の栗原です。 業務では、主にCloud IoT OS チームにてSRE活動を行っています。 今回は、Cloud IoT OS(以下CIOSと記載します)で利用しているMongoDBクラスタの構築と運用についてお話をします。 構築に至った経緯 自前運用を行うにあたり考慮すべき点 構成について ReplicaSet シャーディング configサーバー mongosサーバー(と Load Blancer) 読み書きの流れについて 構築について 物理構成の検討 物理構成 スケールアウト 運用 監視 バックアップ さいごに 構築に至った経緯 もともとは Azure CosmosDB の MongoDB APIを用いていたのですが、 CosmosDBの一部仕様がCIOSでのユースケースと合っていないという課題がありました。 いくつか存在したのですが、大きくは以下
【CyberAgent】技術情報／TechReport - テックレポート／MongoDBの運用について | 株式会社サイバーエージェント
■はじめに 弊社でも、ピグライフをはじめとしてモバイルゲームなどのサービスでMongoDBを使い始めています。 運用に関してはMySQL等にはまだノウハウ的にはかなわないものの、NoSQLのジャンルの中では有用なプロダクトであるといえるかと思います。 ですが、運用に関しての共有ができておらず、有効な使い方ができていないパターンも多いです、そのため運用に関してノウハウを共有するための資料を作成しました。 ■概要／特徴 MongoDBには以下のような特徴がある ● BSONによる、JSONによるスキーマレスなデータ運用 これにより、柔軟なデータ構造をわかりやすく表現できる。 加えてスキーマレスなため、データの構成を柔軟に帰ることが出来る ● レプリカセットによる冗長化対応 MySQLでも、マスタを冗長化するためには、MySQLCluster、MHAなどのプロダクトがあ
Fluentd | Open Source Data Collector
Fluentd is an open source data collector for unified logging layer. Fluentd allows you to unify data collection and consumption for a better use and understanding of data.
MongoDBをNUMAなマシンで使うときの注意 - 酒日記 はてな支店
デュアルCPUで計12コア24スレッド、メモリ48GBというマシンで MongoDB-2.0.8 をしばらく稼働させたところ、突然 CPU の system time が1コア分暴走したようになる、という現象が起きました。 最初は原因がよく分からず、とりあえず mongod のプロセスを kill して起動し直したら復旧したのですが、またしばらくすると同じ現象に。 mongoのメモリ使用量と Load Average をプロットしてみると、どうもある程度 (約24GB?) のメモリを使ったところで暴走が起きているような……とログを見直してみると、起動時に WARNING がでていました。 Sun Jan 20 00:10:01 [initandlisten] MongoDB starting : pid=12669 port=27017 dbpath=/var/lib/mongo 64-b
第4回 Node.jsアプリケーションとMongoDBの連携 | gihyo.jp
はじめに 前回から、いよいよNode.jsを使ったWebアプリケーションを作成しはじめました。前回はデータを保存および読み出す処理がなかったので、今回はデータベースとの連携を実装したいと思います。使うのはMongoDBです。リレーショナルデータベースに対して、MongoDBはドキュメント指向データベースという位置づけです。JSON構造をそのまま保存できるため、Node.jsとの親和性も高いです。簡単に導入でき、日本語ドキュメントもあるので、初めてでもすんなり使えると思います。 MongoDBのセットアップ MongoDBのサイトから、OSごとに用意されたアーカイブをダウンロードして展開してください。展開したフォルダの直下にあるbinディレクトリ内にコマンド群があるため、これらを使って操作します。サーバデーモンとなるのがmongodで、クライアントとなるのがmongoになります。 まず適当に
Twitter Streaming APIをMongoDBに保存して遊んでみる
TwitterのストリーミングAPIを利用する場合、かなりのデータ量が流れてくるので、リアルタイムに解析・集計などを行うと処理が追いつかない可能性が出てきます。 そこで、流れてきたデータをいったんどこかに保存しておいて後からバッチ処理で解析をしていく事になると思います。今回はその保存先にMongoDBをチョイスします。 なぜMongoDBなのか# RDBMSに比べて高速 BSON形式で保存するので、JSONの階層構造をそのまま維持して保存可能 NoSQLながらGROUP BYライクな集計処理が可能 ということで、試しにストリーミングAPIのsampleから流れてくるデータをMongoDBに保存するスクリプトを書いてみました。このスクリプトを動かすには、別途MongoDB本体と「json」「bson_ext」「mongo」の3つのgemが必要になります。 # coding: utf-8 #
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FoursquareのMongoDBが機能停止
8maki.jp
http://www.mongodb.jp/