Designing data intensive applications 輪読会資料

1. Designing Data-Intensive
Applications １と２章
輪読会資料
２０１９年１月 kanda.motohiro@gmail.com 作成。
CC BY-SA 4.0 のもとで公開します

2. 第１章は、ほぼおなはしで
•Reliability
•Scalability
•Maintainability
さらっと流すけど、面白いエピソードは紹介する。

3. Reliability
• 信頼性。障害があっても期待通りのことをすること。
• Netflix Chaos Monkey 本番システムで、わざと、ラックのケーブルを
抜く
• ハードウエア障害。冗長化して対処する。
• ソフトウェアの誤り。は、多数のマシンを同時に落とすことがある。
• 人的誤り。大きなインターネットサービスでの報告：オペレータの構
成誤りは、ハードウエア障害（１０％から２５％）以上の、サービス停
止原因。

4. Scalability
• 負荷が増えても耐えられること
• Twitter の場合
• 主な操作は２つ。
• (1) Post tweet：つぶやく。
• (2) Home timeline：フォローしている人のつぶやきを見る。
• 実装案１．(1) つぶやきのグローバルなキューに入れる。(2) 自分のフォロー
している人のつぶやきを集めて、時刻でソートして見せる。
• 実装案２．(2) 各ユーザは、 Home timeline のキャッシュを持つ。(1) つぶやく
ときは、フォロワーのHome timeline 全てにつっこむ。
• 最初は、１で実装したが、２に変更した。(2) は、(1) より２桁多い。しかし、３
千万フォロワーを持つ人がつぶやくと大変。最終的にハイブリッドにした。

5. Scalability
• ところで、負荷とは？性能とは？
• Amazon の場合。性能値とは？
• 99.9th percentile の応答が、規定時間内に終わることが重要。
• 平均値は意味がない。重い問い合わせをするお客さんは、最も買い物をす
る人。その人たちの満足度を上げることが重要。
• 負荷に対処する方法。スケールアップ、スケールアウト。
• stateless マシンを複製して増やすのは簡単。スケールアウト。例を
挙げよ。
• データベースを複数ノード構成にするのは面倒なので（なぜ？か知
りたければ９章まで読め）普通、スケールアップ。しかしスケールアウ
トするしかない時が来る。＝＞この本の主題

6. Maintainability
Many people working on software systems
dislike maintenance.
It involves
•fixing other people’s mistakes
•systems that were forced to do things they
were never intended for.
（笑）
From Designing Data-Intensive Applications by Martin Kleppmann Copyright © 2017 Martin
Kleppmann. All rights reserved.

7. Maintainability
•Operability 運用しやすいこと
•Simplicity 単純であること
•Evolvability 拡張できること
Also known as extensibility, modifiability,
or plasticity.
１章終わり

8. 第２章

9. データモデルといえばSQL
リレーショナルモデルは表形式。
SELECT * FROM BOOKS WHERE Title =
‘Designing Data-intensive App’
Title Author Publisher

10. 新しいデータモデル：ドキュメント
user table
250 Kanda
251 Kleppmann
positions table
developer
writer
job table
job 1
job 2
リレーショナルが苦手とする階層構造
Designing Data-Intensive Applications by
Martin Kleppmann Copyright © 2017 Martin
Kleppmann. All rights reserved.

11. 新しいデータモデル：ドキュメント
• リレーショナルの問題：１対多とか、階層型構造を入れにく
い。
• 対策：データベースのフィールドに、XML, JSON をいれる。Oracle 他。
• ドキュメントデータベース
• 表形式のデータモデルを捨ててしまえ。
• MongoDB, RethinkDB, CouchDB, Espresso
• 実は、１９７０年代にIBM が、IMS という階層型データベース
製品を出していた。

12. スキーマ
• 伝統的リレーショナルデータベースは、スキーマ、つまりレコードの
フィールド定義を事前に行う。
• ドキュメントデータベースの多くは、スキーマレス。個々のレコードが、
フィールドの記述子、タグ、を持つ。
長所：フィールド追加が簡単。レコードごとにフィールド構成が違っても
大丈夫。データモデルのダイナミックな変更。
短所：読むときにアプリケーションが意識しないといけない。
全てのフィールドがタグ付きで格納されるので、ディスクがむだ。実装
による。

13. ローカリティ
• ドキュメントの tree ごとにディスクに持つと、ドキュメント更新で、
ディスク読み書きが一度で済んで、効率的。ノードで分割されている
場合、通信が発生しないことはもっと重要。
• 実は、ドキュメントデータベースに限らない。
• Google Spanner テーブルの行を、親テーブル内にネストして置く指定がで
きる。
• Oracle multi-table index cluster table と呼ぶ。
• Bigtable(used in Cassandra and HBase) は、column-family という概
念でカラムのまとめをサポートする。

14. データベース問い合わせ言語には
• declarative 何が欲しいかを指示する。SQL
• imperative 欲しいものを取ってくる手順を指示する。
がある。
CSS と XSL の話は省略。
Mongodb での MapReduce の例も省略。

15. あなたのデータが本質的に多対多なら
• グラフデータベースの出番 （だけど私はあまり興味ないのでこのスライド
一枚だけ）
• グラフモデル
• property graph model (implemented by Neo4j, Titan, and
InfiniteGraph)
• triple-store model (implemented by Datomic, AllegroGraph)
• グラフ問い合わせ言語
• Cypher, SPARQL, Datalog, Gremlin, Pregel
２章終わり