分散ライブラリの使用の難しさを打破する: データ シャーディング戦略

分散データベースが成熟するにつれて、その推進と利用の面でより深い領域に入り始めています。このプロセスでは、会社のアーキテクチャ、運用と保守、開発に大きな影響を与えました。この新しい技術をいかに早く習得し、できるだけ早く実装するかが、皆の注目の的となっています。この記事では、開発者の観点から、分散データベースの使用時に直面する困難の 1 つであるデータ シャーディング戦略について説明します。これは、多くの企業が分散データベースを使用できない主な原因でもある問題です。

1. データシャーディング戦略とは何ですか?

分散データベースのコア機能の 1 つは、データ シャーディング ストレージを通じて、より大きなデータ規模とコンピューティング負荷を処理することです。データ シャーディングは、データベースを複数の物理ノードに水平に拡張する分散テクノロジです。これは、特定のシャーディング ルールに従ってテーブル データを複数のフラグメント (シャード) に水平に分割し、これらのデータ フラグメントが異なる物理ノードに分散されるようにすることを意味します。データ シャーディングは、大きく分けて垂直シャーディングと水平シャーディングに分けられます。前者は業務区分ごとに分割され、最も一般的な方法は業務データベース分割です。後者はフィールドに基づいており、特定の戦略に従って複数のテーブルに分割されます。この記事の後半で説明するデータ シャーディングは後者を対象としています。したがって、データを単一のエンティティから分散エンティティに変更するには、データ シャーディング戦略を考慮する必要があります。データ シャーディング戦略には、シャーディング アルゴリズム、データ分散、分散関係などが含まれます。簡単な説明については、下の表を参照してください。

写真

2. 分散データベースシャーディング戦略

業界における分散データベース製品のデータ シャーディング戦略には、通常 3 つのアプローチがあります。 1 つは、主キー/一意のインデックス/暗黙の主キーに基づいて統合されたデータ シャーディングを実行することです。つまり、ユーザーはシャーディング戦略を手動で設定する必要がありません。もう 1 つは、複数のデータ シャーディング アルゴリズムを公開し、ユーザーがデータ オブジェクトを作成するときに手動で指定できるようにすることです。より柔軟なシャーディング方式をサポートし、ユーザーが独自に拡張できるデータベースミドルウェア製品もいくつかあります。上記の 3 つのタイプは、組み込み、オープン、カスタムという名前が付けられます。以下は、開発者の観点から見たこれらの方法の簡単な比較です。

写真

説明は次のとおりです。

• 組み込み製品は通常、開発者にとって使いやすく、ユーザー エクスペリエンスは基本的にスタンドアロン データベースと同じです。しかし、シャーディング戦略に介入する方法がないため、柔軟性が低く、ビジネスとは無関係です。ほとんどのビジネス シナリオでは、上記の欠点を補うために、パフォーマンス エクスペリエンスを犠牲にして、より多くのハードウェア リソースを消費する必要があります。
• オープン製品では、開発者は組み込みの戦略から比較的最適なソリューションを選択する必要があります。一定の柔軟性とパフォーマンスを備えており、ほとんどのシナリオのニーズを満たすことができます。一部のビジネスでは、その特殊性のために適切なシャーディング戦略を見つけるのが難しく、ビジネスのカスタマイズと変革が必要になります。
• カスタマイズされた製品は開発者に最大限の柔軟性と自由度を提供しますが、これはまた、使いやすさが悪く、開発と運用に多くの作業が必要になることを意味し、標準化された製品化を実現することが困難になります。

3. シャーディングの実装における問題点と解決策

最初の方法を除いて、他の 2 つの方法では、既存のデータ オブジェクトをどのように分割するかという問題が伴います。適切な分割戦略は、ビジネス モデル、最適なパフォーマンス、安定性と信頼性、R&D の変革、運用と保守の難しさなどの複数の要素と、分散データベースの特性を組み合わせた最適なソリューションでなければなりません。これは複数の要素のバランスの結果です。具体的な実施に関しては、決定を下す前に多くの情報を収集する必要があります。主な部分は以下の表にまとめられています。

写真

写真

上記の表からわかるように、多次元モデル分析プロセスであるデータシャーディング設計プロセスでは、考慮すべき問題が数多くあります。これには、企業のビジネスフロー、データフロー、データモデル、ビジネス特性、基本環境など、多くの側面を考慮することが含まれます。比較的「適切な」設計ソリューションを生み出すには、上記に加えて、分散アーキテクチャ データベースの機能に関する理解も必要になります。これは企業にとって非常に苦痛であり、企業が分散データベースに移行することを妨げる問題の 1 つです。上記の負担をユーザーに完全に押し付けることはできませんが、データベース製品側で回答を提供するように努める必要があります。つまり、製品にはデータシャーディングの最適化を推奨する機能がなければなりません。シャーディング設計が不合理な場合、ビジネス システムの安定性と信頼性、およびサービス エクスペリエンスに影響を及ぼす可能性があります。サービス エクスペリエンスは速い場合も遅い場合もあり、最悪なのは、特定の時間やビジネス シナリオでは最も遅くなるため、トラブルシューティング分析の難易度と複雑さが増すことです。もちろん、初期設計を完璧にすることは困難ですが、システムの運用中に継続的に検討した結果、データベースには、シャーディング タイプやシャーディング フィールドの調整など、一定のオンライン シャーディング調整機能が必要になります。このプロセスでは、既存のビジネス サービスの正常な動作が中断されないようにする必要があります。また、既存のビジネス サービスのパフォーマンス エクスペリエンスへの影響を最小限に抑える必要があります (つまり、実稼働環境でのリソース使用によるビジネス サービスへの影響を制御する必要があります)。最後に、シャード情報の調整はできるだけ早く完了する必要があります。

4. 業界製品の現状と展望

現在、国内の分散データベースベンダーの多くは、外部ツールによる収集、評価、移行支援、検証といった一連のプロセスのサポートを提供することで、移行機能のサポートを強化しています。次の図では、OceanBase の OMA ツールを例として使用し、このツールが提供するサポート機能を示しています。

写真

上の図からわかるように、この製品はデータシャーディング戦略にはあまり役立たず、主に互換性の評価ツールです。つまり、データベース自体の機能に基づいて、元のオブジェクトと SQL ステートメントにどのような変更を加える必要があるかを評価します。データ シャーディング戦略に関する推奨作業はまだないため、まだ空白の状態です。実は昨年、このプロセスを小さなツールで完了させることを目的とした記事が公式アカウントで公開されましたが、これまでのところメーカーの製品サポートは見られていません。今後この機能がサポートされれば、国内企業における分散データベースの導入が加速すると考えています。