データベースについてもっと多くの開発者が知っておくべきこと

ノート。 翻訳。: Jaana Dogan は Google の経験豊富なエンジニアで、現在 Go で書かれた同社の実稼働サービスの可観測性の開発に取り組んでいます。 英語圏の聴衆の間で大きな人気を博したこの記事では、大規模で要求の厳しいアプリケーションの開発者が考慮するのに役立つ、DBMS (場合によっては分散システム一般) に関する重要な技術的詳細を 17 項目にまとめました。

大多数のコンピュータ システムはその状態を追跡するため、何らかのデータ ストレージ システムが必要です。 私は長期間にわたってデータベースに関する知識を蓄積しましたが、その過程でデータの損失や停止につながる設計ミスを犯しました。 大量の情報を処理するシステムでは、データベースはシステム アーキテクチャの中心にあり、最適なソリューションを選択する際の重要な要素として機能します。 データベースの動作には細心の注意が払われているにもかかわらず、アプリケーション開発者が予期しようとしている問題は氷山の一角にすぎないことがよくあります。 この一連の記事では、この分野を専門としない開発者にとって役立つアイデアをいくつか紹介します。

1. 99,999% の確率でネットワークが問題を引き起こさなければ幸運です。
2. ACID にはさまざまな意味があります。
3. 各データベースには、一貫性と分離を確保するための独自のメカニズムがあります。
4. 通常の状態を維持することが難しい場合は、楽観的なブロックが役に立ちます。
5. ダーティ リードやデータ損失以外にも異常があります。
6. データベースとユーザーは、常に行動方針に同意するとは限りません。
7. アプリケーションレベルのシャーディングはアプリケーションの外に移動できます。
8. 自動インクリメントは危険な場合があります。
9. 古いデータは役立つ場合があるため、ロックする必要はありません。
10. 歪みはどのような時間ソースでも発生するのが一般的です。
11. 遅延には多くの意味があります。
12. パフォーマンス要件は、特定のトランザクションに対して評価する必要があります。
13. ネストされたトランザクションは危険な場合があります。
14. トランザクションはアプリケーションの状態に関連付けられるべきではありません。
15. クエリ プランナーはデータベースについて多くのことを教えてくれます。
16. オンライン移行は困難ですが、可能です。
17. データベースが大幅に増加すると、予測不可能性が増加します。

この記事の以前のバージョンについてフィードバックをくださった Emmanuel Odeke 氏、Rein Henrichs 氏、その他の方々に感謝いたします。

99,999% の確率でネットワークが問題を引き起こさなければ幸運です。

最新のネットワーク テクノロジの信頼性と、ネットワーク障害によりシステムがダウンする頻度については、依然として疑問が残ります。 この問題に関する情報は不足しており、研究は多くの場合、専門のネットワーク、機器、人材を備えた大規模組織によって独占されています。

Spanner (Google の世界的に分散されたデータベース) の可用性率は 99,999% であり、Google は次のことだけを主張しています。 視聴者の３８%が 問題はネットワークに関連しています。 同時に同社は、自社の特殊ネットワークを高可用性の「主柱」と呼んでいます。 勉強 ベイリスとキングズベリー2014年に実施された「分散コンピューティングに関する誤解ピーター・ドイチュが1994年に策定したもの。 ネットワークは本当に信頼できるのでしょうか?

巨大企業の外で、より広範なインターネットを対象に実施される包括的な調査は存在しません。 また、大手企業からは、顧客の問題の何パーセントがネットワーク関連であるかについて十分なデータが得られていません。 私たちは、大規模なクラウド プロバイダーのネットワーク スタックで障害が発生し、インターネット全体が数時間ダウンする可能性があることをよく知っています。これは、多数の人々や企業に影響を与える注目度の高いイベントであるためです。 ネットワークの停止は、すべてのケースが注目されているわけではないとしても、さらに多くのケースで問題を引き起こす可能性があります。 クラウドサービスの顧客も問題の原因については何も知りません。 障害が発生した場合、その原因がサービス プロバイダー側​​のネットワーク エラーであると特定することはほとんど不可能です。 彼らにとって、サードパーティのサービスはブラックボックスです。 大手サービスプロバイダーでなければ、その影響を評価することは不可能です。

大手企業が自社のシステムについて報告している内容を考慮すると、ネットワークの問題が潜在的なダウンタイムの問題のほんの一部を占めているだけであれば、幸運であると言っても過言ではありません。 ネットワーク通信は依然として、ハードウェア障害、トポロジーの変更、管理構成の変更、停電などの日常的な出来事に悩まされています。 最近、考えられる問題のリストが追加されたことを知り驚きました サメに噛まれた （はい、正しく聞こえました）。

ACID にはさまざまな意味があります

ACID は、Atomicity、Consistency、Isolation、Reliability の頭字語です。 トランザクションのこれらのプロパティは、障害、エラー、ハードウェア障害などが発生した場合にトランザクションの有効性を保証することを目的としています。 ACID または同様のスキームがなければ、アプリケーション開発者が自分の責任とデータベースの責任を区別することが困難になります。 ほとんどのリレーショナル トランザクション データベースは ACID に準拠しようとしていますが、実装にコストがかかるため、NoSQL のような新しいアプローチにより、ACID トランザクションのない多くのデータベースが誕生しました。

私が初めてこの業界に入ったとき、当社の技術責任者は、ACID の概念がいかに適切であるかについて話していました。 公平を期すために言うと、ACID は厳密な実装標準ではなく、大まかな説明であると考えられています。 現在では、特定のカテゴリの問題が提起される (そして考えられるさまざまな解決策が提案される) ため、これが非常に役立つと感じています。

すべての DBMS が ACID に準拠しているわけではありません。 同時に、ACID をサポートするデータベース実装は、一連の要件を異なる方法で理解します。 ACID 実装にむらがある理由の XNUMX つは、ACID 要件を実装するために多くのトレードオフを行う必要があるためです。 作成者はデータベースを ACID 準拠として提示するかもしれませんが、「ありそうもない」イベントを処理するメカニズムと同様に、エッジ ケースの解釈は大幅に異なる可能性があります。 少なくとも、開発者は基本実装の複雑さを高レベルで理解し、その特殊な動作と設計のトレードオフを適切に理解することができます。

MongoDB が ACID 要件に準拠しているかどうかに関する議論は、バージョン 4 のリリース後も続いています。 MongoDB は長い間サポートされていませんでした ロギングただし、デフォルトでは、データは 60 秒ごとに 1 回しかディスクにコミットされませんでした。 次のシナリオを想像してください。アプリケーションが 2 つの書き込み (w1 と w2) をポストします。 MongoDB は wXNUMX を正常に保存しましたが、ハードウェア障害により wXNUMX が失われます。

シナリオを示す図。 MongoDB がデータをディスクに書き込む前にクラッシュする

ディスクへのコミットはコストのかかるプロセスです。 頻繁なコミットを避けることで、開発者は信頼性を犠牲にして記録パフォーマンスを向上させます。 MongoDB は現在ログをサポートしていますが、デフォルトではログが 100 ミリ秒ごとにキャプチャされるため、ダーティ ライトは依然としてデータの整合性に影響を与える可能性があります。 つまり、リスクははるかに低くなりますが、ログとそこに示された変更についても同様のシナリオが発生する可能性があります。

各データベースには独自の一貫性と分離のメカニズムがあります。

ACID 要件の中で、一貫性と分離は、トレードオフの範囲が広いため、最も多くの異なる実装を誇ります。 一貫性と分離は非常に高価な機能であると言わなければなりません。 これらには調整が必要であり、データの一貫性を求める競争が激化します。 複数のデータセンターにわたってデータベースを水平に拡張する必要がある場合 (特にデータセンターが地理的に異なる地域にある場合)、問題の複雑さは大幅に増加します。 高レベルの一貫性を達成することは、可用性が低下し、ネットワークのセグメント化が増加するため、非常に困難です。 この現象のより一般的な説明については、以下を参照することをお勧めします。 CAP定理。 また、アプリケーションは少量の不整合を処理でき、プログラマーは問題の微妙なニュアンスを十分に理解して、不整合の処理をデータベースに大きく依存することなくアプリケーションに追加のロジックを実装して不整合を処理できることも注目に値します。

DBMS は多くの場合、さまざまなレベルの分離を提供します。 アプリケーション開発者は、好みに基づいて最も効果的なものを選択できます。 分離性が低いと速度は向上しますが、データ競合のリスクも高まります。 断熱性が高いとこの可能性は低くなりますが、作業が遅くなり、競争が発生する可能性があり、基盤にブレーキがかかり、故障が始まります。

既存の同時実行モデルとそれらの間の関係のレビュー

SQL 標準では XNUMX つの分離レベルのみが定義されていますが、理論上および実際にはさらに多くの分離レベルがあります。 ジェプソンアイオ は、既存の同時実行モデルの優れた概要を提供します。 たとえば、Google Spanner はクロック同期による外部シリアル化可能性を保証しており、これはより厳密な分離レイヤーですが、標準の分離レイヤーでは定義されていません。

SQL 標準では、次の分離レベルについて言及しています。

• シリアライザブル (最も厳格で高価): 直列化可能な実行には、一部の逐次トランザクションの実行と同じ効果があります。 順次実行とは、前のトランザクションが完了した後でのみ後続のトランザクションが開始されることを意味します。 注意すべきレベルは、 シリアライザブル スナップショット分離自体は SQL 標準では表現されていませんが、解釈の違いにより、いわゆるスナップショット分離 (Oracle など) として実装されることがよくあります。
• 反復可能な読み取り: 現在のトランザクション内のコミットされていないレコードは現在のトランザクションで使用できますが、他のトランザクションによって行われた変更 (新しい行など) 見えない.
• 読み取りがコミットされました: コミットされていないデータはトランザクションに使用できません。 この場合、トランザクションはコミットされたデータのみを参照でき、ファントム読み取りが発生する可能性があります。 トランザクションが新しい行を挿入してコミットすると、現在のトランザクションはクエリ時にそれらの行を確認できるようになります。
• コミットされていない読み取り (最も厳密でコストが低いレベル): ダーティ読み取りが許可され、トランザクションは他のトランザクションによって行われたコミットされていない変更を確認できます。 実際には、このレベルはクエリなどの大まかな見積もりに役立つ場合があります。 COUNT(*) テーブルの上に。

Уровень シリアライザブル データ競合のリスクを最小限に抑えることができますが、実装に最も費用がかかり、システムに対する競争負荷が最も高くなります。 他の分離レベルは実装が簡単ですが、データ競合の可能性が高くなります。 カスタム分離レベルを設定できる DBMS もあれば、強力な設定があり、すべてのレベルがサポートされているわけではない DBMS もあります。

特定の DBMS では分離レベルのサポートが宣伝されることがよくありますが、実際に何が起こっているかを明らかにするには、その動作を注意深く調査する必要があります。

さまざまな DBMS のさまざまな分離レベルでの同時実行異常のレビュー

マーティン・クレップマンのプロジェクト 庵 さまざまな分離レベルを比較し、同時実行異常について説明し、データベースが特定の分離レベルを遵守できるかどうかを説明します。 Kleppmann 氏の調査は、データベース開発者が分離レベルについてどのように異なる考え方をしているかを示しています。

通常の状態を維持することが難しい場合は、楽観的なブロックが役に立ちます。

ブロッキングは、データベース内での競合が増えるだけでなく、アプリケーション サーバーがデータベースに常時接続する必要があるため、非常にコストがかかる可能性があります。 ネットワークのセグメント化により、排他的ロックの状況が悪化して、特定と解決が困難なデッドロックが発生する可能性があります。 排他的ロックが適切でない場合には、楽観的ロックが役に立ちます。

楽観的ロック 文字列を読み取るときに、そのバージョン、チェックサム、または最終変更時刻を考慮するメソッドです。 これにより、エントリを変更する前にアトミック バージョンの変更がないことを確認できます。

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

この場合、テーブルを更新すると、 products 以前に別の操作がこの行に変更を加えた場合、実行されません。 この行に対して他の操作が実行されなかった場合、XNUMX 行の変更が発生し、更新が成功したと言えます。

ダーティリードやデータ損失以外にも異常がある

データの一貫性に関しては、ダーティ リードやデータ損失につながる可能性のある競合状態の可能性に焦点が当てられます。 ただし、データの異常はそれだけではありません。

このような異常の一例は、録音の歪みです。 (スキューを書く)。 歪みは通常積極的に探されることがないため、検出するのが困難です。 これらはダーティ リードやデータ損失によるものではなく、データに課された論理制約の違反によるものです。

たとえば、XNUMX 人のオペレーターが常にオンコールである必要がある監視アプリケーションを考えてみましょう。

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

上記の状況では、両方のトランザクションが正常にコミットされた場合、レコードの破損が発生します。 ダーティ リードやデータ損失はありませんでしたが、データの整合性が損なわれました。現在、XNUMX 人が同時にオンコールとみなされます。

シリアル化可能な分離、スキーマ設計、またはデータベース制約は、書き込み破損の排除に役立ちます。 開発者は、実稼働環境での異常を回避するために、開発中にそのような異常を特定できなければなりません。 同時に、コードベースで録音の歪みを探すのは非常に困難です。 特に大規模システムでは、異なる開発チームが同じテーブルに基づいた機能の実装を担当しており、データ アクセスの詳細について合意していない場合に発生します。

データベースとユーザーは何をすべきかについて常に同意するとは限りません

データベースの重要な機能の XNUMX つは実行順序の保証ですが、この順序自体はソフトウェア開発者にとって透過的ではない場合があります。 データベースは、プログラマが意図した順序ではなく、受信した順序でトランザクションを実行します。 トランザクションの順序を予測することは、特に高負荷の並列システムでは困難です。

開発中、特にノンブロッキング ライブラリを使用する場合、スタイルが悪く可読性が低いため、実際にはトランザクションは任意の順序でデータベースに到着する可能性があるにもかかわらず、ユーザーはトランザクションが順番に実行されると信じてしまう可能性があります。

一見すると、以下のプログラムでは T1 と T2 が順番に呼び出されていますが、これらの関数がノンブロッキングであり、すぐに次の形式で結果を返します。 約束の場合、呼び出しの順序は、呼び出しがデータベースに入った瞬間によって決まります。

result1 = T1() // 実際の結果は約束です
結果 2 = T2()

アトミック性が必要で (つまり、すべての操作を完了するか中止する必要がある)、順序が重要な場合は、操作 T1 と T2 を XNUMX つのトランザクション内で実行する必要があります。

アプリケーションレベルのシャーディングはアプリケーションの外に移動可能

シャーディングは、データベースを水平に分割する方法です。 データを自動的に水平分割できるデータベースもあれば、それができない、またはあまり得意でないデータベースもあります。 データ アーキテクト/開発者は、データがどのようにアクセスされるかを正確に予測できる場合、この作業をデータベースに委任する代わりに、ユーザー空間に水平パーティションを作成できます。 このプロセスは「アプリケーションレベルのシャーディング」と呼ばれます。 (アプリケーションレベルのシャーディング).

残念ながら、この名前により、シャーディングがアプリケーション サービスに存在するという誤解が生じることがよくあります。 実際、データベースの前に別のレイヤーとして実装できます。 データの増加とスキーマの反復によっては、シャーディング要件が非常に複雑になる可能性があります。 一部の戦略では、アプリケーション サーバーを再デプロイすることなく反復できる機能からメリットが得られる場合があります。

アプリケーションサーバーとシャーディングサービスを分離したアーキテクチャの例

シャーディングを別のサービスに移行すると、アプリケーションを再デプロイする必要なく、さまざまなシャーディング戦略を使用できる機能が拡張されます。 フィテッセ は、アプリケーション レベルでのそのようなシャーディング システムの例です。 Vitess は MySQL に水平シャーディングを提供し、クライアントが MySQL プロトコル経由で MySQL に接続できるようにします。 システムは、相互について何も知らない異なる MySQL ノードにデータをセグメント化します。

自動インクリメントは危険な可能性があります

AUTOINCREMENT は主キーを生成する一般的な方法です。 データベースが ID ジェネレーターとして使用され、そのデータベースに識別子を生成するように設計されたテーブルが含まれる場合がよくあります。 自動インクリメントを使用して主キーを生成することが理想から程遠い理由はいくつかあります。

• 分散データベースでは、自動インクリメントは深刻な問題です。 ID を生成するには、グローバル ロックが必要です。 代わりに、UUID を生成できます。これには、異なるデータベース ノード間の対話は必要ありません。 ロックを使用した自動インクリメントは競合を引き起こし、分散状況での挿入のパフォーマンスを大幅に低下させる可能性があります。 一部の DBMS (MySQL など) では、マスター間レプリケーションを適切に構成するために、特別な構成とより細心の注意が必要な場合があります。 また、設定時に間違いを犯しやすく、記録の失敗につながります。
• 一部のデータベースには、主キーに基づいたパーティション化アルゴリズムがあります。 ID が連続すると、予測できないホット スポットが発生し、一部のパーティションで負荷が増加する一方、他のパーティションはアイドル状態のままになる可能性があります。
• 主キーは、データベース内の行にアクセスする最も速い方法です。 レコードを識別するためのより良い方法により、シーケンシャル ID を使用すると、テーブル内の最も重要な列が意味のない値で満たされた役に立たない列に変わる可能性があります。 したがって、可能な限り、グローバルに一意で自然な主キー (ユーザー名など) を選択してください。

アプローチを決定する前に、自動インクリメント ID と UUID がインデックス作成、パーティショニング、シャーディングに与える影響を考慮してください。

古いデータは役立つ場合があり、ロックする必要はありません

マルチバージョン同時実行制御 (MVCC) は、上で簡単に説明した一貫性要件の多くを実装します。 一部のデータベース (Postgres、Spanner など) は、MVCC を使用して、データベースの古いバージョンであるスナップショットをトランザクションに「フィード」します。 スナップショット トランザクションは、一貫性を確保するためにシリアル化することもできます。 古いスナップショットから読み取ると、古いデータが読み取られます。

わずかに古いデータを読み取ると、データから分析を生成したり、おおよその集計値を計算したりする場合などに便利です。

レガシー データを操作することの最初の利点は、待ち時間が短いことです (特にデータベースが異なる地域に分散している場合)。 XNUMX つ目は、読み取り専用トランザクションにはロックがないことです。 これは、古いデータを処理できる限り、大量の読み取りを行うアプリケーションにとって大きな利点です。

アプリケーション サーバーは、最新バージョンが太平洋の反対側で利用可能な場合でも、5 秒古いデータをローカル レプリカから読み取ります。

DBMS は古いバージョンを自動的に削除し、場合によっては、要求に応じてこれを実行できるようにします。 たとえば、Postgres ではユーザーが次のことを行うことができます。 VACUUM 要求に応じて、また定期的にこの操作を自動的に実行します。 Spanner はガベージ コレクターを実行して、XNUMX 時間より古いスナップショットを削除します。

あらゆる時間ソースは歪みの影響を受けます

コンピューター サイエンスにおける最大の秘密は、すべてのタイミング API が嘘をついているということです。 実際、私たちの機械は正確な現在時刻を知りません。 コンピューターには、時間を刻むために使用される振動を発生する水晶振動子が含まれています。 ただし、精度が十分ではなく、正確な時刻より進んでいたり遅れたりする可能性があります。 シフトは 20 日あたり XNUMX 秒に達する場合があります。 したがって、コンピュータの時刻をネットワークの時刻と定期的に同期する必要があります。

NTP サーバーは同期に使用されますが、同期プロセス自体はネットワーク遅延の影響を受けます。 同じデータセンター内の NTP サーバーとの同期でも時間がかかります。 パブリック NTP サーバーを使用すると、さらに大きな歪みが生じる可能性があることは明らかです。

原子時計とそれに相当する GPS は現在時刻を測定するのに適していますが、高価で複雑な設定が必要なため、すべての車に搭載できるわけではありません。 このため、データセンターでは階層型アプローチが使用されます。 アトミック クロックや GPS クロックは正確な時間を示し、その後、セカンダリ サーバーを通じて他のマシンにブロードキャストされます。 これは、各マシンが正確な時間から一定のオフセットを経験することを意味します。

アプリケーションとデータベースが (異なるデータセンターにない場合でも) 異なるマシン上に配置されていることが多いという事実により、状況はさらに悪化します。 したがって、時間は、異なるマシンに分散された DB ノードだけで異なるわけではありません。 アプリケーションサーバーでも異なります。

Google TrueTime はまったく異なるアプローチを採用しています。 ほとんどの人は、Google のこの方向への進歩は、原子時計と GPS 時計への平凡な移行によって説明されると信じていますが、これは全体像の一部にすぎません。 TrueTime の仕組みは次のとおりです。

• TrueTime は、GPS と原子時計という XNUMX つの異なるソースを使用します。 これらの時計には、相関関係のない故障モードがあります。 [詳細は5ページを参照] ここで — 約翻訳）、そのため、それらを併用すると信頼性が高まります。
• TrueTime には珍しい API があります。 測定誤差と不確実性が組み込まれた間隔として時間を返します。 実際の瞬間は、間隔の上限と下限の間のどこかにあります。 Google の分散データベースである Spanner は、現在時刻が範囲外であると言えるまで待機するだけです。 この方法では、特にマスターの不確実性が高い場合にシステムに多少の遅延が生じますが、グローバルに分散された状況でも正確性が保証されます。

Spanner コンポーネントは TrueTime を使用します。ここで、TT.now() は間隔を返します。そのため、Spanner は、現在時刻が特定の時点を通過したと確信できる時点までスリープするだけです。

現在時刻の決定精度が低下すると、Spanner の操作時間が長くなり、パフォーマンスが低下します。 このため、完全に正確な時計を入手することは不可能であっても、可能な限り最高の精度を維持することが重要です。

遅れには多くの意味がある

遅延とは何かについて十数人の専門家に質問すると、おそらく異なる答えが得られるでしょう。 DBMS では、遅延は「データベース遅延」と呼ばれることが多く、クライアントが認識する遅延とは異なります。 実際には、クライアントはネットワーク遅延とデータベース遅延の合計を監視します。 増大する問題をデバッグする場合、レイテンシーの種類を分離する機能が重要です。 メトリクスを収集して表示するときは、常に両方のタイプに注目するようにしてください。

パフォーマンス要件は特定のトランザクションに対して評価する必要があります

DBMS のパフォーマンス特性とその制限は、書き込み/読み取りのスループットと待ち時間の観点から指定される場合があります。 これは主要なシステム パラメータの概要を示していますが、新しい DBMS のパフォーマンスを評価する場合、より包括的なアプローチは、重要な操作 (各クエリおよび/またはトランザクションごと) を個別に評価することです。 例:

• 関連テーブルの指定された制約と行パディングを使用して、テーブル X (50 万行) に新しい行を挿入するときの書き込みスループットと待機時間。
• 平均友達数が500人の場合、特定のユーザーの友達の友達の表示が遅れる。
• ユーザーが 100 時間あたり X エントリを持つ他の 500 人のユーザーをフォローしている場合に、ユーザーの履歴から上位 XNUMX のエントリを取得するまでの待ち時間。

データベースがパフォーマンス要件を満たしていると確信できるまで、評価と実験にはこのような重大なケースが含まれる場合があります。 同様の経験則により、レイテンシ メトリクスを収集して SLO を決定するときにもこの内訳が考慮されます。

各操作のメトリクスを収集するときは、高いカーディナリティに注意してください。 ログ、イベント収集、または分散トレースを使用して、強力なデバッグ データを取得します。 記事では「レイテンシーをデバッグしたいですか?» 遅延のデバッグ方法に慣れることができます。

ネストされたトランザクションは危険な可能性があります

すべての DBMS がネストされたトランザクションをサポートしているわけではありませんが、ネストされたトランザクションをサポートしている場合、そのようなトランザクションによって予期せぬエラーが発生する可能性があり、そのエラーは必ずしも検出が容易ではありません (つまり、何らかの異常があることが明らかである必要があります)。

ネストされたトランザクションを検出してバイパスできるクライアント ライブラリを使用すると、ネストされたトランザクションの使用を回避できます。 ネストされたトランザクションを放棄できない場合は、ネストされたトランザクションが原因で完了したトランザクションが誤って中止されるという予期せぬ状況を避けるために、その実装に特別な注意を払ってください。

トランザクションを異なるレイヤーにカプセル化すると、予期しないネストされたトランザクションが発生する可能性があり、コードの可読性の観点から、作成者の意図を理解することが困難になる可能性があります。 次のプログラムを見てください。

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

上記のコードの出力はどうなるでしょうか? 両方のトランザクションをロールバックしますか、それとも内側のトランザクションだけをロールバックしますか? トランザクションの作成をカプセル化する複数のライブラリ層に依存するとどうなるでしょうか? このようなケースを特定して改善することはできるでしょうか?

複数の操作を含むデータ層を想像してください (例: newAccount) はすでに独自のトランザクションに実装されています。 これらを、独自のトランザクション内で実行される上位レベルのビジネス ロジックの一部として実行するとどうなるでしょうか? この場合の分離性と一貫性はどうなるのでしょうか?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

このような終わりのない質問に対する答えを探すのではなく、ネストされたトランザクションを避ける方が良いでしょう。 結局のところ、データ層は、独自のトランザクションを作成しなくても、高レベルの操作を簡単に実行できます。 さらに、ビジネス ロジック自体は、トランザクションの開始、トランザクションに対する操作の実行、トランザクションのコミットまたは中止を行うことができます。

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

トランザクションはアプリケーションの状態に関連付けられるべきではありません

場合によっては、トランザクションでアプリケーションの状態を使用して、特定の値を変更したり、クエリ パラメーターを微調整したくなることがあります。 考慮すべき重要なニュアンスは、適用の正しい範囲です。 ネットワークに問題が発生した場合、クライアントはトランザクションを再開することがよくあります。 トランザクションが他のプロセスによって変更されている状態に依存している場合、データ競合の可能性によっては間違った値が選択される可能性があります。 トランザクションでは、アプリケーション内のデータ競合状態のリスクを考慮する必要があります。

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

上記のトランザクションは、最終結果に関係なく、実行されるたびにシーケンス番号をインクリメントします。 ネットワークの問題によりコミットが失敗した場合、再試行するとリクエストは別のシーケンス番号で実行されます。

クエリ プランナーはデータベースについて多くのことを教えてくれます

クエリ プランナは、データベース内でクエリがどのように実行されるかを決定します。 また、リクエストを送信する前に分析し、最適化します。 プランナーは、自由に使える信号に基づいて、考えられる推定値をいくつか提供することしかできません。 たとえば、次のクエリに最適な検索方法は何ですか?

SELECT * FROM articles where author = "rakyll" order by title;

結果は次の XNUMX つの方法で取得できます。

• フルテーブルスキャン: テーブル内の各エントリを調べて、一致する著者名を持つ記事を返し、それらを並べ替えることができます。
• インデックススキャン: インデックスを使用して、一致する ID を検索し、それらの行を取得し、並べ替えることができます。

クエリ プランナーの仕事は、どの戦略が最適かを判断することです。 クエリ プランナーの予測機能は限られていることを考慮する価値があります。 これは間違った決定につながる可能性があります。 DBA や開発者は、これらを使用して、パフォーマンスの低いクエリを診断し、微調整することができます。 DBMS の新しいバージョンではクエリ プランナーを構成でき、新しいバージョンによってパフォーマンスの問題が発生した場合にデータベースを更新するときに自己診断が役立ちます。 遅いクエリのログ、レイテンシの問題レポート、または実行時間の統計は、最適化が必要なクエリを特定するのに役立ちます。

クエリ プランナーによって提示される一部のメトリックは、ノイズの影響を受ける可能性があります (特に、レイテンシや CPU 時間を見積もる場合)。 スケジューラに追加すると、実行パスを追跡および追跡するためのツールが追加されます。 これらを使用すると、そのような問題を診断できます (残念ながら、すべての DBMS がそのようなツールを提供しているわけではありません)。

オンライン移行は困難だが可能

オンライン マイグレーション、ライブ マイグレーション、またはリアルタイム マイグレーションとは、ダウンタイムやデータ破損を発生させずに、あるデータベースから別のデータベースに移行することを意味します。 移行が同じ DBMS/エンジン内で発生する場合、ライブ マイグレーションの実行が容易になります。 パフォーマンスやスキーマの要件が異なる新しい DBMS に移行する必要がある場合、状況はさらに複雑になります。

さまざまなオンライン移行モデルがあります。 ここにその XNUMX つを示します。

• 両方のデータベースで二重入力を有効にします。 この段階の新しいデータベースにはすべてのデータが含まれているわけではなく、最新のデータのみを受け入れます。 これを確認したら、次のステップに進むことができます。
• 両方のデータベースからの読み取りを有効にします。
• 読み取りと書き込みが主に新しいデータベースで実行されるようにシステムを構成します。
• 古いデータベースからのデータの読み取りを継続しながら、古いデータベースへの書き込みを停止します。 この段階では、新しいデータベースにはまだデータがいくつかありません。 これらは古いデータベースからコピーする必要があります。
• 古いデータベースは読み取り専用です。 不足しているデータを古いデータベースから新しいデータベースにコピーします。 移行が完了したら、パスを新しいデータベースに切り替え、古いデータベースを停止してシステムから削除します。

詳細については、お問い合わせいただくことをお勧めします статьеでは、このモデルに基づいた Stripe の移行戦略について詳しく説明します。

データベースの大幅な増加には予測不可能性の増加が伴います

データベースの成長により、その規模に関連した予測不可能な問題が発生します。 データベースの内部構造について知れば知るほど、データベースがどのように拡張されるかをより正確に予測できるようになります。 ただし、まだ予測できない瞬間もあります。
ベースが拡大するにつれて、データ量とネットワーク帯域幅の要件に関する以前の仮定や期待が時代遅れになる可能性があります。 このとき、潜在的な問題を回避するために、大規模な設計の見直し、大規模な運用改善、展開の再検討、または他の DBMS への移行の問題が生じます。

ただし、既存のデータベースの内部構造に関する優れた知識だけが必要であるとは考えないでください。 新しい秤は、新たな未知をもたらします。 予測できない問題点、不均一なデータ分散、予期しない帯域幅とハードウェアの問題、増加し続けるトラフィックと新しいネットワーク セグメントにより、データベースのアプローチ、データ モデル、展開モデル、データベース サイズの再考が必要になります。

...

この記事の公開を考え始めた時点で、元のリストにはすでにさらに XNUMX つの項目がありました。 そしたらすごい数が来たよ 新しいアイデア 他にカバーできるものについて。 したがって、この記事では、最大限の注意が必要な、あまり目立たない問題について触れます。 ただし、これはこのトピックがすべて終わったことを意味するものではなく、今後の資料でこのトピックに戻ることはなく、現在の資料に変更を加えるつもりはありません。

PS

私たちのブログもお読みください:

• «データベースと Kubernetes (レビューとビデオ レポート)";
• «分散トレーシング: 私たちのやり方は間違っていました";
• «サービス メッシュ: すべてのソフトウェア エンジニアが最も注目されているテクノロジについて知っておくべきこと'。

出所： habr.com