Phân Biệt Điểm Khác Nhau Giữa SQL và NoSQL

Cơ sở dữ liệu SQL (Structured Query Language - Ngôn ngữ truy vấn có cấu trúc) đã là cơ chế lưu trữ dữ liệu chính trong hơn bốn thập kỷ. Việc sử dụng cơ chế SQL bùng nổ vào cuối những năm 1990 với sự gia tăng của các ứng dụng web và các tùy chọn mã nguồn mở như MySQL, PostgreSQL và SQLite.

Cơ sở dữ liệu NoSQL đã tồn tại từ những năm 1960, nhưng gần đây dần đạt được sức hút với các tùy chọn phổ biến như MongoDB, CouchDB, Redis và Apache Cassandra.

Bạn sẽ tìm thấy nhiều hướng dẫn giải thích cách sử dụng một phiên bản SQL hoặc NoSQL cụ thể, nhưng ít người thảo luận về lý do tại sao bạn nên chọn cái này thay vì cái kia. Vì thế, trong bài viết này, chúng ta sẽ đề cập đến những điểm khác biệt cơ bản giữa SQL so với NóQL.

Hầu hết các ví dụ áp dụng cho hệ thống cơ sở dữ liệu SQL MySQL và NoSQL MongoDB phổ biến. Các cơ sở dữ liệu SQL / NoSQL khác cũng tương tự, nhưng sẽ có những khác biệt nhỏ về tính năng và cú pháp.

Thánh Chiến SQL vs NoSQL

Trước khi chúng ta đi xa hơn, hãy làm rõ một số quan niệm nhé…

MYTH: NoSQL sẽ soán ngôi SQL

Điều đó giống như việc nói rằng tàu thuyền được thay thế bằng ô tô vì chúng là một công nghệ mới hơn. SQL và NoSQL cùng có chung một nhiệm vụ: lưu trữ dữ liệu. Chúng có những cách tiếp cận khác nhau, có thể giúp ích hoặc cản trở dự án của bạn. Mặc dù mang đến cảm giác mới lạ hơn và thu hút sự chú ý gần đây, NoSQL không soán ngôi SQL - mà là phương án thay thế.

MYTH: NoSQL tốt / tệ hơn SQL

Một số dự án phù hợp hơn với việc sử dụng cơ sở dữ liệu SQL. Một số phù hợp hơn với NoSQL. Một số có thể sử dụng luân phiên cho nhau.

MYTH: SQL vs NoSQL khác nhau rất rõ ràng

Nhận định trên không dúng hoàn toàn. Một số cơ sở dữ liệu SQL đang áp dụng các tính năng của NoSQL và ngược lại. Một số lựa chọn có thể ngày càng trở nên tương đồng nhau và cơ sở dữ liệu lai (hybrid databases) NewSQL có thể cung cấp một số tùy chọn thú vị trong tương lai.

MYTH: the ngôn ngữ/framework quyết định cơ sở dữ liệu

Chúng ta đã trở nên quen thuộc với các tổ hợp công nghệ, chẳng hạn như -

• LAMP: Linux, Apache, MySQL (SQL), PHP
• MEAN: MongoDB (NoSQL), Express, Angular, Node.js
• .NET, IIS và SQL Server
• Java, Apache và Oracle.

Có những lý do thực tế, thương mại trong quá khứ khiến những tổ hợp này phát triển - nhưng đừng bạn không nhất thiết phải kết hợp cứng nhắc theo những tổ hợp này. Bạn có thể sử dụng cơ sở dữ liệu MongoDB NoSQL trong dự án PHP hoặc .NET. Bạn có thể kết nối với MySQL hoặc SQL Server trong Node.js. Bạn có thể không tìm thấy nhiều hướng dẫn và tài nguyên, nhưng yêu cầu sử dụng của bạn sẽ xác định loại cơ sở dữ liệu phù hợp - chứ không phải ngôn ngữ.

(Như vậy, việc lựa chọn một tổ hợp công nghệ khác thường, hoặc kết hợp giữa SQL và NoSQL là hoàn toàn có thể, nhưng bạn sẽ thấy khó khăn hơn khi cần hỗ trợ và tuyển dụng các developer có kinh nghiệm.)

Kế tiếp, hãy cùng xem xét những điểm khác biệt chính giữa SQL Tables và NoSQL

 …

SQL Tables vs NoSQL: Documents

Cơ sở dữ liệu SQL cung cấp một kho lưu trữ các bảng dữ liệu liên quan. Ví dụ: nếu bạn điều hành một cửa hàng sách trực tuyến, thông tin sách có thể được thêm vào bảng tên book:

ISBN	title	author	format	price
9780992461225	JavaScript: Novice to Ninja	Darren Jones	ebook	29.00
9780994182654	Jump Start Git	Shaumik Daityari	ebook	29.00

Mỗi hàng là một danh mục (record) sách khác nhau. Thiết kế này sẽ là cố định; bạn không thể sử dụng cùng một bảng để lưu trữ thông tin khác nhau hoặc chèn một string ở vị trí cho dữ liệu dạng số được.

Cơ sở dữ liệu NoSQL thì lại lưu trữ các tài liệu theo dạng cặp trường-giá-trị giống như trong JSON, ví dụ:

{
  ISBN: 9780992461225,
  title: "JavaScript: Novice to Ninja",
  author: "Darren Jones",
  format: "ebook",
  price: 29.00
}

Các tài liệu giống nhau có thể được lưu trữ trong một collection, tương tự như bảng SQL. Tuy nhiên, bạn có thể lưu trữ bất kỳ dữ liệu nào bạn thích trong bất kỳ tài liệu nào; cơ sở dữ liệu NoSQL sẽ không phàn nàn. Ví dụ:

{
  ISBN: 9780992461225,
  title: "JavaScript: Novice to Ninja",
  author: "Darren Jones",
  year: 2014,
  format: "ebook",
  price: 29.00,
  description: "Learn JavaScript from scratch!",
  rating: "5/5",
  review: [
    { name: "A Reader", text: "The best JavaScript book I've ever read." },
    { name: "JS Expert", text: "Recommended to novice and expert developers alike." }
  ]
}

Table trong SQL tạo ra data template rất nghiêm ngặt, vì vậy rất khó để ta mắc lỗi. NoSQL thì linh hoạt và dễ sử dụng hơn, nhưng việc có thể lưu trữ bất kỳ dữ liệu nào ở bất kỳ đâu có thể dẫn đến các vấn đề về tính nhất quán.

SQL Schema vs NoSQL Schemaless

Trong cơ sở dữ liệu SQL, không thể thêm dữ liệu cho đến khi bạn xác định bảng và field type trong schema (lược đồ). Schema theo tùy chọn còn có thể chứa các thông tin khác, chẳng hạn như -

• primary keys — unique identifier như ISBN, áp dụng cho một bản ghi (record)
• indexes — các trường thường được truy vấn, được lập thành chỉ mục (index) để hỗ trợ tìm kiếm nhanh
• relationships — liên kết logic giữa các trường dữ liệu
• Các chức năng như triggers và stored procedures.

Lược đồ dữ liệu của bạn phải được thiết kế và triển khai trước khi phát triển bất kỳ business logic nào để thao tác dữ liệu. Bạn hoàn toàn có thể có thể cập nhật sau (nhưng những thay đổi lớn có thể sẽ phức tạp).

Trong cơ sở dữ liệu NoSQL, dữ liệu có thể được thêm vào mọi lúc, mọi nơi. Không cần phải chỉ định trước thiết kế tài liệu (document design) hoặc thậm chí là bộ sưu tập (collection). Ví dụ: trong MongoDB, câu lệnh sau sẽ tạo một tài liệu mới trong một bộ sưu tập book mới nếu nó chưa được tạo trước đó:

db.book.insert(
  ISBN: 9780994182654,
  title: "Jump Start Git",
  author: "Shaumik Daityari",
  format: "ebook",
  price: 29.00
);

(MongoDB sẽ tự động thêm một giá trị _id độc nhất vào mỗi tài liệu trong một bộ sưu tập. Bạn có thể vẫn muốn xác định các chỉ mục, nhưng điều đó có thể được thực hiện sau nếu cần.)

Cơ sở dữ liệu NoSQL sẽ phù hợp hơn với các dự án mà các yêu cầu dữ liệu ban đầu khó xác định được. Tuy vậy, đừng dùng sự khó khăn làm lý do cho việc lười biếng: việc lơ là trong việc thiết kế một kho lưu trữ dữ liệu tốt khi bắt đầu dự án sẽ dẫn đến các vấn đề sau này.

SQL Normalization vs NoSQL Denormalization

Giả sử chúng ta muốn thêm thông tin nhà xuất bản vào cơ sở dữ liệu cửa hàng sách. Một nhà xuất bản có thể cung cấp nhiều hơn một tên sách, do đó, trong cơ sở dữ liệu SQL, chúng ta sẽ tạo một bảng publisher mới:

id	name	country	email
SP001	SitePoint	Australia	feedback@sitepoint.com

Sau đó, chúng ta có thể thêm trường publisher_id vào table book của mình, table này sẽ tham chiếu đến các bản ghi theo publisher.id:

ISBN	title	author	format	price	publisher_id
9780992461225	JavaScript: Novice to Ninja	Darren Jones	ebook	29.00	SP001
9780994182654	Jump Start Git	Shaumik Daityari	ebook	29.00	SP001

Để giảm thiểu sự dư thừa dữ liệu; chúng ta không cần lặp lại thông tin nhà xuất bản cho mọi cuốn sách - chỉ cần tham chiếu thôi. Kỹ thuật này được gọi là chuẩn hóa (normalization) và mang đến những lợi ích thiết thực. Chúng ta có thể cập nhật một nhà xuất bản duy nhất mà không cần thay đổi dữ liệu của book.

Chúng ta cũng có thể sử dụng các kỹ thuật chuẩn hóa trong NoSQL. Tài liệu trong collection book :

{
  ISBN: 9780992461225,
  title: "JavaScript: Novice to Ninja",
  author: "Darren Jones",
  format: "ebook",
  price: 29.00,
  publisher_id: "SP001"
}

— tham chiếu một document trong collection publisher :

{
  id: "SP001"
  name: "SitePoint",
  country: "Australia",
  email: "feedback@sitepoint.com"
}

Tuy nhiên, cách làm này không phải lúc nào cũng thực tế, vì những lý do chúng ta sẽ tìm hiểu thêm dưới đây. Chúng ta có thể chọn cách làm không chuẩn hóa tài liệu của mình, và lặp lại thông tin nhà xuất bản cho mọi cuốn sách:

{
  ISBN: 9780992461225,
  title: "JavaScript: Novice to Ninja",
  author: "Darren Jones",
  format: "ebook",
  price: 29.00,
  publisher: {
    name: "SitePoint",
    country: "Australia",
    email: "feedback@sitepoint.com"
  }
}

Như vậy thì truy vấn sẽ nhanh hơn, nhưng cập nhật thông tin nhà xuất bản trong nhiều bản ghi sẽ chậm hơn đáng kể.

SQL Relational JOIN vs NoSQL

Truy vấn trong SQL cho ta mệnh đề JOIN mạnh mẽ. Chúng ta có thể lấy dữ liệu liên quan trong nhiều bảng bằng cách sử dụng một câu lệnh SQL duy nhất. Ví dụ:

SELECT book.title, book.author, publisher.name
FROM book
LEFT JOIN book.publisher_id ON publisher.id;

Câu lệnh trả về tất cả các tên sách, tác giả và tên nhà xuất bản được liên kết (giả sử dữ liệu đã được thiết đặt đầy dủ).

NoSQL không có câu lệnh nào giống như JOIN, nếu ai đó chưa có kinh nghiệm SQL họ có thể bị sock nhẹ. Nếu chúng ta sử dụng các bộ sưu tập chuẩn hóa như được mô tả ở trên, chúng ta sẽ cần tìm nạp tất cả document book, truy xuất tất cả các document publisher  liên quan, và liên kết thủ công hai document theo program logic của chúng ta. Đây là một lý do khiến việc không chuẩn hóa đôi khi lại tốt hơn là chuẩn hóa.

SQL vs NoSQL Data Integrity

Hầu hết các cơ sở dữ liệu SQL cho phép bạn thực thi các Quy tắc toàn vẹn dữ liệu (data integrity rules) bằng cách sử dụng các Ràng Buộc Khóa Ngoại - Foreign Key Constraints (trừ khi bạn vẫn đang sử dụng công cụ lưu trữ MyISAM cũ hơn, không còn tồn tại trong MySQL). Cửa hàng sách của ta có thể:

• Đảm bảo mọi cuốn sách đều có một mã publisher_id hợp lệ khớp với một đầu mục tương ứng trong bảng publisher , và
• không cho phép xóa publisher nêu có một cuốn sách trở lên liên kết với publisher đó.

Lược đồ (Schema) sẽ thực thi các quy tắc này để cơ sở dữ liệu tuân theo. Developer hoặc người dùng không thể thêm, chỉnh sửa hoặc xóa bản ghi, điều này có thể dẫn đến dữ liệu không hợp lệ hoặc sinh ra bản ghi "mồ côi" (orphan records).

Các tùy chọn Toàn vẹn dữ liệu (data integrity) tương tự không có sẵn trong cơ sở dữ liệu NoSQL; bạn có thể lưu trữ những gì bạn muốn không cần quan tâm đến các document khác. Lý tưởng nhất, một tài liệu duy nhất sẽ chứa tất cả thông tin về một item.

SQL vs NoSQL Transactions

Trong cơ sở dữ liệu SQL, hai hoặc nhiều bản update có thể được thực hiện trong một transaction duy nhất. Ví dụ, giả sử cửa hàng sách của chúng ta có các bảng order  và stock. Khi một cuốn sách được đặt hàng, chúng ta thêm một bản ghi vào bảng order và giảm số lượng hàng trong bảng stock. Nếu ta thực hiện hai bản cập nhật đó riêng lẻ, một cập nhật có thể thành công và cập nhật kia không thành công - dẫn đến số liệu không đồng bộ. Việc đặt các bản cập nhật giống nhau trong một giao dịch đảm bảo cả hai đều thành công hoặc cả hai đều thất bại.

Trong cơ sở dữ liệu NoSQL, việc sửa đổi một tài liệu được thực hiện tuần tự. Nói cách khác, nếu bạn đang cập nhật ba giá trị trong một tài liệu, thì từng giá trị này lần lượt được cập nhật thành công hoặc không thay đổi. Như vậy, không có giao dịch nào tương đương với updates đồng bộ cho nhiều tài liệu. Để có thể xử lý dữ liệu đồng bộ như với SQL, ta cần phải xử lý code thủ công.

SQL vs NoSQL CRUD Syntax

Tạo, đọc, cập nhật và xóa dữ liệu là cơ sở của tất cả các hệ thống cơ sở dữ liệu. Về bản chất —

• SQL là một ngôn ngữ khai báo nhẹ (lightweight declarative language). Nó có hiệu quả mạnh mẽ và đã trở thành một tiêu chuẩn quốc tế, và hầu hết các hệ thống đều triển khai theo cú pháp khác nhau một cách tinh vi.
• Cơ sở dữ liệu NoSQL sử dụng các truy vấn JavaScripty với các đối số giống JSON! Các hoạt động cơ bản rất đơn giản, nhưng JSON lồng nhau (nested) sẽ khiến bạn bối rối đối với các truy vấn phức tạp hơn.

So sánh nhanh:

SQL	NoSQL
nhập đầu mục sách mới
INSERT INTO book ( `ISBN`, `title`, `author` ) VALUES ( '9780992461256', 'Full Stack JavaScript', 'Colin Ihrig & Adam Bretz' );	db.book.insert({ ISBN: "9780992461256", title: "Full Stack JavaScript", author: "Colin Ihrig & Adam Bretz" });
cập nhật đầu mục sách
UPDATE book SET price = 19.99 WHERE ISBN = '9780992461256'	db.book.update( { ISBN: '9780992461256' }, { $set: { price: 19.99 } } );
trả kết quả của tất cả đầu sách có giá trên $10
SELECT title FROM book WHERE price > 10;	db.book.find( { price: { >: 10 } }, { _id: 0, title: 1 } ); Object JSON thứ hai được xem là projection: Object này chỉ định trường nào sẽ được return (_id theo mặc định sẽ luôn được return).
Đếm số lượng sách SitePoint
SELECT COUNT(1) FROM book WHERE publisher_id = 'SP001';	db.book.count({ "publisher.name": "SitePoint" }); Giả định ta đang sử dụng tài liệu không chuẩn hóa.
Trả số kiểu định dạng sách
SELECT format, COUNT(1) AS `total` FROM book GROUP BY format;	db.book.aggregate([ { $group: { _id: "$format", total: { $sum: 1 } } } ]); Đây gọi là aggregation: một bộ document mới được tính toán từ bộ gốc.
Xóa tất cả sách SitePoint
DELETE FROM book WHERE publisher_id = 'SP001';	db.book.remove({ "publisher.name": "SitePoint" });

SQL vs NoSQL Performance

Có lẽ là so sánh gây tranh cãi nhất, NoSQL thường xuyên được cho là nhanh hơn SQL. Điều này không có gì đáng ngạc nhiên; Cách lưu trữ không chuẩn hóa đơn giản hơn của NoSQL cho phép bạn truy xuất tất cả thông tin về một mặt hàng cụ thể trong một request duy nhất. Không cần các JOIN liên quan hoặc các truy vấn SQL phức tạp.

Như vậy, thiết kế của dự án và yêu cầu dữ liệu của bạn sẽ có tác động nhiều nhất. Một cơ sở dữ liệu SQL được thiết kế tốt gần như chắc chắn sẽ hoạt động tốt hơn một NoSQL tương đương được thiết kế tồi và ngược lại.

SQL vs NoSQL Scaling

Khi dữ liệu mở rộng, bạn có thể thấy cần phải phân phối tải giữa nhiều máy chủ. Điều này có thể phức tạp đối với các hệ thống dựa trên SQL. Làm thế nào để bạn phân bổ dữ liệu liên quan? Clustering có thể là lựa chọn đơn giản nhất; nhiều máy chủ truy cập vào cùng một kho lưu trữ trung tâm - nhưng ngay cả điều này cũng có những thách thức.

Nói chung là vậy thôi, để triển khai cụ thể hơn hãy tìm lời khuyên của chuyên gia để có hướng phát triển phù hợp.

SQL vs NoSQL Practicalities

Cuối cùng, hãy xem xét các vấn đề về bảo mật và hệ thống. Các cơ sở dữ liệu NoSQL phổ biến nhất chỉ mới có mặt khoảng vài năm; nên sẽ dễ xuất hiện vấn đề hơn các sản phẩm SQL trưởng thành hơn. Nhiều vấn đề đã được đăng tải, nhưng hầu hết đều tập trung vào một điểm duy nhất: kiến thức.

Developers và sysadmins có ít kinh nghiệm hơn với các hệ thống cơ sở dữ liệu mới hơn, vì vậy sẽ dễ mắc phải sai lầm. Nếu chưa tìm hiểu kỹ mà chọn NoSQL chỉ để thử giải pháp mới mẻ hơn hoặc vì bạn muốn tránh thiết kế theo schema, thì việc vấp phải trục trặc chỉ là chuyện sớm muộn.

SQL vs NoSQL Summary

Cơ sở dữ liệu SQL và NoSQL đảm nhiệm cùng một nhiệm vụ theo những cách khác nhau. Ta hoàn toàn có thể chọn một trong hai và chuyển sang cái kia nếu cần thiết, nhưng hãy xem xét và tính toán cản thận để tiết kiệm thời gian và tiền bạc về sau.

Lý do nên chọn SQL:

• Các yêu cầu dữ liệu rời rạc liên quan đến lôgic có thể được xác định trước
• tính toàn vẹn dữ liệu là điều cần thiết
• Công nghệ đã được chứng minh dựa trên tiêu chuẩn với kinh nghiệm và hỗ trợ cho developer tốt.

Lý do nên chọn NoSQL:

• yêu cầu dữ liệu ít liên kết, không xác định hoặc đang phát triển
• mục tiêu dự án đơn giản hơn hoặc lỏng lẻo hơn, có thể bắt đầu viết mã ngay lập tức
• tốc độ và khả năng mở rộng là bắt buộc.

Trong trường hợp cửa hàng sách của chúng ta, cơ sở dữ liệu SQL được xem là lựa chọn thiết thực nhất - đặc biệt khi chúng ta đụng đến thương mại điện tử, thì yêu cầu hỗ trợ transaction phải càng chặt chẽ.

Theo dõi chúng tôi trên Facebook

Theo Sitepoint