タグ

MongoDBに関するShoCohのブックマーク (12)

  • B TreeとB+ Treeの違い - Carpe Diem

    概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう?と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは1ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの

    B TreeとB+ Treeの違い - Carpe Diem
  • MongoDBと位置情報 ~地理空間インデックスの紹介

    Topological indices (t is) of the graphs to seek qsar models of proteins com...Jitendra Kumar Gupta

    MongoDBと位置情報 ~地理空間インデックスの紹介
  • 【CyberAgent】技術情報/TechReport - テックレポート/MongoDBの運用について | 株式会社サイバーエージェント

    ■はじめに 弊社でも、ピグライフをはじめとしてモバイルゲームなどのサービスでMongoDBを使い始めています。 運用に関してはMySQL等にはまだノウハウ的にはかなわないものの、NoSQLのジャンルの中では有用なプロダクトであるといえるかと思います。 ですが、運用に関しての共有ができておらず、有効な使い方ができていないパターンも多いです、そのため運用に関してノウハウを共有するための資料を作成しました。 ■概要/特徴 MongoDBには以下のような特徴がある ●      BSONによる、JSONによるスキーマレスなデータ運用 これにより、柔軟なデータ構造をわかりやすく表現できる。 加えてスキーマレスなため、データの構成を柔軟に帰ることが出来る ●      レプリカセットによる冗長化対応 MySQLでも、マスタを冗長化するためには、MySQLCluster、MHAなどのプロダクトがあ

  • CyberAgentにおけるMongoDB

    Akihiro KuwanoExperienced server engineer, Solution Architect of cloud computing at Amazon Web Services Japan

    CyberAgentにおけるMongoDB
  • 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

  • Mongo dbを知ろう

    5. mongoDBの背景 • 2009年よりMongoDB社(元10gen)が提供。 • 累計調達資金2億3100万ドル。 • mongoDBのダウンロード数は500万回に達する。 • mongoDB技術者の求人数はredisやCassandraを抜いて トップを君臨。 • キーワードの検索数はHTML5に次ぐ2番目に多い。 ※一部情報はTechCrunchから引用 © CROOZ,Inc 5 6. MongoDBの特徴 • ドキュメンド指向 – レコードではなく、JSONオブジェクトが格納される。 • スキーマフリー – 動的なスキーマ、リレーションの概念なし。 • Memory-Mapped File – メモリ上で動作する前提の設計で高いパフォーマンスを叩き出す。 • レプリケーション、シャーディング構成 – クラスタ構成により、自動的なフェイルオーバー、シャーディングを 実現。

    Mongo dbを知ろう
  • MongoDBの集計機能が便利過ぎて泣けてくるお話し - Y's note

    MongoDBイン・アクション 作者: Kyle Banker,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2012/12/14メディア: 大型購入: 5人 クリック: 55回この商品を含むブログ (4件) を見る MongoDB集計機能 CentOSでNginxのログをFluentdを使ってMongodbにリアルタイムで格納する - Yuta.Kikuchiの日記 時給3000円のCEOと揶揄されている@yutakikucです。今日は簡単にMongodbのログ集計機能を紹介します。機能が豊富過ぎて泣けてくるんで、ログ解析する人は是非使ってみて下さい。FluentdでMongodbNginxLogを流し込む設定は上のエントリーを参照して下さい。次回はAggregationFramework/MapReduce周りについて触れたいと思います。 泣ける話 : 集

    MongoDBの集計機能が便利過ぎて泣けてくるお話し - Y's note
  • 10gen: MongoDBのフォールトトレラントの正当性を主張

    Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

    10gen: MongoDBのフォールトトレラントの正当性を主張
  • MongoDBの信頼性に疑問

    原文(投稿日:2011/11/07)へのリンク 最近、MongoDB に関して非常に好ましくない内容のかなり話題になった市場報告が2つあった。批判の大部分は、パフォーマンス問題とデータ損失の組合せに集中している。この話を続ける前に、これらは公式の事例研究でないことを肝に命じて欲しい。そうではなくて、最近 MongoDBを使った開発チームによる市場報告である。 まず Urban Airshipの Michael Schurter氏のレポートから始める。 Urban Airshipは既に、MongoDBの問題を経験しており、このレポートを書く前にデータのほとんどを PostgreSQLに移行を済ませていた。残ったデータはMongoDBにとって理想的のようだ。 短命-もしそれを失っても、短い間サービス低下を経験するが、 壊滅的ではない 小さい-容易にメモリーに収まる(~15 GB) 二次索引-キ

    MongoDBの信頼性に疑問
  • MongoDB 2.4 の性能 徹底評価(レコード長による評価) - 中年engineerの独り言 - crumbjp

    前回のMongoDB 2.4 の性能 徹底評価の反響が大きかったので続編。 今回の調査対象 ドキュメントサイズ毎の性能を評価する。 今回の検証用にベンチを書いた。 性能見積りにも使えると思うので、紹介しておきます。 MongoDB-JP/mongo_bench 今回の検証も、Sakura VPS 2G で行った。 専用環境ではないので、ある程度まわりの影響を受けている。(何度もベンチを取って極力排除はしたが、、) また、記事に載せた以外にも色々と検証しており、その結果も少し混ざっていたり。。 オンメモリデータの処理が高速な事は解っているので 今回の検証の肝は『ディスクアクセス』 MongoDBはメモリ以上のデータを扱う為のプロダクトなのでなるべく性能が出ない様な条件=ワーストケースを狙った。 2GBメモリに対して40GBのデータを扱い、データ全体を万遍なく使うようなクエリーを発行する。 評

    MongoDB 2.4 の性能 徹底評価(レコード長による評価) - 中年engineerの独り言 - crumbjp
  • MongoDBの薄い本

    2.6対応版 MongoDBの薄い The Little MongoDB Book Karl Seguin 著 / 濱野 司 訳 i 目次 目次 i このについて iii ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 著者について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 最新バージョン . . . . . . . . . . . . . . . . . .

  • MongoDBが適さないケース - 中年engineerの独り言 - crumbjp

    > 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 (もちろん是非原文で読むのをお勧めする) 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、1ノード辺り数TBとあるのでSharding環境ではないかと思われる。

    MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
  • 1