3.4 データアーキテクチャとストレージ

概要と動機

データはコードより長生きします。アプリケーションは数年ごとに書き直されますが、それが管理するデータ(顧客レコード、財務の元帳、給付の履歴、医療記録)は何十年も残ります。それはしばしば、組織の最も価値があり、最も規制された資産です。データアーキテクチャとは、そのデータがどうモデル化され、どこに保存され、どう一貫性を保たれ、どう進化し、規模で十分に速くどう提供されるかを決める規律です。大きな組織にとって、これらの決定は基礎的なものです。ストレージエンジンとデータモデルの選択は、システムの全寿命にわたって、ビジネスが何をでき、どれだけ速く動け、いくらかかるかを制約します。

賭け金が最も高いのは、規模、寿命、規制のために、企業と政府です。銀行のトランザクションストアは、1セントも失ったり二重に数えたりしてはなりません。政府の登録簿は、法定の期間レコードを保持し、監査人にその完全性を証明しなければなりません。医療システムは、きめ細かなアクセスと所在地のルールを徹底しなければなりません。同時に、これらの組織は莫大な読み書きの量を扱い、すべてのクエリが単一のリレーショナルデータベースに当たることを許せません。だからデータアーキテクチャは、正しさと耐久性を、性能と規模と両立させなければならず、スキーマが新しい義務づけに応えて変わり続けるなかでそれを行います。

本章は、主要なストレージのパラダイムとそれぞれをいつ使うか、ポリグロットパーシステンスの規律、データモデリングとしばしば過小評価されるスキーマの進化と移行の問題、無効化という悪名高く難しい問題を伴うキャッシュとCDN(コンテンツ配信ネットワーク)、そしてトランザクション、ロック、並行性が規模に押し上げられたときにどう振る舞うかを扱います。貫く線は単純です。万能のデータベースはありません。トレードオフがあり、良いデータアーキテクチャとは、それらをワークロードごとに意識的に選ぶことです。

主要原則

データを、アクセスパターンに合うようにモデル化する。逆ではない。 抽象的な「正しい」モデルではなく、データがどう読み書きされるかを軸にストレージを設計します。
すべてを統べる一つのデータベースはない。 異なるワークロードは異なるエンジンを求めます。規模ではポリグロットパーシステンスが普通です。
記録のシステムでは、正しさが最優先である。 権威あるデータでは、耐久性と一貫性は交渉の余地がありません。それらを通してではなく、それらの周りで性能を最適化します。
スキーマは変わるので、それに備える。 移行は、一度きりではなく、継続的な第一級のエンジニアリング活動です。
サービスの境界の背後で自分のデータを所有する。 各境界付けられたコンテキスト(独自の明示的な境界を持つ自己完結したドメインモデル)が自分のデータを所有します。データベースを共有するとチームを結合し、自律性を破壊します。
キャッシュは、性能の勝利を装った正しさの問題である。 すべてのキャッシュは、古さと無効化のリスクを持ち込みます。意図して扱います。
非正規化は罪ではなくトレードオフである。 読み取り性能のためにデータを複製することは、一貫性の帰結を自分で引き受けるなら正当です。
一貫性とスケールはトレードオフである。 トランザクションの保証が強いほど、分散するのは難しくなります。ワークロードが必要とするものだけを買います。

推奨事項

ワークロードからストレージのパラダイムを選ぶ

各ワークロードを、それに合うモデルに合わせます。リレーショナルデータベースは、強い一貫性、結合、成熟したトランザクションを与え、記録のシステムと複雑な整合性ルールを持つあらゆるものの既定です。ドキュメントストアは、一つの単位として読まれる(注文全体、プロフィール全体)階層的でスキーマの柔軟なデータに合います。キーバリューストアは、単純な検索(セッション、フィーチャーフラグ、キャッシュ)に極端な速度を与えます。グラフデータベースは、関係がクエリである所(不正のリング、組織図、権限、サプライチェーン)で優れます。カラムナストアは、数十億行にわたって少数の列をスキャンする分析クエリ(データウェアハウス、レポート)を支えます。時系列データベースは、追記の多いタイムスタンプ付きデータ(メトリクス、テレメトリ、モノのインターネット(IoT)のセンサー、市場データ)に最適化されます。一つのエンジンにあらゆる仕事をさせるのに抵抗してください。リレーショナルデータベースをキューとして、ドキュメントストアを元帳として使うのは、苦痛を招きます。

ポリグロットパーシステンスを意図して採用する

大きなシステムは、正当にいくつかのストアを使います。リレーショナルの記録のシステム、検索インデックス、キャッシュ、分析のウェアハウス、そしておそらくグラフや時系列のエンジン。これがポリグロットパーシステンスで、ワークロードが本当に異なるときの正しいパターンです。コストは運用的です。運用し、保護し、バックアップし、人員を配置するエンジンが増えるからです。各ストアをサービスによって所有されるものとして扱い、運用ツールを標準化し、技術の数をその場所を稼ぐものに限ることで、そのコストを管理します。些細なニーズごとに新しいデータベースを採用するのは警戒してください。それぞれが恒久的な運用上のコミットメントです。

データをモデル化し、スキーマの進化を継続的なものとして扱う

記録のシステムのために、前もってデータモデリングに投資します。整合性を守るために正規化し、それから実証された読み取りのホットスポットに対して選択的に非正規化します。モデルが何であれ、スキーマは永遠に進化するので、移行を安全で日常的なものにします。バージョン管理され、自動化された、前進のみの移行スクリプトを、ソース管理にチェックインし、デプロイのパイプラインを通じて適用します。大きなテーブルでのダウンタイムなしの変更には、エクスパンド・コントラクト(並行変更)パターンを使います。新しい列やテーブルを追加し、埋め戻して二重書き込みし、読み手を移行し、それから古い形を取り除きます。単一の破壊的なalterは決して行いません。古いコードと新しいコードが同時に動くよう、スキーマの変更をデプロイをまたいで後方互換にします。イベントソーシングやメッセージベースのシステムでは、イベントとメッセージのスキーマを明示的にバージョン管理し、古いイベントのアップキャスト(読み取り時に現在のスキーマに変換する)をサポートします。

キャッシュと無効化を目を開いて設計する

キャッシュとCDNは、最もてこの効く性能の道具です。CDNはユーザーの近くのエッジから静的でキャッシュ可能なコンテンツを提供し、アプリケーションのキャッシュは繰り返しの読み取りからデータベースを守ります。しかし難しいのは無効化、つまりキャッシュされたデータがいつ古くなるかを知ることです。ケースごとに戦略を選びます。わずかな古さが許容できる所では、最も単純な時間ベースの有効期限(TTL)を使います。鮮度が重要な所では、明示的な無効化やライトスルーを使います。アプリケーションが投入を管理する所では、キャッシュアサイドを使います。TTLを意識して設定し、キャッシュスタンピード(多くのクライアントが同じ期限切れのエントリを同時に再構築する)をロックやリクエストの合体で防ぎ、冷えたキャッシュでの雷鳴の群れを防ぎます。古さが正しさやコンプライアンスの失敗を引き起こしうるデータ(権限、残高、同意)は、明示的でテストされた無効化の経路なしにはキャッシュしてはいけません。キャッシュのキー、TTL、無効化を、偶発的な設定ではなく、設計された成果物として扱います。

規模のために、トランザクション、ロック、並行性を管理する

分離レベルを理解し、各トランザクションにとって正しい最も弱いものを選びます。高い分離は並行性のコストがかかるからです。競合が少なく読み取りの多いワークロードには楽観的並行性制御(書き込み時のバージョンチェック)を好み、本物のホットな競合のもとでのみ悲観的ロックに手を伸ばし、デッドロックを避けるためにロックを短く、一貫した順序に保ちます。スケールするにつれて、単一の書き込み可能なデータベースがボトルネックになります。読み取りのスケーリングのために読み取りレプリカを導入し(レプリケーションの遅延を受け入れる)、負荷を均等に広げ、関連するデータを一緒に保ってシャードをまたぐトランザクションを避けるキーで、シャード/パーティションします。シャーディングは、容易なシャードをまたぐ結合と複数シャードのACID(原子性、一貫性、分離性、耐久性)トランザクションを手放すことを忘れないでください。それがしばしば、サガと非正規化が現れる理由です。これらの技法は、ワークロードが求めるときにだけ取り入れます。早すぎるシャーディングは、恒久的な複雑さを加えます。

トレードオフ: 長所と短所

ストアの種類	最適な用途	強み	弱み
リレーショナル	記録のシステム、複雑な整合性	ACID、結合、成熟したツール	書き込みを水平にスケールするのが難しい
ドキュメント	集約の読み取り、柔軟なスキーマ	オブジェクト全体の速い読み書き、柔軟	ドキュメントをまたぐ結合/トランザクションが弱い
キーバリュー	セッション、キャッシュ、単純な検索	極端な速度とスケール	キー以外のクエリができない
グラフ	関係の多いクエリ	速い走査、表現力がある	特殊な運用スキル、スケールの限界
カラムナ	分析、レポート	速い集計スキャン、圧縮	行レベルのトランザクション書き込みに不向き
時系列	メトリクス、テレメトリ、IoT	効率的な追記と時間のクエリ	用途が狭い

支配的なトレードオフは、一貫性と豊かなクエリ対、水平スケーラビリティと速度です。リレーショナルのシステムは、最強の保証と最も柔軟なクエリを与えますが、多くのマシンにわたる書き込みのスケールが最も難しいものです。NoSQL(非リレーショナル)の仲間は、スケールと速度を得るために、結合、トランザクション、スキーマを緩めます。キャッシュは鮮度をレイテンシと交換します。シャーディングは、パーティションをまたぐトランザクションを書き込みスループットと交換します。そのどれも普遍的に正しくありません。技芸は、各ワークロードを、その正しさと性能のニーズが実際に必要とする、曲線上の点に置くことです。

チームで議論すべき問い

各重要なデータセットについて、全員が唯一の記録のシステムを名指しでき、キャッシュやプロジェクションが静かに真実として扱われていませんか。データはコードより長生きし、最も被害の大きいデータのインシデントは、ずれから来ます。キャッシュ、検索インデックス、読み取りのプロジェクションが権威あるものと間違われ、本物の源から静かに乖離する。大きなチームでは、オーナーシップが曖昧で、いくつかのサービスが重なるコピーを書き込むときにこれが起き、インシデントの間、どの値が正しいかを誰も言えません。重要なデータのマップと、各項目について、権威ある唯一のストアと、そこから再構築できなければならない派生コピーを持ち込んでください。金融と政府では、どのレコードが法的な源かを証明し、残りを再構成できることは、しばしば便利さではなく規制上の要件です。記録のシステムから再構築できないものはすべて、意図したかどうかにかかわらず、それ自体が記録のシステムです。
資産の中の各データベースエンジンは、運用し、保護し、バックアップするのに実際いくらかかり、すべてがまだその場所を稼いでいますか。 ポリグロットパーシステンスは、ワークロードが本当に異なるときに正しいですが、各エンジンは恒久的な運用上のコミットメントです。パッチ、バックアップ、監視、セキュリティレビュー、そして午前3時にそれを知っているスタッフ。大きな組織は、一つの機能のために採用されたストアの動物園に流れ込みえて、限界的なものは、すでに運用しているストアが扱えたワークロードに仕えながら、永遠にコストを加えます。すべてのエンジン、それを正当化するワークロード、誰がそのオンコールかを一覧にし、主要なストアが今や満たせるニーズのために採用されたものに印を付けてください。新しいデータベースの採用は高い基準を超えるべきです。後でそれを取り除くことは、もう一つの移行を意味するからです。保つストア全体で運用ツールを標準化することが、一つのエンジンにあらゆる仕事をさせずにコストを抑える方法です。
ユーザーが自分の書き込みの直後に、レプリカから古い値を読みうるのはどこで、それは約束したことを破りますか。 読み取りレプリカは読み取りをスケールしますが、プライマリに遅れるので、プロフィールを更新してすぐにリロードしたユーザーは古い値を見ることがあり、それはバグとして、あるいは残高や同意フラグでは、コンプライアンスの失敗として読まれます。フローごとに、自分の書き込みの読み取りが重要かを決め、それらの読み取りをプライマリにルーティングするか、セッション一貫性の仕組みを使います。レプリカから提供されるフローのリストを持ち込み、ユーザーが書き込みの直後にそれに基づいて行動するものに印を付けてください。残高、権限、同意については、古い読み取りを見た目の問題ではなく正しさの失敗として扱います。要点は、各ワークロードが実際に必要とする一貫性を買い、受け入れる古さを偶発的ではなく明示的にすることです。
今日、最大で最も忙しいテーブルのスキーマをダウンタイムなしに変更できますか。そして誰が実際にエクスパンド・コントラクトの手順をリハーサルしましたか。スキーマは永遠に進化し、最も痛い失敗は、巨大なテーブルをロックし、サービスを固め、きれいに元に戻せない一括のalterです。大きなチームではリスクが倍増します。いくつかのサービスが同じ形を読むので、破壊的な変更には、段階的なデプロイをまたいで古いコードと新しいコードが並んで動く必要があるからです。相反する引力は速度です。単一のalterは書くのが速く、エクスパンド・コントラクト(新しい形を追加し、埋め戻し、二重書き込みし、読み手を移行し、古い形を落とす)は、より多くのステップとより多くの忍耐を要します。最大のテーブルと、素朴なalterがそれをどれだけロックするかの誠実な見積り、そして誰かが理論ではなくリハーサルで端から端まで実行した具体的な移行を持ち込んでください。継続的に動き、法定の可用性目標を負う企業や政府のシステムでは、移行のためのダウンタイムは違反なので、エクスパンド・コントラクトの規律が、そもそもスキーマを変更することを許される代償です。
古いまま提供されると、見た目ではなくコンプライアンスや安全の失敗を引き起こすキャッシュやレプリケートされた値はどれで、それらの無効化の経路はすべてテストされていますか。キャッシュは、性能の衣装をまとった正しさの問題です。危険は遅さではなく、権限、残高、同意フラグ、アクセスの決定が変わった後にそれを提供することです。大きな組織では、危険は拡散しています。キャッシュとエッジ層がチーム全体に積み上がり、何がどこにキャッシュされ、いつクリアされるかを、誰一人として列挙できないからです。緊張は本物です。積極的なキャッシュと長いTTLはレイテンシを買いデータベースを守り、厳格な鮮度は両方にコストがかかります。キャッシュとCDNから提供されるデータの一覧を、コンプライアンスや安全上の結果を持つエントリに印を付けて持ち込み、それらそれぞれの無効化の経路が、単に設定されているだけでなく、実際に動かされた証拠を持ち込んでください。規制された公共の設定では、古い同意や適格性の値は監査可能な失敗なので、それらの項目には、明示的でテストされた無効化の経路が必要か、まったくキャッシュしてはいけません。
各権威あるストアの保持、アーカイブ、データ所在地の戦略は何で、監査人にそれを証明できますか。 データはコードより、そしてそれを書いたチームより長生きするので、際限のない成長と曖昧な所在地のルールは、テーブルが手に負えなくなったり、レコードが誤った法域にあったりするまで、誰も所有しない問題に静かになります。大きな組織は多くのストアとリージョンにまたがり、相反する考慮は、コスト(ホットストレージは高価なので、アーカイブして階層化する)、性能(肥大したテーブルはすべてを遅くする)、法的義務(衝突しうる、法定の保持の下限と所在地の上限)です。権威あるデータセットごとに、保持期間、データが物理的にどこにあるか、アーカイブと削除の仕組み、それに責任を負う人の名前を持ち込んでください。企業、特に政府のシステムでは、保持と所在地は通常、監査と主権の要件を伴う法的な義務づけなので、各レコードがどこにあり、どれだけ保持され、いつ破棄されるかを証明できることは、気の利いたものではなく、事業を営む免許です。

セクター別の視点

スタートアップ。 データベースを一つ運用し、動物園には抵抗してください。単一のマネージドなリレーショナルストアは、トランザクション、バックアップする対象一つ、一貫性について推論する場所一つを与え、それはまさに3人のチームが頭に収められるものです。特定の遅いクエリや本物の読み取りの量が強いるときにだけ、キャッシュ、読み取りレプリカ、検索インデックスを加え、複雑さが、見返りのある理由とともに届くようにします。稼働中の製品に移行の規律を後付けするのは、最初からそれを持つよりはるかに難しいので、初日から移行をバージョン管理してください。

小規模事業者。 データベースの専門家はおらず、複数のエンジンを運用する時間もないので、マネージドなストアを好み、バックアップ、パッチ、レプリケーションはプラットフォームのプロバイダーに任せます。ストアの選択を買う決定として扱い、ベンチマークで最速のものではなく、ツールがすでに統合している、退屈でよくサポートされたエンジンを選びます。実際に検証できる単純な保持とバックアップの方針を設定し、お金や権限に結びついたものは、クリアする明確な方法なしに決してキャッシュしないでください。古い価格や権限は、顧客を失わせるからです。

大企業。 中核の課題は、多くのチームにわたるポリグロットパーシステンスです。リレーショナルの記録のシステムに加えて、検索、キャッシュ、ウェアハウス、おそらくグラフや時系列のエンジンで、それぞれが共有されるのではなく、サービスによって所有されます。保つストア全体で運用ツール、バックアップ、監視を標準化し、新しいエンジンの採用に高い基準を課し、エクスパンド・コントラクトの移行と明示的なキャッシュの無効化を既定にします。資産を明確なデータのオーナーシップを持つポートフォリオとして管理し、どのエンジンもそれを正当化したワークロードより長生きせず、どのチームも共有データベースを通じて結合されないようにします。

政府。 データ所在地、法定の保持、証明可能な完全性が、あらゆる選択を形づくります。すべてのストアを主権のあるリージョンにプロビジョニングし、CDNを個人情報でないデータだけをキャッシュするよう設定し、規制当局のために再構成可能でなければならないレコードの不変の監査履歴を保ちます。新しい法律によって義務づけられた移行は、立法の期限を通じてサービスが利用可能であり続けるよう、パイプラインを通じて後方互換に適用しなければならず、記録のシステムは、どの値が法的な源かを証明し、すべての派生コピーをそこから再構築できるよう、特定可能でなければなりません。

事例

スタートアップ。 シード段階のスタートアップは、すべてを単一のマネージドなPostgreSQLインスタンスで運用し、必要になる前に別の検索エンジン、キャッシュ、ウェアハウスを加えたい衝動に抵抗します。一つのデータベースは、バックアップする対象一つ、一貫性について推論する場所一つ、ただ動くトランザクションを意味し、チーム全体が3人のエンジニアのときに重要です。特定の遅いクエリと本物の読み取りの量が正当化するときにだけ、Redisのキャッシュと読み取りレプリカを加えるので、複雑さは、それに先立つのではなく、見返りのある理由とともに届きます。

大企業。 小売銀行が、権威ある元帳を、強く一貫したリレーショナルデータベースに保っています。すべての仕訳は適切なACIDトランザクションで、書き込みのスケールのために口座の範囲でシャードされています。その周りにポリグロットの資産があります。顧客検索のための検索インデックス、モバイルアプリの口座サマリー用のRedisキャッシュ(ライトスルー、短いTTL)、規制と分析のレポートのためのカラムナのウェアハウス、取引ネットワークの不正検知のためのグラフデータベース。元帳へのスキーマの変更は二重書き込みを伴うエクスパンド・コントラクトを使うので、24時間365日のシステムは、移行のためのダウンタイムを一度も取りません。

政府。 国の車両登録簿が、法定の保持と完全な監査履歴を伴うリレーショナルの記録のシステムに、権威あるレコードを保存しています。公共向けの「車両を確認する」検索は、読み取りレプリカと短いTTLのエッジキャッシュから提供されます。わずかに古い公開データは許容でき、読み取りの量が書き込みをはるかに上回るからです。データ所在地の法律がすべてのレコードの国内保持を求めるので、すべてのストアが主権のあるリージョンにプロビジョニングされ、CDNは個人情報でないデータだけをキャッシュするよう設定されています。交通政策によって義務づけられた新しいフィールドを加える移行は、立法の期限の間もサービスが利用可能であるよう、パイプラインを通じて後方互換に適用されます。

ビジネスケース: 動機、ROI、TCO

データアーキテクチャの決定は、ソフトウェアの中で最も長く最大のコストの尾を持つものの一つです。データとそのスキーマは、システムと統合がそれに依存したら、最も変えにくいものだからです。良い実践(意図したストアの選択、規律ある移行、設計されたキャッシュ、適切なシャーディング)の採用コストは、おもにシニアエンジニアの時間と、いくらかの追加の運用ツールです。それを採用しないコストは、ビジネス全体を絞る単一の過負荷なデータベース、誤ったストアが遅れて発見されたときの緊急の再プラットフォーム化、失敗した移行による長引く障害、そして最も被害が大きいのは、誤って無効化されたキャッシュや失われたトランザクションによるデータ破損やコンプライアンス違反として現れます。

リーダーシップには、スケーラビリティの余裕、インシデントのリスク、規制上のリスクで論拠を示してください。正しいストレージの選択が、書き直しなしにビジネスが読み書きの量を増やせるようにします。規律ある移行が、ダウンタイムなしにスキーマが新しい義務づけに追随できるようにします。正しいキャッシュが、静かな古さのバグなしに速いユーザー体験を届けます。システムの寿命にわたるTCOを定量化してください。よく選ばれた単一のデータアーキテクチャは、悪いものを回避する繰り返しのコストを避け、防がれたデータ破損のインシデント一つは、通常、うまくやる全体のコストをはるかに上回ります。規制された分野では、データの完全性と所在地を証明できることは、コストセンターではなく、事業を営む免許です。

アンチパターンと落とし穴

サービス間の共有データベース。 複数のサービスが一つのスキーマを読み書きし、チームを結合し、あらゆる変更を調整の危機にすること。
すべてに一つのデータベース。 分析、キュー、検索、トランザクションを単一のリレーショナルエンジンに、それが崩壊するまで押し込むこと。
一括の移行。 ダウンタイムを要し、安全に元に戻せない単一の破壊的なスキーマ変更。
無効化戦略のないキャッシュ。 古いデータが無期限に提供される、あるいはキャッシュがいつクリアされるかを誰も所有しないために正しさのバグが生じること。
早すぎるシャーディング。 負荷が求める前にデータを分散し、利益なしに結合とトランザクションを恒久的に失うこと。
レプリケーションの遅延の無視。 遅れているレプリカから自分の書き込みを読んで古いデータを得て、ユーザーの期待を破ること。
際限のないデータの成長。 アーカイブや保持の戦略がなく、性能とコストが耐えられなくなるまでテーブルが育つこと。
派生データを真実として保存する。 キャッシュ、インデックス、プロジェクションを記録のシステムとして扱い、それがずれたことを発見すること。

成熟度モデル

レベル1: 開始。 一つのデータベースがあらゆる目的に使われます。スキーマの変更は手作業で場当たり的で、移行の規律がなく、キャッシュは偶発的で無効化は後回しです。性能の問題は、より大きなマシンを買うことで反応的に解決され、あるデータセットの記録のシステムを確実に名指しできる人はいません。
レベル2: 発展。 一部のストレージの選択は意図的で、キャッシュやウェアハウスが現れましたが、実践はチームごとに異なります。移行はバージョン管理されますが、ときにダウンタイムを要し、エクスパンド・コントラクトは、たまたま知っている人が使います。いくつかのサービスはまだデータベースを共有し、キャッシュ戦略はチームごとに異なります。
レベル3: 標準化。 ポリグロットパーシステンスはワークロードに合わせられ、各ストアは共有されずサービスによって所有されます。自動化された後方互換のダウンタイムなしのエクスパンド・コントラクトの移行は、文書化され組織全体で徹底される標準です。キャッシュ戦略、TTL、無効化の経路は明示的な設計成果物で、各データセットの唯一の記録のシステムが文書化され、派生コピーはそこから再構築可能です。
レベル4: 管理。 データ資産がベースラインに対して測定され、制御されます。移行の所要時間とロールバック率、自分の書き込みの読み取りの要件に対するレプリケーションの遅延、キャッシュのヒット率と古さのインシデント、ストアごとの運用コスト、目標パーセンタイルでのクエリのレイテンシを追跡し、数字に基づいて行動します。保持と所在地は法定の要件に照らして監査され、派生データの正しさは継続的に検証され、すべてのエンジンは、それが仕えるワークロードに対してコストを正当化しなければなりません。
レベル5: オーケストレーション。 データアーキテクチャは、組織全体で、キャパシティ、コスト、リスクの計画と統合され、継続的に改善されます。シャーディング、キャッシュ、一貫性の選択は、アクセスパターンとコストの変化に応じてワークロードごとに再均衡され、もうその場所を稼がないストアは、計画された移行によって退役します。スキーマの進化、アーカイブ、所在地は完全に自動化され適応的なので、資産は緊急の再プラットフォーム化なしに、新しい義務づけと負荷に合わせて自ら形を変えます。

議論のためのアイデア

現在のストアのうち、設計されていない仕事をしているものはどれで、正しいエンジンは何でしょうか。
今日、最大のテーブルのスキーマ変更をダウンタイムゼロで実行できますか。できないなら、なぜですか。
システムのどこで、古さがコンプライアンスや正しさの失敗を引き起こしうるデータをキャッシュしていますか。
どのサービスがデータベースを共有していて、それぞれに自分のものを与えるには何が必要ですか。
単一の書き込み可能なデータベースがスケールの天井になっているのはどこで、読み取りレプリケーションとシャーディングのどちらが正しい次の一歩ですか。
保持とアーカイブの戦略は何で、その責任は誰にありますか。

要点

データはコードより長生きします。ストレージとモデリングの決定は、システムの全寿命にわたってビジネスを制約します。
各ワークロードを、そのアクセスパターンに合うストレージのパラダイムに合わせ、規模ではポリグロットパーシステンスを予期します。
各サービスに自分のデータのオーナーシップを与え、共有データベースを通じてチームを結合してはいけません。
スキーマの進化を継続的なものとして扱い、後方互換でダウンタイムなしのエクスパンド・コントラクトの移行を使います。
キャッシュは正しさの問題です。TTL、無効化、スタンピード対策を意図して設計し、テストされた無効化の経路なしに、コンプライアンスに重要なデータをキャッシュしてはいけません。
各ワークロードが必要とする一貫性とトランザクションの保証だけを買います。シャーディングとレプリケーションは、パーティションをまたぐトランザクションをスケールと交換します。

参考文献とさらなる読み物

Martin Kleppmann, Designing Data-Intensive Applications
Pramod Sadalage and Martin Fowler, NoSQL Distilled
Pramod Sadalage and Scott Ambler, Refactoring Databases: Evolutionary Database Design
C. J. Date, An Introduction to Database Systems
Joe Celko, SQL for Smarties
Vlad Mihalcea, High-Performance Java Persistence (transactions, isolation, concurrency)
Eric Evans, Domain-Driven Design (bounded contexts and data ownership)
Werner Vogels, “Eventually Consistent”