オリジナルの「 データ集約型アプリケーションの設計 」（2016年9月に発表しました）で言及したMartin Kleppmanの待望の基本的な仕事は、印刷会社から来たばかりです。 この本はサイトで注文できます（感謝しないでください、私たちは喜んでいます）
そして、昨年11月の終わりに、待望の本Database Reliability EngineeringがO'Reillyから出版されました。これは、Kleppmanの研究を完全に補完するものと思われます。 ちなみに、Amazonにいる間は絶賛レビューのみ
カットの下で、私たちはあなたに馬を使った本の楽観的なレビューだけでなく、このレビューに関する現実的な解説も提供します。
データベース信頼性エンジニアリングの表紙を見ると、「ちょっと待ってください。このエンジニアリングとデータベース管理との違いは何ですか？」
私はあなたを喜ばせます：レーン・キャンベルとチェリティー・メジャーが序文で最初に応答するのはまさにこの質問です。
「...非常に長い間、DBAの仕事は細胞と雪片を作ることでした。 皆のためのツールは異なっていました、機器は異なっていました、プログラミング言語も異なっていました（...）そのようなモデルの実際の効率と安定性の日はすでに番号が付けられていました。 この本は、データベースエンジニアの観点からシステムの信頼性を確保することについて語っています。この本は単に配信します。実際には、 Googleのサイト信頼性エンジニアリングの本の 250ページのバリエーションです（私は気に入っています）。企業。
上級データベースエンジニアがこの本を読む方法
第10章の189ページの「データ複製」セクションを開きます。著者は、次の違いを説明します。
- シングルマスターレプリケーション-Microsoft SQL ServerのAlways On可用性グループのように、1つのサーバーのみが特定のデータベースへの書き込みを受け入れることができます
- マスターレスレプリケーション— SQL Serverのピアツーピアレプリケーションの場合。任意のノードが書き込み操作を受け入れることができます。
- 多くの主要なノードでのレプリケーション-複雑なレプリケーショントポロジについて話します。2〜3ノードのみが書き込み操作を受け入れ、残りはすべて読み取り操作を受け入れます。
シングルマスターレプリケーションについては、p。 190-202; ここで、著者は、「アクセシビリティグループ」などのシステムのすべての長所と短所を驚くほど説明しています。 はい。12ページでは、アクセシビリティグループの設計、実装、デバッグの方法を詳細に説明することはできません。 ただし、これらの12ページを習得したので、このようなソリューションを推奨するタイミングと、注意すべき落とし穴をよりよく学習できます。
これは、データベースの信頼性を確保するためのエンジニアの仕事です。 このようなエンジニアは、1つのデータベースを操作する方法を知っているだけでなく、特定の機能を使用する価値がある場合、価値がない場合、および（一般的に）システムを自動化してシステムの弱点を排除する方法も知っています。
これらの12ページは、この250ページの本が実際にどの程度の範囲にあるかを示しているので気に入っています。 著者は、データベースの詳細だけでなく、データベースとアプリケーションの間の相互作用、およびビジネスロジックがデータベースに実装される方法についても最も深い知識を持っています。 著者は、専門的にデータを扱うすべての人にとって本が興味深いように、自分の経験から抽象化することができます。 それにもかかわらず、彼らは本に示されている資料が他の現代の技術を扱うときに直接適用できるように十分に明確に書くことができます。
たとえば、コードレベルでインフラストラクチャを提供しながらバージョニングを使用する方法については説明しません。 この本は、バージョニングを習得する必要があると単に述べており、このスキルを習得し始めるための重要な用語を紹介しています。
新しい用語と概念を学ぶ必要があります。 あなたが現在働いている組織で彼らが実践されるまでには何年もかかるかもしれません。 これは普通のことです。なぜなら、本は視野を広げるために必要だからです。
マネージャーはこの本をどのように読むべきですか？
マネージャー、そしてこの本もあなたにとって興味深いものになるでしょう。 結局のところ、あなたは理解するでしょう：「ああ、私はこれを行うことができるデータベース管理者のチームが必要です」
第2章（サービスレベルでの管理）を注意深く学習し、現在の従業員とこのモードで作業を開始することをお勧めします。 このレベルで目標の設定を開始し、達成のペースを測定する方法について話し合います。 私の意見では、これは本の最も難しい部分です。 彼女は、ビジネスオーナーがこれらの問題について喜んで妥協することを提案します。 これらは技術的な計画ではなく、社会の問題であり、それを解決しなければならないのはマネージャーです...
この章から、単純に楽しい2つの行（イタリック鉱山）を引用します。
「 SLO（Service Level Goals）は、従うゲームのルールを管理します 。 これらの目標は、どのようなリスクを負う準備ができているか、どのようなアーキテクチャ上の決定を下すか、そのようなアーキテクチャの機能を保証するプロセスを設計する方法を決定するために必要です。「可用性」と「遅延時間」の現象は、データベースの信頼性のエンジニアにとって、営業担当者の「収入」と「利益」と同じくらい重要です。 誰がマーケティング担当者に伝えるアイデアを思いついたでしょうか：「ああ、できる限り最高の価格を打ち負かしてください-そして、すべてがうまくいくでしょう。」 信頼性エンジニアの場合、このような数値も機能しません。
開発者とシステム管理者がこの本を読む方法
データベースの管理を始めたばかりの場合は、いくつかの用語がよく知られているように思われます（「リリース管理」、「監視」、「ヒューマンファクター」）。
第10章から第12章は単純に素晴らしいようです。
これらの章では、大規模な概念（ACID、CAP定理、キャッシング、メッセージングシステム）の多くを学びます。 あなたは単に驚いて目を閉じ、そのようなテキストを読んでいるとき、あなたのエゴはcr屈になるかもしれません。 絶望しないでください。すでにこれらの章を読んでいると、ほとんどのデータベース管理者が疑わないことの多くを学ぶことができます。
はい、もちろん、この本をお勧めします。
結局のところ、これは読みやすいだけで実装するのが難しい本です。 真剣に、ほとんどの典型的な企業におけるサービスレベル（第2章のトピック）でのサービスの実装だけでは、すべての側面を調整および追跡するのに数か月かかります。
時間が経つにつれて、他のツールが現在の商用およびオープンソースのツールに取って代わりますが、本に記載されている概念自体は少なくとも10年間は揺るぎないままです。 この本は、5〜10年先を見通すことに慣れているすべての人にとって素晴らしい場所ですが、さらに見ても構いません。
これらの本が気に入ったら、Googleのサイト信頼性エンジニアリングもお勧めします。 本ではなく、奇跡。
DAN CAROLLOによるコメント
はい。この本は、設計、開発、リリース、生産管理ライフサイクルなどのトピックに関する確かな基盤を確実に築きます。 これは、インフラストラクチャを管理するだけでなく、自分自身よりも成長したいデータベース管理者にとって必読の文書です。
一部のデータベース管理者は、「不機嫌な監視員」になり、生産チェーンを閉鎖する場合があります。 それどころか、この本は、プロのデータエンジニアがシステムの設計と開発の非常に早い段階からプロセスに関与することがいかに重要であるかを強調しています。
しかし、この本の欠点のうち、私は過度に複雑なスタイルについて不満を言いたいです。 ふう！
さらに、この本はオープンソースプラットフォーム（Linux、MySQL）への明確なバイアスを示しており、Microsoftプラットフォームを巧みに使用している読者を怖がらせることができます。 （SQL Serverへの栄光！）。 SQL Serverスペシャリストの仲間であるあなたは、ここで概説した概念をネイティブプラットフォームに適合させる必要があります。
本の詳細は、インターネット上の分散アプリケーションを扱うために明確に明確化されています。つまり、データ分析、ビッグデータおよびデータウェアハウスの分野に限定されません。 著者は、これを86ページに明示的に報告しています。「データウェアハウスを配布することを想定しています。」
したがって、いくつかの小さな欠陥に目を向けると、この本はデータベース管理者とそのチームメイトのための優れた入門書です。