データが主食

データ系エンジニアのぽえむ。分析だったり、読んだ本のメモだったり。

書籍「Designing Data-Intensive Applications」まとめ(Part2)

ktr89.hateblo.jp

に引き続き「Designing Data-Intensive Applications」のまとめです。日本語記事が少なくて、困っている方も多いのではないでしょうか?

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Part II. Distributed Data

通常だとRDBをもっと深入りしそうなところですがいきなり分散データのPartです。楽しみですね。

データを分散させる目的としては

  • Scalability
  • Fault tolerance/ high availability
  • Latency

とあります。普通に納得ですね。

The problem with a shared-memory approach is that the cost grows faster than linearly: a machine with twice as many CPUs, twice as much RAM, and twice as much disk capacity as another typically costs significantly more than twice as much. And due to bottlenecks, a machine twice the size cannot necessarily handle twice the load.

やはり水平分散させるしかないですね。水平分散の方法には - Replication - Partitionng があります。この二つに分けてChapterが進行していきます。

Chapter 5. Replication

Replication には3つの種類があります。 - single-leader - multi-leader - leaderless

Leader and Followers

f:id:ktr89:20180621230505p:plain

この図分かりやすいですね。いわゆる、LeaderとFollowerです。Leaderに書き込まれた内容をFollowerに伝える際に同期/非同期のふた通りのやりかたがあります。 Followerの台数を増やす時の手続きや、Leaderが障害になった時の自動フェイルオーバーについて説明があります。具体的なDBの名前を出さず一般論で話を進むのがとても分かりやすいです。

Problems with Replication Lag

レプリケーションのラグがある場合、ユーザーがデータを追加した直後にデータが見れないなどの問題が発生します。こういった問題にどう対処するか?そういった説明です。 例えば、とあるユーザーに関連する情報は一つのノードにまとめることや、地理的な条件でノードを整理することでこういった問題を軽減できます。 それ以外にも、とあるユーザーがPCでデータを追加した後、スマホで確認したらデータが無かったなどの問題もこの類です。初期のGoogle Driveはこういうの多かったですね。

Multi-Leader Replication

書き込みがリーダーノードが担うというのが基本ですが、書き込みが多いシステムの場合、リーダーを複数台構築することになります。例えば、日本に1台リーダー、北米に1台リーダーなどを設置します。問題としては、同じデータに関する更新を別の2台に同時リクエストされたときにコンフリクトが発生します。

For example, consider the calendar apps on your mobile phone, your laptop, and other devices. You need to be able to see your meetings (make read requests) and enter new meetings (make write requests) at any time, regardless of whether your device currently has an internet connection. If you make any changes while you are offline, they need to be synced with a server and your other devices when the device is next online.

これ面白いですね。今の時代スマホのDBに書き込んで、サーバーのDBへ同期するっていうのはよくあるアーキテクチャですよね。ここでも、同じ問題が生じます。それ以外にもGoogleDocsみたいなコラボレーションソフトでも各ユーザーがDBを持っていて、コンフリクト解決を実行する必要があります。ここでは、細かい説明はされませんが、自動でコンフリクトを解決する手法が研究されているそうです。

Chapter 6. Partitioning

ビッグデータ処理の基本パーティショニングですね。これをうまくやれるかでクエリの実行時間に大きな影響があるので、日々パーティションのことを考えていると言っても過言ではございません。大きなデータを複数ノードに分散させることでクエリのロードを分散し、レイテンシーを短くできますね。

この章では、KVSを想定しキーをどのように複数ノードに配置するべきか?ノードが増えたときに引越データ量を少なくするためにはどうすればよいのか?などが説明されます。

Secondary Indexの説明がなされます。AWSではなんとなくでDynamoDBを使っていましたが、この本を読んでDynamoDBの裏側がだいぶイメージできるようになりました。

他にキーが分散しているDBにクエリを投げるとき、どこのノードにデータがあるかを管理する必要があります。そのためにZooKeeperを使うんですね。EMRでなんとなくインストールしていましたが、こういう役割だったとは。

Chapter 7. Transactions

トランザクション。アプリケーション開発時には絶対に知らないといけない内容ですね。やっとここまでたどり着きました。

We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.

本当にその通りで、DBへの読み書きのタイミングで都度トランザクションのことを考えていたら、ビジネスロジックに時間を使えません。DBMSに依存して進めいていきたいところです。

Almost all relational databases today, and some nonrelational databases, support transactions. Most of them follow the style that was introduced in 1975 by IBM System R, the first SQL database [1, 2, 3]. Although some implementation details have changed, the general idea has remained virtually the same for 40 years: the transaction support in MySQL, PostgreSQL, Oracle, SQL Server, etc., is uncannily similar to that of System R.

完全に枯れた技術ですね。

Atomicity

f:id:ktr89:20180624153611p:plain

Consistency

Consistencyという言葉は文脈によって4つも意味があるそうです。著者はACIDというキーワード自体マーケティングのための言葉で技術的な言葉ではないと書いています。

Isolation

f:id:ktr89:20180624153446p:plain

Durability

結局ディスクが全部吹っ飛んだらデータは消えるので、完全なるDurabilityなど存在しない。特にRDB文脈では、メモリではなくディスクに書き込んでいることをこのように表現するようです。