シャーディングとパーティション分割によるデータベースのスケーリング

デニス・イワノフ（2GIS）

みなさんこんにちは！ 私の名前はDenis Ivanovです。シャーディングとパーティション分割によるデータベースのスケーリングについて説明します。 このレポートの後、誰もがパーティーをしたい、何かを破片にする必要があります。あなたはそれが非常に簡単で、食べ物をまったく要求せず、機能し、すべてがうまくいくことを理解するでしょう。



私自身について少しお話します。私は2GISのWebAPIチームで働いており、組織にAPIを提供しています。さまざまなデータがあり、8か国、250の大都市、5万の集落があります。 かなり大きな負荷があります-アクティブなユーザーは月あたり2500万人で、平均して約2000 RPSの負荷がAPIにかかります。 これらはすべて3つのデータセンターにあります。



今日解決する問題に移りましょう。 問題の1つは、大量のデータです。 特定のプロジェクトを開発しているとき、大量のデータがあることがいつでも発生する可能性があります。 ビジネスが機能する場合、それはお金をもたらします。 したがって、これらの要求は非常に長い時間実行され始め、サーバーは私たちからエクスポートしないため、より多くのデータ、より多くのお金、およびこのデータで何かを行う必要があります。 このデータをどう処理するかに対する1つのソリューションは、データベースを拡張することです。



シャーディングについて詳しく説明します。 縦と横です。 レプリケーションのようなスケーリングの方法もあります。 SphinxのAndrei Aksenovによるレポート「 How MySQL Replication Works 」は、これに関するものでした。 このトピックについてはほとんど説明しません。



パーティショニング（垂直シャーディング）のトピックに移りましょう。 それはすべてどのように見えますか？







たとえば、ユーザーを含む大きなテーブルがあります-多くのユーザーがいます。 パーティション化とは、ある原則に従って、1つの大きなテーブルを多数の小さなテーブルに分割することです。

水平シャーディングでは、すべてがほぼ同じですが、同時に、プレートは他のインスタンスの異なるベースにあります。







水平スケーリングと垂直スケーリングの唯一の違いは、水平スケーリングによって異なるインスタンスにデータが分散されることです。



レプリケーションについては停止しません。ここではすべてが非常に簡単です。







このトピックをさらに深く掘り下げ、Postgresの例を使用してパーティション化に関するほとんどすべてのことを説明します。

単純なタブレットを見てみましょう。確かに、プロジェクトのほぼ99％がそのようなタブレットを持っています。これはニュースです。







ニュースには識別子があり、このニュースが置かれているカテゴリがあり、ニュースの著者、その評価、ある種の見出しがあります-完全に標準的な表、複雑なものはありません。



このテーブルを複数に分割する方法は？ どこから始めますか？



合計で、プレート上で2つのアクションを実行する必要があります。これは、news_1などのシャードに入れて、ニューステーブルに継承されるようにするためです。 ニュースはベーステーブルになり、構造全体が含まれます。パーティションを作成するときに、ベーステーブルに継承されることを示します。 継承されたテーブルには、親のすべての列（指定したベーステーブル）が含まれます。また、独自の列を追加することもできます。 これは完全なテーブルになりますが、親から継承され、親からの制限、インデックス、またはトリガーはありません-これは非常に重要です。 ベーステーブルにインデックスを作成して継承する場合、継承されたインデックステーブルにインデックス、制限、またはトリガーはありません。



実行する2番目のアクションは、制限を設定することです。 これは、この属性を持つデータがこのテーブルにのみ入ることを確認するものです。







この場合、属性はcategory_id = 1、つまり category_id = 1のエントリのみがこのテーブルに分類されます。

パーティションテーブルにはどのような種類のチェックがありますか？







厳密な意味があります。 フィールドと明らかに等しいフィールドがあります。 値のリストがあります-これはリストのエントリです。たとえば、この特定のパーティションにニュースの3人の作成者を置くことができ、値の範囲があります-これは、データが保存される値と値です。



チェックはBETWEEN演算子によってサポートされているため、ここでさらに詳しく説明する必要があります。







そして、あなたはそれをとても簡単にすることができます。 しかし、できません。 私たちはこれを行うことが許可されているため、PostgreSQLはこれをサポートしています。 ご覧のとおり、最初のパーティションでは100〜200のデータを取得し、2番目のパーティションでは200〜300のデータを取得します。これらのパーティションのうち、200のレーティングのレコードを取得するのはどれですか。 どれほど幸運かはわかりません。 したがって、これは実行できません。厳密な値を指定する必要があります。 厳密には最初のパーティションでは100を超え200以下の値になり、2番目のパーティションでは200を超えるが200ではなく、300以下になります。







どのパーティションがデータを取得するかわからないので、これは覚えておく必要があります。 すべての検証条件を明確に述べる必要があります。



また、異なるフィールドにパーティションを作成しないでください。 1番目のパーティションではcategory_id = 1のエントリを取得し、2番目のパーティションでは100の評価を取得します。







繰り返しますが、category_id = 1およびrating = 100のようなエントリを取得した場合、このレコードがどのパーティションに分類されるかはわかりません。 パーティショニングは、1つの機能、1つのフィールドに基づいています-これは非常に重要です。

パーティション全体を見てみましょう。







パーティションテーブルは次のようになります。 これは、category_id = 1のレコードのみがそこに到達するという記号が付いたnews_1テーブルであり、このテーブルはベーステーブルnewsから継承されます。すべてが非常に単純です。







メインテーブルニュースを操作するときに、category_id = 1のレコードへの挿入がメインパーティションではなくそのパーティションに分類されるように、ベーステーブルにルールを追加する必要があります。 単純なルールを指定し、必要なものを呼び出します。category_id= 1でニュースにデータが挿入されると、代わりにnews_1にデータが挿入されます。 ここでも、すべてが非常に単純です。テンプレートによると、すべてが変更され、素晴らしい動作をします。 このルールはベーステーブルに作成されます。







したがって、必要なパーティションの数を開始します。 たとえば、簡単にするために2つのパーティションを使用します。 つまり このテーブルの名前とデータが到達する条件を除いて、すべて同じです。 また、各テーブルに適切なテンプレートルールを設定します。







データ挿入の例を見てみましょう。







通常の大きな太いテーブルがあるように、通常どおりデータを挿入します。 category_id = 2のcategory_id = 1のレコードを挿入し、category_id = 3のデータを挿入することもできます。







ここで、データを選択します。すべて持っています：







3番目のパーティションはありませんが、データはありますが、挿入したものすべて。 これにはちょっとした魔法があるかもしれませんが、そうではありません。



特定のパーティションに適切なリクエストを行うこともできます。つまり、category_id = 1、または番号（2、3）の出現を条件として示します。







すべてがうまく機能し、すべてのデータが選択されます。 繰り返しますが、category_id = 3のパーティションはありませんが、







パーティションから直接データを選択できます-これは前の例と同じですが、必要なパーティションを明確に示します。 この特定のパーティションからデータを選択する必要があるという正確な条件がある場合、この特定のパーティションを直接指定し、他のパーティションに移動することはできません。 しかし、3番目のパーティションはなく、データはメインテーブルに送られます。







このテーブルにパーティション分割を適用しましたが、メインテーブルはまだ存在しています。 これは実際のテーブルであり、データを格納できます。ONLY演算子を使用すると、このテーブルからのみデータを選択でき、このレコードがここに隠されていることがわかります。







ここで、スライドを見るとわかるように、パーティションにデータを直接挿入できます。 メインテーブルにルールを使用してデータを挿入できますが、パーティション自体にも挿入できます。







たとえば、category_id = 4のような外部条件のあるパーティションにデータを挿入すると、「このようなデータはここに挿入できません」というエラーが表示されます。これも非常に便利です。本当に必要です。何か問題が発生した場合は、基本レベルですべてを把握します。







これはもっと大きな例です。 bulk_insert、つまり 複数のレコードを同時に挿入すると、それらはすべて目的のパーティションのルールを使用して配布されます。 つまり 私たちはまったく気にすることはできません、私たちが働いていたように、私たちのテーブルで作業してください。 アプリケーションは引き続き動作しますが、同時にデータがパーティションに分類され、これらすべてが、参加せずに棚にうまく配置されます。







条件付きのメインテーブルからデータを選択できることを思い出させてください。この条件を示すことなく、パーティションからデータを選択できます。 これが次のように見えるもの：







データはまだそこに到達することができ、パーティションごとのスキャンがあるため、テーブル全体でSeqスキャンが行われます。 複数のカテゴリの条件を指定すると、条件のあるテーブルのみがスキャンされます。 彼はパーティションの残りの部分を見ません。 これがオプティマイザーの仕組みです-そうです。したがって、非常に高速です。



Explainがパーティション自体でどのように見えるかを確認できます。







これは通常のテーブルで、Seq Scanだけで、超自然的なものではありません。 更新と削除も同じように機能します。 メインテーブルを更新できます。また、更新をパーティションに直接送信することもできます。 削除も機能します。 挿入で作成したのと同じルールで作成する必要がありますが、挿入ではなく更新または削除を書き込みます。

インデックスのようなものに移りましょう。

メインテーブルで作成されたインデックスは、パーティションの子テーブルでは継承されません。 これは悲しいことですが、すべてのパーティションに同じインデックスを作成する必要があります。 それについてやるべきことがありますが、すべてのインデックス、すべての制限を開始し、すべてのテーブルですべてのトリガーを複製する必要があります。



自宅でこの問題にどのように取り組んだか。 素晴らしいユーティリティPartitionMagicを作成しました。このユーティリティを使用すると、インデックスの作成、存在しないパーティションのトリガー、発生する可能性のある問題を気にすることなく、パーティションを自動的に管理できます。 このユーティリティはオープンソースであり、以下のリンクがあります。 データベースにストアドプロシージャとしてこのユーティリティを追加します。追加の拡張機能は不要で、拡張機能は不要です。再構築する必要はありません。 通常の手順であるPostgreSQLを使用して、データベースにプッシュして操作します。



ここに私たちが調べたのと同じテーブルがありますが、新しいものは何もありません。







どうやって分割するのですか？ そしてこのように：







プロシージャを呼び出し、テーブルがニュースになることを示し、category_idでパーティション分割します。 そして、それは単独で機能し続けます。他に何もする必要はありません。 データも挿入します。



category_id = 1の3つのエントリと、category_id = 2の2つのエントリ、category_id = 3の1つのエントリがあります。







挿入後、データは自動的に必要なパーティションに分類され、選択することができます。







すべて、パーティションがすでに作成されており、すべてのデータが棚に置かれ、すべてがうまく機能しています。

この利点により得られるもの：

• 挿入時に、パーティションが存在しない場合は自動的に作成します。
• 現在の構造を維持し、インデックス、チェック、トリガーを掛けて列を追加するだけでベーステーブルを管理できます。このプロシージャを再度呼び出すと、自動的にすべてのパーティションに分類されます。

これには非常に大きな利点があります。 リンクはhttps://github.com/2gis/partition_magicです。 これで、レポートの最初の部分が完成しました。 データを分割する方法を学びました。 パーティショニングは1つのインスタンスに適用されることを思い出させてください。これは、大きな太いテーブルを持つデータベースの同じインスタンスですが、小さな部分に分割します。 アプリケーションを完全に変更することはできません。メインテーブルでも同じように機能します。そこにデータを挿入、編集、削除します。 すべてが動作しますが、より速く動作します。 およそ、平均で3〜4倍高速です。



レポートの2番目の部分に進みましょう-これは水平シャーディングです。 水平シャーディングとは、複数のサーバーにデータを分散することです。 これらはすべて非常に簡単に実行できます。一度設定するだけで十分です。 これをどのように行うことができるかについて、さらに詳しく説明します。



2つのシャード、news_1とnews_2を使用して同じ構造を検討しますが、これらは異なるインスタンスになり、3番目のインスタンスが作業のメインベースになります。







同じ表：







そこで追加する必要があるのはCONSTRAINT CHECKだけです。レコードはcategory_id = 1の場合にのみドロップアウトします。 前の例と同じですが、これは継承されたテーブルではなく、サーバー上で作成したシャードを持つテーブルになり、category_id = 1のシャードとして機能します。 これは覚えておく必要があります。 行うべき唯一のことは、制約を追加することです。



オプションで、category_idにインデックスを作成することもできます。







チェックがあるという事実にもかかわらず-チェック、PostgreSQLはまだこのシャードを参照し、シャードは非常に長い間考えることができます。なぜなら、大量のデータがある可能性があり、インデックスの場合、インデックスに何もないため、すぐに応答するからですこのようなリクエストにより、追加する方が良いでしょう。



メインサーバーでシャーディングを設定する方法は？







EXTENSIONを接続します。 EXTENSIONはボックスからPostgresに移動します。これは、CREATE EXTENSIONコマンドで実行されます。postgres_fdwと呼ばれ、外部データラッパーの略です。



次に、リモートサーバーを起動してメインサーバーに接続し、好きな名前で呼び出して、このサーバーが指定した外部データラッパーを使用することを示します。



同様に、MySQL、Oracle、Mongoなどのシャードに使用できます。外部データラッパーは、非常に多くのデータベースに使用できます。 個別のシャードを異なるデータベースに保存できます。



オプションでは、ホスト、ポート、操作するデータベースの名前を追加します。サーバーのアドレス、ポート（ほとんどの場合、標準になる）、開始したベースを指定するだけです。



次に、ユーザーのマッピングを作成します。これらのデータに従って、メインサーバーは子に対して承認されます。 サーバーnews_1には、postgresパスワードを持つpostgresユーザーがいることを示します。 そして、ユーザーpostgresとしてメインデータベースにマッピングされます。



すべてを標準設定で示しました。プロジェクト、個々のデータベースに独自のユーザーを設定できます。ここでは、すべてが機能するように指定する必要があります。



次に、メインサーバーでプレートを起動します。







同じ構造のプレートになりますが、異なるのは、外部テーブルであるというプレフィックスのみです。 それは私たちにとってリモートのようなものであり、どのサーバーから取得するかを示し、オプションで取得する必要があるテーブルのスキームと名前を示します。



デフォルトのスキームはパブリックで、作成したテーブルはニュースと呼ばれます。 同様に、2番目のテーブルをメインサーバーに接続します。 サーバーの追加、マッピングの追加、テーブルの作成。 残っているのは、メインテーブルを用意することだけです。







これはVIEWを使用して行われ、プレゼンテーションを通じて、UNION ALLを使用してリモートテーブルからクエリを結合し、リモートサーバーから1つの大きなシックニューステーブルを取得します。



挿入や削除の際にこのテーブルにルールを追加して、シャードの代わりにメインテーブルを操作することもできます。これにより、アプリケーションでの書き換えや処理が不要になります。







チェックが機能しない場合にトリガーされる基本ルールを設定し、何も起こらないようにします。 つまり DO INSTEAD NOTHINGを指定し、以前と同じチェックを開始しますが、条件の表示のみを使用します。 category_id = 1および代わりにデータが分類されるテーブル。







つまり 唯一の違いは、category_idでテーブルの名前を示すことです。 データ挿入も見てください。







存在しないパーティションを特に強調表示したのは、 条件に応じて、このデータはどこにも届きません。 これはVIEWであり、これは実際のテーブルではなく、データをそこに挿入できないため、条件がない場合は何もしないことを示しています。 その状態で、データが3番目のテーブルに挿入されることを記述できます。 バッファやバスケットのようなものを取得し、テーブルにINSERT INTOを実行して、突然パーティションがなくなり、シャードのないデータが来始めた場合、そこにデータが蓄積されるようにします。

データを選択

識別子のソートに注意してください-最初に最初のシャードのエントリを表示し、次に2番目のシャードから表示します。 これは、postgresがVIEWを順番に処理するためです。 UNION ALLを介して選択を指定し、そのように実行します-リクエストをリモートマシンに送信し、このデータを収集して接着します。そして、このVIEWを作成し、そのサーバーがデータを提供した原則に従って並べ替えられます。



カテゴリを使用してメインテーブルから以前に作成したクエリを作成すると、postgresは2番目のシャードからのみデータを返すか、シャードに直接接続します。







上記の例のように、異なるサーバー、異なるインスタンスのみがあり、すべてが以前と同じように機能します。



説明をご覧ください。







パーティション分割と同様に、news_1による外部スキャンとnews_2による外部スキャンがありますが、Seqスキャンの代わりに外部スキャンがあります。これは別のサーバーで実行されるリモートスキャンです。







パーティショニングは非常に簡単で、完了するのにわずかなアクションしか必要なく、すべてをセットアップし、すべてがうまく機能し、食事を求めません。 以前に作業したようにメインテーブルを使用することもできますが、同時に、すべてが棚に美しく配置されており、多くのデータに対応できるように拡張する準備ができています。 , 3-4 , , , .. .



— , , , , , .

連絡先

2