アプリケーションに適したデータベースを選択する方法

多くの場合、「適切な」データベースを選択することは、アプリケーションの成功にとって重要です。ベンダーのアドバイスを受けたり、データベースをすでに持っているためにデータベースを使用したりするのではなく、データストアの基本的な目的と要件を検討することが役立ちます。

これらは、データベースを選択するときに尋ねる最も重要な質問です。

  • アプリケーションが成熟したときに、どのくらいのデータを保存すると予想しますか?
  • ピーク負荷時に同時に何人のユーザーを処理すると予想しますか?
  • アプリケーションに必要な可用性、スケーラビリティ、遅延、スループット、およびデータの整合性は何ですか?
  • データベーススキーマはどのくらいの頻度で変更されますか?
  • ユーザー人口の地理的分布はどのくらいですか?
  • データの自然な「形」は何ですか?
  • アプリケーションには、オンライントランザクション処理(OLTP)、分析クエリ(OLAP)、またはその両方が必要ですか?
  • 本番環境では、読み取りと書き込みの比率はどのくらいになると思いますか?
  • 地理的クエリやフルテキストクエリが必要ですか?
  • 好きなプログラミング言語は何ですか?
  • 予算はありますか?もしそうなら、それはライセンスとサポート契約をカバーしますか?
  • データストレージに法的な制限はありますか?

それらの質問とその意味について詳しく見ていきましょう。

どのくらいのデータを保存しますか?

見積もりがギガバイト以下の場合、ほとんどすべてのデータベースがデータを処理し、インメモリデータベースは完全に実行可能です。テラバイト(数千ギガバイト)の範囲のデータを処理するためのデータベースオプションはまだたくさんあります。

答えがペタバイト(数百万ギガバイト)以上の場合は、少数のデータベースのみが適切に機能します。オンプレミスストレージの設備投資または運用コストのいずれかで、かなりのデータストレージコストに備える必要があります。クラウドストレージ。その規模では、「ライブ」データに対するクエリをメモリ内またはローカルSSDに対して実行して速度を上げ、完全なデータセットを回転するディスクに置いて経済的にできるように、階層型ストレージが必要になる場合があります。

同時ユーザーは何人ですか?

多くの同時ユーザーからの負荷を見積もることは、多くの場合、本番データベースをインストールする直前に実行されるサーバーサイジングの演習として扱われます。残念ながら、多くのデータベースは、スケーリングの問題のために、テラバイトまたはペタバイトのデータをクエリする何千ものユーザーを処理できません。

同時ユーザーの推定は、パブリックデータベースよりも従業員が使用するデータベースの方がはるかに簡単です。後者の場合、予期しない負荷や季節的な負荷に備えて、複数のサーバーにスケールアウトするオプションが必要になる場合があります。残念ながら、すべてのデータベースが、時間のかかる大きなテーブルの手動シャーディングなしで水平スケーリングをサポートしているわけではありません。

あなたの「-ility」要件は何ですか?

このカテゴリには、すべての用語が「-ility」で終わるわけではありませんが、可用性、スケーラビリティ、遅延、スループット、およびデータの整合性が含まれます。

多くの場合、可用性はトランザクションデータベースの重要な基準です。すべてのアプリケーションが99.999%の可用性で24時間年中無休で実行する必要があるわけではありませんが、必要なものもあります。いくつかのクラウドデータベースは、複数のアベイラビリティーゾーンで実行している限り、「ファイブナイン」のアベイラビリティーを提供します。オンプレミスデータベースは通常、スケジュールされたメンテナンス期間外に高可用性を実現するように構成できます。特に、アクティブとアクティブのサーバーのペアをセットアップする余裕がある場合はそうです。

スケーラビリティ、特に水平スケーラビリティは、SQLデータベースよりもNoSQLデータベースの方が歴史的に優れていましたが、いくつかのSQLデータベースが追いついてきています。動的なスケーラビリティは、クラウドで実現するのがはるかに簡単です。スケーラビリティの高いデータベースは、スループットが負荷に対して十分になるまでスケールアップまたはスケールアウトすることで、多数の同時ユーザーを処理できます。

レイテンシーとは、データベースの応答時間とアプリケーションのエンドツーエンドの応答時間の両方を指します。理想的には、すべてのユーザーアクションの応答時間は1秒未満です。これは多くの場合、単純なトランザクションごとに100ミリ秒未満で応答するデータベースが必要であることを意味します。多くの場合、分析クエリには数秒または数分かかることがあります。アプリケーションは、複雑なクエリをバックグラウンドで実行することにより、応答時間を節約できます。

OLTPデータベースのスループットは通常、1秒あたりのトランザクション数で測定されます。高スループットのデータベースは、多くの同時ユーザーをサポートできます。

SQLデータベースの場合、データの整合性は通常「強力」です。つまり、すべての読み取りで最新のデータが返されます。NoSQLデータベースの場合、データの整合性は「最終的」から「強力」までさまざまです。結果整合性は、古いデータを読み取るリスクを伴いながら、待ち時間を短縮します。

整合性は、エラー、ネットワークパーティション、および電源障害が発生した場合の有効性に必要なACIDプロパティの「C」です。4つのACIDプロパティは、原子性、一貫性、分離、および耐久性です。

データベーススキーマは安定していますか?

データベーススキーマが時間の経過とともに大幅に変更される可能性が低く、ほとんどのフィールドにレコード間で一貫したタイプを持たせたい場合は、SQLデータベースが適しています。それ以外の場合は、NoSQLデータベース(一部はスキーマさえサポートしていない)がアプリケーションに適している可能性があります。ただし、例外があります。たとえば、Rocksetでは、インポートするデータに固定スキーマや一貫性のあるタイプを課すことなく、SQLクエリを実行できます。

ユーザーの地理的分布

データベースユーザーが世界中にいる場合、その地域に追加のサーバーを提供しない限り、光の速度によってリモートユーザーのデータベース遅延に下限が課せられます。一部のデータベースでは、分散型の読み取り/書き込みサーバーが許可されています。他のサーバーは分散読み取り専用サーバーを提供し、すべての書き込みは単一のマスターサーバーを経由するように強制されます。地理的な分布により、一貫性と遅延の間のトレードオフがさらに困難になります。

グローバルに分散されたノードと強力な整合性をサポートするデータベースのほとんどは、コンセンサスグループを使用して、整合性を大幅に低下させることなく書き込みを高速化します。通常、Paxos(Lamport、1990)またはRaft(Ongaro and Ousterhout、2013)アルゴリズムを使用します。結果整合性のある分散NoSQLデータベースは通常、非コンセンサスのピアツーピアレプリケーションを使用します。これにより、2つのレプリカが同じレコードへの同時書き込みを受信すると競合が発生する可能性があり、競合は通常、ヒューリスティックに解決されます。

データの形

SQLデータベースは、古典的に、強い型のデータを行と列のある長方形のテーブルに格納します。これらは、テーブル間の定義された関係に依存し、インデックスを使用して選択したクエリを高速化し、JOINSを使用して複数のテーブルを一度にクエリします。ドキュメントデータベースは通常、配列やネストされたドキュメントを含む可能性のある弱い型のJSONを格納します。グラフデータベースは、頂点とエッジ、トリプル、またはクワッドのいずれかを格納します。他のNoSQLデータベースカテゴリには、Key-Valueストアと列ストアが含まれます。

データは、分析にも役立つ形で生成される場合があります。そうでない場合もあり、変換が必要になります。ある種類のデータベースが別の種類のデータベース上に構築される場合があります。たとえば、Key-Valueストアは、ほぼすべての種類のデータベースの基礎となる可能性があります。

OLTP、OLAP、またはHTAP?

上記の頭字語のスクランブルを解除するには、アプリケーションにトランザクション、分析、またはその両方のデータベースが必要かどうかが問題になります。高速トランザクションが必要な場合は、書き込み速度が速く、インデックスが最小限であることを意味します。分析が必要なことは、読み取り速度が速く、インデックスが多いことを意味します。ハイブリッドシステムは、レプリケーションを通じてセカンダリ分析ストアにフィードするプライマリトランザクションストアを持つなど、さまざまなトリックを使用して両方の要件をサポートします。

読み取り/書き込み比率

一部のデータベースは読み取りとクエリが高速であり、他のデータベースは書き込みが高速です。アプリケーションに期待する読み取りと書き込みの組み合わせは、データベースの選択基準に含めるのに役立つ数であり、ベンチマークの取り組みをガイドすることができます。インデックスタイプの最適な選択は、読み取りが多いアプリケーション(通常はBツリー)と書き込みが多いアプリケーション(多くの場合、ログ構造のマージツリー、別名LSMツリー)で異なります。

地理空間インデックスとクエリ

地理データまたは幾何学的データがあり、境界内のオブジェクトまたは場所の特定の距離内のオブジェクトを見つけるために効率的なクエリを実行する場合は、通常のリレーショナルデータの場合とは異なるインデックスが必要です。多くの場合、地理空間インデックスにはRツリーが推奨されますが、他にも12を超える地理空間インデックスデータ構造が考えられます。空間データをサポートするデータベースは数十あります。ほとんどは、Open GeospatialConsortium標準の一部またはすべてをサポートしています。

フルテキストインデックスとクエリ

同様に、テキストフィールドの効率的な全文検索には、リレーショナルデータや地理空間データとは異なるインデックスが必要です。通常、トークン化された単語の転置リストインデックスを作成し、それを検索して、コストのかかるテーブルスキャンを回避します。

推奨されるプログラミング言語

ほとんどのデータベースは多くのプログラミング言語のAPIをサポートしていますが、アプリケーションで優先されるプログラミング言語がデータベースの選択に影響を与える場合があります。たとえば、JSONはJavaScriptの自然なデータ形式であるため、JavaScriptアプリケーションのJSONデータ型をサポートするデータベースを選択することをお勧めします。強く型付けされたプログラミング言語を使用する場合は、強く型付けされたデータベースを選択することをお勧めします。

予算上の制約

データベースの価格は、無料から非常に高価なものまでさまざまです。多くのデータベースには無料バージョンと有料バージョンの両方があり、エンタープライズバージョンやさまざまなサービス応答時間を提供するなど、複数のレベルの有料サービスがある場合もあります。さらに、一部のデータベースは、従量課金制でクラウドで利用できます。

無料のオープンソースデータベースを選択した場合、ベンダーのサポートを放棄しなければならない場合があります。社内に専門知識がある限り、それで問題ないかもしれません。一方、アプリケーションに集中し、データベースの管理と保守をベンダーまたはクラウドプロバイダーに任せる方が生産性が高い場合があります。

法的規制

データのセキュリティとプライバシーについては多くの法律があります。EUでは、GDPRはプライバシー、データ保護、データの場所に幅広い影響を及ぼします。米国では、HIPAAが医療情報を規制し、GLBAが金融機関が顧客の個人情報を処理する方法を規制しています。カリフォルニアでは、新しいCCPAがプライバシー権と消費者保護を強化しています。

一部のデータベースは、ベストプラクティスに従っている限り、これらの規制の一部またはすべてに準拠する方法でデータを処理できます。他のデータベースには欠陥があり、どんなに注意を払っても、個人を特定できる情報に使用することは非常に困難です。

正直なところ、それはデータベースを選択するときに考慮すべき要素の長いリストであり、おそらくあなたが考慮したいよりも多いでしょう。それでも、不十分または過度に高価なデータベースであることが判明したプロジェクトにプロジェクトをコミットするリスクを冒す前に、チームの能力を最大限に発揮してすべての質問に答えることを試みる価値があります。