データが主食

データエンジニアの備忘録。分析だったり、読んだ本のメモだったり。

書籍「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

Part2は分散データです。

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

  • 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つの種類があります。つまり、複数マシンの役割の分担方法が3つあります。 - single-leader - multi-leader - leaderless

Leader and Followers

f:id:ktr89:20180621230505p:plain

この図分かりやすいですね。いわゆる、LeaderとFollowerです。Leaderに書き込まれた内容をFollowerに伝える際に同期/非同期の2通りの方法があります。同期でFollowerに書き込む場合はレスポンスが遅くなります。一方で、非同期で書き込む場合には、整合性の問題が発生します。

Followerの台数を増やす時の詳細な手続きや、Leaderが障害になった時の自動フェイルオーバーについて説明があります。やはり複数台構成のシステムを作ると障害時の対応などが難しくなるので、ここあたりを一通り頭に入れておくと安心ですね。

Problems with Replication Lag

レプリケーションのラグがある場合、ユーザーがデータを追加した直後にデータが見れないなどの整合性の問題が発生します。

例えば、ユーザーを中心とするDBの場合を考えてみます。北米ユーザーによるデータ更新を日本ユーザーが瞬時に必要とする可能性は低いです。そのため、北米データベースとアジアデータベースなどを分離し、同地域内データは同期、それ以外は非同期などとします。こうすることで、問題を軽減できます。

整合性が顕著な問題になりそうなケースを整理した上で、データベースの分散設計をすることになります。

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

Hiveなどを使っているとパーティションの設計がクエリ実行時間にダイレクトに影響することを感じられます。大きなデータを複数ノードに分散させつつ、必要なデータのみディスクから読み出すことで高速化できます。

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

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

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

Chapter 7. Transactions

7節はトランザクションです。アプリケーション開発時には絶対に知らないといけない内容ですね。

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文脈では、メモリではなくディスクに書き込んでいることをこのように表現するようです。

関連

ktr89.hateblo.jp ktr89.hateblo.jp