データベース：タイプとアプローチの概要。Yandexレポート

これは、Yandex.Tutorialのバックエンド開発者であるTatyanaDenisovaによる講演の概要です。データベースの種類、覚えておくべき重要な機能、データを操作する際にシステムの特性とスケーリング計画を考慮する方法、特定の問題を解決するために掘り下げる必要のあるトピックについて学習します。また、バグの場合に、データベースでの作業が問題の原因であるかどうかを判断する方法（もしそうであれば、どの方向に掘り下げるか）。







-正確には何について話しますか？プリミティブな選択と結合についてではありません-あなたのほとんどはすでにそれらについて知っていると思います。



データベースの実際の使用法、直面する可能性のある問題、およびバックエンド開発者として知っておく必要のあることについて説明します。たくさんの情報があります、ここに内容があります。これらの各ポイントの詳細を直接完全に知る必要はありませんが、このポイントが存在することを知る必要があります。







また、構造を構築してデータを保存するタスクがあるときに、選択するデータモデルとその保存方法を理解できるように、どのような問題が解決されるかを知る必要があります。または、問題がある、データベースがダウンしている、遅い、またはデータに問題がある、不整合があることがわかったとします。次に、どこを掘るかを理解する必要があります。つまり、どの概念が存在し、どちらの側から問題に取り組むかを知る必要があります。







まず、データについて説明します。とにかくこれは何ですか？私たちの周りにはたくさんの事実、たくさんの情報がありますが、それらが何らかの形で収集されるまで、それらは私たちにとって役に立たないものです。それらを収集、構築、保存します。そして、データと呼ばれるのはこの格納された構造であり、それを格納するのはデータベースと呼ばれます。しかし、このデータがどこかで収集されている限り、基本的に私たちにとっても役に立ちません。したがって、データベースの上にレイヤー（DBMS）があります。これにより、データを取得、保存、分析することができます。したがって、受け取ったデータを、ユーザーにすでに表示できる情報に変換します。ユーザーは知識を受け取り、それを適用します。







情報と事実を構造化し、それらをどのような形式のデータで、どのモデルで保存するかについて説明します。そして、多くのユーザーが同時にデータにアクセスして正しい結果を得ることができるようにそれらを取得する方法。これにより、適用する最終的な知識が真実で正しいものになります。





まず、リレーショナルデータベースについて説明します。リレーショナルモデルは多くの人に馴染みがあると思います。これは、テーブルのタイプとテーブル間の関係のモデルです。ユーザー間でデータやメッセージを書き込むメッセンジャーがあると想像してみてください。それらすべてを、幅の広い1つの大きなボリュームのあるテーブルに書き込むことができます。ここには、誰から、誰に、誰に、どのチャットで、多くの反復データがあります。そして、これらすべてをさまざまなテーブルに書き込むことができます。つまり、データを正規化し、それを3番目の通常の形式にすることができます。



スライドにはメモとリンクがあります。ここでは、すべての概念について深く掘り下げることはしません。なじみのない技術的な概念については話さないようにします。しかし、私が言うことはすべてスライドノートにあります。正規化を含め、リファレンスもあります。この概念に慣れていない場合は、それを読むことができます。







一般的に、正規化とは、データをより構造化することを目的として、データをテーブルに分割することです。たとえば、ユーザー、メッセンジャーチャット、メッセージのテーブルができました。この構造により、私たちが知っているユーザーやチャットからのメッセージがここに記録されます。つまり、データの整合性を保証します。私たちは常に全体像を収集できるという事実を保証します。しかし同時に、たとえば、メッセージテーブルにはIDのみ、識別子のみを格納します。したがって、データベースの全体的なサイズを縮小して、データベースを小さくします。したがって、このデータベースへの書き込みが容易になります。常に多くのテーブルに書き込む必要はありません。 IDスペシャリストと一緒に1つのテーブルに書き込むだけです。







正規化について話すと、非常にグラフィカルであるため、一般にシステムのビジョンが大幅に簡素化され、どのテーブル間にどのような関係があるかがすぐにわかります。



メッセンジャーにメッセージを書き込んでいて、そのようなユーザーがまだいない場合は、作成する必要があるため、データを書き込むときのエラーの数を減らします。しかし、最終的な全体像である一般的なデータは完全なままです。



データベースのサイズを小さくすることについてはすでに述べました。ユーザーに関するすべてのデータを毎回メッセージテーブルに書き込む必要はありません。プロファイルを表示するには、Userテーブルに移動するだけです。



また、依存関係に一貫性がないことについても警告しました。これらは他のテーブルのIDへの単なるリンクであり、識別子は1つのテーブル内の一意の値です。別の方法では、これらはプライマリキーと呼ばれ、これらのプライマリキーへのリンクがある場合、別のテーブル内のリンク自体は外部キーと呼ばれます。



この構造は、データを誤って削除することからも保護します。たとえば、メッセージがあるため、ユーザーを削除することはできません。これはとても小さいですが、セーフティネットです。



私たちは優れた構造を作り上げたように見えます。すべてが明確で、すべてが依存しており、すべてが不可欠です。他に何を扱う必要がありますか？







私たちが実際にそれを運用し、多くのユーザーがいて、それに応じて多くのメッセージがあると想像してみましょう。彼らは常に互いに通信します。メッセージテーブルで何が起こっているのですか？それは絶えず成長しています。また、データ以外を検索するには、常にすべてのメッセージを調べ、このユーザーからのものかどうか、このチャットであ​​るかどうかを確認してから、表示する必要があります。



当然、ユーザーが多いほど、メッセージも多くなり、検索クエリにかかる時間が長くなります。テーブル内のメッセージをすばやく検索できるソリューションが必要です。



このような場合、インデックスは検索を高速化するために使用されます。インデックスとの最も単純な関連付けは、本の内容です。本の中から情報を見つける必要がある場合は、本をめくるか、目次に移動することができます。インデックスは一種の目次です。



電話帳の良い例もあります。電話で文字をクリックすると、この文字で始まる姓を参照するとすぐにスローされます。データベースインデックスは非常によく似た方法で機能します。メッセージのあるテーブルと、このデータを取得する方法を見てみましょう。







データの取り扱いにご注意ください。テーブルにある行ではなく、一般的に。インデックスは、実行したクエリに基づいて作成されます。



主にチャットでリクエストを行う、つまり、このチャットに含まれるメッセージを確認するとします。チャット列に正確にインデックスを作成しましょう。データベースインデックスは別の構造です。テーブルはそれから独立しています。つまり、いつでもインデックスを削除して再構築でき、テーブルはこれに悩まされることはありません。



ここでは、選択した内容を確認し、列にインデックスを配置します。チャット11にはすでにいくつかのメッセージがあるため、エントリの数がすでにわずかに減少している別の構造があります。DBMSは、この小さなチャットテーブルでクイック検索を提供します。それはどのように行われますか？当然、検索は単純な検索ではありません。多くの高速検索アルゴリズムがあります。ほとんどのデータベースでデフォルトで使用されている最も一般的なアルゴリズムの1つを見ていきます。バランスの取れた木です。







それはどのように機能しますか？チャット番号があり、これは整数値であり、ツリーは次の原則に従って構築されます：ノードの左側にある値が少ないほど、ノードの右側にある値が多くなります。この構造は私たちに何を与えますか？このツリーの概要シートを見ると、下部にあるすべての値が並べられています。これは、生産性の向上に大きなプラスです。理由をお見せします。







たとえば、値を探しています。 1つの意味を検索するのは非常に簡単です。この値が大きいか小さいかに応じて、ツリーを下に移動するか、左、右に移動します。







たとえば、範囲を見つけたい場合は、それがどれほど単純で高速であるかを調べます。値に到達し、順序付けられた値に沿ってすでに葉のリンクをたどり、最後に移動します。







からとまでの範囲を定義する必要がある場合は、まったく同じことを行います。初期値を見つけて、リーフリンクをたどって最大値に到達します。私たちは一度だけ木を歩いた。とても便利で、とても速いです。



同様に、最大値と最小値を検索します。完全に左、完全に右に歩きます。注文リストもお送りします。つまり、すべてのチャットを順番に取得する必要がある場合は、最初のチャットに到達し、リーフを右端の値まで通過すると、順序付きリストが取得されます。この原則により、データベースはインデックステーブルで選択する必要のある行を非常に迅速に検索し、それらを返します。



ここで知っておくべき重要なことは何ですか？かっこいい構造のように思えます。次に、そのようなツリーに従って各列を作成し、検索します。なぜうまくいかないと思いますか？列ごとにツリーを作成すると、速度が向上しないのはなぜですか？ （...）



私たちの選択は本当にスピードアップします。ある値を調べる必要があるたびに、インデックスに移動し、そこに値自体へのリンクを見つけます。インデックスには通常、文字列自体ではなく、文字列への参照が正確に含まれています。そして、選択のためにそれは完全に機能します。ただし、テーブルデータを設定したり、データを更新または削除したりするとすぐに、これらすべてのツリーを再構築する必要があります。



実際、削除しても再構築はされませんが、このツリーが断片化されるだけで、多くの空の値が作成されます。空の値を持つ巨大なツリーがあります。しかし、これらのツリーが毎回再構築されるのは、更新と作成によるものです。その結果、このすべての構造に大きなオーバーヘッドが発生します。また、データをすばやくフェッチしてデータベースを高速化する代わりに、クエリの速度を低下させます。





他に知っておくべき重要なことは何ですか？データベースを操作するときは、データベースに存在するインデックスを調べて読んでください。各データベースには独自の実装があり、独自の異なるインデックスがあるためです。スピードアップするためのインデックスがあり、整合性を確保するためのインデックスがあります。最も単純なものの1つは、主キーだけです。これもユニークなインデックスです。また、データベースに関しては、データベースがどのように機能するか、どのように操作するかを確認してください。これは、最適なクエリを作成するのに役立つ種類の知識だからです。



データを挿入するときにインデックスを維持するオーバーヘッドに留意する必要があることについて説明しました。インデックスを作成するとき、それは非常に選択的でなければならないということを忘れました。どういう意味ですか？



この木を見てみましょう。インデックスがtruefalseに設定されている場合、左右に2つの巨大な木片が表示されることを理解しています。そして、私たちはせいぜいテーブルの50％を通過しますが、これは実際にはあまり効率的ではありません。最も異なる値を持つ列にインデックスを作成するのが最善です。これにより、選択がスピードアップします。



断片化について述べました。データを削除するときは、それを覚えておく必要があります。インデックスに含まれるデータが頻繁に削除される場合は、それをデフラグする必要があり、これも監視する必要があります。また、使用している列ではなく、そのデータの使用方法に基づいてインデックスを作成していることを理解することも重要です。また、インデックスを含むクエリは慎重に作成する必要があります。きちんとしたとはどういう意味ですか？リクエストを作成してデータベースに送信すると、データベースに直接送信されるのではなく、クエリスケジューラと呼ばれる特定のソフトウェアレイヤーに送信されます。



スケジューラーには、操作コストとそのコストに関する特定の対応テーブルがあります。 PostgreSQLの例には、データやテーブルに関する情報を収集する特別な技術テーブルがあります。プランナーは、どのクエリがあり、どのデータがpg_statテーブルに格納されているかを確認します。これは、テーブルにあるデータの量、テーブル内の列、テーブル上のインデックスに関する一般的な情報を格納する単なるテーブルです。これに基づいて、彼はクエリの実行計画を調べ、クエリにかかる計画に応じて時間を計算し、最適な計画を選択します。





クエリの予測実行時間を確認する場合は、Explain操作を使用できます。実際の実行が必要な場合は、Explainanalyzeを使用できます。違いは何ですか？私が言ったように、スケジューラーは最初に各操作の推定時間に基づいて実行時間を計算します。そのため、実際の時間はマシンやデータの性質によって異なる場合があります。したがって、実際の実行が必要な場合は、もちろんExplainanalyzeを使用することをお勧めします。



このスライドで例を見ることができます。これは、インデックスを持つ列に基づくクエリがスキャンインデックスを使用せず、テーブル全体を完全にスキャンする場合があることを示しています。これは、インデックスの選択性が低く、プランナーがテーブルに対するフルスキャンクエリの方が収益性が高いと考えている場合に発生します。



メッセンジャーがあり、チャットリストに、たとえばチャット名や未読メッセージの数を表示したいとします。チャットを開くたびに、すべてのチャットのすべてのデータを再計算すると、非常に不採算になります。







そのようなことがあります-非正規化。これは、使用された最もホットなデータのコピー、または必要なデータの事前計算であり、それをテーブルに保存します。







これは、ユーザーとチャットの関係がどのように見えるかを示しています。つまり、ユーザーIDとチャットIDに加えて、チャット名、チャットログ、および未読メッセージの数を簡単に保存します。したがって、毎回、すべてのテーブルをロードして選択を行い、これらすべてを再計算する必要はありません。







非正規化のプラスは何ですか？データサンプリングプロセスをスピードアップします。つまり、私たちの選択は可能な限り迅速に行われ、ユーザーに可能な限り迅速に回答を提供します。



難しいのは、新しいデータを追加するたびに、これらすべての列を再計算する必要があり、エラーが発生する可能性が非常に高いことです。つまり、選択がはるかに単純になり、常に参加する必要がない場合、トリガーをそこでハングさせ、再計算し、何も忘れないようにする必要があるため、更新と作成は非常に面倒になります。



したがって、非正規化は本当に必要な場合にのみ使用する必要があります。そして、このロジック全体に従ったので、最初にデータを正規化し、それをどのように使用するかを確認し、インデックスを調整する必要があります。うまく機能していないと思われるクエリがある場合は、非正規化する前にExplainを確認してください。それらが実際にどのように実行されるか、スケジューラーがどのように実行するかを調べてください。そしてその時だけ、あなたがすでに非正規化がまだ必要であるという結論に達したとき、あなたはそれをすることができます。しかし、そのような慣行があり、データの非正規化は実際のプロジェクトでよく使用されます。



さらに進んでみましょう。データを適切に構造化し、データモデルを選択し、収集し、すべてを非正規化し、インデックスを作成したとしても、ITの世界では多くの問題が発生する可能性があります。



ソフトウェアに障害が発生したり、電源が切れたり、ハードウェアまたはネットワークに障害が発生したりする可能性があります。 2番目のクラスの問題もあります。多くのユーザーがデータベースを同時に使用しています。同じデータを同時に更新できます。私たちはこれらすべての問題を解決できなければなりません。



これが何であるかの特定の例を見てみましょう。







会議室を予約したいユーザーが2人いると想像してみてください。ユーザー1は、この時点で会議室が空いていることを確認し、予約を開始します。彼のウィンドウが開き、彼は私の同僚のどれに電話するかを考えます。彼が考えている間、ユーザー2は会議室が空いていることを確認し、自分用の編集ウィンドウを開きます。



その結果、ユーザー1がこのデータを保存したとき、彼は去り、すべてが正常であると考え、会議室が予約されました。しかし、この時点で、ユーザー2が自分のデータを上書きし、チャットルームがユーザー2に割り当てられていることが判明しました。これはデータ競合と呼ばれます。そして、私たちはこれらの対立を人々に示し、どういうわけかそれらを解決することができなければなりません。再録音するのはこの場所です。







どうやってするの？ユーザー1が考えている間、会議室をしばらくブロックするだけです。彼がデータを保存した場合、ユーザー2にこれを許可しません。彼がデータをリリースして保存しなかった場合、ユーザー2は会議を予約できます。映画のチケットを購入すると、同様の写真が表示されます。チケットの支払いには15分が与えられます。それ以外の場合は、チケットを受け取って支払うことができる他の人に再び提供されます。



これは、私たちの業務が完全に実行されることを保証することがいかに重要であるかを示す別の例です。銀行口座1から口座2に送金したいとします。現時点では3つのオペレーションがあります。十分な資金があることを確認し、最初のアカウントから資金を差し引いて、2番目のアカウントに預けます。これらの瞬間のいずれかで私が失敗した場合、何かがうまくいかないことは明らかです。



たとえば、この段階でデータを読み取る別のトランザクションが発生した場合、アカウントの資金が不足し、他の操作を実行できなくなります。たとえば、2番目の瞬間に問題が発生した場合、1つのアカウントからお金を引き出しましたが、2番目のアカウントにはお金を入れませんでした。その結果、私の銀行口座、すべての私の口座がいくらか削減されることが判明しました。このお金は決して返還することはできません。



このような問題を解決するために、トランザクションの概念があります。これは、3つの操作すべてを同時にアトミックに統合的に実行することです。



データベースはどのようにそれを行いますか？これらすべての変更を特定のログに書き込み、トランザクションがコミットされたときにのみ適用します。したがって、これらすべての操作が全体として実行されるか、まったく実行されないことを保証します。



この時点で障害が発生した場合、最初のアカウントからお金が差し引かれることはなく、したがって、それを失うことはありません。



トランザクションには4つのプロパティがあり、それらには4つの要件があります。これらは、アトミック性、一貫性、分離、および耐久性です。データの原子性、一貫性、分離、および永続性です。これらのプロパティは何ですか？

• アトミック性またはアトミック性は、実行している操作が完全に完了し、部分的に実行されないことを保証します。したがって、データベース内のデータの全体的な一貫性が操作の前後の両方になるようにします。
• Consistency — -, . (Integrity). - , , Integrity Error, : , . . — , .
  
  
  
  , , , , . . .
  
  
  
  
• Isolation — , . . , .
• Durability — , , , , .

断熱についてもう少し話しましょう。トランザクションの分離は非常に高価なプロパティであり、多くのリソースがそれに費やされます。そのため、データベースにはいくつかの分離レベルがあります。問題が何であるかを見てみましょう。これに基づいて、問題を解決する方法についてはすでに説明します。



問題には、更新の喪失、ダーティリード、繰り返し不可のリード、ゴーストリードの4つの主要なクラスがあります。よく見てみましょう。



失われた更新は、ユーザー1がデータを上書きし、それについて知らない場合のチャットルームの例のようなものです。つまり、このユーザーが変更したデータをブロックしなかったため、上書きされました。







ダーティリードの問題は、ユーザーが別のユーザーによる一時的な変更を確認したときに発生します。変更は、ロールバックするか、単に一時的に行うことができます。







この場合、ユーザー1はデータベースに何かを書き込みました。当時のユーザー2は、そこから何かを計算し、このデータに基づいて分析を構築していました。また、ユーザー1はエラーと不整合を検出し、このデータをロールバックしています。したがって、ユーザー2が書き留めた分析は、彼が計算したデータがもう存在しないため、偽物であり、正しくありません。また、この問題を解決できる必要があります。



繰り返し不可能な読み取りとは、1つの長いトランザクションを持つユーザーがいる場合です。彼はデータベースからデータをフェッチし、この時点でユーザー2は同じデータの一部を変更します。







この場合、ユーザー1は自分が持っているデータへの変更をブロックしていないことがわかります。そして、彼自身がデータのスナップショットを受け取ったという事実にもかかわらず、彼が同じ選択を繰り返し要求されたとき、彼はこれらの行で異なる値を取得することができます。したがって、それは競合、それが書き込むデータの不一致を持ちます。







ユーザー2がデータを追加または削除した場合にも、同様の問題が発生する可能性があります。つまり、ユーザー1が要求を行い、同じデータを2回要求した後、行があったか消えました。この場合、トランザクションのフレームワーク内で、それらをどう処理するか、どのように処理するかを理解することは非常に困難です。







これらの問題を解決するために、4つの分離レベルがあります。最初の最低レベルは、コミットされていない読み取りです。これは、PostgreSQLがロックなしと説明しているものです。データの読み取りまたは書き込みを行う場合、他のユーザーによるそのデータの読み取りまたは書き込みをブロックしません。変更をブロックしていないことがわかりました。これらの4つの問題はすべて引き続き発生する可能性があります。しかし、この分離レベルは何を防ぎますか？これにより、データベースに到着するすべてのトランザクションが確実に実行されます。 2人のユーザーが同じデータで同時にクエリの実行を開始した場合、これらのトランザクションは両方とも順番に実行されます。



これは何に役立ちますか？この分離レベルが実際に使用されることはめったにありませんが、たとえば、大規模な分析クエリがあり、2番目のクエリを読み取って、分析がどの段階にあるか、どのデータがすでに記録されているか、どのデータが記録されていないかを確認する場合に役立ちます。次に、2番目の要求（デバッグ、デバッグ、チェック用）は、この分離レベルで実行されます。そして、彼は最初の分析クエリのすべての変更を確認します。これは最終的にロールバックできます。またはロールバックされませんが、現時点ではシステムの状態を確認できます。







コミット済みの読み取り、コミット済みデータの読み取り。この分離レベルは、PostgreSQLやOracleを含むほとんどのリレーショナルデータベースでデフォルトで使用されます。ダーティデータを読み取らないようにします。つまり、別のトランザクションが最初のトランザクションの中間段階を見ることはありません。利点は、小さくて短いクエリで非常にうまく機能することです。データの一部、不完全なデータが表示されることは決してありません。たとえば、部門全体の給与を引き上げた場合、一部の人だけが引き上げられた時期はわかりません。2番目の部分はインデックスなしの給与で座っています。そのような状況が発生した場合、アナリストがすぐに「移動」するのは当然のことです。



この分離レベルは何から保護しませんか？選択したデータが変更される可能性があるという事実から保護するものではありません。小さなクエリの場合、この分離レベルで十分ですが、大規模で長いクエリ、複雑な分析の場合は、もちろん、テーブルをロックするより複雑なレベルを使用できます。



繰り返し可能な読み取り分離レベルは、私たちがあなたと話し合った最初の3つの問題から保護します。これと、チャットルームを再録音したときに失われた更新。ダーティ読み取り-コミットされていないデータの読み取り。そして、この繰り返し不可能な読み取り-他のトランザクションによって更新されたデータの読み取り。







それはどのように提供されますか？テーブルをロックする、つまり選択をロックする。選択をトランザクションに取り込むと、データのスナップショットのように見えます。また、現時点では、このデータのスナップショットを使用している間は、他のユーザーの変更は確認されていません。欠点は、データをブロックするため、データを処理できる並列リクエストが少なくなることです。これは非常に重要な側面です。そして、一般的に、なぜこれほど多くの分離レベルがあるのですか？



レベルが高いほど、データベースを並行して操作できるブロックが多くなり、ユーザーが少なくなります。各トランザクションには、変更できないデータの特定のスナップショットが表示されます。ただし、新しいデータが表示される場合があります。したがって、この分離レベルでは、選択に適した新しいデータの出現から私たちを救うことはできません。



もう1つの分離レベルがあります-シリアル化。これはしばしば注文と呼ばれます。これは、テーブルの完全なデータロックです。テーブルをロックしているため、テーブルへの書き込みを許可しないため、ファントム読み取り、つまり、追加または削除したデータのみの読み取りから節約できます。そして、私たちは私たちの要求を総合的に満たします。







これは、精度とデータの整合性が重要である複雑で大規模な分析クエリに非常に役立ちます。ある時点でユーザーデータを読み取った後、新しい統計が別のテーブルに表示され、同期していないことが判明したことはわかりません。



これは最高の分離レベルです。ロックの数が最も多く、クエリの並列化が可能な限り少なくなっています。



トランザクションについて知っておくべきことは何ですか？それらはDBMSレベルで実装されており、クエリを正しく作成し、正しく形成するだけでデータの一貫性が保たれるため、私たちの生活が簡素化されます。また、ユーザーが使用するデータを正確にブロックします。どこでもすべてをブロックするのは悪いことだということを心に留めておく必要があります。使用しているシステムと、誰がどれだけ読み取り/書き込みを行うかによって、分離のレベルが異なります。ミスを犯す可能性のある最速のシステムが必要な場合は、最小の分離レベルを選択できます。データの一貫性を確保する必要のある銀行システムがある場合、すべてが実行され、何も失われません。もちろん、最大の分離レベルを選択する必要があります。



データベースを構造化する方法と何が起こり得るかを理解する上で、すでにかなりの進歩を遂げています。さらに進んでみましょう。



1つのデータベースを保存するのはどれほど安全ですか。確かに安全ではありません。彼女に何かが起こった場合、私たちはすべてのデータを失います。バックアップがある場合はロールできますが、システムのダウンタイムが発生します。ネットワークが故障したり、ノードが使用できなくなったりすると、システムはダウンタイム中にしばらくアイドル状態になります。



これはどのように解決できますか？そのような概念があります-複製。これは、他のノードやサーバーへのデータベースの複製です。







これはまさに完全な複製であり、データベースのコピーです。このメカニズムをどのように使用できますか？



まず、データベースに何かが起こった場合、リクエストをデータベースの別のコピーにリダイレクトできます。これは原則として論理的です。これがメインアプリケーションです。他にどのようにこれを使用できますか？



ユーザーがサーバーから遠く離れていると想像してみましょう。最大数のユーザーをカバーし、可能な限り迅速にリクエストを送信できるようにサーバーを分散できます。これらの各サーバーには他のサーバーと同じコピーがありますが、リクエストはユーザーにすばやく返されます。







もう1つの非常に一般的な使用法は、負荷分散です。データの同一のコピーがあるため、頭からではなく、1つのデータベースからではなく、異なるデータベースから読み取ることができます。したがって、サーバーをオフロードします。







OLTPクエリとOLAPクエリの概念もあります。それは何ですか？ OLTP-短いトランザクションクエリ。 OLAPは長期的な分析です。これは、私たちが大規模な結合、大規模な選択を行うときです。すべてをマージします。この時点ですべてのデータがロックされているため、変更がなく、データベースが完成していることが非常に重要です。



このような状況では、データベースの別のコピーで分析を行うことができます。したがって、ユーザーに影響を与えることはありません。ユーザーはデータベースにエントリを作成することもできます。そうすると、これらのエントリがコピーに追加されます。







データベースのコピーを正しく配布するために、マスターノードとスレーブノードであるマスターとスレーブの概念が導入されています。スレーブは、レプリカまたはフォロワーと呼ばれることがよくあります。マスター-ユーザー、アプリケーションが書き込むノード。マスターはすべての変更を適用し、変更のログを保持して、このログをスレーブに送信します。スレーブはユーザーからの変更を受け入れませんが、マスターからのログへの変更のみを適用します。マスターは毎回コピーを送信するのではなく、変更を送信することに注意してください。スレーブはこれらの変更をロールオーバーし、マスターと同じデータのコピーを受け取ります。



複製されたシステムの非常に重要なパラメータは、要求が同期的または非同期的に実行されることです。同期リクエストとは何ですか？これは、マスターが同期レプリカと同期スレーブに要求を送信し、スレーブが「はい、承諾しました」と言うのを待って、マスターが確認を返すときです。そうして初めて、マスターはユーザーに答えを返します。レプリカが非同期の場合、マスターはレプリカにリクエストを送信しますが、すぐにユーザーに「それだけです、書き留めました」と伝えます。それがどのように機能するか見てみましょう。







マスターにデータを書き込んだユーザーがいます。マスターはそれらを2つのレプリカに送信し、同期レプリカからの応答を待ち、すぐにユーザーに応答しました。非同期レプリカが記録され、マスターに「はい、大丈夫です。データが書き込まれます」と言われました。







このような階層、マスターとスレーブに関しては、1つまたは複数のヘッドを持つことができます。マスターノードが1つある場合、それに書き込むのは非常に便利ですが、同期レプリカから読み取ることができます。なぜ正確に同期からですか？同期レプリカは、データが最大の精度で最新であることを保証するためです。



ログからの操作であるデータにクエリを適用する場合も時間がかかります。したがって、受信したいデータの100％の精度が重要である場合は、マスターで選択するために、読み取りに行く必要があります。データがわずかに遅れて到着する可能性があることに問題がない場合は、同期スレーブから読み取ることができます。データの関連性にまったく批判的でない場合は、非同期レプリカからも含めて読み取ることができます。これにより、マスターと同期レプリカを要求からアンロードできます。



レプリケーションには複数のマスターを含めることもできます。さまざまなアプリケーションがさまざまなヘッドに書き込むことができ、これらのマスターは相互の競合を解決します。







このようなデータを使用する非常に簡単な例は、あらゆる種類のオフラインアプリケーションです。たとえば、電話にカレンダーがあります。ネットワークから切断し、カレンダーにイベントを記録しました。この場合、ローカルストレージである電話はマスターです。データ自体が保存されており、マスターネットワークが表示されると、ローカルコピーとサーバー上のコピーが競合を解決し、このデータを結合します。



これは、そのような複製の非常に単純な例です。オンラインドキュメントの共同編集や、ネットワークを失う可能性が非常に高い場合によく使用されます。







マスターレスレプリケーションも存在します。それは何ですか？これはレプリケーションであり、クライアント自体がほとんどのレプリカにデータを送信し、ほとんどのレプリカからもデータを読み取ります。ここでは、中央のレプリカが読み取りと更新の共通部分であることがわかります。



つまり、データを読み取るたびに、データが最も関連性の高いレプリカの少なくとも1つにアクセスすることを保証します。そして、それらの間で、レプリカは、レプリカ間の変更と競合のメインログと情報を交換するためのメカニズムを構築します。この場合、実装されるのはファットクライアントであることがよくあります。別のレプリカよりも新しい変更を含むデータをレプリカから受信した場合は、データを別のレプリカに送信するか、競合を解決します。







レプリケーションについて知っておくべき重要なことは何ですか？レプリケーションの主なポイントは、システムの障害耐性、サーバーの高可用性です。データベースに何が起こっても、システムが利用可能になり、ユーザーはデータを書き込むことができ、マスターまたは別のレプリカとの接続が復元されると、すべてのデータも復元されます。



レプリケーションは、サーバーのオフロードや、マスターからレプリカへの読み取り要求の再配布に非常に役立ちます。この読み取りをスケーリングし、より多くの読み取りレプリカを作成して、システムをさらに高速化できます。また、多数のロックを必要とし、システムの可用性に影響を与える可能性のある複雑で長期的な分析クエリを複製することもできます。



例としてオフラインアプリケーションを使用して、そのようなデータを保存し、競合を解決する方法を検討しました。同期レプリカの場合、レプリケーションラグ、つまりタイムラグが発生する可能性があります。非同期レプリカの場合、ほとんどの場合そこにあります。つまり、非同期レプリカからデータを読み取るときは、関連性がない可能性があることを理解する必要があります。



階層によると、同期レプリカからの応答を待機しているマスターが1つある場合、すべてのレプリカが同期していて、一部が突然使用できなくなった場合、システムは要求を保存できないと想定するのが論理的であると言うのを忘れました。次に、マスターは最初の同期スレーブに書き込み、応答を受け取り、2番目のスレーブを要求し、応答を受信しません。その結果、トランザクション全体をロールバックする必要があります。



したがって、このようなシステムでは、原則として、1つのレプリカが同期され、残りは非同期になります。同期レプリカにより、データが別の場所に保存されます。つまり、何かが発生する可能性のあるマスターに加えて、まったく同じトランザクションログ、同じデータの完全なコピーを含むノードが少なくとも1つあることを保証します。



一方、非同期レプリカはデータの整合性を保証しません。非同期レプリカのみがあり、マスターが切断されている場合、それらは遅れている可能性があり、データはまだそこに到着していない可能性があります。そのような場合、原則として、データの永続性が重要でない場合は、マスターがあり、1つの同期レプリカと残りが非同期であるか、マスターがあり、すべてのレプリカが非同期であるような階層を構築します。



「しかし」が1つあります。すべてのレプリカは同じ構成である必要があります。例としてPostgreSQLについて説明する場合、データベースのバージョンが異なれば操作ログの形式も異なる可能性があるため、PostgreSQL自体のバージョンが同じである必要があります。また、レプリカが別のバージョンからのものである場合、他のベースが書き込んだ操作を読み取れない可能性があります。



レプリカとは何ですか？これはすべてのデータの完全なコピーです。サーバーが処理できないほど多くのデータがあるとしましょう。最初の解決策は何ですか？



最初の決定は、より多くのメモリ、より大きなCPU、より大きなディスクを備えた、より高価なマシンを購入することです。鉄のコストが高いという問題に直面しない限り、この決定はほとんどの場合正しいでしょう。いつの日か、新しい車を買うのは高すぎるか、単に成長する場所がなくなるでしょう。 1台のマシンに収めることが物理的に不可能な膨大な量のデータがあります。







このような場合、水平スケーリングを使用できます。以前に見た、マシンあたりのパフォーマンスの向上は、垂直スケーリングです。マシン数の増加は水平スケーリングです。







データをマシンごとに分割するには、シャーディング、つまりパーティショニングが使用されます。つまり、データをキー、ID、日付でセクションとブロックに分割します。これについてはさらに説明します。これは重要なパラメータの1つですが、重要なのは、データを特定の基準に従って分割し、別のマシンに送信することです。したがって、私たちのマシンは効率が低下する可能性がありますが、システムは機能し、さまざまなマシンからデータを受信できます。







データがどこにあるかを一般的に理解するには、シャード、コピー、およびデータの特定の対応テーブルが必要です。



特別なデータストアが使用されず、クライアントが各シャードを順番にウォークスルーして、要求に一致するデータがあるかどうかを確認する場合があります。



どのシャードがどのデータ範囲にあるかについての特定の知識を格納する特別なソフトウェアレイヤーがあります。そして、それに応じて、必要なデータが配置されているノードに正確に移動します。







太ったクライアントがいます。これは、クライアント自身を別のレイヤーに縫い付けないが、データがどのようにシャーディングされているかに関するデータをクライアントに縫い付ける場合です。







これが事実です。ちなみに、最もよく使われているものです。良い点は、アプリケーション、クライアント、作成したコードでさえ、テーブルがシャーディングされていることを認識しないことです。ただし、これは構成、データベース自体で示されます。私たちは彼女に言うだけです-選択してください、そしてすでにデータベース自体に、シャードへの分割とどこから選択するかについての理解があります。ここでは、コード自体で、データの読み取り先を定義します。



情報の構造化と一般的な更新に役立つ特別なサービスがあります。一貫性と関連性を維持することは困難です。何かを選択し、新しいデータを記録しました。または、何かが変更され、リクエストを非常に正しくルーティングする必要があります。リクエストを調整するための特別なサービスがあります。それらの1つはZookeperです。それらが一般的にどのように機能するかを見ることができます。非常に興味深い構造です。彼らは開発者のために多くの神経と時間を節約しました。



重要なこと、パーティションを作成するときに留意すべき側面は何ですか？シャードに分割するために使用するキーを理解することが重要です。このすべてのデータを再収集することは非常に費用がかかるため、データが将来どのように使用される可能性があるかについて誤解しないことが非常に重要です。シャーディングを適切かつ正しく行った場合、最も頻繁に使用されるクエリを使用すると、どのレプリカに移動するかが常にわかります。



たとえば、ユーザーのIDに従って、すべてのデータを特定のレプリカに保存すると、この1つのレプリカにアクセスして、すべての結合を実行できることがわかります。しかし、IDでそれを維持することは最もクールなアイデアではありません。理由をお話しします。



パーティショニングでキーを誤って識別した場合、非常に複雑なクエリがある場合は、実際には別のシャードに移動し、すべてのデータを結合してから、それをアプリケーションに渡す必要があります。幸い、ほとんどのDBMSがこれを行ってくれます。しかし、不十分に記述されたクエリでは、どのようなオーバーヘッドが発生しますか？またはシャーディングの下で​​、間違ったノードで壊れていますか？



IDについて。システムが新しいユーザーでのみ機能し、IDが増加している場合、すべてのリクエストは最後のノードに送られます。



何が起こるのですか？他の3台の実行中のマシンはアイドル状態になります。そして、この車は単に燃えるでしょう-いわゆるホットスポット。これは、潜在的なシステムのボトルネックであり、接続を拒否する可能性さえあります。



したがって、シャーディングキーを定義するときは、これらのノードのバランスを理解することが非常に重要です。ハッシュは非常に頻繁に使用されます。これは、多かれ少なかれ中立でバランスの取れたデータの配置です。ただし、キーにハッシュ関数がある場合、たとえば範囲で選択することはできません。範囲を異なるシャードに広げることはできないため、これは論理的です。



日付別-同じ。たとえば、分析を分散して日付ごとにシャードを作成する場合、もちろん、10年前の1つのシャードはまったく使用されません。それは私たちにとって有益ではありません。また、データを再構築して過度に強化することは、常に非常にコストがかかります。



前に出てきた質問にお答えします。何をすべきか-インデックスを定義するか、シャードを作成しますか？もちろん、インデックス。



ほら、シャードは全体が隆起したインフラストラクチャを備えた別個のマシンです。そして、この中間のコンポーネントには、インデックスに似たものが含まれています。パラメータによるクイック検索があります-どこに、どこに行くか。これが比率です。しかし、シャーディングがある場合、最終的な画像は次のようになり







ます。アプリケーションがあり、どこに行くべきかを知っているある種の頭があります。また、シャードがあり、それぞれにレプリカが構成されています。データが少ない場合、これは非常に大きなオーバーヘッドです。つまり、実際に垂直スケーリングの制限に達した場合にのみ、シャーディングに頼る必要があります。より高価なマシンを購入しても、データや収入に関係がない場合です。次に、いくつかの異なる安価な車を購入して、そのようなアーキテクチャを構築できます。



レプリカの目的は明らかだと思います。シャードが壊れているため、それらはデータベースの一部ですが、一種のユニークなものです。それらはこれらの場所でのみ見つかります。また、それらをコピーに分割します。これにより、ノードは耐障害性になり、問題が発生しなくなります。







最も重要なこと：シャーディングは、データを分類に分類したいだけでなく、実際に大量のデータがある場所で正確に使用されます。



それでは、データモデルについて詳しく見ていき、データを保存する方法を見てみましょう。



以前に調べたリレーショナルデータベースには、まず第一に、非常に一般的で誰もが理解できるため、非常に多くの利点があります。オブジェクト間の関係を視覚的に示し、整合性を提供します。



ただし、欠点があります。明確な構造が必要です。すべてのデータをプッシュする必要があるテーブルがあります。私たちが一般的に収集するすべての情報と事実を見ると、それらは非常に異なっています。つまり、製品データ、ユーザーデータ、メッセージなどを処理できます。このデータには、明確な構造と整合性が本当に必要です。リレーショナルデータベースは彼らにとって理想的です。



ただし、たとえば、操作のログやオブジェクトの説明があり、各オブジェクトの特性が異なるとします。もちろん、これをリレーショナルデータベースのジェイソンに書き留めることができ、それが私たちとともに際限なく成長することを嬉しく思います。



そして、他のスキームや他のストレージシステムを見ることができます。 NoSQLは非常に派手な略語であり、直接挑発的でさえあります-「SQLなし」。それはどのようにして起こったのですか？



リレーショナルデータベースがどこでも成功しているわけではないという事実に直面したとき、彼らはハッシュタグを必要とする会議をまとめたので、彼らは#NoSQLを思いつきました。根付いた。その後、彼らは「SQLなし」ではなく「SQLだけでなく」と言い始めました。これは、リレーショナルではないものです。リレーショナルデータベースほど厳密に構造化されておらず、概略的で、表形式ではない、さまざまなデータベースの巨大なファミリです。



非リレーショナルデータモデルのファミリは、キー値データベース、ドキュメント指向データベース、列データベースデータベース、およびグラフデータベースの4つのタイプに分けられます。これらの各ポイントを検討し、どのデータをどのデータに保存するのが適切で、何に使用されるのかを調べてみましょう。







キー値。これが最も簡単です。これが辞書です、これが比率です。これは、データがキーによって格納されるデータベースであり、特定のキーの下に何があるかは関係ありません。キー自体の両方があり、データは単純な構造でも、はるかに複雑な構造でもかまいません。このようなデータベースの良いところは、インデックスのように、データを非常にすばやく検索することです。これが、キー値がキャッシュに非常に頻繁に使用される理由です。利点は、キーによって値が異なる可能性があることです。



たとえば、キーを使用してユーザーセッションを保存できます。ユーザーがクリックしたので、これを値で記述しました。これはスキーマレスであり、特定のスキーマ、値構造のないデータモデルです。非常にシンプルな構造であるため、高速で簡単にスケーリングできます。私たちはすでに鍵を持っています、そして私たちはそれらを非常に簡単に破り、それらのハッシュを作ることができます。これは、最もスケーラブルなデータベースの1つです。



例としては、Redis、Memcached、Amazon DynamoDB、Riak、LevelDBがあります。キー値ストレージの実装機能を確認できます。







ドキュメントデータベースは、いくつかの用途でキー値と非常によく似ています。しかし、彼らのユニットはドキュメントです。これは、特定のデータを選択し、一括操作（一括挿入、一括更新）を実行できるような複雑な構造です。



各ドキュメントは、原則として、XML、JSON、またはBSON（バイナリに保存されたJSON）をそれ自体に保存できます。しかし、今ではほとんどの場合JSONまたはBSONです。これもキーと値のペアのようなもので、各行に特定の特性があるテーブルとして想像でき、これらのキーを使用してそこから何かを取得できます。



ドキュメント指向データベースの利点：非常に高いデータ可用性と柔軟性を備えています。どのドキュメントでも、どのJSONでも、絶対にすべてのデータセットを書き込むことができます。また、カタログを作成する必要がある場合や、カタログ内の各製品の特性が異なる場合など、非常に頻繁に使用されます。



または、たとえば、ユーザープロファイル。誰かが彼らの好きな映画、誰か-彼らの好きな食べ物を示しました。すべてを1つのフィールドに貼り付けないようにするために、何を格納するかが明確ではないため、ドキュメントベースのJSONですべてを書き込むことができます。



データを保存するためのもう1つの便利なモデルは、列データベースです。それらは、columnar、columndatabaseとも呼ばれます。







これは非常に興味深い構造であり、私が思うに、ほとんどすべての大規模で複雑なプロジェクトで使用されています。このようなデータベースは、データを行ではなく列でディスクに保存することを意味します。大量のデータを非常に高速に検索するために使用されます。原則として、分析の場合、特定の列からのみ値を選択する必要がある場合。







巨大なテーブルがあると想像してみましょう。そして、データを行に格納すると、次のようになります。膨大な数の行です。このテーブルの3つのパラメーターを選択するには、テーブル全体を調べる必要があります。そして、列ごとに値を格納する場合、3つの値で選択する場合、列はこのように記述されているため、大まかに言って3行だけを通過する必要があります。これらの3行を通過すると、必要な値の順序番号がすぐに取得され、他の列から取得されます。



そのようなデータベースの利点は何ですか？少量のデータを検索するため、構造を変更せずに任意の数の列を追加できるため、クエリ処理速度が非常に高く、データの柔軟性が高くなります。ここでは、リレーショナルデータベースとは異なり、データを特定のフレームに強制する必要はありません。



最も人気のある円柱状のものは、おそらくCassandra、HBase、およびClickHouseです。それらをテストします。頭の中の行と列の比率を逆にするのは非常に興味深いことです。そして、これは大量のデータへの非常に効率的で高速なアクセスです。







グラフデータベースのファミリーもあります。また、ノードとエッジも含まれています。エッジは、リレーショナルデータベースの場合と同様に、リレーションシップを表示するために使用されます。ただし、グラフベースはさまざまな方向に無限に大きくなる可能性があります。したがって、より柔軟です。すべてのテーブルを選択して結合する必要がないため、検索速度が非常に速くなります。ノードには、すべての異なるオブジェクトとの関係を示すエッジがすぐにあります。



これらのデータベースは何に使用されますか？ほとんどの場合-関係を示すためだけに。たとえば、ソーシャルネットワークでは、誰が誰をフォローしているかという質問に答えることができます。適切な人のすべてのフォロワーへのリンクがすぐにあります。それでも非常に頻繁に、これらのデータベースは詐欺スキームを識別するために使用されます。これは、トランザクション間の相互関係の実証にも関連しているためです。たとえば、同じ銀行カードが別の都市で使用されたときや、他の誰かが同じIPアドレスから別のユーザーのアカウントを入力したときを追跡できます。



このような相互作用や関係を分析するためによく使用される異常な状況を解決するのに役立つのは、これらの複雑な関係です。



非リレーショナルデータベースは、リレーショナルデータベースに置き換わるものではありません。彼らはただ違う。彼らの仕事の異なるデータフォーマットと異なるロジック、悪くも良くもありません。これは、他のデータとは異なるアプローチです。そして、はい、非リレーショナルデータベースが頻繁に使用されます。あなたはそれらを恐れる必要はありません;逆に、あなたはそれらを試す必要があります。



キャッシュを作成する場合は、もちろん、単純で高速なキー値である、ある種のRedisを使用します。分析用のログが大量にある場合は、ClickHouseまたは列ベースにドロップできます。これにより、検索が非常に便利になります。または、ドキュメントの意味が異なる可能性があるため、ドキュメントベースに書き込みます。これは、選択にも役立ちます。



使用するデータに基づいてデータモデルを選択します。リレーショナルまたは非リレーショナルのいずれか。データを説明してください。このようにして、将来拡張できる最適なストレージを見つけることができます。







今日、あなたはさまざまな問題とデータの保存方法について多くを学びました。最初に言ったことをもう一度繰り返します。すべてを詳細に知る必要はなく、1つのことを掘り下げる必要もありません。もちろん、興味があればできます。しかし、それが一般的に存在すること、そこにどのようなアプローチがあり、一般的にどのように考えることができるかを知ることは重要です。耐障害性が必要な場合は、レプリカを作成するのが理にかなっています。データを書き留めたが、表示されなかったとします。それから、おそらく、私の発言は遅れをとった。車輪を作り直す必要はありません-さまざまなタスクのための既製のソリューションがすでにたくさんあります。視野を広げると、バグやその他の問題が発生した場合、バグの特性によって障害が発生した場所を正確に把握し、検索エンジンから解決策を見つけることができます。清聴ありがとうございました。