リレーショナル データベースは、長い間、大企業や中小企業が解決しなければならないさまざまな (そしてほぼすべての) ソフトウェア ユース ケースに対する非常に標準的なソリューションでした。
現在、NoSQL、インメモリ、またはデータ レイク データベースの可用性が向上したことで、変動性ははるかに大きくなっています。 それにもかかわらず、現在のオンプレミス データベースをクラウドに移行する決定が下されるときはいつでも、ターゲットとしてのリレーショナル データベースは、この移行の最も簡単なオプションです。
このようなイニシアチブの一部となる可能性のある次のデータベースを詳しく見ていきます。
- オラクル
- オーロラ
- マイクロソフト SQL サーバー
- MySQL & PostgreSQL
- マリアDB
それらが他のものとどのように異なり、何がそれらを際立たせているか、それらの欠点を含めて明確にします. 次に、典型的な実際の使用例を示して、それらを文脈に取り入れます。 最後に、あなたのケースで異なるデータベースを決定する際の私の見解を共有します.
AWS オラクル DB
ソース: aws.amazon.com
Oracle DB は、間違いなく過去数十年で最も広く使用されている商用データベースでした。 企業が堅牢で高性能なデータベース ソリューションを必要とするときはいつでも、Oracle DB が最初の選択肢でした。 そして、多くの正当な理由があります。
違い
Oracle は堅牢で機能が豊富なプラットフォームであり、まったく異なる設定や要件に対しても膨大な量のサービスを提供できます。 時間の経過とともに、オンプレミスのハードウェア インフラストラクチャ上で最先端の信頼性、スケーラビリティ、および保守性が必要な場合に備えて、この DB は究極の頼りになるソリューションになりました。
主な利点
Oracle のような成熟したデータベース システムを選択した場合に得られる主な利点のいくつかを次に示します。
✅ 効果的なバックアップおよび復元アクティビティのための優れたサポートとオプション。
✅ システム内の DB ソリューションのパフォーマンスを調整する方法の幅広い可能性。 ずっと後になっても、ソリューションはすでに運用されています。 このプラットフォーム内でのサポートおよび保守活動は、セットアップが非常に簡単で、非常に効果的です。
✅ DB ソリューションの高度なカスタマイズ。 Oracle DBは幅広い機能から選択できるため、システム・インテグレータには、プラットフォームが必要とする機能(トリガー、パーティション、サブパーティション、自動化された主キー・シーケンス、ビューなど)で構成される堅牢なシステムを構築するための多くのオプションがあります。 、スナップショット、データ制約、一意キー、結合キー、外部キー、複合インデックスなど)。 すべてをサポートします。
✅ データベースのアクティビティとプロセスを簡単に管理できます。 専用の管理コンソールとダッシュボード、およびオラクルが作成し、すぐに使用できる管理者専用の多くのツール。
✅ マルチユーザー環境のサポート。 要件が、何千もの異なるアクティブ ユーザーを同時にサポートすることである場合、Oracle がその答えです。
主な欠点
Oracle DB は、パフォーマンスの垂直スケーリングに関して非常に柔軟です。 ただし、強力な水平方向のスケーリングが必要な場合はそうではありません。 つまり、より強力な CPU、より多くのメモリ、およびクラスター DB のストレージ スペースに簡単にアップグレードできます。
しかし、データが短期間で大幅に増加する場合 (クラウド内のデータでよくあるケースです)、パフォーマンスのボトルネックがより顕著になり、解決が難しくなります。 データを複数のクラスターに分散させ、それらが動的に成長することを期待することが、今後の主な要件になります。 この場合、Oracle DB が将来のニーズを満たすよりも制限的になり始めていることに気付くかもしれません。
もう1つの考えられる欠点は、コストです。 Oracle DB は多くの機能をサポートしていますが、その多くにはコストがかかります。 複数のクラスターが配置されていて、物理的なパフォーマンスのアップグレードが必要な場合はなおさらです。 つまり、データ モデルのソフトウェア チューニングはもはや十分ではありません。 より多くの管理ツールと機能を利用するには、エンタープライズ ライセンスを購入する必要があります。 これにより、すでに高いコストがさらに増加します。
最後に、Oracle DB はネイティブの AWS DB サービスではないため、AWS からの完全なサポートは期待できません。 むしろ、Oracle サポートに向けてください。 ただし、Oracle と AWS の問題点に並行して対処し、2 つの異なるサポート チームのセットに対処します。
いつ選択するか
現在のオンプレミス ソリューションがすでに Oracle DB を使用している場合は、Oracle DB に対応するクラウドを選択するのが最も自然な決定です。 また、クラウドベースのソリューションへの移行と切り替えが可能な限り簡単になります。
したがって、次の場合は AWS Oracle DB を選択します。
- クラウド DB は、近い将来、オンプレミスのバリアントと同じプロセスと機能をサポートすると予想されます。
- DB を非常に多くの AWS ネイティブ サービスとすぐに統合する予定はありません。
- 現在のデータ量が短期間で大幅に増加するとは思わない。
- 膨大な量の機能を適切にサポートする必要があります。 つまり、クラウドに切り替えたときに、現在配置されているそれらの一部を失うことは困難です。
- システムは、同時に何百人 (またはそれ以上) のアクティブ ユーザーをサポートする必要があります。
使用例
- 課金、CRM、およびミドルウェア データ用の大規模な通信システム。
- いくつかの異なるカスタム ツールまたはサードパーティ ベンダー ツールと統合された、自動車データベース システム用のカスタム DB 実装。
- 銀行業界向けのパッケージ システム ソリューション。Oracle はベンダーからのパッケージ ソリューションの固定部分であり、最終的には追加のカスタム DB コンポーネントを 1 つの複雑な実装に統合します。
AWS オーロラ DB
ソース: aws.amazon.com
多くの点で、Aurora は、依然としてリレーショナル データベースであっても、Oracle の正反対です。
違い
Autora DB は、AWS のネイティブ データベース サービスです。 AWS は、完全なサポートと継続的な開発を提供し、他の AWS サービス エコシステムと深く統合します。
Aurora DB は、Oracle がすでに持っているような機能の多様化のレベルには達していません。 しかし、それはクラウドで生まれました (Oracle とは異なります)。 AWS はさらに Aurora を開発しているため、将来的に機能のギャップは現在よりも小さくなる可能性があります。
多くの点で、特に他の AWS クラウド サービスとの統合に関して、Aurora はすでに Oracle よりも進んでいます。 また、Amazon はクラウド エコシステムを念頭に置いて Aurora を作成したため、Aurora は大量のデータ収入と時間の経過とともに増加する準備ができているため、水平スケーリングは強力な特性です。
主な利点
Aurora DB の主な利点は次のとおりです。
✅ 読み取り専用 DB コピー インスタンスの非常に柔軟な拡張性。 ほんの数秒で作成できるもの。 読み取り専用インスタンスは、元のメイン データベースの同じ DB ログを共有します。 つまり、新しい読み取り専用データベースを作成するために、すべてのデータを同期する必要はありません。 既存のものを共有することで自動的に行われます。
✅ 大規模なデータの増加に対応 – 水平スケーリングは Aurora DB の大きな特徴です。 新しいクラスターを追加し、異なるアベイラビリティ ゾーン間でスケーラビリティを拡張することは、非常に簡単です。 Aurora は、大量のデータを非常に高速に選択するのに非常に効果的です。
✅ Aurora DB のサーバーモードとサーバーレスモードのどちらを使用するかを選択できます。 サーバーレス モードでは一部の機能が失われます。 ただし、サーバーレス モードを選択すると、多くの柔軟性とコストの最適化が得られます。
✅ 自動バックアップと簡単な特定時点への復帰。 もう 1 つのハイライトは、Aurora DB が簡単な毎日のバックアップを実行できることと、完全なデータベースを任意の時点に復元することがはるかに簡単であることです。 ここでは、クラウド環境のすべての利点を組み合わせることができます。これには、常に利用可能な空きスペース、高速な内部 AWS 操作、および高速な復旧時間と短いダウンタイムを目標とする専用の Aurora DB 機能があります。
✅ MySQL または PostgreSQL DB エンジンのいずれかをサポートしているため、どちらか適切なものを選択できます。
主な欠点
- Aurora はおそらく、AWS で選択できる最も機能豊富なネイティブ リレーショナル データベースですが、この点ではまだ Oracle に遅れをとっています。 それは理解できます。 オラクルには、過去にこれらの機能を開発するためのより多くの時間がありました。 Aurora DB は、リリースごとに、より強力になり、より近くなっているという事実は変わりません。
- オンプレミス空間には Aurora DB に相当するものはありません。 MySQL または PostgreSQL データベース内に構築された古いデータベースはほぼ一致すると主張することができます。 しかし、それらは厳密に同等ではありません。 つまり、移行はそれほど単純ではありません。 移行プロセスをカスタマイズして実装し、オンプレミスからデータを転送して Aurora DB に保存することを、すべて正しいデータモデル形式で行う必要があります。
- さまざまな AWS の制限、特に厳しい制限は、場合によっては、この DB を先に進むためのターゲットとして選択することを妨げる可能性がある要因です。 それらすべてを回避できる可能性は非常に高いですが、場合によっては、リファクタリングへのより深刻な投資が必要になる場合があります。これにより、最終的に、別のデータベース ターゲットと比較して、移行の全体的なコストが増加する可能性があります。
いつ選択するか
一言で言えば、AWS プラットフォームで goto リレーショナル データベースとして Aurora DB を選択することは決して悪い決定ではありませんが、特に次の場合は選択してください。
- リレーショナル データベースを中心にクラウド システムをゼロから構築します。
- 可能な限りさまざまなネイティブ AWS サービスとの最高レベルの互換性と統合性が期待されます。
- 短期間でデータ量が大幅に増加することが予想されます。
- リレーショナル データベースのサーバーレス バージョンのすべての利点を活用できる、いくつかのスピンオフの概念実証 (POC) プロジェクトを開始する予定です。
使用例
- 大量のインフラストラクチャ画像データを分析するためのサーバーレス プラットフォーム。
- 機械学習モデルを利用してデータレイク情報を処理し、ビジネスのビジネス予測を生成します。
- Netflix は Aurora DB を使用して、カタログ データに対する高速な並列クエリを実行しています。
AWS Microsoft SQL DB
ソース: aws.amazon.com
このデータベースは、いくつかの点で Oracle に匹敵します。 また、クラウドが本格化するずっと前に作成されたものであり、現在、MS SQL DB をソースとしてクラウドへの移行を計画しているオンプレミス ユーザーが多数います。
違い
これらの類似点にもかかわらず、MS SQL DB は、Oracle DB と比較して、過去にはあまり使用されていませんでした。
少なくとも私の個人的な経験の観点から判断すると。 過去 20 年間、私は複数の Oracle プロジェクトに関与していましたが、MS SQL DB が関与したケースはほんの一握りでした。 率直に言って、私は Oracle DB ほど扱いたくありませんでした。
いずれにせよ、MS SQL DB をすべてのデータの唯一の真実であるメイン データベースとして使用している企業の大部分を今でも認識しています。
主な利点
MS SQL DB の主な利点:
✅ 他のマイクロソフトのサービスやソフトウェアとの優れた統合。これがあなたのケースにとって価値があると認識している機能である場合に備えて。
✅ 主に Javascript コード モジュールの形式のカスタム コード拡張による簡単なカスタマイズ。 これは、より複雑なビジネス プロセスやジョブをデータベース上でスケジュールする場合に役立ちます。
✅ 管理の観点からは非常に単純です (少なくとも Oracle DB と比較すると)。
✅ Azure クラウド エコシステムでは、ネイティブのリレーショナル データベース システムと見なされ、他のクラウド サービスとの互換性がはるかに高いため、おそらくはるかに理にかなっています。
主な欠点
- Oracle DB の場合と同様に、AWS クラウドのスペース内の非ネイティブ データベースとして、すべてのサポートと問題解決は、別の専任の MS SQL サポート チームによって推進される必要があります。
- Oracle DB や Aurora DB と比較すると、一般的に機能サポートの多様性が低くなります。
- 多数のアクティブ ユーザーには適していません。
- 水平方向のスケーラビリティは、Oracle DB の場合よりもさらに大きな問題です。
いつ選択するか
MS SQL DB は、オンプレミスの既存の MS SQL DB をクラウドに移行し、気を散らすものをできるだけ少なくしたい場合に最適です。 また、他の AWS クラウド サービスとの統合はあまり期待できません。
次に、MS SQL DB は AWS クラウド内に完全に管理されたデータベースとして存在し、無制限のストレージと、オンプレミスの代替と比較して水平方向のスケーラビリティと高可用性のための拡張オプションを備えています。
使用例
- さまざまなデータベース システムをカスタム統合するための中間プラットフォームとして機能します (たとえば、Oracle DB など、異なるタイプの場合もあります)。
- データベース ソリューションのコストを考慮する必要があり、予算が限られているさまざまな小規模プロジェクト (本格的な Oracle DB ソリューションを導入することはできません)。
AWS MySQL および PostgreSQL DB
ソース: aws.amazon.com
これらのデータベースは両方ともオープンソースであり (現在はすでに大企業に買収されています)、最終的にはメリットとデメリットの両方をもたらします。
また、特にネイティブ形式では、他の代替手段ほど機能が豊富ではありません. そして、AWS インフラストラクチャでこの形式で両方を引き続き使用できますが、これが実用的な意味を持ちすぎるとは思えません。
違い
オンプレミス DB (MySQL または PostgreSQL) を AWS クラウドに移行する場合、Aurora を MySQL または PostgreSQL エンジンをターゲットとして直接使用するだけで、Aurora DB が提供するすべての追加の利点を得ることができます。
確かに、ネイティブの代替手段が選択される場合と比較して、移行フェーズに追加の労力がかかることを意味します. しかし、その追加の努力はほんのわずかです。
それらの主な利点はコストにあり、堅牢性が実際には問題にならない小規模なプロジェクト イニシアチブに最適です。
主な欠点
- どちらもサポートされる機能がかなり制限されており、保守性と管理のための限られたオプションに備えておく必要があります。
- 多くのアクティブ ユーザーがいる大規模なプロジェクトには適していません。
- 高性能ソリューションや、一定のパフォーマンス チューニングが強く求められる場合には最適ではありません。
いつ選択するか
- コストが主なトピックで、予算が非常に限られている場合。
- プロジェクトのイニシアチブがかなり小さい場合。
- データ量がかなり少なく、大幅な増加の計画がない場合。
使用例
- インフラストラクチャのコストを最小限に抑える個人プロジェクト イニシアチブ。
- 提案されたコンセプトが実現可能であることを証明する小さな POC。
- 少量のデータを使用する中小企業のプロジェクト。
- 大量のデータベース負荷を必要としない小規模な SaaS プロジェクトの場合、リレーショナル データ モデルの方法でのデータ ストレージだけが本当に必要なすべてです。
AWS MariaDB
ソース: aws.amazon.com
MariaDB は、以前の MySQL 開発者 (Oracle による MySQL の買収後) によって作成された、完全にオープンソースのデータベースです。
互換性に関しては、どの MySQL DB も MariaDB 内で問題なく動作します。
違い
機能的には MySQL との違いはあまりありませんが、オープン ソースの特性が際立っています。
技術的には、MySQL ではなく MariaDB で利用できる便利な機能が多数あります。
主な欠点
MySQL の場合と非常によく似ています。
いつ選択するか
- 現在の MariaDB オンプレミス実装が気に入っていて、何らかの理由で Aurora DB に移行したくない場合。
- AWS クラウド エコシステム内のデータベース ソリューションで真のオープンソースを維持したい場合。
使用例
MySQL の場合と非常によく似ています。
最後の言葉
同様に、オンプレミスの世界では Oracle DB がソリューションであったように、AWS クラウドの世界では Aurora DB がこれに取って代わっているようです。 少なくとも機能セットの観点からは、これが最も近いものです。
また、主要な利害関係者をあまり気にしていない場合でも、既存のデータベースを AWS クラウドに移行する方法について、非常に簡単なオプションがあることを知っておくとよいでしょう。
さらに良いことに、このスイッチを使用すると、それまで不足していた可能性が最も高い機能が自動的に取得されます. 最も重要なことは、優れたストレージの拡張性、高可用性、および水平方向のスケーラビリティはすべて、クラウド環境のネイティブ機能です。
