Nguyên tắc cơ bản về thiết kế cơ sở dữ liệu - So sánh PostgreSQL, Cassandra và MongoDB

Xin chào các bạn. Trước khi bước sang phần thứ hai của kỳ nghỉ tháng XNUMX, chúng tôi chia sẻ với bạn tài liệu mà chúng tôi đã dịch nhằm đón chờ sự ra mắt của một luồng mới trong khóa học "DBMS quan hệ".

Các nhà phát triển ứng dụng dành nhiều thời gian so sánh nhiều cơ sở dữ liệu vận hành để chọn cơ sở dữ liệu phù hợp nhất với khối lượng công việc dự kiến. Các nhu cầu có thể bao gồm mô hình hóa dữ liệu được đơn giản hóa, đảm bảo giao dịch, hiệu suất đọc/ghi, chia tỷ lệ theo chiều ngang và khả năng chịu lỗi. Theo truyền thống, sự lựa chọn bắt đầu với danh mục cơ sở dữ liệu, SQL hoặc NoSQL, vì mỗi danh mục thể hiện một tập hợp sự đánh đổi rõ ràng. Hiệu suất cao với độ trễ thấp và thông lượng cao thường được coi là một yêu cầu không thể đánh đổi và do đó rất cần thiết cho bất kỳ cơ sở dữ liệu mẫu nào.

Mục đích của bài viết này là giúp các nhà phát triển ứng dụng đưa ra lựa chọn đúng đắn giữa SQL và NoSQL trong bối cảnh mô hình hóa dữ liệu ứng dụng. Chúng ta sẽ xem xét một cơ sở dữ liệu SQL, cụ thể là PostgreSQL và hai cơ sở dữ liệu NoSQL, Cassandra và MongoDB, để đề cập đến các kiến ​​thức cơ bản về thiết kế cơ sở dữ liệu, chẳng hạn như tạo bảng, điền dữ liệu, đọc dữ liệu từ bảng và xóa bảng. Trong bài viết tiếp theo, chúng ta chắc chắn sẽ xem xét các chỉ mục, giao dịch, THAM GIA, chỉ thị TTL và thiết kế cơ sở dữ liệu dựa trên JSON.

Sự khác biệt giữa SQL và NoSQL là gì?

Cơ sở dữ liệu SQL tăng tính linh hoạt của ứng dụng thông qua đảm bảo giao dịch ACID, cũng như khả năng truy vấn dữ liệu bằng cách sử dụng THAM GIA theo những cách không ngờ tới trên các mô hình cơ sở dữ liệu quan hệ chuẩn hóa hiện có.

Với kiến ​​trúc nguyên khối/nút đơn và việc sử dụng mô hình sao chép chính-nô lệ để dự phòng, cơ sở dữ liệu SQL truyền thống thiếu hai tính năng quan trọng - khả năng mở rộng ghi tuyến tính (tức là phân vùng tự động trên nhiều nút) và mất dữ liệu tự động/không. Điều này có nghĩa là lượng dữ liệu nhận được không thể vượt quá thông lượng ghi tối đa của một nút. Ngoài ra, một số mất mát dữ liệu tạm thời phải được tính đến trong khả năng chịu lỗi (trong kiến ​​trúc không chia sẻ). Ở đây bạn cần lưu ý rằng các cam kết gần đây vẫn chưa được phản ánh trong bản sao nô lệ. Các bản cập nhật không ngừng hoạt động cũng khó đạt được trong cơ sở dữ liệu SQL.

Cơ sở dữ liệu NoSQL thường được phân phối một cách tự nhiên, tức là trong đó, dữ liệu được chia thành các phần và phân phối trên nhiều nút. Họ yêu cầu không chuẩn hóa. Điều này có nghĩa là dữ liệu đã nhập cũng phải được sao chép nhiều lần để đáp ứng các yêu cầu cụ thể mà bạn gửi. Mục tiêu tổng thể là đạt được hiệu suất cao bằng cách giảm số lượng phân đoạn có sẵn trong quá trình đọc. Điều này ngụ ý rằng NoSQL yêu cầu bạn lập mô hình các truy vấn của mình, trong khi SQL yêu cầu bạn lập mô hình dữ liệu của mình.

NoSQL tập trung vào việc đạt được hiệu suất cao trong cụm phân tán và đây là lý do cơ bản cho nhiều sự cân bằng trong thiết kế cơ sở dữ liệu, bao gồm mất giao dịch ACID, THAM GIA và các chỉ mục phụ toàn cầu nhất quán.

Có ý kiến ​​​​cho rằng mặc dù cơ sở dữ liệu NoSQL cung cấp khả năng mở rộng ghi tuyến tính và khả năng chịu lỗi cao nhưng việc mất đi các đảm bảo giao dịch khiến chúng không phù hợp với dữ liệu quan trọng.

Bảng sau đây cho thấy cách lập mô hình dữ liệu trong NoSQL khác với SQL như thế nào.

SQL và NoSQL: Tại sao cần cả hai?

Các ứng dụng trong thế giới thực với số lượng lớn người dùng, chẳng hạn như Amazon.com, Netflix, Uber và Airbnb, được giao nhiệm vụ thực hiện các nhiệm vụ phức tạp, nhiều mặt. Ví dụ: một ứng dụng thương mại điện tử như Amazon.com cần lưu trữ dữ liệu nhẹ, có tính quan trọng cao như thông tin người dùng, sản phẩm, đơn đặt hàng, hóa đơn, cùng với dữ liệu nặng, ít nhạy cảm hơn như đánh giá sản phẩm, thông báo hỗ trợ, hoạt động của người dùng, đánh giá và đề xuất của người dùng. Đương nhiên, các ứng dụng này dựa trên ít nhất một cơ sở dữ liệu SQL cùng với ít nhất một cơ sở dữ liệu NoSQL. Trong các hệ thống liên khu vực và toàn cầu, cơ sở dữ liệu NoSQL hoạt động như một bộ đệm được phân phối theo địa lý cho dữ liệu được lưu trữ trong cơ sở dữ liệu SQL nguồn đáng tin cậy đang chạy trong một khu vực cụ thể.

YugaByte DB kết hợp SQL và NoSQL như thế nào?

Được xây dựng trên công cụ lưu trữ hỗn hợp theo định hướng nhật ký, tự động phân chia, sao chép đồng thuận phân tán và giao dịch phân tán ACID (lấy cảm hứng từ Google Spanner), YugaByte DB là cơ sở dữ liệu nguồn mở đầu tiên trên thế giới tương thích đồng thời với NoSQL (Cassandra & Redis) và SQL (PostgreSQL). Như được hiển thị trong bảng bên dưới, YCQL, API YugaByte DB tương thích với Cassandra, bổ sung các khái niệm về giao dịch ACID đơn và đa khóa cũng như chỉ mục phụ toàn cầu vào API NoSQL, từ đó mở ra kỷ nguyên của cơ sở dữ liệu NoSQL giao dịch. Ngoài ra, YCQL, API YugaByte DB tương thích với PostgreSQL, bổ sung các khái niệm về chia tỷ lệ ghi tuyến tính và khả năng chịu lỗi tự động cho API SQL, đưa cơ sở dữ liệu SQL phân tán ra thế giới. Vì YugaByte DB có bản chất là giao dịch nên API NoSQL hiện có thể được sử dụng trong bối cảnh dữ liệu quan trọng.

Như đã nêu trong bài viết trước đó "Giới thiệu YSQL: API SQL phân tán tương thích PostgreSQL cho YugaByte DB", việc lựa chọn giữa SQL hay NoSQL trong YugaByte DB phụ thuộc hoàn toàn vào đặc điểm của khối lượng công việc cơ bản:

• Nếu khối lượng công việc chính của bạn là các thao tác THAM GIA nhiều khóa thì khi chọn YSQL, hãy hiểu rằng các khóa của bạn có thể được phân phối trên nhiều nút, dẫn đến độ trễ cao hơn và/hoặc thông lượng thấp hơn NoSQL.
• Nếu không, hãy chọn một trong hai API NoSQL, lưu ý rằng bạn sẽ có được hiệu suất tốt hơn nhờ các truy vấn được phân phát từ một nút tại một thời điểm. YugaByte DB có thể phục vụ như một cơ sở dữ liệu vận hành duy nhất cho các ứng dụng phức tạp, trong thế giới thực cần quản lý nhiều khối lượng công việc cùng một lúc.

Phòng thí nghiệm mô hình hóa dữ liệu trong phần tiếp theo dựa trên cơ sở dữ liệu YugaByte DB tương thích với PostgreSQL và Cassandra API, trái ngược với cơ sở dữ liệu gốc. Cách tiếp cận này nhấn mạnh sự dễ dàng tương tác với hai API khác nhau (trên hai cổng khác nhau) của cùng một cụm cơ sở dữ liệu, trái ngược với việc sử dụng các cụm hoàn toàn độc lập của hai cơ sở dữ liệu khác nhau.
Trong các phần sau, chúng ta sẽ xem xét phòng thí nghiệm lập mô hình dữ liệu để minh họa sự khác biệt và một số điểm chung của cơ sở dữ liệu được đề cập.

Phòng thí nghiệm mô hình hóa dữ liệu

Cài đặt cơ sở dữ liệu

Với sự nhấn mạnh vào thiết kế mô hình dữ liệu (thay vì các kiến ​​trúc triển khai phức tạp), chúng tôi sẽ cài đặt cơ sở dữ liệu trong các bộ chứa Docker trên máy cục bộ và sau đó tương tác với chúng bằng cách sử dụng các shell dòng lệnh tương ứng.

Cơ sở dữ liệu YugaByte DB tương thích với PostgreSQL & Cassandra

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

Truy cập dòng lệnh

Hãy kết nối với cơ sở dữ liệu bằng shell dòng lệnh cho các API tương ứng.

PostgreSQL

psql là một shell dòng lệnh để tương tác với PostgreSQL. Để dễ sử dụng, YugaByte DB có kèm theo psql ngay trong thư mục bin.

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

Cassandra

cqlsh là một shell dòng lệnh để tương tác với Cassandra và các cơ sở dữ liệu tương thích của nó thông qua CQL (Ngôn ngữ truy vấn Cassandra). Để dễ sử dụng, YugaByte DB đi kèm cqlsh trong danh mục bin.
Lưu ý rằng CQL được lấy cảm hứng từ SQL và có các khái niệm tương tự về bảng, hàng, cột và chỉ mục. Tuy nhiên, là một ngôn ngữ NoSQL, nó bổ sung một số hạn chế nhất định, hầu hết chúng tôi cũng sẽ đề cập trong các bài viết khác.

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

MongoDB

mongo là một shell dòng lệnh để tương tác với MongoDB. Nó có thể được tìm thấy trong thư mục bin của bản cài đặt MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

Tạo một bảng

Bây giờ chúng ta có thể tương tác với cơ sở dữ liệu để thực hiện các thao tác khác nhau bằng dòng lệnh. Hãy bắt đầu bằng cách tạo một bảng lưu trữ thông tin về các bài hát được viết bởi các nghệ sĩ khác nhau. Những bài hát này có thể là một phần của album. Ngoài ra, các thuộc tính tùy chọn cho một bài hát là năm phát hành, giá cả, thể loại và xếp hạng. Chúng tôi cần tính đến các thuộc tính bổ sung có thể cần thiết trong tương lai thông qua trường "thẻ". Nó có thể lưu trữ dữ liệu bán cấu trúc dưới dạng cặp khóa-giá trị.

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

Tạo bảng trong Cassandra rất giống với PostgreSQL. Một trong những điểm khác biệt chính là thiếu các ràng buộc toàn vẹn (ví dụ: NOT NULL), nhưng đây là trách nhiệm của ứng dụng chứ không phải cơ sở dữ liệu NoSQL. Khóa chính bao gồm khóa phân vùng (cột Nghệ sĩ trong ví dụ bên dưới) và một tập hợp các cột phân cụm (cột SongTitle trong ví dụ bên dưới). Khóa phân vùng xác định hàng sẽ được đặt vào phân vùng/phân đoạn nào và các cột phân cụm cho biết cách sắp xếp dữ liệu trong phân đoạn hiện tại.

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 tổ chức dữ liệu thành các cơ sở dữ liệu (Database) (tương tự như Keyspace trong Cassandra), trong đó có các Collection (tương tự như bảng) chứa Documents (tương tự như các hàng trong một bảng). Trong MongoDB, về cơ bản không cần xác định lược đồ ban đầu. Đội "sử dụng cơ sở dữ liệu", được hiển thị bên dưới, khởi tạo cơ sở dữ liệu trong lệnh gọi đầu tiên và thay đổi ngữ cảnh cho cơ sở dữ liệu mới được tạo. Ngay cả các bộ sưu tập cũng không cần phải được tạo một cách rõ ràng; chúng được tạo tự động, chỉ khi bạn thêm tài liệu đầu tiên vào bộ sưu tập mới. Lưu ý rằng MongoDB sử dụng cơ sở dữ liệu thử nghiệm theo mặc định, do đó, mọi thao tác ở cấp độ bộ sưu tập mà không chỉ định cơ sở dữ liệu cụ thể sẽ chạy trên cơ sở dữ liệu đó theo mặc định.

use myNewDatabase;

Lấy thông tin về một bảng
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)

Cassandra

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;

Nhập dữ liệu vào bảng
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}'
);

Cassandra

biểu hiện tổng thể INSERT trong Cassandra trông rất giống với trong PostgreSQL. Tuy nhiên, có một sự khác biệt lớn về ngữ nghĩa. ở Cassandra INSERT thực sự là một hoạt động UPSERT, trong đó các giá trị cuối cùng được thêm vào hàng nếu hàng đã tồn tại.

Nhập dữ liệu tương tự như PostgreSQL INSERT trên đây

.

MongoDB

Mặc dù MongoDB là một cơ sở dữ liệu NoSQL giống như Cassandra, hoạt động chèn của nó không có điểm chung nào với hành vi ngữ nghĩa của Cassandra. Trong MongoDB chèn() không có cơ hội UPSERT, điều này làm cho nó tương tự như PostgreSQL. Thêm dữ liệu mặc định mà không cần _idspecified sẽ khiến một tài liệu mới được thêm vào bộ sưu tập.

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"
}
}
);

Truy vấn bảng

Có lẽ sự khác biệt đáng kể nhất giữa SQL và NoSQL về mặt xây dựng truy vấn là ngôn ngữ được sử dụng FROM и WHERE. SQL cho phép sau biểu thức FROM chọn nhiều bảng và biểu thức với WHERE có thể có bất kỳ độ phức tạp nào (bao gồm cả các hoạt động JOIN giữa các bảng). Tuy nhiên, NoSQL có xu hướng áp đặt một giới hạn nghiêm trọng đối với FROMvà chỉ làm việc với một bảng được chỉ định, và trong WHERE, khóa chính phải luôn được chỉ định. Điều này liên quan đến việc thúc đẩy hiệu suất NoSQL mà chúng ta đã nói đến trước đó. Mong muốn này dẫn tới mọi sự giảm thiểu có thể có trong mọi tương tác giữa các bảng và các phím chéo. Nó có thể gây ra độ trễ lớn trong giao tiếp giữa các nút khi đáp ứng yêu cầu và do đó nói chung tốt nhất nên tránh. Ví dụ: Cassandra yêu cầu các truy vấn được giới hạn ở một số toán tử nhất định (chỉ =, IN, <, >, =>, <=) trên các khóa phân vùng, ngoại trừ khi yêu cầu chỉ mục phụ (chỉ cho phép toán tử = ở đây).

PostgreSQL

Dưới đây là ba ví dụ về các truy vấn có thể dễ dàng được thực thi bởi cơ sở dữ liệu SQL.

• Hiển thị tất cả các bài hát của một nghệ sĩ;
• Hiển thị tất cả các bài hát của nghệ sĩ phù hợp với phần đầu tiên của tiêu đề;
• Hiển thị tất cả các bài hát của nghệ sĩ có một từ nhất định trong tiêu đề và có giá nhỏ hơn 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;

Cassandra

Trong số các truy vấn PostgreSQL được liệt kê ở trên, chỉ truy vấn đầu tiên sẽ hoạt động không thay đổi trong Cassandra, vì toán tử LIKE không thể áp dụng cho các cột phân cụm như SongTitle. Trong trường hợp này, chỉ người vận hành mới được phép = и 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

Như được hiển thị trong các ví dụ trước, phương thức chính để tạo truy vấn trong MongoDB là db.collection.find (). Phương thức này chứa rõ ràng tên của bộ sưu tập (music trong ví dụ bên dưới), vì vậy việc truy vấn nhiều bộ sưu tập bị cấm.

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

Đọc tất cả các hàng của bảng

Đọc tất cả các hàng chỉ đơn giản là một trường hợp đặc biệt của mẫu truy vấn mà chúng ta đã xem xét trước đó.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Tương tự như ví dụ PostgreSQL ở trên.

MongoDB

db.music.find( {} );

Chỉnh sửa dữ liệu trong bảng

PostgreSQL

PostgreSQL cung cấp hướng dẫn UPDATE để thay đổi dữ liệu. Cô ấy không có cơ hội UPSERT, vì vậy câu lệnh này sẽ thất bại nếu hàng đó không còn trong cơ sở dữ liệu.

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

Cassandra

Cassandra có UPDATE tương tự như PostgreSQL. UPDATE có cùng ngữ nghĩa UPSERT, giống INSERT.

Tương tự như ví dụ PostgreSQL ở trên.

MongoDB
Hoạt động cập nhật () trong MongoDB hoàn toàn có thể cập nhật một tài liệu hiện có hoặc chỉ cập nhật một số trường nhất định. Theo mặc định, nó chỉ cập nhật một tài liệu bị tắt ngữ nghĩa UPSERT. Cập nhật nhiều tài liệu và hành vi tương tự UPSERT có thể được áp dụng bằng cách đặt cờ bổ sung cho hoạt động. Ví dụ: trong ví dụ bên dưới, thể loại của một nghệ sĩ cụ thể được cập nhật dựa trên bài hát của anh ấy.

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

Xóa dữ liệu khỏi bảng

PostgreSQL

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

Cassandra

Tương tự như ví dụ PostgreSQL ở trên.

MongoDB

MongoDB có hai loại hoạt động để xóa tài liệu - xóaOne() /xóaMany() и tẩy(). Cả hai loại đều xóa tài liệu nhưng trả về kết quả khác nhau.

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

Xóa một bảng

PostgreSQL

DROP TABLE Music;

Cassandra

Tương tự như ví dụ PostgreSQL ở trên.

MongoDB

db.music.drop();

Kết luận

Cuộc tranh luận về việc lựa chọn giữa SQL và NoSQL đã nổ ra hơn 10 năm. Có hai khía cạnh chính trong cuộc tranh luận này: kiến ​​trúc công cụ cơ sở dữ liệu (SQL nguyên khối, SQL giao dịch so với NoSQL phân tán, không giao dịch) và phương pháp thiết kế cơ sở dữ liệu (mô hình hóa dữ liệu của bạn trong SQL so với mô hình hóa các truy vấn của bạn trong NoSQL).

Với cơ sở dữ liệu giao dịch phân tán như YugaByte DB, cuộc tranh luận về kiến ​​trúc cơ sở dữ liệu có thể dễ dàng kết thúc. Khi khối lượng dữ liệu trở nên lớn hơn những gì có thể được ghi vào một nút duy nhất, một kiến ​​trúc phân tán hoàn toàn hỗ trợ khả năng mở rộng ghi tuyến tính với khả năng phân chia/cân bằng lại tự động trở nên cần thiết.

Ngoài ra, như đã nêu ở một trong những bài viết Google CloudCác kiến ​​trúc nhất quán mạnh mẽ, mang tính giao dịch hiện nay được sử dụng nhiều hơn để mang lại sự linh hoạt phát triển tốt hơn so với các kiến ​​trúc phi giao dịch, cuối cùng là nhất quán.

Quay trở lại cuộc thảo luận về thiết kế cơ sở dữ liệu, công bằng mà nói thì cả hai phương pháp thiết kế (SQL và NoSQL) đều cần thiết cho bất kỳ ứng dụng thực tế phức tạp nào. Cách tiếp cận "mô hình hóa dữ liệu" SQL cho phép các nhà phát triển dễ dàng đáp ứng các yêu cầu kinh doanh đang thay đổi, trong khi cách tiếp cận "mô hình hóa truy vấn" NoSQL cho phép các nhà phát triển tương tự hoạt động trên khối lượng dữ liệu lớn với độ trễ thấp và thông lượng cao. Vì lý do này mà YugaByte DB cung cấp API SQL và NoSQL trong lõi chung, thay vì thúc đẩy một trong các phương pháp tiếp cận. Ngoài ra, bằng cách cung cấp khả năng tương thích với các ngôn ngữ cơ sở dữ liệu phổ biến bao gồm PostgreSQL và Cassandra, YugaByte DB đảm bảo rằng các nhà phát triển không phải học ngôn ngữ khác để làm việc với công cụ cơ sở dữ liệu phân tán, có tính nhất quán cao.

Trong bài viết này, chúng ta đã xem xét sự khác biệt giữa các nguyên tắc cơ bản về thiết kế cơ sở dữ liệu giữa PostgreSQL, Cassandra và MongoDB. Trong các bài viết sau, chúng ta sẽ đi sâu vào các khái niệm thiết kế nâng cao như chỉ mục, giao dịch, THAM GIA, chỉ thị TTL và tài liệu JSON.

Chúc bạn cuối tuần vui vẻ và mời bạn đến hội thảo trên web miễn phí, sẽ diễn ra vào ngày 14 tháng XNUMX.

Nguồn: www.habr.com