将来を見据えたウェブ・アプリケーションの構築:The Codestのエキスパート・チームによる洞察
The Codestが、最先端技術を駆使してスケーラブルでインタラクティブなウェブアプリケーションを作成し、あらゆるプラットフォームでシームレスなユーザー体験を提供することにどのように秀でているかをご覧ください。The Codestの専門知識がどのようにデジタルトランスフォーメーションとビジネス...
新しいプロジェクトの作成には、データを保存するための適切なデータベースの選択が含まれる。私の知る限り、多くの開発者は最初からデフォルトでリレーショナル・データベースを選んでいる。しかし、それは最善の選択なのだろうか?もちろん、それは多くの要因によります。この記事では、他の種類のデータベースを紹介することで、あなたの選択を容易にし、今後の取り組みに役立てたいと思います。
データベースの種類だけが考慮すべきトピックではありません。例えば、アプリケーションには何人のアクティブユーザーがいるのか?どこでも強力な一貫性が必要なのか?場合によっては、最終的な一貫性で十分なのでしょうか?などなど。"ハマればハマるほどややこしくなる "ので、明確な答えのない質問がたくさんあります。ですから、この記事はデータベースの種類だけに焦点を当てていることに注意してください。
コーヒーでも飲みながら、この読書を楽しもう。
最初に、データベースには大きく分けてリレーショナル(SQL)とノンリレーショナル(NoSQL)の2種類があることを知っておくといいだろう。
上記の2種類とは別に、もう1種類、つまりインメモリデータベースがある。これは、データが物理的に保存されている場所に関係するため、リレーショナルにもノンリレーショナルにも分類できない。どのデータベースもディスクに格納されることもあれば、メモリに格納されることもある。
私見では、最もポピュラーなタイプのデータベースである。レコード間の関係を保持したい構造的なデータに適している。データベースの構造はスキーマに記述される。
主な利点は、トランザクション(データの整合性を保証し、ACIDルールに従うのに役立つ)と、複雑なクエリを大量に処理する能力である。
構造的にあまり変化がなく、永続的に保存する必要があるデータなどを保存するのに便利です:
Amazon Aurora、Microsoft Azure SQLデータベース、PostgreSQL、MySQL。
リレーショナル・データベースは多くの新しいアプリケーションには不十分であり、複数のデータベースを持つ必要がある。次のパートでは、非リレーショナル・データベースに焦点を当てます。
各データ値を一意のキーで保存する。つまり、ハッシュマップと同じように、単一のキーでデータにアクセスする。リレーショナル・データベースとは対照的に、スキームもレコード間の関係も強制しない。これらのデータベースのほとんどは、通常、更新操作をサポートしていない。データを変更するには、既存のセットをすべて上書きしなければならない。
高速に読み書きしたい(しかし更新頻度は高くない)データに便利だ:
Memcached、Amazon DynamoDB、Azure Cosmos DB、Redis。
ドキュメントのコレクションを保存する。各ドキュメントにはデータのフィールドがあり、単純な値であったり、リストや子コレクションのような複雑な要素であったりする。重要なのは、たとえ同じものを表現していたとしても、すべてのドキュメントは異なる構造を持つ可能性があるということです(各ドキュメントはユニークで、時間とともに進化します)。例えば、最初の顧客ドキュメントは2番目の顧客ドキュメントよりも少ない情報しか含んでいません:
{
"FirstName":"John"、
"LastName":"Fake"、
「バイク:" [
{
"Model":"BMW"、
"年":2020
}
]
}
{
"FirstName":"Alex"、
"LastName":"Nolastname"、
年齢15,
「Address":{
国":"ポーランド",
"City":"どこか"
},
「バイク:" [
{
"Model":"BMW"、
"年":2020
}
]
}
高速処理のために柔軟なスキーマを必要とするデータに有効である:
Amazon DocumentDB、Azure Cosmos DB、MongoDB、Redis。
グラフ構造を使用し、ノードとエッジという2つの要素で構成される。ノードはテーブルの行やJSONドキュメントに似ている。エッジはノード間の関係であり、ノードと同様に重要である。どちらもプロパティを持つことができる。さらに、エッジは関係の方向を定義することができる。
データがグラフに似ている場合、つまりデータ項目間の関係が動的で時間と共に変化する場合に有効です。さらに、ビジネスや技術的に チーム データ内の関係を理解する必要がある。著名な例としては、以下のようなものがある:
Amazon Neptune、Neo4j、ArangoDB、Titan。
時間ごとに整理されたデータを保存する。通常、リアルタイムで膨大な量のデータを蓄積する。データの保存に使用されることが多いが、更新されることはほとんどない。一般に、タイムスタンプが主キーやデータの並べ替えに使われる。データベースによっては、データの出所や種類などの追加情報としてタグを定義できるものもある。
例えば、少量のデータを時系列に並べて保存するのに便利である:
Azure Time Series Insights、Amazon Timestream、InfluxDB。
QLDBは、中央機関によって所有される、不変で、透過的で、暗号的に検証可能なトランザクションログを提供する。- アマゾンのQLDBの概要
上の引用にあるすべてのキーワードを簡単に説明しよう:
正確な履歴を保存しておくと便利で、例えば、データを変更するたびに、順を追って入力を記録することができる:
アマゾンQLDB
この記事のタイトルにある質問に対する単純な答えはない。適切なデータベースを選択する唯一の方法は、あなたのデータについてもっと知ることです。質問に答えてください:「そうすれば、正しい選択ができるようになるでしょう。
さらに、ビジネス要件とアプリケーション・ドメインをよく知る必要がある。データをどのように使用するのか、データベースにどのようなクエリを送信するのか、データを何回保持、読み込み、更新、削除するのかを知っておく必要があります。これらのことはすべて重要ですが、すべての開発者がこれらの領域に十分な注意を払っているわけではありません。
より良いソフトウェアを開発するために、開発するアプリケーションのデータについて考えてください。全体として、私はあなたが自分のデータを十分に理解し、それが幸せになるような場所に保管することを願っています。
続きを読む