データベース設計の基礎 - PostgreSQL、Cassandra、MongoDB の比較

皆さん、こんにちは。 XNUMX 月の休暇の後半に出発する前に、コースでの新しいストリームの開始に備えて翻訳した資料を共有します。 「リレーショナルDBMS」.

アプリケーション開発者は、複数の運用データベースを比較して、目的のワークロードに最も適したデータベースを選択することに多くの時間を費やします。 ニーズには、簡略化されたデータ モデリング、トランザクション保証、読み取り/書き込みパフォーマンス、水平スケーリング、およびフォールト トレランスが含まれる場合があります。 従来、選択はデータベース カテゴリ (SQL か NoSQL) から始まります。これは、各カテゴリには明確なトレードオフがあるためです。 低レイテンシーと高スループットの観点からの高いパフォーマンスは、一般に非トレードオフの要件とみなされているため、あらゆるサンプル データベースにとって不可欠です。

この記事の目的は、アプリケーション開発者がアプリケーション データ モデリングのコンテキストで SQL と NoSQL のどちらを適切に選択できるかを支援することです。 XNUMX つの SQL データベース (PostgreSQL) と XNUMX つの NoSQL データベース (Cassandra と MongoDB) を見て、テーブルの作成、テーブルへのデータの入力、テーブルからのデータの読み取り、テーブルの削除などのデータベース設計の基本を説明します。 次回の記事では、インデックス、トランザクション、JOIN、TTL ディレクティブ、および JSON ベースのデータベース設計について見ていきます。

SQLとNoSQLの違いは何ですか?

SQL データベースは、ACID トランザクション保証と、既存の正規化されたリレーショナル データベース モデル上で予期しない方法で JOIN を使用してデータをクエリする機能によって、アプリケーションの柔軟性を高めます。

モノリシック/単一ノード アーキテクチャと冗長性のためのマスター/スレーブ レプリケーション モデルの使用を考慮すると、従来の SQL データベースには XNUMX つの重要な機能、つまり線形書き込みスケーラビリティ (つまり、複数のノードにわたる自動パーティショニング) と自動/ゼロ データ損失が欠けています。 これは、受信するデータの量が単一ノードの最大書き込みスループットを超えることができないことを意味します。 さらに、フォールト トレランス (シェアードナッシング アーキテクチャにおける) では、一時的なデータ損失の一部を考慮する必要があります。 ここで、最近のコミットがまだスレーブ コピーに反映されていないことに留意する必要があります。 SQL データベースでは、ダウンタイムなしで更新を実現することも困難です。

NoSQL データベースは通常、本質的に分散されています。 それらでは、データがセクションに分割され、複数のノードに分散されます。 非正規化が必要です。 これは、送信した特定のリクエストに応答するために、入力されたデータを何度もコピーする必要があることを意味します。 全体的な目標は、読み取り中に使用可能なシャードの数を減らすことで高いパフォーマンスを実現することです。 これは、NoSQL ではクエリをモデル化する必要があるのに対し、SQL ではデータをモデル化する必要があることを意味します。

NoSQL は、分散クラスターで高いパフォーマンスを達成することに重点を置いており、これが、ACID トランザクション損失、JOIN、一貫性のあるグローバル セカンダリ インデックスを含む多くのデータベース設計のトレードオフの基礎となる理論的根拠です。

NoSQL データベースは線形書き込みスケーラビリティと高いフォールト トレランスを提供しますが、トランザクション保証が失われるためミッション クリティカルなデータには適さないという議論があります。

次の表は、NoSQL のデータ モデリングが SQL とどのように異なるかを示しています。

SQL と NoSQL: なぜ両方が必要なのでしょうか?

Amazon.com、Netflix、Uber、Airbnb など、多数のユーザーを抱える現実のアプリケーションは、複雑で多面的なタスクを実行する必要があります。 たとえば、Amazon.com のような電子商取引アプリケーションでは、ユーザー情報、製品、注文、請求書などの軽量で重要度の高いデータと、製品レビュー、サポート メッセージ、ユーザー アクティビティなどの重くて機密性の低いデータを保存する必要があります。ユーザーのレビューと推奨事項。 当然のことながら、これらのアプリケーションは少なくとも XNUMX つの SQL データベースと少なくとも XNUMX つの NoSQL データベースに依存します。 リージョンを越えたグローバル システムでは、NoSQL データベースは、特定のリージョンで実行されている信頼できるソース SQL データベースに保存されているデータの地理分散キャッシュとして動作します。

YugaByte DB は SQL と NoSQL をどのように組み合わせていますか?

YugaByte DB は、ログ指向の混合ストレージ エンジン、自動シャーディング、シャーディングされた分散コンセンサス レプリケーション、および ACID 分散トランザクション (Google Spanner からインスピレーションを受けた) 上に構築されており、NoSQL (Cassandra および Redis ) と同時に互換性がある世界初のオープン ソース データベースです。 SQL (PostgreSQL)。 以下の表に示すように、Cassandra と互換性のある YugaByte DB API である YCQL は、単一キーおよびマルチキー ACID トランザクションとグローバル セカンダリ インデックスの概念を NoSQL API に追加し、それによってトランザクション NoSQL データベースの時代を迎えます。 さらに、PostgreSQL と互換性のある YugaByte DB API である YCQL は、SQL API に線形書き込みスケーリングと自動フォールト トレランスの概念を追加し、分散 SQL データベースを世界にもたらします。 YugaByte DB は本質的にトランザクションであるため、NoSQL API をミッションクリティカルなデータのコンテキストで使用できるようになりました。

以前の記事でも述べたように、 「YSQL の紹介: YugaByte DB 用の PostgreSQL 互換分散 SQL API」YugaByte DB での SQL か NoSQL の選択は、基盤となるワークロードの特性に完全に依存します。

• 主なワークロードがマルチキー JOIN 操作である場合、YSQL を選択するときは、キーが複数のノードに分散される可能性があることを理解してください。その結果、NoSQL よりも待ち時間が長くなったり、スループットが低くなったりします。
• それ以外の場合は、一度に XNUMX つのノードからクエリを実行することでパフォーマンスが向上することに留意して、XNUMX つの NoSQL API のいずれかを選択してください。 YugaByte DB は、複数のワークロードを同時に管理する必要がある現実世界の複雑なアプリケーション用の単一の運用データベースとして機能します。

次のセクションのデータ モデリング ラボは、ネイティブ データベースではなく、PostgreSQL および Cassandra API と互換性のある YugaByte DB データベースに基づいています。 このアプローチでは、XNUMX つの異なるデータベースの完全に独立したクラスターを使用するのではなく、同じデータベース クラスターの XNUMX つの異なる API (XNUMX つの異なるポート上) との対話の容易さが強調されます。
次のセクションでは、データ モデリング ラボを見て、対象となるデータベースの相違点といくつかの共通点を説明します。

データモデリング研究室

データベースのインストール

(複雑なデプロイメント アーキテクチャではなく) データ モデルの設計に重点を置いているため、ローカル マシン上の Docker コンテナにデータベースをインストールし、それぞれのコマンド ライン シェルを使用してデータベースを操作します。

PostgreSQL および Cassandra と互換性のある YugaByte DB データベース

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDBの

docker run --name my-mongo -d mongo:latest

コマンドラインアクセス

対応する API のコマンド ライン シェルを使用してデータベースに接続しましょう。

PostgreSQL

psql PostgreSQL と対話するためのコマンド ライン シェルです。 使いやすさを考慮して、YugaByte DB には bin フォルダー内に psql が付属しています。

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

カサンドラ

cqlsh CQL (Cassandra Query Language) を介して Cassandra およびその互換データベースと対話するためのコマンド ライン シェルです。 使いやすさを考慮して、YugaByte DB には以下が付属しています。 cqlsh カタログにある bin.
CQL は SQL からインスピレーションを受けており、テーブル、行、列、インデックスの同様の概念を持っていることに注意してください。 ただし、NoSQL 言語として一定の制限が追加されており、そのほとんどについては他の記事でも説明します。

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDBの

モンゴ MongoDB と対話するためのコマンド ライン シェルです。 これは、MongoDB インストールの bin ディレクトリにあります。

docker exec -it my-mongo bash 
cd bin
mongo

テーブルの作成

これで、コマンド ラインを使用してデータベースと対話し、さまざまな操作を実行できるようになりました。 まずは、さまざまなアーティストによって書かれた曲に関する情報を保存するテーブルを作成しましょう。 これらの曲はアルバムの一部である場合があります。 また、曲のオプションの属性として、リリース年、価格、ジャンル、評価があります。 「タグ」フィールドを通じて、将来必要になる可能性のある追加の属性を考慮する必要があります。 半構造化データをキーと値のペアの形式で保存できます。

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

カサンドラ

Cassandra でのテーブルの作成は PostgreSQL と非常に似ています。 主な違いの XNUMX つは、整合性制約 (NOT NULL など) がないことですが、これは NoSQL データベースではなくアプリケーションの責任です。。 主キーは、パーティション キー (以下の例の Artist 列) と一連のクラスタリング列 (以下の例の SongTitle 列) で構成されます。 パーティション キーは行をどのパーティション/シャードに配置するかを決定し、クラスタリング列は現在のシャード内でデータをどのように編成するかを示します。

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDBの

MongoDB は、データをデータベース (データベース) (Cassandra のキースペースに似ています) に編成します。そこには、ドキュメント (テーブルの行に似ています) を含むコレクション (テーブルに似ています) があります。 MongoDB では、基本的に初期スキーマを定義する必要はありません。 チーム 「データベースを使用する」以下に示すように、最初の呼び出しでデータベースをインスタンス化し、新しく作成されたデータベースのコンテキストを変更します。 コレクションであっても、明示的に作成する必要はなく、最初のドキュメントを新しいコレクションに追加するだけで自動的に作成されます。 MongoDB はデフォルトでテスト データベースを使用するため、特定のデータベースを指定しないコレクション レベルの操作はデフォルトでテスト データベース上で実行されることに注意してください。

use myNewDatabase;

テーブルに関する情報の取得
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

カサンドラ

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDBの

use myNewDatabase;
show collections;

テーブルへのデータの入力
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

カサンドラ

全体の表現 INSERT Cassandra の見た目は PostgreSQL の見た目と非常によく似ています。 ただし、セマンティクスには大きな違いが XNUMX つあります。 カサンドラで INSERT 実際には操作です UPSERT、行がすでに存在する場合、最後の値が行に追加されます。

データ入力はPostgreSQLに似ています INSERT 上記

.

MongoDBの

MongoDB は Cassandra と同じ NoSQL データベースですが、その挿入操作は Cassandra のセマンティック動作と何の共通点もありません。 MongoDB 内 インサート（） チャンスがない UPSERT, そのため、PostgreSQL に似ています。 デフォルトデータを追加せずに _idspecified 新しいドキュメントがコレクションに追加されます。

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

テーブルクエリ

おそらく、クエリ構築に関して SQL と NoSQL の最も大きな違いは、使用される言語です。 FROM и WHERE。 SQL では式の後に使用できます FROM 複数のテーブルを選択し、式を使用します WHERE 任意の複雑さ (操作を含む) にすることができます。 JOIN テーブル間）。 ただし、NoSQL は厳しい制限を課す傾向があります。 FROM、指定された XNUMX つのテーブルのみを操作します。 WHERE、主キーは常に指定する必要があります。 これは、先ほど説明した NoSQL のパフォーマンス向上につながります。 この要望により、クロス表やクロスキーの相互作用を可能な限り削減することができます。 リクエストに応答するときにノード間通信に大きな遅延が生じる可能性があるため、一般的には回避するのが最善です。 たとえば、Cassandra ではクエリを特定の演算子 (のみ) に制限する必要があります。 =, IN, <, >, =>, <=) セカンダリ インデックスを要求する場合を除き、パーティション キーに対して使用します (ここでは = 演算子のみが許可されます)。

PostgreSQL

以下に、SQL データベースで簡単に実行できるクエリの XNUMX つの例を示します。

• アーティストごとにすべての曲を表示します。
• タイトルの最初の部分に一致するアーティストのすべての曲を表示します。
• タイトルに特定の単語が含まれ、価格が 1.00 未満であるアーティストのすべての曲を表示します。

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

カサンドラ

上記の PostgreSQL クエリのうち、Cassandra では最初のクエリのみが変更されずに機能します。 LIKE などのクラスタリング列には適用できません。 SongTitle。 この場合、演算子のみが許可されます = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDBの

前の例で示したように、MongoDB でクエリを作成する主な方法は次のとおりです。 db.collection.find（）。 このメソッドにはコレクションの名前が明示的に含まれています (music 以下の例では)、複数のコレクションのクエリは禁止されています。

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

テーブルのすべての行を読み取る

すべての行の読み取りは、前に説明したクエリ パターンの特殊なケースにすぎません。

PostgreSQL

SELECT * 
FROM Music;

カサンドラ

上記の PostgreSQL の例と似ています。

MongoDBの

db.music.find( {} );

テーブル内のデータを編集する

PostgreSQL

PostgreSQL が手順を提供します UPDATE データを変更します。 彼女にはチャンスがない UPSERTしたがって、行がデータベースに存在しない場合、このステートメントは失敗します。

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

カサンドラ

カサンドラは UPDATE PostgreSQLに似ています。 UPDATE 同じセマンティクスを持っています UPSERT、 のように INSERT.

上記の PostgreSQL の例と似ています。

MongoDBの
操作 更新（） MongoDB では、既存のドキュメントを完全に更新することも、特定のフィールドのみを更新することもできます。 デフォルトでは、セマンティクスが無効になっている XNUMX つのドキュメントのみが更新されます UPSERT。 複数のドキュメントの更新および同様の動作 UPSERT 操作に追加のフラグを設定することで適用できます。 たとえば、以下の例では、特定のアーティストのジャンルがその曲に基づいて更新されます。

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

テーブルからのデータの削除

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

カサンドラ

上記の PostgreSQL の例と似ています。

MongoDBの

MongoDBには、ドキュメントを削除するためのXNUMX種類の操作があります- deleteOne() /deleteMany() и 削除する（）。 どちらのタイプでもドキュメントは削除されますが、異なる結果が返されます。

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

テーブルを削除する

PostgreSQL

DROP TABLE Music;

カサンドラ

上記の PostgreSQL の例と似ています。

MongoDBの

db.music.drop();

まとめ

SQL と NoSQL のどちらを選択するかについての議論は、10 年以上にわたって激しくなっています。 この議論には主に XNUMX つの側面があります。それは、データベース エンジン アーキテクチャ (モノリシックなトランザクション SQL と分散型の非トランザクション NoSQL) とデータベース設計アプローチ (SQL でのデータのモデル化と NoSQL でのクエリのモデル化) です。

YugaByte DB のような分散トランザクション データベースを使用すると、データベース アーキテクチャに関する議論を簡単に終わらせることができます。 データ量が単一ノードに書き込める量を超えると、自動シャーディング/リバランスによる線形書き込みスケーラビリティをサポートする完全分散アーキテクチャが必要になります。

さらに、ある記事で述べたように、 Googleクラウド現在、トランザクション型の強力な一貫性のあるアーキテクチャは、非トランザクション型の最終的に一貫性のあるアーキテクチャよりも開発の機敏性を向上させるために使用されることが多くなっています。

データベース設計の議論に戻ると、現実世界の複雑なアプリケーションには両方の設計アプローチ (SQL と NoSQL) が必要であると言っても過言ではありません。 SQL の「データ モデリング」アプローチを使用すると、開発者は変化するビジネス要件に簡単に対応できるようになります。一方、NoSQL の「クエリ モデリング」アプローチを使用すると、同じ開発者が低遅延かつ高スループットで大量のデータを操作できるようになります。 YugaByte DB がどちらかのアプローチを推進するのではなく、共通のコアで SQL および NoSQL API を提供するのはこのためです。 さらに、YugaByte DB は、PostgreSQL や Cassandra などの一般的なデータベース言語との互換性を提供することで、開発者が分散型の一貫性の高いデータベース エンジンを使用するために別の言語を学習する必要がないことを保証します。

この記事では、PostgreSQL、Cassandra、MongoDB の間でデータベース設計の基本がどのように異なるかを検討しました。 今後の記事では、インデックス、トランザクション、JOIN、TTL ディレクティブ、JSON ドキュメントなどの高度な設計概念について詳しく説明します。

素晴らしい週末をお過ごしください。ぜひご参加ください。 無料ウェビナー、14月XNUMX日に開催されます。

出所： habr.com