Your SlideShare is downloading. ×
20120831 mongoid
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

20120831 mongoid

1,268
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,268
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Mongoidを語ってみよう 2012/08/31 @akimatter13年1月24日木曜日
  • 2. 自己紹介 秋間武志 RBCスタッフ 仕事でmongoidを使って約2年 株式会社グルーヴノーツ @akimatter https://github.com/akm http://d.hatena.ne.jp/akm/13年1月24日木曜日
  • 3. アジェンダ NoSQLのおさらい MongoDBの概要 Mongoidの概要 Mongoid3の変更点 MongoDB 2.2の新機能 Mongoidでのモデリング13年1月24日木曜日
  • 4. NoSQLのおさらい13年1月24日木曜日
  • 5. NoSQLとは NoSQLとは、リレーショナルデータベース管理シ ステム(RDBMS)以外のデータベース管理システム を指し、リレーショナルデータベースの長い歴史 を打破するものとして、広い意味での関係モデル 以外に属するデータベースの発展を促進させよう とする運動である。 http://ja.wikipedia.org/wiki/NoSQL より13年1月24日木曜日
  • 6. 実装 産業界での有名な実装 GoogleのBigTable アマゾンのAmazon DynamoDB オープンソースの実装 MongoDB Apache HBase Apache Cassandra13年1月24日木曜日
  • 7. 分散データベース いくつかのNoSQLシステムは分散アーキテクチャ を採用している13年1月24日木曜日
  • 8. CAP定理 ブリュワーの定理とも呼ばれ、分散コンピュータ システムのマシン間の情報複製に関する定理。 ウェブサービスを想定して作られた定理。同時に 以下の3つを満たすことはできないというもの。 一貫性 (Consistency) 可用性 (Availability) 分断耐性 (Partition-tolerance)13年1月24日木曜日
  • 9. 13年1月24日木曜日
  • 10. 13年1月24日木曜日
  • 11. Eventually Consistency システム内に、一時的にConsistentでない状態が生 まれても、ある期間の後には、Consistentな状態 になるような性質を、Eventually Consistencyとい う。13年1月24日木曜日
  • 12. Eventually Consistency この言葉が定義されたことで「Scalableで Availableで、かつ、Eventually Consistentなシステ ムは可能である。」と言うことが可能になった。 実際、mongoidにも、consistencyの選択肢 に:eventual と :strongがある13年1月24日木曜日
  • 13. BASE CAPの全部を満たさなくてもシステムとして十分 Basically Available Soft-state Eventually consistent http://qcontokyo.com/tokyo-2009/pdf/ GeneralSession-Day2-Maruyama.pdf13年1月24日木曜日
  • 14. MongoDBの概要13年1月24日木曜日
  • 15. 特徴 「MongoDB はドキュメント志向のDBMSです。 MySQLですがJSON型オブ ジェクトを伴い、RDBMS表ではなく、データモデルで構成されます。大切 なことは、MongoDBは、結合やトランザクションをサポートしないという ことです。しかし二次的インデックスで、クエリ言語表示、アトミックがド キュメントレベルで書き込みを行い一貫した読み込みをするのを特徴としま す。 操作上、MongoDBは、自動範囲ベース自動フェイルオーバーと水平スケー リングを内蔵する、マスタースレーブ・レプリケーションを特徴としま す。」 http://jp.docs.mongodb.org/manual/faq/fundamentals/#what-kind-of-database-is- mongodb13年1月24日木曜日
  • 16. 例えばこんな構成も13年1月24日木曜日
  • 17. 分散アーキテクチャ レプリケーション マスター/スレイブ レプリカセット シャーディング13年1月24日木曜日
  • 18. JOINなし 「Mongoでは、リレーショナルデータベースのデ ザインでするような"正規化"はそれほど必要ありま せん。サーバサイドでの"join"がないからです。」 http://www.mongodb.org/pages/viewpage.action? pageId=720915613年1月24日木曜日
  • 19. 埋め込みドキュメント ドキュメントに複数のドキュメントを埋め込むこ とができる db.employees.insert({_id:   ObjectId("4d85c7039ab0fd70a117d734"),   name:  Ghanima,  family:  {mother:   Chani,  father:  Paul,  brother:   ObjectId("4d85c7039ab0fd70a117d730")}}) http://www.mongodb.org/pages/viewpage.action?pageId=1890728613年1月24日木曜日
  • 20. 組み込み vs 参照 http://www.mongodb.org/pages/viewpage.action?pageId=720915613年1月24日木曜日
  • 21. トランザクションなし 「MongoDBは ACIDトランザクションを提供しま せん。」 http://jp.docs.mongodb.org/manual/faq/ fundamentals/#does-mongodb-support- transactions13年1月24日木曜日
  • 22. アトミックな操作 「MongoDBは、一つのドキュメント でのアト ミックな操作をサポートしています」 http://www.mongodb.org/pages/viewpage.action? pageId=720957313年1月24日木曜日
  • 23. トランザクション 「トランザクションが満たすべき技術的要件に ACID特性がある」 http://ja.wikipedia.org/wiki/トランザクション13年1月24日木曜日
  • 24. ACIDについて比較 RDB MongoDB 原子性 atomicity ○ △ 一貫性 consistency ○ ○ 独立性 isolation ○ ○ 永続性 durability ○ ○ http://ja.wikipedia.org/wiki/ACID_(コンピュータ科学)13年1月24日木曜日
  • 25. consistencyという言葉 「一貫性のあるサービスでは、操作は完了するか、一切何もしないかの、ど ちらかだ。 ギルバートとリンチは、一貫性ではなく原子性(atomic)という 語を証明の中で使っている。 理論的な文脈では原子性という方が要領を得 ている。 というのも細かい話をすると、一貫性(Consistent) は データ ベーストランザクションの望ましい性質をあらわす ACID の C に使われて おり、 これはあるデータが事前に与えられた制約を破った状態で残らない ことを意味している。 ところが CAP の C を分散システムでの事前の制約 とみなし、 同じデータをあらわす複数の値を許さないことにすると、抽象 化が漏れて紛らわしいことになる。 (それに、もしブリュワーが原子性 (atomic)という語を使っていたら AAP 定理になる。 こんなのを発音しよ うとしたら皆が病人みたいになってしまう。)」 http://www.hyuki.com/yukiwiki/wiki.cgi?BrewersCapTheorem13年1月24日木曜日
  • 26. Mongoidの概要13年1月24日木曜日
  • 27. ODM for MongoDB Mongoid (pronounced mann-goyd) is an Object- Document-Mapper (ODM) for MongoDB written in Ruby. It was conceived in August, 2009 during a whiskey-induced evening at the infamous Oasis in Florida, USA by Durran Jordan. http://mongoid.org/en/mongoid/index.html13年1月24日木曜日
  • 28. Mongoidの哲学 The philosophy of Mongoid is to provide a familiar API to Ruby developers who have been using Active Record or Data Mapper, while leveraging the power of MongoDBs schemaless and performant document-based design, dynamic queries, and atomic modifier operations. MongoIdの哲学は、MongoDBのスキーマレスとパフォー マンスのドキュメントベースの設計、動的なクエリ、お よびアトミックな更新操作のパワーを活用しながら、 ActiveRecordやDataMapperを使用しているRubyの開発 者におなじみのAPIを提供することです。13年1月24日木曜日
  • 29. Documents Fields Array BigDecimal Boolean Date class Person DateTime include Mongoid::Document Float field :first_name, type: String Hash field :middle_name, type: String Integer field :last_name, type: String Moped::BSON::ObjectId end Range Regexp String Symbol Time TimeWithZone13年1月24日木曜日
  • 30. Persistence Standard Model.create, Model.create!, Model#save, Model#save!, Model#update_attributes, Model#update_attributes!, Model#update_attribute, Model#upsert, Model#touch, Model#delete, Model#destroy, Model.delete_all, Model.destroy_all この辺はActiveRecordと同じ感じ13年1月24日木曜日
  • 31. Persistence Atomic Model#add_to_set, Model#bit, Model#inc, Model#pop, Model#pull, Model#pull_all, Model#push, Model#push_all, Model#rename, Model#set, Model#unset コールバックもバリデーションも呼ばれないから 要注意13年1月24日木曜日
  • 32. relations Mongoid Mongoid ActiveRecord Reference Embed belongs_to belongs_to embedded_in has_many has_many embeds_many has_one has_one embeds_one has_and_belongs_ has_and_belongs_ N/A to_many to_many13年1月24日木曜日
  • 33. IDの振り方 ActiveRecordでは、RDBサーバのautoincrementの カラムをidとして使用する。 MongoDBでは主キーとなる_idの値はクライアン トで生成する必要がある。 Mongoidではドライバ のmopedが行う。この値はUUIDを用いる。衝突す る可能性はxxxくらい。13年1月24日木曜日
  • 34. Mongoid3の変更点13年1月24日木曜日
  • 35. 構造13年1月24日木曜日
  • 36. origin One of MongoDBs greatest features is its ability to execute dynamic queries, which Origin abstracts in a familiar Arel-style DSL that Mongoid includes.13年1月24日木曜日
  • 37. moped Goal of this gem Thread-safe No more extension (bson_ext) Cleanest API Better ReplicaSet management13年1月24日木曜日
  • 38. moped limitation Limitation Ruby 1.9 only No GridFS support The only case where moped is slower than bson_ext is the ObjectId generation13年1月24日木曜日
  • 39. MongoDB2.213年1月24日木曜日
  • 40. New Features Aggregation Framework TTL Collections Concurrency Improvements Improved Data Center Awareness with Tag Aware Sharding Fully Supported Read Preference Semantics http://docs.mongodb.org/manual/release-notes/13年1月24日木曜日
  • 41. Mongoidでのモデリング13年1月24日木曜日
  • 42. Tengineの例 TengineはGroovenautsが開発している分散環境 におけるイベントハンドリングおよびジョブの 実行制御のためのフレームワーク https://github.com/tengine/tengine13年1月24日木曜日
  • 43. 分散処理でのカウント13年1月24日木曜日
  • 44. 分散処理でのカウント13年1月24日木曜日
  • 45. 分散処理でのカウント13年1月24日木曜日
  • 46. 公式ドキュメントの例 http://mongoid.org/en/mongoid/docs/ relations.html13年1月24日木曜日
  • 47. モデリングのポイント ◦ リレーショナルモデリングは利用可能なデータ構造駆動 だ。この設計をするにあたって重要なテーマは"自分は どの答えを持っているか?" ◦ NoSQLデータモデリングはアプリケーション特有のアク セスパターン、すなわち、サポートされるクエリの型駆 動だ。メインテーマは"自分は何を知りたいのか?" https://gist.github.com/239623413年1月24日木曜日
  • 48. 組み込み vs 参照 再び http://www.mongodb.org/pages/viewpage.action?pageId=720915613年1月24日木曜日
  • 49. 関連テーブルとか13年1月24日木曜日
  • 50. 関連テーブルとか13年1月24日木曜日
  • 51. 参考文献 12年後のCAP定理: "法則"はどのように変わったか http://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules- have-changed MongoDBドキュメント http://www.mongodb.org/display/DOCSJP/Home Cloudの技術的特徴について 丸山先生 http://qcontokyo.com/tokyo-2009/pdf/GeneralSession-Day2- Maruyama.pdf13年1月24日木曜日
  • 52. 参考文献 NoSQLデータモデリング技法 https://gist.github.com/2396234 ブリュワーの CAP 定理 http://www.hyuki.com/yukiwiki/wiki.cgi?BrewersCapTheorem13年1月24日木曜日

×