分散データベースを使用した後、パフォーマンスが 50% 向上したのに、なぜ諦めたのでしょうか?

最近、Lao Yu はある事例を耳にしました。ある銀行が、業務の中核となる集中型データベースの代わりに分散型データベースを導入する計画を立てていたのです。当初の計画では、コアビジネスでパイロットを実施し、パイロットの状況に基づいて大規模な導入を継続するかどうかを決定します。

パイロット プロジェクトのコア ビジネスでは、「O」データベース、3 ノード RAC、および 3 台のミニコンピュータが使用され、そのうち 2 台はビジネス システム用に使用され、1 台はリモート データ バックアップとして同じ市内の災害復旧センターに配置されます。置き換え後、データベースは 600 台を超える X86 サーバーを使用する分散データベースになりました。

[[377439]]

現在、パイロットサービスが展開されており、置き換え前と比較してピークパフォーマンス（TPS）が50％向上し、平均パフォーマンス（TPS）が33.3％向上しました。平均トランザクション応答時間は不明です。

最終的に、銀行は実施を進めず、現状を維持することを決定しました。

この時点で、誰もが何かがわかるはずだと私は信じています。

3 ノードの RAC で十分な機能があるのに、なぜこれほど多くの X86 が必要なのでしょうか?

そうです、たとえ銀行によってコアビジネスの複雑さが異なっていても、そして入れ替え後にパフォーマンスが 50% 向上したとしても、しかし!しかし！しかし！重要なことは3回言うべきです。いずれにせよ、老宇は多くの専門家に相談したところ、全員が同じ意見でした。これほど多くの機械が必要だとは誰も思っていませんでした。それはお金の無駄です！資金に不足していないとしても、今後の開発チームと運用チームの作業負荷と複雑さが劇的に増加することを考慮する必要があります。

分散トランザクションによってネットワーク遅延が発生し、さらに多くのサーバーが必要になる場合、それは分散データベース アーキテクチャの設計が不十分であることを意味します。平均トランザクション応答時間は不明です。これはアプリケーション層で実装されているからでしょうか?すると、上記のネットワーク遅延が再び覆されました。

このプロジェクトの5年間のTCOを計算するのは難しくなく、投資額は1億元を超えることは間違いありません。ハードウェア コスト (サーバー、スイッチなど)、ソフトウェア コスト (オペレーティング システム、データベース ライセンス)、4 年目/5 年目のメンテナンス コストなどはすべて簡単に見積もることができます。

しかし、簡単に見落とされがちなコストが 1 つあります。それは、全体の調達コストの 20 ～ 30% を占める可能性がある運用および保守コストです。分散データベースの運用と保守は問題点です。分散化後は、必然的に運用・保守・開発の作業負荷が急増します。

運用と保守の観点から見ると、ハードウェアが大幅に増加したため、当初の 3 台のミニコンピュータに必要なオペレーターが 2 人だけだったとすると、600 台を超える X86 に必要な運用と保守は 2 倍、あるいはそれ以上に増えることになります。運用保守スタッフの平均年収が20万だとすると、5年後には100万になります。 3増えたら300万になります。第二に、マシンの大幅な増加は、必然的に電気代、放熱費、コンピューター室の使用料などのコストの増加につながります。

開発の観点から見ると、アーキテクチャの変更によってアプリケーションがそのまま残ることはほとんどなく、アプリケーションを完全に再構築することも可能です。

したがって、このケースはパフォーマンスとコストの両方の点で費用対効果が高くありません。

このケースはいくぶん極端ではありますが、市場における実際の潜在的な問題や認知上の誤解を反映しており、詳しく議論する価値があります。

近年、分散データベースがトレンドになっています。さまざまな光輪の祝福を受けた彼らは、暗闇の中の灯台のような存在であり、過度に神話化されてきたのは必然です。

さまざまなメーカーが積極的または受動的に独自の分散データベース製品をリリースしているだけでなく、市場は競争に満ちています。多くの伝統的な企業も分散データベースを試しています。分散データベースを使わないと時代に淘汰されてしまうし、分散データベースを使ったことがないとレベルの低い人と思われてしまうようです。

試験的に参入した企業の中には成功した企業もあれば、失敗した企業もあった。分散データベースには統一された業界標準がないため、各人が独自の意見を持っています。

Lao Yu は、普遍的なデータベースは存在せず、最も適切なデータベースのみが存在すると信じています。

分散データベースは優れていますが、万能薬ではありません。これらはさまざまなシナリオに適用可能であり、それぞれに欠点があります。現在の分散データベースの最適なアプリケーション シナリオを理解するには、分散データベースの歴史的背景と人気の理由から始める必要があります。

歴史的背景

分散データベースは、データベースの歴史の初期の頃から存在していました。それらに関する研究は1970年代に始まりました。世界初の分散データベース システムである SDD-1 は、1979 年に Computer Corporation of America (CCA) によって DEC コンピュータに実装されました。

しかし、分散データベースが注目されるようになったのは近年になってからであり、それには多くの理由があります。

インターネットが誕生する前は、企業データの規模は大きくなく、「O」で表される従来のデータベースでほとんどのデータ管理ニーズを満たすことができました。したがって、分散データベースは役に立たなかった。これには2つの理由がありました。まず、この時期には市場にこれより優れた分散データベース製品はありませんでした。第二に、分散データベース自体には必然的に欠陥がありました。

しかし、インターネット時代に入り、データ量の増加とオンライン上の膨大なユーザー数の増加に直面し、従来のデータベースではビジネス開発をサポートできなくなりました。その結果、インターネット業界を筆頭とした企業が効果的な解決策を模索し始めました。

最初に開発された NoSQL は、強力な一貫性などのリレーショナル データベースのいくつかの制限を犠牲にして、データ処理にスケーラビリティをもたらしました。その後、NewSQL が誕生し、従来のリレーショナル データベースのスケーラビリティと特性を組み合わせた新しいタイプのデータベースが定義されました。最も典型的な代表例は、Google Spanner/F1 ペーパーに基づいています。

このプロセスにおいて、従来のデータベースもその価値を回復しつつあります。最も一般的な方法は、データベースとテーブルを分割することです。ただし、このソリューションでは、アプリケーション システムの大幅な変換が必要になり、データの保存場所を認識する必要があり、運用と保守の複雑さが増します。

したがって、分散データベースには、オープンソース データベース + MyCat などの分散ミドルウェア ソリューションという 2 つの技術的なルートがあります。既存のオープンソースデータベースの成熟した安定した製品機能を活用できるのが利点です。欠点は、ミドルウェアは結局は回り道に過ぎず、スタンドアロン データベースの機能によって制限されることです。

もう 1 つの技術的なルートは、ネイティブ分散データベースです。これは本質的に分散されており、最初から分散アーキテクチャ向けに設計されています。欠点は、製品の成熟度を向上させる必要があり、さまざまなシナリオ、さまざまなデータ規模、さまざまな業界のアプリケーションでテスト、改善、完成させる必要があることです。

現時点では、データ量が一定規模に達しておらず、超高ピーク値がなく、高同時実行シナリオもない場合は、分散データベースを使用する必要はないというのが一般的な見解です。明らかな利点が得られないだけでなく、集中型単一マシンのスケーラビリティと開発および運用保守の簡便性が犠牲になる可能性が高いためです。

目的が国内代替を達成することだけであれば、一部の国内リレーショナル データベースで実際にニーズを満たすことができ、分散データベースを直接使用する必要はありません。

一般的に、分散データベースの利点は優れたスケーラビリティです。データを複数のノードに分散して保存できるため、水平方向の拡張が可能になります。さらに、複数のノードを並列に実行できるため、全体的なスループットが向上します。

欠点は、分散トランザクション処理のコストが高いことです。これは主に、2 フェーズ コミットによって発生する過剰なメッセージ送信に起因します。ロック競合の可能性が高くなります。複数のコピーと高可用性が必要です。第二に、製品の成熟度を向上させる必要があり、操作と保守が複雑です。

よくある誤解

1. 分散変換は単なる技術的な問題である

従来の集中型アーキテクチャから分散型アーキテクチャへの移行は、単純な技術的な問題ではなく、テクノロジー エコシステムを切り替える問題です。

データベースの分散は、データベース システムの再構築だけでなく、アプリケーション システムの再構築ももたらします。分散データベースは一般にストアド プロシージャをサポートしておらず、SQL 実行効率が低いため、これらの問題は通常アプリケーション側でのみ解決できます。

従来のデータベースと比較すると、分散データベースの開発、運用、保守に対する技術要件は高くなります。民生銀行の技術部長はかつて、分散型変革の過程ではインテリジェントな運用・保守プラットフォームの開発が非常に重要であると述べた。

したがって、分散データベースを導入する前に、全体的な計画を立て、資金、環境の変革、人員のスキル、管理の自動化、技術的準備の面で十分な準備を整える必要があります。

2. 分散型変革によりTCOが削減される

分散データベースには、オープンソース データベース + 分散ミドルウェアとネイティブ分散データベースという 2 つの技術的なルートがあります。分散データベース製品を開発する企業のほとんどはインターネット企業やスタートアップ企業などであるため、一般的には MySQL を使用します。そのため、分散データベースを導入することでソフトウェア調達コストが削減され、RISC が X86 に置き換えられ、ハードウェアの単価が大幅に下がるため、TCO が削減されると多くの人が考えています。しかし、現実はそうではないかもしれない。

例えば、この記事の冒頭のケースがその一例です。もちろん、このケースは少し極端です。もう一つの例を挙げましょう。

ある国立銀行のクレジットカード システムには、もともと 4 台のミニコンピュータをベースにしたデータベース システムがありました。分散変換後、120 台のデータベース サーバーが必要になりました。ソフトウェアとハ​​ードウェアの購入コストは50％削減されましたが、運用・保守要員は66％増加し、開発者数は5倍に増加しました。 5年後の総所有コストは、当初のコストと比較して60%以上増加しました。節約された調達コストでは、後期段階で増加する運用および開発コストをカバーできません。

この事例から、分散変換によって初期購入コスト TCA のみが削減され、全体的な所有コスト TCO は削減されないことがわかります。

3. 既存のシステムの可能性を探らず、インターネットモデルを盲目的にコピーする

「テクノロジーはビジネスに従う」ということわざがあります。 IT アーキテクチャの進化とアップグレードは、企業のビジネス変革と同期する必要があります。遅れれば事業展開が制限され、一方、急進的すぎると投資の無駄を招き、事業にリスクをもたらすことにもなります。

伝統的な企業のビジネスはインターネット企業のビジネスとは根本的に異なります。インターネット企業には、膨大なユーザー数、高頻度のユーザー訪問と取引、高頻度のビジネス革新という 3 つの注目すべき特徴があります。例えば、Douyin、Kuaishou、Toutiao は 1 年間で数千万人のユーザーを獲得することができ、各ユーザーは 1 日に複数回ログインします。したがって、IT インフラストラクチャは、まず拡張性と柔軟性を追求する必要があります。

従来の企業のコアビジネスは、ユーザー数が限られており、取引頻度が低く、開発者が少なく、IT 支出も少ないため、比較的安定しています。企業の IT に対する要求は、インターネット企業のそれとは根本的に異なります。分散変革によってもたらされる経済的コストと技術的リスクを負担することは困難であり、通常はサードパーティが提供する総合的なソリューションとサービスに頼るしかありません。したがって、このような企業にとっては、従来の集中型データベースが依然として最良の選択肢となります。

たとえば、この記事の冒頭のケースでは、データベース システムのパフォーマンスを向上させるには、ハードウェア プラットフォームを 2 ウェイおよび 4 ウェイ サーバーから 8 ウェイおよび 16 ウェイの大規模サーバーにアップグレードするだけで、ほとんどのビジネス ニーズに対応できます。コストは分散システムを直接使用するよりも高くならず、むしろ低くなる可能性があります。現在、国内のサーバーとミニコンピュータには、完全なカテゴリ範囲と透明な価格があります。これで十分でない場合は、RAC クラスターを使用できます。国内の多くのリレーショナル データベースにも RAC クラスタ拡張ソリューションがあります。

最後に

一般的に、どのデータベースを使用するかは、ビジネス ニーズによって完全に異なります。

企業はデータベースを何に使用しますか?分析か取引か？それとも両方ですか?ビジネスではどのようなデータを処理する必要がありますか?データベースのパフォーマンス要件は何ですか?

トランザクションの整合性を必要とし、ACID トランザクションを保証する従来の ERP、CRM、財務、またはその他の「お金」に関連するコアビジネスシステムの場合、従来の集中型リレーショナルデータベースが最良の選択であることに疑いの余地はありません。

ビジネスではどのようなデータを処理する必要がありますか?構造化されていますか?半構造化？非構造化データ?サポートする必要があるデータ モデルを決定します。原則として、「データ モデルに一致するライブラリを使用する」必要があります。

画像、音声、ビデオなどの非構造化データを保存および処理する場合は、NoSQL データベースが最適です。さらに、ビジネスでゲームシーン内の役割情報、経験値アイテム情報、フレンドランキングなどの情報を保存する必要があり、これらの情報が一般的に ID (キー) にリンクされている場合は、キーバリューデータベースが適しています。

ビジネスで処理する必要があるデータの規模、同時スループット、応答時間の要件は何ですか?データベースのパフォーマンス要件を決定します。

フラッシュセールや春節の鉄道チケットなど、ピーク時や同時実行性が非常に高いビジネスの場合は、分散データベースが適切な選択肢となります。

まとめると、アーキテクチャとデータベースの選択に関する議論は常に存在しますが、その核心では、「ビジネス ニーズが技術革新を推進する」ということを明確にする必要があります。重要なのは、アーキテクチャと分散データベースの選択を合理的に分析して扱い、ビジネス シナリオに最適なアーキテクチャとデータベースを選択することです。