分散ストレージシステム設計（3）-ストレージ構造（転送）

NoSQLストレージシステムでは、一般的にKey-Valueデータ型が採用されていますが、Key-Value構造はシンプルで格納が簡単で、分散NoSQLストレージシステムに非常に適しています。ただし、単純なデータ型には、リスト型データを格納する必要性など、ビジネスに格納されるデータに対する特定の制限があります。この問題に対応するために、システムはKey-Valueタイプのデータにいくつかの拡張を行い、1つのキーの下に複数のフィールドとリストを格納することをサポートし、データストレージのビジネスシナリオを拡張します。この記事では主に、この分散ストレージシステムでサポートされているデータ型と、メモリへのデータストレージの実装について紹介します。

データ型

Key-Value

Key-Valueは最も単純なデータ型です。キーと値は構造化データをサポートしていません。サービスの読み取りと書き込みを行う場合、シリアル化と逆シリアル化が必要です。システムはデータ構造を理解せず、バイナリシーケンスとして扱います。シリアル化後のデータ長が制限を超えない限り、Key and Valueがあらゆるタイプのデータをサポートするように、汎用性。

キーフィールド

キーフィールドは複数のフィールドをサポートし、フィールドの識別に整数タグを使用します。各タグに対応するフィールドの長さは異なる場合があります。フィールドもシリアル化されたデータであり、より一般的です。キーのデータに複数のフィールドを格納する必要があるシナリオでは、キーフィールドはキー値よりもはるかに使いやすくなっています。

キー行

Key-Rowsは複数の行をサポートし、各行はKey-Fieldsであり、複数のフィールドをサポートします。各行のフィールドの数と長さは異なる場合があり、非常に柔軟です。キー行を使用してリストを格納し、ユーザーの買い物注文情報の格納など、より複雑なビジネスシナリオをサポートできます。

マルチレベルハッシュテーブル

データはフルメモリに格納されるため、再起動時にプロセスがデータを失わないようにするために、共有メモリを使用すると、複数のプロセスがデータにアクセスすることも容易になります。Key-Valueデータの場合、最も効率的なデータ構造は当然ハッシュテーブルです。ここでは、シンプルで効率的かつ堅牢で、エンジニアリングアプリケーションに非常に適したマルチオーダーハッシュテーブルの実装を紹介します。

マルチオーダーハッシュテーブルは、競合を解決するために再ハッシュするという考え方を採用しています。次の図に示すように、線形配列はNステップに分割され、各ステップのバケットサイズ（要素数）はNi（1≤i≤N）です。データを挿入すると、ハッシュ（キー）％Niがそれぞれで計算されますオーダーの位置。最初のオーダーから開始し、競合がある場合は、空いている場所が見つかるまで次の順序で検索を続けます。Nオーダーに競合がある場合、挿入は失敗し、検索プロセスも同様である必要があります。新しいデータを挿入する場合、最初にすべてのステージを検索する必要があることに注意してください。これは、パフォーマンスに特定の影響を与えます。たとえば、データ1は最初にステージ3に挿入され、次に検索パスに挿入されます。レベル2のデータは削除されます。データ1を再度挿入すると、レベル2に空きが生じます。この位置を挿入すると、レベル3のデータ2が残り、クリーニングできなくなり、スペースが無駄になります。NoSQLデータストレージシステムの場合、新しく追加されたデータの割合は比較的小さく、ほとんどの操作はデータの更新と読み取りであるため、マルチレベルハッシュテーブルはこのシナリオで比較的良好なパフォーマンスを維持できます。

マルチレベルハッシュテーブルの品質を測定する2つの主な指標は、スペース使用率と平均検索時間です。実験により、注文数が多いほど競合への対処能力が高く、スペース使用率が高くなることがわかります。ただし、平均検索時間が長くなるほど、スペース使用率と平均検索時間は相互に制限されることがわかり、実際の状況に応じて重み付けする必要があります。

バケットサイズの次数ごとに異なる素数を選択する必要があります。各次数のバケットサイズを数学的に証明できる場合、各次数でのデータの分布がより均一になり、衝突の確率が減少します。最も簡単な方法は、各注文に対して連続する素数を選択することです。より良い選択肢はありますか？同じ注文でより高いスペース使用率とより少ない平均検索時間を得ることができます。各バケットのサイズが類似している場合、より低い次数がより多くのデータを分散するため、バケットのサイズが低次から高次に減少すると、スペース使用率が向上します。次数が一定であるという条件下では、削減するためにルックアップの平均数は、下位のバケットサイズを可能な限り大きくする必要があります。同時に、競合に対処するための上位の機能を維持するために、バケットサイズが小さすぎないようにする必要があります。要約すると、バケットのサイズは順番に低から高に減少し、低次の減少はより深刻であり、高次の減少は穏やかであり、比例シーケンスはこの機能とより一貫しています。係数1.5の等数系列を使用したバケットサイズとバケットサイズの平均分布を使用したバケットサイズの比較テスト結果は次のとおりです。挿入には乱数が使用されます。挿入が初めて失敗したときのスペース使用率が最終結果として使用されます。次に、バケットサイズが比例すると、スペース使用率が高くなり、平均検索時間が短くなります。20の次数が適切な選択です。現時点では、マルチオーダーハッシュテーブルのスペース使用率は93％に達します、平均検索時間は約3回です。

上記のデータの種類では、キーとデータが可変長で、ハッシュテーブルのノードが固定長ですが、ハッシュテーブルノードに直接データを格納すると、スペースの無駄になります。メモリの使用率を向上させるため、ここではハッシュテーブルとリンクリストを組み合わせたデータインターフェイスを使用しています。次の図に示すように、ハッシュテーブルノードはデータインデックスを格納し、キーとデータは固定長ブロックリンクリストに格納されます。このようにして、固定長ブロックの数をデータサイズに応じて割り当てることができます。これは効率的で、スペースを無駄にしません。固定長ブロックのサイズも慎重に検討する必要があります。大きすぎるとボイドが大きくなり、小さすぎると各データが占める固定長ブロックの数が多くなり、パフォーマンスに一定の影響があります。

読み取りと書き込みの競合

ストレージスペースの場合、単一プロセスの読み取りと書き込みが最も単純な設計です。読み取りと書き込みの競合の問題はありませんが、単一プロセスの処理能力がボトルネックになります。処理能力を向上させるには、マルチプロセスまたはマルチスレッドの並行性を使用する必要があり、読み取りと書き込みの競合の問題が発生します。

複数の書き込みプロセスがストレージスペースで同時に動作する場合、相互排他ロックメカニズムが必要です。ストレージ構造はリンクリストを使用するため、誤ったチェーンが発生しないようにするために大まかなロックが必要であり、ロックメカニズムも実装が複雑です。このシリーズの前回の記事では、1つのマシンのストレージスペースを複数のストレージユニットに分割し、各ストレージユニットを書き込みプロセスで処理することで、同時排除も保証される、より優れたソリューションを提案しました。このロックフリーの実装のパフォーマンスも優れています。

書き込みプロセスの相互排除の問題を解決します。読み取りプロセスと書き込みプロセスの間には依然として競合があります。特定のデータが書き込みプロセスにあり、読み取りプロセスがこのデータを読み取っている場合、不完全に読み取られる可能性がありますデータ。この問題は検証によって解決できます。検証値はデータに記録され、データが書き込まれるたびに検証値が更新されます。データを読み取るときにデータが検証されます。検証が失敗すると、読み取りと書き込みの競合が発生します。、再試行する必要があります。読み取りと書き込みの競合の可能性を減らすために、下の図に示すプロセスに従ってデータを更新するときに、元の固定長ブロックチェーンを上書きする代わりに、新しい固定長ブロックチェーンをデータの書き込みに割り当てます。

分散ストレージを使用するほとんどのビジネスは、書き込みと読み取りが少ないシナリオです。上記の読み取り/書き込み競合処理メカニズムでは、ストレージユニットは1つの書き込みプロセスと複数の読み取りプロセスを同時にサポートできるため、読み取り操作が高くなります。同時実行機能は、書き込みを減らし、読み取りを増やすのに非常に適しています。