リレーショナル データベースは、長い間、大企業または中小企業が解決する必要があるさまざまな (そしてほぼすべての) ソフトウェア ユース ケースに対する非常に標準的なソリューションでした。
現在、NoSQL データベース、インメモリ データベース、またはデータ レイク データベースの可用性が広くなっているため、その変動性はさらに大きくなっています。しかし、それにもかかわらず、現在のオンプレミス データベースをクラウドに移行する決定がなされるときは常に、ターゲットとしてリレーショナル データベースがこの移行の最も簡単なオプションであることに変わりはありません。
このような取り組みの一部となる可能性のある次のデータベースを詳しく見ていきます。
- オラクル
- オーロラ
- Microsoft SQLサーバー
- MySQL と PostgreSQL
- マリアDB
他のものとどう違うのか、デメリットも含めて何が違うのかを明確に説明します。次に、典型的な実際の使用例を示して、それらをコンテキストに取り入れます。最後に、あなたのケースに応じて異なるデータベースのどちらを選択するかについての私の見解を共有します。
AWS オラクル DB

Oracle DB は間違いなく、過去数十年間で最も広く使用されている商用データベースでした。企業が堅牢で高性能のデータベース ソリューションを必要とするときは常に、Oracle DB が最初の選択肢でした。それには多くの正当な理由があります。
どう違うのか
Oracle は、まったく異なるセットアップや要件にも膨大な量の対応ができる、堅牢で機能が豊富なプラットフォームです。時間が経つにつれ、この DB は、オンプレミスのハードウェア インフラストラクチャ上で最先端の信頼性、拡張性、保守性が必要な場合に最適なソリューションとなりました。
主な利点
Oracle のような成熟したデータベース システムを選択した場合に得られる主な利点のいくつかを以下に示します。
✅ 効果的なバックアップと復元アクティビティのための優れたサポートとオプション。
✅ システム内の DB ソリューションのパフォーマンスを調整する方法の幅広い可能性。それからずっと後でも、ソリューションはすでに運用されています。このプラットフォーム内のサポートとメンテナンスのアクティビティはセットアップが非常に簡単で、非常に効果的です。
✅ DB ソリューションの高度なカスタマイズ。 Oracle DBは選択できる広範な機能をサポートしているため、システム・インテグレータには、プラットフォームに必要な機能(トリガー、パーティション、サブパーティション、自動化された主キー・シーケンス、ビューなど)で構成される堅牢なシステムを構築するためのオプションが豊富にあります。 、スナップショット、データ制約、一意キー、結合キー、外部キー、複合インデックスなど)。すべてをサポートしてくれます。
✅ データベースのアクティビティとプロセスの管理が簡単。専用の管理コンソールとダッシュボード、およびオラクルによって作成され、すぐに使用できる管理者専用の多くのツール。
✅ マルチユーザー環境のサポート。要件が数千の異なるアクティブ ユーザーを同時にサポートすることである場合、Oracle がその答えです。
主な欠点
Oracle DB は、パフォーマンスの垂直方向のスケーリングに関して非常に柔軟です。ただし、強力な水平スケーリングが必要な場合は、それほど重要ではありません。つまり、クラスター DB 上のより強力な CPU、より多くのメモリ、ストレージ スペースに簡単にアップグレードできます。
しかし、データが短期間に大幅に増加すると、これはクラウド内のデータでよく起こるケースであり、パフォーマンスのボトルネックがより顕著になり、解決が困難になります。データを複数のクラスターに分散し、それらが動的に増加することを期待することが、今後の主な要件になります。この場合、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

Aurora は、依然としてリレーショナル データベースであるにもかかわらず、多くの点で Oracle の正反対です。
どう違うのか
Autora DB は、AWS のネイティブ データベース サービスです。 AWS は、これに完全なサポートと継続的な開発を提供し、他の AWS サービス エコシステムと深く統合します。
Aurora DB は、Oracle がすでに備えている機能の多様化レベルには達していません。しかし、それは (Oracle とは異なり) クラウドで生まれました。 AWS は Aurora をさらに開発しているため、機能のギャップは将来的には現在よりも小さくなる可能性があります。
Aurora は多くの点で、特に他の AWS クラウド サービスとの統合に関して、すでに 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 に遅れをとっています。それは理解できます。 Oracle は以前はこれらの機能を開発するのにはるかに多くの時間を費やしていました。 Aurora DB がリリースごとにさらに強力になり、さらに近づいているという事実は変わりません。
- オンプレミススペースには Aurora DB に相当するものはありません。 MySQL または PostgreSQL データベース内に構築された古いデータベースはほぼ一致していると主張することもできますが、互換性の観点からは、確かに一致しています。しかし、それらは厳密に同等ではありません。つまり、移行はそれほど簡単ではないということです。オンプレミスからデータを転送し、それをすべて正しいデータモデル形式で Aurora DB に保存するには、移行プロセスをカスタマイズして実装する必要があります。
- AWS のさまざまな制限、特に厳しい制限は、場合によっては、今後のターゲットとしてこの DB を選択することを妨げる要因となる可能性があります。それらすべてを回避できる可能性は非常に高いですが、一部のものについては、リファクタリングへのより本格的な投資が必要となり、最終的には別のデータベース ターゲットと比較して移行の全体的なコストが増加する可能性があります。
いつ選択するか
一言で言えば、AWS プラットフォームの goto リレーショナル データベースとして Aurora DB を選択することは決して悪い決断ではありませんが、特に次の場合にはそうしてください。
- リレーショナル データベースを中心としたクラウド システムを一から構築します。
- 可能な限りさまざまなネイティブ AWS サービスとの最高レベルの互換性と統合性が期待されます。
- データ量が短期間で大幅に増加すると予想されます。
- あなたは、リレーショナル データベースのサーバーレス バージョンの利点をすべて活用できる、いくつかのスピンオフの概念実証 (POC) プロジェクトを開始する予定です。
使用例
- 大量のインフラストラクチャ画像データを分析するためのサーバーレス プラットフォーム。
- 機械学習モデルを利用してデータ レイク情報を処理し、ビジネスのビジネス予測を生成します。
- Netflix は、カタログ データに対する高速な並列クエリ実行に Aurora DB を使用しています。
AWS Microsoft SQL DB

このデータベースは、ある意味、Oracle に匹敵します。また、クラウドが普及するずっと前に作成されたものであり、MS SQL DB をソースとして使用してクラウドへの移行を計画している現在のオンプレミス ユーザーが多数います。
どう違うのか
これらの類似点にもかかわらず、MS SQL DB は依然として、Oracle DB と比較して過去にあまり使用されていませんでした。
少なくとも私の個人的な経験の観点から判断すると。私は過去 20 年間にわたって複数の Oracle プロジェクトに関わってきましたが、MS SQL DB が関与したのはほんの一握りのケースだけでした。そして率直に言って、私は Oracle DB ほどこれを扱うのが好きではありませんでした。
いずれにせよ、私は依然として、大部分の企業が MS SQL DB を、すべてのデータに対する単一の信頼点であるメイン データベースとして使用していることを認識しています。
主な利点
MS SQL DB の主な利点は次のとおりです。
✅ 他の Microsoft サービスおよびソフトウェアとの優れた統合 (これがお客様のケースにとって価値があると認識される機能の場合)。
✅ カスタム コード拡張機能 (主に Javascript コード モジュールの形式) による簡単なカスタマイズ。これは、より複雑なビジネス プロセスやデータベース上でスケジュールされるジョブを扱う場合に役立ちます。
✅ 管理の観点から見ると非常にシンプルです (少なくとも Oracle DB と比較して)。
✅ Azure クラウド エコシステムでは、ネイティブ リレーショナル データベース システムと考えられており、他のクラウド サービスとの互換性がはるかに高いため、おそらく 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 インフラストラクチャで両方を使用することはできますが、これが実際的にあまり意味があるとは思えません。
どう違うのか
オンプレミス DB (MySQL または PostgreSQL) を AWS クラウドに移行する場合、MySQL または PostgreSQL エンジンをターゲットとして Aurora を直接使用するだけで、Aurora DB が提供する追加のメリットをすべて得ることができます。
確かに、ネイティブの代替手段が選択された場合と比較して、移行フェーズでの追加の労力が必要になります。しかし、その追加の努力はほんのわずかなものにすぎません。
その主な利点はコストにあり、堅牢性がそれほど重要ではない小規模なプロジェクトの取り組みに最適です。
主な欠点
- どちらもサポートされる機能が非常に限られているため、保守性と管理のオプションが限られていることを覚悟する必要があります。
- アクティブ ユーザーが多い大規模プロジェクトには適していません。
- 高性能ソリューションや、継続的なパフォーマンス調整が強く求められる場合には最適ではありません。
いつ選択するか
- コストが主なテーマであり、予算が非常に限られている場合。
- プロジェクトの取り組みが比較的小規模な場合。
- データ量がかなり少なく、大幅な増加の予定がない場合。
使用例
- インフラストラクチャのコストを可能な限り最小限に抑えた個人プロジェクトの取り組み。
- 提案されたコンセプトが実現可能であることを証明する小規模な POC。
- 少量のデータを使用する小規模企業のプロジェクト。
- 小規模な SaaS プロジェクトの場合、大量のデータベースの読み込みは必要なく、実際に必要なのはリレーショナル データ モデルの方法でのデータ ストレージだけです。
AWS マリアDB

MariaDB は、(Oracle による MySQL の買収後) 元 MySQL 開発者によって作成された完全なオープンソース データベースです。
互換性の点では、どの MySQL DB も MariaDB 内で問題なく動作します。
どう違うのか
機能的には、MySQL との違いはそれほど多くありませんが、オープンソースであることが注目に値します。
技術的には、MariaDB では利用できても MySQL では利用できない便利な機能が数多くあります。
主な欠点
MySQL の場合と非常によく似ています。
いつ選択するか
- 現在の MariaDB のオンプレミス実装がとても気に入っていて、何らかの理由で Aurora DB に移行したくない場合。
- AWS クラウド エコシステム内でデータベース ソリューションを真のオープンソースに保ちたい場合。
使用例
MySQL の場合と非常によく似ています。
最後の言葉
同様に、オンプレミスの世界では Oracle DB がソリューションでしたが、AWS クラウドの世界でも Aurora DB がその地位を占めているようです。少なくとも機能セットの観点からは、これが最も近いものになります。
また、主要な関係者を実際に追求していない場合でも、既存のデータベースを AWS クラウドに移行する方法については、非常に簡単なオプションがまだあることを知っておくと良いでしょう。
さらに良いことに、このスイッチを使用すると、それまで不足していた可能性が高い機能が自動的に得られるようになります。最も重要なことは、優れたストレージ拡張性、高可用性、水平スケーラビリティはすべてクラウド環境のネイティブ機能であることです。