データベース シャーディングは、大規模システムで水平方向のスケーラビリティを実現する手法です。
現実世界のほとんどすべてのシステムは、大量の読み取りリクエストと無視できない量の書き込みリクエストを受け取るデータベース サーバーで構成されています。これによりサーバーに過負荷がかかり、システムのパフォーマンスが低下する可能性があります。
このような影響を軽減し、システムのパフォーマンスを向上させるには、データベース レプリケーションやデータベース シャーディングなどのアプローチがあります。このガイドでは、まずシステムのパフォーマンスを向上させるための次のようなテクニックを検討します。
- データベースサーバーのスケールアップ
- データベースのレプリケーション
- 水平分割
これらの手法について説明した後、データベース シャーディングがどのように機能するかを学び、このアプローチの利点と制限についても見ていきます。
さぁ、始めよう!
システムパフォーマンスを向上させるテクニック
まず、データベース サーバーが原因でボトルネックが発生した場合にシステム パフォーマンスを向上させる手法について説明します。
#1. データベースサーバーのスケールアップ
データベース サーバー インスタンスをスケールアップすることは、システム パフォーマンスを向上させるための簡単なアプローチのように思えるかもしれません。これには、処理能力の強化、RAM の追加などが含まれます。
ただし、この手法には次の制限があります。無限のストレージと処理能力を備えたサーバーは存在できません。そして、一定の限界を超えると、収益は逓減していきます。
#2. データベースのレプリケーション
リクエストの受信によりデータベース サーバー インスタンスの過負荷が発生した場合は、データベース レプリケーションを検討できます。
データベース レプリケーションでは、通常書き込みリクエストを受信する マスター ノードが 1 つ あります。 複数のリードレプリカが あります。

これにより、可用性が向上し、システムの過負荷が軽減されます。読み取りリクエストをリードレプリカの 1 つにルーティングできるため、複数のクエリを並行して処理できるようになりました。
しかし、これは別の問題を引き起こします。マスター ノードへの書き込みリクエストによりデータが変更される可能性があり、これらの更新は定期的にリード レプリカに伝播されます。

マスターノードで書き込み操作が進行していると同時に、リードレプリカの 1 つに対する読み取りリクエストがあるとします。
マスターノードの変更はまだリードレプリカには反映されていません。この場合、古いデータが読み取られる可能性があり、これは望ましくないことです。

#3. 水平分割
水平パーティショニングは、システムのパフォーマンスを最適化するためのもう 1 つの手法です。数十億行を含む単一の大きなテーブル (顧客やトランザクション データのテーブルなど) がある場合があります。
このようなデータベース テーブルからの読み取り操作は遅くなります。しかし、水平パーティショニングを使用すると、単一の大きなテーブルが複数のパーティション (または小さなテーブル) に分割され、そこから読み取ることができます。 PostgreSQL などのリレーショナル データベースは、パーティショニングをネイティブにサポートしています。
ただし、すべてのパーティションは依然として単一のデータベース サーバー インスタンス内にあります。唯一の違いは、単一の大きなテーブルではなくパーティションから読み取ることができることです。
したがって、受信リクエストの数が増加すると、サーバーは増加した需要をサポートできなくなる可能性があります。
データベースシャーディングはどのように機能しますか?
システムのパフォーマンスを向上させるアプローチとその制限について説明したので、データベース シャーディングがどのように機能するかを理解しましょう。
シャーディングでは、単一の大規模データベースを複数の小さなデータベースに分割し、それぞれがデータベース サーバー インスタンス上で実行されます。このような小さなデータベースはそれぞれ シャード と呼ばれます。そして、各シャードにはデータの一意のサブセットが含まれています。

しかし、データベースをシャードに分割するにはどうすればよいでしょうか?そして、どの行がどのシャードに入るのかをどのように判断するのでしょうか?
🔑 シャーディングキーを入力します。
シャーディングキーについて
シャーディング キーの役割を理解しましょう。
シャーディング キー は通常、データベース テーブル内の列 (または列の組み合わせ) であり、データの分散が複数のシャード間で均等になるように選択する必要があります。特定のシャードが他のシャードよりも大幅に大きくなることが望ましくないからです。
顧客とトランザクションに関するデータを保存するデータベースでは、
customer_ID
がシャーディング キーの適切な候補です。
シャーディング キーを決定したら、どの行がどのシャードに入るかを決定するハッシュ関数を考え出すことができます。
この例では、
customer_ID
シャーディング キーとして使用して、データベースを 5 つのシャード (シャード #0 からシャード #4) に分割する必要があるとします。この場合、単純なハッシュ関数は
customer_ID % 5
です。

5 で割ったときにゼロが残るすべての
customer_ID
値は、シャード #0 にマップされます。そして、残り 1 ~ 4 を残す
customer_ID
値は、それぞれシャード #1 ~ シャード #4 にマッピングされます。

この方法でデータベース シャーディングを実装した後は、受信リクエストを正しいデータベース シャードにルーティングするルーティング層を用意することが重要です。
データベースシャーディングの利点
データベース シャーディングの利点の一部を次に示します。
#1. 高い拡張性
より大きなデータベースを複数の小さなシャードに分割することはいつでも可能です。したがって、データベースのシャーディングにより、水平方向に スケールアウトできる ようになります。
#2. 高可用性
すべての受信リクエストを処理する単一のデータベース サーバー インスタンスがある場合、単一障害点が発生します。データベース サーバーがダウンすると、アプリケーション全体がダウンします。
データベース シャーディングを使用すると、特定の瞬間にすべてのデータベース シャードがダウンする可能性は比較的低くなります。したがって、特定のシャードがダウンしている場合、そのシャードに対する読み取りリクエストを処理できません。ただし、他のシャードは受信リクエストを処理できます。これにより、高可用性と耐障害性が向上します。
データベースシャーディングの制限事項
次に、データベース シャーディングの制限のいくつかを見てみましょう。
#1. 複雑
シャーディングにはスケーラビリティと耐障害性の点で利点がありますが、システムが複雑になります。
レコードのパーティションへのマッピングから、クエリをそれぞれのシャードにルーティングするためのルーティング レイヤーの実装に至るまで、データベースのシャーディングにはかなりの複雑さが伴います。
#2. リシャーディング
シャーディングのもう 1 つの制限は、再シャーディングの必要性です。
データ レコードを均等に分散するためにハッシュ関数を使用していますが、シャードの 1 つが他のシャードよりもはるかに大きく、すぐに使い果たされてしまう可能性があります。この場合、再シャーディング (または再シャッフル) を考慮する必要があり、これにはかなりのオーバーヘッドが伴います。
#3. 複雑なクエリの実行
結合を含む分析のためにクエリを実行する必要がある場合は、単一のデータベースではなく、複数のシャードのレコードを使用する必要があります。したがって、あまりにも多くの分析クエリを実行する必要がある場合、これは困難になる可能性があります。 データベースを非正規化する ことでこの問題を回避できますが、それでもある程度の努力が必要です。
結論
学んだことをまとめてディスカッションを締めくくりましょう。
ハードウェアのスケールアップが常に最適であるとは限りません。したがって、サーバー インスタンスを強化することはお勧めできません。また、データベース レプリケーションや水平パーティショニングなどの技術とその制限についても確認しました。
次に、大規模なデータベースを より小さく管理しやすいシャード に分割することで、データベース シャーディングがどのように機能するかを学びました。均等なパーティションを取得するには シャーディング キーを 慎重に選択する必要があることと、受信リクエストを正しいデータベース シャードにルーティングするためのルーティング層の必要性について説明しました。
データベースのシャーディングには、高可用性やスケーラビリティなどの利点があります。欠点としては、シャーディングの設定や 1 つ以上のシャードが使い果たされた場合の再シャーディングの複雑さが挙げられます。
したがって、シャーディングによって生じる複雑さよりも利点の方が大きいと思われる場合は、シャーディングを検討してください。次に、さまざまな AWS リレーショナル データベースの比較を確認してください。