NoSQLのパーティション - ダミー

パーティションは、NoSQLの2つの異なる概念に使用されます。データパーティションは、データがクラスタ全体に均等に分散されることを保証するためのメカニズムです。一方、ネットワークパーティションは、同じデータベースクラスタの2つの部分が通信できない場合に発生します。非常に大規模なクラスタシステムでは、1つの装置の障害が発生する可能性がますます高まっています。クラスタ内のサーバ間でネットワークスイッチが失敗すると、（コンピュータ用語で）

スプリットブレインと呼ばれる現象が発生します。この場合、個々のサーバーは依然として要求を受信していますが、相互に通信することはできません。 <！ - 1 - >

このシナリオでは、データの矛盾やデータストレージの容量低下の原因となる可能性があります。サーバーの数が最小のネットワークパーティションがクラスタから削除されている（またはBig Brotherの真のファッション）。

パーティションを許容する

ネットワークパーティションが発生すると、2つの選択肢があります。

あるレベルでは、読み取りと書き込みの操作を続行します。

パーティションの1つの部分を「投票」し、後で両方の部分が通信できるようにデータを修正することを決定します。これには、通常、読取りレプリカを、欠落しているマスター・パーティション・ノードごとに新しいマスターとして投票することが含まれます。
<！ - 2 - >
Riakでは、データが複製される回数（デフォルトでは3つ、つまりn = 3）と、読み込みを成功させるためにクエリを実行するサーバの数を指定できます。つまり、キーのプライマリマスターがネットワークパーティションの間違った側にある場合、他の2つのサーバーが使用可能な場合（つまり、r = 2の読み取り可）、読み取り操作は引き続き成功する可能性があります。

ヒントハンドオフ

と呼ばれるシステムを使用してプライマリパーティションサーバが停止したとき、Riakは書き込みを処理します。データが最初に複製されるとき、特定のキーパーティションの最初のノードは、次の隣接ノードのうちの2つ（デフォルトで）に書き込まれます。 <！ - 3 - > プライマリに書き込むことができない場合、リングの次のノードに書き込まれます。これらの書き込みは、効果的に次のノードに渡されます。プライマリ・サーバが復帰すると、ライトはプライマリ・ライト動作を再び引き継ぐ前にそのノードに再生されます。

これらの両方の動作において、数ミリ秒間であっても、異なるレプリカが異なるバージョン状態にある可能性があるため、バージョンの不一致が起こり得る。 Riakは、この問題を緩和するために、

能動的な抗999 - 999エントロピー

と呼ばれるさらに別のシステムを使用する。このシステムは、更新された値をトラップし、ある時点で、好ましくは後ではなくより早く、複製が更新されることを保証する。これにより、読み込み時の競合を回避しながら処理速度を向上させることができ、マスタスレーブ、非共有クラスタリングをサポートする他のNoSQLデータベースで使用される2フェーズコミットを回避できます。

読み込みで競合が発生した場合、Riakは読み取り修復を使用して最新のデータのみを返します。最終的には、使用する整合性と可用性の設定に応じて、クライアントアプリケーションに複数のバージョンが提示され、それ自体を決定するように求められます。状況によっては、このトレードオフが望ましく、多くのアプリケーションが、提示されるデータ、使用するバージョン、および廃棄するバージョンに基づいて直感的に知ることができる。二次索引付け二次索引は、ある値内の特定のデータに対する索引です。ほとんどのキー値ストアは、このインデックス付けをアプリケーションに委ねます。しかし、Riakは、二次索引付けを可能にする

文書 - ベースのパーティション化

というスキームを採用しています。

ドキュメントベースのパーティショニングでは、JSON構造をRiakデータベースに書き込むことを前提としています。

{"order-id"：5001、 "customer-id"：1429857、 "order-date"： "2014-09-24"このJSON構造内の特定の名前付きプロパティにインデックスを設定できます。 "、" total "：134.24} 前月の顧客の注文を表示しているアプリケーションがある場合、顧客IDが固定値であるように、すべてのレコードを照会します（1429857 ）、注文日は特定の範囲（月の始まりと終わり）にあります。ほとんどのキーストアでは、顧客番号と月を合わせたキーを持つ別のバケットを作成し、その値は注文IDのリストです。しかし、Riakでは、customer-id（整数）とorder-date（日付）の両方にセカンダリインデックスを追加するだけです。これは追加のストレージスペースを占有しますが、アプリケーション開発者にとって透過的ですという利点があります。これらのインデックスもライブで更新されています。つまり、Riakでドキュメントの値を更新するときと最新のインデックス間に遅延がないという意味です。データへのこのライブアクセスは、見た目よりも引き離すのが難しいです。結局、インデックスが矛盾していると、一貫して保持されているデータを見つけることはできません！ Riakの評価

Riakの背後にある商業団体Bashoは、次期バージョン2.0を発表しました.NoSQLデータベースは、他のNoSQLベンダーとの強い一貫性を常に持っています。 NoSQLベンダーの主張は常に強固な一貫性を持っていると主張するのは、牛肉を食べた日曜日を除いて強い菜食主義者であると主張するようなものです。

RiakはACID準拠のデータベースではありません。その構成はACID準拠モードで実行されるように変更することはできません。クライアントは、通常の操作中またはネットワークパーティション中に矛盾したデータを取得する可能性があります。 Riakは、可用性とパーティションの許容差を高めるために絶対的な一貫性を保ちます。

強力な整合性モードでRiakを実行すると、読み取りレプリカがプライマリマスターと同時に更新されることを意味します。これには、2フェーズコミットが含まれます。基本的に、マスタノードは、書き込みが完了したことを確認する前に他のノードに書き込みます。

<！ - 1 - >

この執筆時点では、Riakの強力な一貫性モードでは、セカンダリインデックスや複合データ型（JSONなど）はサポートされていません。うまくいけば、Bashoは今後のリリースのデータベースでこの問題を修正する予定です。

強力な一貫性を使用すると、Riak Search（ブランド化され、統合されたApache Solr検索エンジンは最終的に一貫性のある更新モデルを使用します）が誤検出を引き起こす可能性があります。この状況は、データが書き込まれた後にトランザクションが破棄されるために発生しますが、データは引き続きインデックス作成に使用され、「偽陽性」の検索結果が残るため、結果は実際には検索クエリに対して有効ではありません。

<！ - 2 - >

Riakは別の

監視モジュールプロセス

を使用して、どのノードがフェイルオーバー状態でマスターになるかを判断します。しかし、このプロセスは高可用性ではありません。つまり、数秒間、

sentinelプロセス

の新しいコピーがオンラインになる間に、新しいノードを追加することも、新しいノードを追加することもできませんマスターは選出されました。高ストレス・フェイルオーバー状態では、この可能性に注意する必要があります。

<！ - 3 - >

Riakには、セカンダリインデックスや組込みJSON値のサポートなど、アプリケーション開発者にとって便利な機能があります。他のデータセンターへの災害復旧のためのデータベース複製は有料版でのみ利用可能で、その価格はウェブサイト上に表示されます（表示されたレンタル価格、アプリケーションでの永久ライセンス価格のみ）。 Riak Controlクラスタ監視ツールは、クラスタ監視時の遅延時間のために高く評価されていません。 Riakは多くの約束を守っており、Bashoが将来のバージョンでさらに999以上のクラスター管理施設を追加すると、クラス最高の製品になるでしょう。