いくつかの優れた分散リレーショナルデータベース

いくつかの優れた分散リレーショナルデータベース

[[270121]]

[51CTO.com クイック翻訳] リレーショナル SQL データベースは 1980 年代から存在し、メインフレームまたは単一のサーバー上で実行されていました。データベースでより多くのデータを処理し、より高速に実行したい場合は、より多くの高速な CPU、メモリ、ディスクを備えた大規模なサーバーにデータベースを配置する必要があります。言い換えれば、垂直方向のスケーラビリティ、つまり「スケールアップ」に頼ることになります。後で、可用性を向上させるためにフェイルオーバーが可能になる必要がある場合は、通常は共有ストレージを使用して、ホット スタンバイ サーバーをアクティブ サーバーと同じ「アクティブ/パッシブ」クラスターに配置できます。

ネットワークのパーティション分割、停電、その他のエラーが発生した場合でも、データベース トランザクションが常に有効であることを保証するためには、原子性、一貫性、独立性、耐久性という 4 つの ACID プロパティが必要です。単一サーバー上のデータベースが 4 つの ACID プロパティすべてに従うのは比較的簡単ですが、分散データベースにこれらのプロパティを適用するのはやや困難です。

最近、いくつかの「スケールアウト」SQL データベースが市場に登場しました。さらに良いことに、これらのデータベースの一部は、一貫性を犠牲にすることなく、地理的に分散したサーバーを処理できます。光速の制限により、リモート サーバー ノードの更新にはローカル ノードよりも時間がかかりますが、コンセンサス グループ Quora や超高速ネットワークおよびストレージの使用など、いくつかの手法でこの問題を軽減できます。

一般に、スキーマとアプリケーションの変換コストを最小限に抑えるには、これまで使用していたデータベースと、使用する新しい分散データベースの互換性を可能な限り高める必要があります。単純なケースでは、スキーマとデータを移行し、アプリケーションの接続文字列を変更するだけです。より複雑な状況では、データ変換プロセスを完了し、ストアド プロシージャとトリガーを完全に書き換え、SQL クエリを含むアプリケーションのデータ層を大幅に書き換える必要があります。

Amazon RDS と Amazon Aurora

Amazon RDS (Relational Database Service) は、ユーザーがクラウド内でリレーショナルデータベースを簡単にインストール、操作、拡張できるようにする Web サービスです。 Amazon RDS は、MySQL、MariaDB、PostgreSQL、Oracle Database、Microsoft SQL Server をサポートしています。

Amazon RDS データベースは、フェイルオーバー用の同期セカンダリインスタンスを使用して高可用性を実現できるように構成できます。残念ながら、スタンバイセカンダリインスタンスから読み取ることはできません。 MySQL、MariaDB、または PostgreSQL の読み取りレプリカを使用して読み取りスケーリングを強化できますが、レプリケーションは非同期であるため、レプリカの状態がプライマリインスタンスの状態よりも遅れる可能性があります。

Amazon Aurora は、高速分散ストレージ上で高性能な MySQL および PostgreSQL データベース クラスターを提供する Amazon RDS のサービスです。読み取り専用クエリをサポートするためにデータベース クラスターに最大 15 個の Aurora レプリカを作成でき、グローバル分散のために複数のアベイラビリティー ゾーン (AZ) にレプリカを作成することもできます。

Amazon によれば、Aurora はほとんどの既存アプリケーションを変更することなく、MySQL の最大 5 倍、PostgreSQL の最大 3 倍のスループットを実現できるとのことです。 Amazon はまた、Aurora リードレプリカの更新のレイテンシは約 20 ミリ秒であり、MySQL リードレプリカよりもはるかに高速であると主張しています。

Azure SQL データベース

Azure SQL Database は、SQL Server エンジンとの幅広い互換性を提供し、データベース リソースを動的に増減できる、完全に管理されたリレーショナル クラウド データベース サービスです。 Azure SQL Database には、地理的に分散されたセカンダリ データベースであるアクティブ ジオレプリカを作成するオプションが含まれています。

同じリージョンまたは異なるリージョンで最大 4 つのセカンダリ データベースがサポートされ、セカンダリ データベースは読み取り専用クエリにも使用できます。プライマリ データベースをセカンダリの 1 つにフェイルオーバーする必要がある場合は、手動で、または API を介して実行できます。

クラスタリックスDB

現在 MariaDB が所有する ClustrixDB は、シェアードナッシング アーキテクチャで設計された、スケールアウト型、クラスター化型、リレーショナル HTAP (ハイブリッド トランザクション/分析処理) データベースです。 ClustrixDB は主に MySQL および MariaDB と互換性があります。 ClustrixDB をレビューしたとき、この製品は空間拡張型と全文検索をサポートしていませんでした。以前のバージョンでは、両方の機能がまだ欠けています。

ClustrixDB にノードを追加すると、読み取りと書き込みをスケーリングできます。 ClustrixDB を使用すると、複数のリージョンにまたがってクラスターを展開し、予期しないリージョン障害が発生した場合でもフォールト トレランスを実現できます。独立したラボ (InfoWorld ではない) が実施したテストでは、ClustrixDB は、90 パーセントの読み取りと 10 パーセントの書き込みの負荷で、15 ミリ秒のレイテンシで 1 秒あたり 40,000 件のトランザクションを処理でき、e コマースにとってサイバー マンデーにふさわしいスケーラビリティを実現しました。

コックローチDB

CockroachDB は、Google Cloud Spanner に精通した元 Google 社員によって開発された、水平スケーラブルでオープンソースの分散型 PostgreSQL 互換 SQL データベースです。 CockroachDB は Spanner のデータ ストレージ システムの設計を借用し、Raft アルゴリズムを使用してノード間のコンセンサスを実現します。 CockroachDB は、Spanner を同期するために GPS や原子時計を必要としません。

CockroachDB は、トランザクション的に一貫性のあるキー値ストアである RocksDB に基づいています。 CockroachDB の主な設計目標は、ACID トランザクション、水平スケーラビリティ、そして (最も重要な) 存続可能性のサポートであり、これが名前の由来です。 CockroachDB はデフォルトでシリアル化可能な分離モードを使用します。これは、他のほとんどのデータベースで実装されている分離メカニズムよりも優れたパフォーマンスを発揮します。

2018 年の初めに CockroachDB をテストしたとき、その JOIN パフォーマンスはあまり良くありませんでした。この問題はその後解決されました。 CockroachDB は、複数のアベイラビリティーゾーンにわたるクラスターの分散をサポートし、Google Cloud Platform と AWS 上で完全に管理されたクラウド データベース クラスターも提供します。

Google クラウド スパナ

Google Cloud Spanner は、SQL 互換性、リレーショナル スキーマ、ACID トランザクション、外部一貫性を維持しながら、NoSQL データベースのスケーラビリティを備えたマネージド分散データベースです。 Spanner は CAP 定理を覆すように見えます。

Spanner はシャード化され、グローバルに分散され、複製され、Paxos アルゴリズムを使用してノード間の合意に達します。 Spanner は、強力な一貫性を確保するために 2 フェーズ コミットを使用しますが、Paxos グループをトランザクションのメンバーとして扱います。各 Paxos グループには、100% のメンバーシップではなく、定足数のみが必要です。

Google 社内で使用する場合、Spanner の可用性は 99.999% を超えるファイブナイン以上となり、年間のダウンタイムは 5 分未満になります。これによって、ほとんどのプログラマーは、Spanner の可用性障害を処理するためのコードを記述する必要がなくなります。

Spanner は、ANSI 2011 SQL の方言である Google Common SQL を使用します。 Common SQL は、PostgreSQL、MySQL、SQL Server、または Oracle Database で使用される SQL 方言のいずれとも同一ではなく、データ型が若干異なり、データ操作の側面も大きく異なります。

原題: 最高の分散リレーショナル データベース、著者: Martin Heller

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。

<<:  SaaSに関する10のよくある質問

>>:  IBM、340億ドルでRed Hat買収を完了:ハイブリッドクラウドのオープンな未来を定義

推薦する

「SEO は死んだ」というあなたの意見を話してください

Xiaomao は今日、A5 Marketing の公式グループでチャットをしていたのですが、SEO...

「百度アルゴリズムアップグレード」についての私の考え

6月28日のKステーション事件は人々の記憶にまだ新しい。復旧されていないKステーションサイトはまだ多...

クラウド コンピューティングの複雑さの中での可観測性を成功させるための 5 つのヒント

クラウド コンピューティングと急速なデジタル化によって増大した複雑さを制御するための新しい方法を I...

百度シェアはウェブサイトの百度ランキングに影響を与えるだろう

百度は数年前に新製品「百度シェア」を発売しました。これはウェブサイトのスナップショットの背後に表示さ...

raksmart - 米国サーバー/1Gbps帯域幅/無制限トラフィック/中国語と英語のバイリンガル+Alipay

ダウンロード、ビデオの作成、画像サイトの作成など、トラフィックの多いプロジェクトを実行する必要がある...

ウェブサイトの最適化は双方に利益のある協力が王道

現在、あらゆる分野でウィンウィンの協力が重視されています。インターネットが急速に発展する時代において...

Shi Yuzhuがウェブサイトのコンテンツを最適化する方法をガイドします

マーケティング業界の伝説的人物である石玉竹は、「巨人」、「美百品」、「黄金パートナー」などを通じて、...

hao123 映画チャンネルの SEO 分析: タイトル キーワード レイアウト

みなさんこんにちは。私は徐子宇です。 SEO に関しては、詳細な分析を行った後、多くの問題が比較的基...

Docker は問題を抱えているのでしょうか?

「Docker」や「コンテナ」という言葉は近年非常に人気がありましたが、最近急速に低迷しているようで...

Baidu のレビュー期間の長さは誰が決めるのですか?

6月28日の地震以来、Baiduの審査期間は大幅に長くなり、多くのウェブマスターから苦情が出ている。...

2020年、エンタープライズレベルのSaaSは流行によって「一時停止」されましたか?

死亡者数と感染者数は依然として増加しています。この突然の新型コロナウイルス感染症の流行により、常に重...

百度の検索独占が崩れ、ユーザーにはより多くの選択肢が与えられるかもしれない

最新の検索エンジン市場シェアデータによると、360の総合検索市場シェアは徐々に上昇しており、3月時点...

レシピウェブサイトの進化

[iTianxia.com からの注記] 数年前、レシピ ウェブサイトは単にレシピを表示するだけのも...