Starcounter という名前のデータベースについて読んでいます。「NoSql」データベースのみが一貫性を失うことなく処理できる負荷を処理できると主張しています。CAP 定理を理解している限り、一貫性を維持すると、可用性や分断耐性が失われます。では、StarCounter を機能させるにはどのようなトリックが必要なのでしょうか?
StarCounter が高速であることは想像できますが、NoSql は一貫性を維持するために一貫性を落とす必要があるという主張は、私には少し奇妙に思えます。誰でも説明できますか？
よろしくお願いしますローランド
CAP の定理 (ブリューワーの定理とも呼ばれます) は、単一の情報 (一貫したデータベースなど) では打ち負かすことはできません。水平方向にスケーリングされたデータベースがある場合、一貫性とパフォーマンスは得られません。この結論は物理法則に由来し、ブリューワーの定理とアインシュタインの相対性理論から導き出すことができます。スケールアウトではなく、スケールイン/アップする必要があります。それほど「曇っている」わけではありませんが、ガリレオの敵が今日生きていればおそらく告白するように、自然は人間のファッションを尊重するのに不十分な仕事をしています.
他のアプローチもあると思いますが、Starcounter はデータベース イメージを RAM にホストすることで機能します。データベース データをアプリケーション コードに移動する代わりに、アプリケーション コードの一部をデータベースに移動します。最終応答のデータのみが、RAM メモリ内の元の場所 (データが最初にあった場所) から移動されます。これにより、毎秒何百万ものリクエストが処理されたとしても、ほとんどのデータが保持されます。欠点は、データベースがアプリケーション ロジックのプログラミング言語を認識する必要があることです。ただし、1 秒間に何百万もの HTTP 要求を処理しようとしたことがあり、それぞれが広範なデータベース アクセスを必要とする場合、その利点は明らかです。
質問は良い質問です。CAP が証明された (定理になった) のはほんの数年前のことなので、奇妙に感じるのも不思議ではありません。多くの開発者は、理論物理学者が永久機関を探すのをやめるように言ったとき、子供が失望するのと同じくらいがっかりします。スケールアウトの一貫したデータベースはまだ必要ですよね。
CAP の定理は、どの情報も一貫性 (C)、可用性 (A)、分割耐性 (P) を持つことはできないことを示しています。情報の単位 (データベースなど) に適用されます。もちろん、異なる動作をする独立した情報を持つこともできます。1 つは AP、もう 1 つは CA、3 番目は CP です。同じ情報を CAP にすることはできません。
一貫性のある利用可能なデータベースで「P」が不可能であるという問題は、スケールアウトされたデータベースがノード間のシグナリングをどのように行う必要があるかという結果になります。結論は、今から 100 年後でも、単一の一貫したデータが、ハード ワイヤまたは光ビームを使用して相互接続されたハードウェア上に存在する必要があるということです。
利用可能な一貫したデータベースに水平スケーリングを適用する場合、問題はパフォーマンスにあります。そもそも水平方向のスケーリングを行う理由は、優れたパフォーマンスでした。これは非常に悪いことです。すべてのノードは、一貫性を保つためにデータベースへのアクセスがある場合は常に他のノードと通信する必要があるため、シグナリングは最終的に光の速度によって制限されるという事実を考えると、データベース科学者 (CPU 科学者と同様に) という悲しい事実が残されます。 ）は、スケールアウトを魔法の特効薬とみなさないために頑固になっているだけではありません。これは起こり得ないため、起こりません (ただし、データベースの一部が AP セットに配置される可能性があるため、ここでは一貫したデータについて話していることを思い出してください)。
データベース コミュニティの状況は、馬車が仕事の手段だった時代の永久機関の状況に少し似ています。それに対する理論的証拠がないにもかかわらず、特許庁は不可能な永久機械に対して数百の特許を付与しました。今日、私たちはこれを笑うかもしれませんが、一貫したスケールアウト データベースを使用するデータベース業界でも同様の状況があります。誰かがスケールアウト ACID データベースを持っていると主張するのを聞いたら、用心してください。MIT のドットコム クラッシュの数学者が、Brewer の CAP 定理が正式に誕生したことを証明した後のことでした。そのため、残念ながら、不可能への探求はまだ終わっていません。必要に応じて、これを比較できます。現代の理論物理学が合理的にそれを止めるべきだった後、後進者が何年もの間永久機械を発明しようとし続けた方法に。古い習慣はなかなか消えません (スタック オーバーフローの誰かに申し訳ありませんが、自分の意思で無限に動くベアリングと腕の図を作成しています。攻撃的であるつもりはありません)。
ただし、すべてが失われるわけではありません。すべての情報が一貫している必要はありません。すべての部分をスケールアウトする必要はありません。ブリューワーの定理を受け入れて、それを最大限に活用するだけです。
Facebook などのアプリケーションでは、一貫性が失われます。これは、データが一度入力された後は 1 人のユーザーによって操作されるため問題ありません。それでも、Facebook を日常的に使用することで、何かが一時的に現れたり消えたりするなどの副作用を経験することができます。
ただし、ほとんどのビジネス アプリケーションでは、データは正確である必要があります。簿記のすべての勘定科目の合計がゼロになる必要があります。複数のユーザーが同じ在庫から購入している場合でも、10 個のアイテムのうち 2 個を販売した場合、在庫在庫は 8 に等しくなければなりません。
利用可能なデータをスケールアウトする際の問題は、パーティション トレランスなしでやり遂げなければならないことです。この派手な言葉は、クラウド内のノード間で常に信号を送る必要があることを意味します。光は 1 メートル移動するのに数ナノ秒かかるため、スケールアウトの結果、パフォーマンスが向上するどころか低下することなしには、これは不可能になります。もちろん、これは一貫したデータにのみ当てはまります。これが意味することは、Intel、AMD、Oracle などのエンジニアによって知られています。長い間。彼らの科学者がスケールアウトについて聞いたことがないわけではありません。アインシュタインが説明したように、彼らは世界を受け入れるようになったというだけです。
計算を行うと、1 台の PC が、実行されている 1 秒ごとに地球上に住む各人間に余裕を持たせる命令を持っていることがわかります (「最新の CPU」と「MIPS」でググってください)。Amazon.com (www.nasdaq.com で確認できます) の総売上高を平均的な本の価格で割るなど、さらに計算を行うと、販売トランザクションの総数が次の式に収まることがわかります。単一の最新の PC の RAM。すばらしいことに、アイテム、顧客、注文、製品などの数は、1950 年と同じ量のスペースを 2012 年に占めています。画像、ビデオ、およびオーディオのサイズは増加していますが、数値およびテキスト情報は、アイテム。確かにトランザクション数は増加しますが、コンピューターの処理能力が向上するのと同じ段階ではありません。したがって、論理的な解決策は、読み取り専用データと AP データをスケールアウトし、「スケールイン/アップ」することです。
VM で実行されるデータベース エンジンとビジネス ロジック (Java VM や .NET CLR など) は、通常、かなり効果的なマシン コードを使用します。これは、メモリの移動が、一貫したデータベースの合計スループットの影に隠れているボトルネックであることを意味します。これは、メモリ ウォールと呼ばれることがよくあります (ウィキペディアには役立つ情報があります)。
秘訣は、データベース イメージからコードにデータを転送する代わりに、コードをデータベース イメージに転送することです (MVC または MVVM パターンを使用している場合)。これは、消費するコードがデータベース イメージと同じアドレス空間で実行され、データが移動されないことを意味します (そして、ディスクはトランザクションとイメージを保護しているだけです)。データは元のデータベース イメージにとどまることができ、アプリケーションのメモリにコピーする必要はありません。データベースを RAM データベースとして扱うのではなく、データベースをプライマリ メモリとして扱います。すべてがそのままです。
最終的なユーザー応答の一部であるデータのみが、データベース イメージから移動されます。数億の同時ユーザーを持つ大規模なアプリケーションの場合、これは通常、1 秒あたり数百万のリクエストにすぎません。これは、HTTP パッケージ化がゲートウェイ サーバーで行われることを考えると、1 台の PC で処理するのに問題はありません。幸いなことに、このようなサーバーはデータを共有する必要がないため、見事にスケールアウトします。
結局のところ、ディスクはシーケンシャル書き込みで高速であるため、RAID されたディスクはテラバイトまたは毎分変更を保持できます。
通常、Starcounter ノードはスケーリングしません。スケールアウトではなく、スケールインします。これは、数百万の同時ユーザーに適しています。それを超えるには、Starcounter ノードをさらに追加する必要があります。これらはデータの分割に使用できます (ただし、一貫性が失われ、Starcounter は分割用に設計されていないため、Volt DB などのソリューションよりも洗練されていません)。そのため、追加の Starcounter ノードをゲートウェイ サーバーとして使用することをお勧めします。これらのサーバーは、すべての着信 HTTP 要求を一度に 1 ミリ秒単純に蓄積します。これは短い時間のように聞こえるかもしれませんが、Starcounter をスケーリングする必要があると判断した場合、数千のリクエストを蓄積するには十分です。リクエストのバッチは、ZLATAN ノード (Zero LATency Atomicity Node) に 1 秒間に 1,000 回送信されます。このような各バッチには、数千のリクエストが含まれる場合があります。この上、1 つの ZLATAN ノードで数億のユーザー セッションを処理できます。複数の ZLATAN ノードを持つことができますが、アクティブな ZLATAN ノードは一度に 1 つだけです。これが、CAP定理が尊重される方法です。それを超えるには、Facebook などと同じトレードオフを考慮する必要があります。
もう 1 つの重要な注意点は、ZLATAN ノードはアプリケーションにデータを提供しないということです。代わりに、アプリケーション コントローラー コードは ZLATAN ノードによって実行されます。データをシリアライズ/デシリアライズしてアプリケーションに送信するコストは、コントローラのロジック サイクルを処理するコストよりもはるかに高くなります。つまり、その逆ではなく、コードがデータベースに送信されます (従来のアプローチでは、アプリケーションがデータを要求するか、データを送信します)。
シリアライゼーションとデシリアライゼーションのためのリモート システムではなく、プログラミング言語の「ヒープ」としてデータベースを使用することは、Starcounter が VMDBMS と呼ぶトリックです。データベースが RAM にある場合、RAM のある場所から RAM の別の場所にデータを移動しないでください。これは、ほとんどの RAM データベースの場合です。
「トリック」はありません。Starcounterは速度について話し、CAP/NoSQLはスケーラビリティについて話します。機能+スケーラビリティと速度の間にはトレードオフがあります。
他の場所にボトルネックがあることを証明できる場合は、スケーラビリティを無視しても問題ない場合があります。たとえば、新しいスタートアップは、Webサイトが100万人のユーザーに拡大することを心配する必要はなく、最初の100人のユーザーを獲得することを心配する必要があります。（Twitterが初期にどれほど頻繁にダウンしたかを覚えている人はいますか？）Starcounterは、トランザクション率がWebページのヒット率よりもはるかに高い場合に役立ちます。
一方で、すべての「NoSQL」データベースをひとまとめにしている人は誰も信用していません。さまざまなNoSQLデータベースは、同じものとは異なります。それらは根本的に異なるアーキテクチャとプロパティを持っています。それらのいくつかは数千のノードにスケーリングし、いくつかは1つのノードを超えてスケーリングしません。スケーラビリティを追加すると、速度が低下することがあります。機能を削除するとスピードアップすることがあります。
http://strata.oreilly.com/2010/12/strata-gems-mysql-handlersocket.html