Những điểm khác biệt giữa SQL và NoSQL

tải

SQL (Structured Query Language) từng là cơ chế lưu trữ dữ liệu chính hơn bốn thập kỉ qua với sự gia tăng các ứng dụng web như MysSQL , PostgreSQL, SQLite… NoSQL đã tồn tại từ nhưng năm 1960 nhưng gần đây mới trở lên được chú ý và được sử dụng phổ biến như MongoDB, Redis hay Apache Cassandra Bạn có thể tìm rất nhiều tutorial về cả SQL, NoSQL để tìm hiểu sâu về chúng. Trong bài viết này mình sẽ chỉ ra những điểm khác biệt giữa hai loại truy vấn này.

Contents

SQL tables và NoSQL Documents

SQL databases cung cấp kiểu lưu trữ dữ liệu dưới dạng bảng và các bảng này có quan hệ với nhau. VD thông tin books trong bảng được đặt tên books. Mỗi một row ứng với một record, mỗi column ứng với mỗi field dữ liệu. NoSQL databases lưu trữ dưới dạng JSON dưới dạng field-value từng cặp một.

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

Nó giống như document được lưu trữ trong một collection, tương tự như một bảng trong SQL vậy. Tuy nhiên bạn có thể lưu bất kì dữ liệu nào bạn thích VD

{
  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." }
  ]
}

SQL table thì lại tạo ra một mẫu dữ liệu rất chặt chẽ từ datatype, field name, validation, và đó cũng là điểm mấu chốt có thể gây ra những sai lầm. NoSQL thì lại mềm dẽo hơn rất nhiều và có thể lưu ở mọi nơi nên có vẫn có thể gặp vấn đề về nhất quán

SQL schema và NoSQL Schemaless

Trong SQL databases, ta có thể thêm dữ liệu nếu bạn tạo bảng và field types tương ứng được gọi là schema. Schema chứa nhưng thông tin về database mà bạn đang sử dụng như: primary keys, indexes, relationships … Do đó schema phải được design và implements đầu tiên. Tuy nhiên nó cũng có thể update sau nhưng những thay đổi lớn sẽ trở lên phức tạp hơn khi nhìn vào file schema.

Còn trong NoSQL dữ liệu được add mọi nơi và bất kì lúc nào. VD trong MongoDB đoạn dưới đây sẽ tạo ra một document mới trong book collection . MongoDB sẽ tự động add id unique cho mỗi document trong một collection.

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

NoSQL database có thể phù hợp hơn cho các dự án mà các yêu cầu dữ liệu ban đầu rất khó xác định.

SQL Normalization vs NoSQL Denormalization

Giả sử nếu muốn thêm thông tin nhà publisher vào databases. Một nhà xuất bản có thể cung cấp nhiều books vì vậy, trong một cơ sở dữ liệu SQL tạo một bảng publisher_tbl sau đó add một field publisher_id vào books_tbl để tham chiếu đến mỗi bản ghi trong publisher_tbl

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

Chúng ta có thể sử dụng các kỹ thuật chuẩn hóa trong NoSQL. Các documents trong book collection

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

và nó sẽ tham chiếu đến mỗi document trong publisher collection

{
  id: "SP001"
  name: "SitePoint",
  country: "Australia",
  email: "[email protected]"
}

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

{
  ISBN: 9780992461225,
  title: "JavaScript: Novice to Ninja",
  author: "Darren Jones",
  format: "ebook",
  price: 29.00,
  publisher: {
    name: "SitePoint",
    country: "Australia",
    email: "[email protected]"
  }
}

Điều này sẽ làm tốc độ query nhanh hơn. nhưng khi update thông tin của publisher thì lại phải update rất nhiều bản ghi.

SQL Relational JOIN vs NoSQL

SQL query cung cấp JOIN query rất 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. Ví dụ:

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

NoSQL không trang bị JOIN, và điều này có thể gây sốc cho những người có kinh nghiệm SQL. Nếu chúng ta sử dụng collection như mô tả ở trên, chúng ta cần phải get all các documents trong book collection, lấy tất cả các tài liệu của nhà xuất bản liên quan và liên kết chúng bằng tay trong logic chương trình của chúng ta. Đây là một trong những lý do denormalization thường là cần thiết.

SQL vs NoSQL Transactions

Trong SQL, hai hoặc nhiều record update có thể được thực hiện trong một transaction – đảm bảo tất cả update thành công hoặc nếu 1 record update fails thì sẽ rollback lại toàn bộ các record khác. Điều này đảm bảo tính đồng nhất cho dữ liệu

Trong NoSQL, việc sửa đổi một document là riêng lẻ. Nói cách khác, nếu bạn đang cập nhật ba giá trị trong một document, cả ba đều được cập nhật thành công hoặc nó vẫn không thay đổi. Tuy nhiên, không có transaction tương đương để update cho nhiều document. Có những option tương tụ như transaction.Nhưng chúng phải được xử lý thủ công trong khi viết code.

SQL vs NoSQL Performance

Đây là chủ đề đáng tranh cái nhất. NoSQL thường được cho là nhanh hơn SQL. Điều này không đáng ngạc nhiên; NoSQL thì denormalized cho phép bạn lấy được tất cả thông tin về một item cụ thể với các codition mà không cần JOIN liên quan hoặc truy vấn SQL phức tạp.

Điều đang nói là để hệ thống SQL hoạt động tốt và nhanh thì việc desgin tốt là cực kì quan trong và ngược lại.

SQL vs NoSQL conclusion

Từ bài viết này bạn có thể thấy được một số điểm khác biệt giữa SQL và NoSQL. cảm ơn bạn đã theo dõi SQL phù hợp với nhưng dự án đã có yêu cầu dữ liệu rõ ràng xác định quan hệ logic có thể được xác định trước. Còn NoSql phù hợp với những dự án yêu cầu dữ liệu không liên quan, khó xác định, đơn giản mềm dẻo khi đang phát triển

 

Để lại một bình luận