Learn DevOps

Database căn bản

Hải Yến Trịnh's photo
Hải Yến Trịnh
·

15 min read

SQL databases vs NoSQL

SQL databases

Cơ sở dữ liệu SQL được thiết kế phục vụ việc lưu trữ dữ liệu có cấu trúc. Chúng có thể thực hiện truy vấn phức tạp và thường lưu trữ dữ liệu tối thiểu có thể bằng cách giảm mọi sự trùng lặp dữ liệu trong bảng trong một quy trình được gọi là chuẩn hóa. Dữ liệu được chuẩn hóa có nghĩa là việc truy cập nó thường yêu cầu các phép nối phức tạp của các bảng khác nhau.

Ảnh: packt publishing

Các bảng này chỉ chứa các cột cụ thể áp dụng cho chúng, vì vậy users chỉ chứa các cột về users và không chứa cột nào về movies hoặc ratings. Bảng movies cũng tương tự và chỉ chứa dữ liệu về phim. Hai bảng còn lại (tags và ratings) chứa các con trỏ quay lại bảng users và movies. Nếu bạn muốn lấy thông số first_name của người dùng đã xếp hạng 5 sao cho một bộ phim cụ thể, bạn sẽ phải nối ba bảng để truy xuất thông tin này vì nó không được lưu trữ ở một nơi. Đối với các tập dữ liệu lớn, bạn có thể thấy rằng hiệu suất sẽ kém vì cơ sở dữ liệu không chỉ phải lấy dữ liệu từ ba vị trí khác nhau mà còn phải kết hợp dữ liệu đó trước khi chuyển kết quả lại cho người dùng.

Cơ sở dữ liệu SQL tuân thủ các tiêu chuẩn tính atmoicity, consistency, isolation và durability (ACID) và là một lựa chọn tuyệt vời cho transactional data yêu cầu giảm thiểu sự mất dữ liệu và duy trì độ chính xác. Cơ sở dữ liệu SQL thường có thiết kế single-node design, vì vậy việc thêm các nodesbổ sung để tăng quy mô theo chiều ngang là khó khăn và tốn kém.

Cơ sở dữ liệu SQL đánh đổi tốc độ và hiệu suất của các bộ dữ liệu lớn để duy trì độ bền và nhất quán. Do đó, khi làm việc với dữ liệu có tổng số hàng triệu bản ghi, thường xảy ra các vấn đề về hiệu suất và chậm.

Có 2 loại SQL database:

  • Row-oriented (relational hoặc online transaction processing (OLTP))

  • Column-orientated (analytical hoặc online analytic processing (OLAP))

Ảnh: packt publishing

NOSQL

Bởi vì cơ sở dữ liệu NoSQL không sử dụng lược đồ bảng cụ thể, chúng được thiết kế để lưu trữ dữ liệu bán cấu trúc hoặc không cấu trúc. Khi cần, bạn có thể thêm thuộc tính dữ liệu mà không thay đổi cấu trúc của bảng. Các cơ sở dữ liệu không hoạt động tốt trong các truy vấn join do thiếu cấu trúc thực thi. Thông thường, cấu trúc cơ sở dữ liệu được xác định bằng cách xem application code sẽ được sử dụng để truy cập cơ sở dữ liệu và sau đó bắt chước cấu trúc tương tự.

Cơ sở dữ liệu NoSQL có thể mở rộng quy mô theo chiều ngang một cách dễ dàng và chúng được thiết kế để xử lý việc partitioning và sharding. Cơ sở dữ liệu NoSQL thường được sử dụng khi bạn cần thời gian phản hồi cực nhanh cho lượng lớn dữ liệu. Cơ sở dữ liệu NoSQL đạt được tốc độ này bằng cách sử dụng eventual consistency model. Khi sử dụng cơ sở dữ liệu NoSQL, có nguy cơ mất dữ liệu cao hơn và kết quả không nhất quán.

Các loại Cơ sở dữ liệu NoSQL:

  • Key-value databases

  • Document databases

  • Column-oriented and analytics databases

  • Graph databases

Ảnh: packt publishing

Relational database management systems

Có 2 kiểu lưu trữ:

  • Row-orientated

  • Column-orientated

Các kiểu hiệu suất khác nhau do các phương pháp lưu trữ và sắp xếp dữ liệu khác nhau gây ra (ví dụ: một số thứ hoạt động nhanh hơn những thứ khác), nhưng biết cách sử dụng loại phù hợp có thể cải thiện hiệu suất của ứng dụng của bạn. Bề ngoài của cả hai loại cơ sở dữ liệu có thể giống nhau, nhưng bên trong chúng khá khác nhau.

Row-orientated databases

Trong cơ sở dữ liệu hướng hàng, dữ liệu được lưu trữ trong các bảng ở dạng chuẩn hóa với các liên kết hoặc khóa giữa chúng.

Cơ sở dữ liệu định hướng theo hàng lưu trữ dữ liệu trong các khối liên tục, mỗi khối được kết nối với nhau. Hãy xem bảng sau:

Đây là cách lưu trữ trên ổ đĩa:

Dữ liệu được lưu trữ thành các hàng hoàn chỉnh, lần lượt từng hàng, như bạn có thể thấy. Nếu chúng ta thêm một hàng mới vào bảng này, cơ sở dữ liệu sẽ hoàn thành nhanh chóng vì nó chỉ cần tìm hàng cuối cùng trên đĩa và thêm dữ liệu mới vào. Điều này cũng sẽ hiệu quả đối với các lần đọc mà bạn muốn trả về phần lớn các cột từ mỗi hàng. Tuy nhiên, nếu bạn chỉ muốn trả một cột từ một bảng nhưng đối với một số lượng lớn hàng, thì có thể xảy ra vấn đề. Giả sử bạn muốn biết độ tuổi trung bình của mọi người. Tại đây, bạn sẽ phải đọc nhiều khối dữ liệu vì dữ liệu được lưu trữ rải rác trên toàn bộ đĩa. Sơ đồ sau đây cho thấy bạn cần đọc một truy vấn từ ba khu vực khác nhau của đĩa:

Tóm lại, về cơ sở dữ liệu định hướng theo hàng:

  • Nhanh chóng trong việc ghi dữ liệu

  • Hiệu quả trong việc truy xuất dữ liệu khi bạn cần trả về phần lớn dữ liệu của hàng.

  • Không hiệu quả khi bạn muốn truy vấn hay làm việc với các cột đơn lẻ.

Do đặc tính này, cơ sở dữ liệu định hướng theo hàng thường được sử dụng cho các ứng dụng có số lần đọc và ghi tương tự nhau và nơi bạn sẽ sử dụng nhiều dữ liệu trong mỗi hàng thay vì chỉ một cột. Những cơ sở dữ liệu này thường được gọi là cơ sở dữ liệu xử lý giao dịch trực tuyến hoặc cơ sở dữ liệu OLTP.

Các hệ thống xử lý phân tích trực tuyến (OLAP) theo hướng cột có thể hữu ích nếu bạn làm việc với phần lớn các cột dữ liệu đơn lẻ.

Column-orientated databases

Các cơ sở dữ liệu này sử dụng các bảng thường được chuẩn hóa và có các links hoặc keys giữa chúng. Sự khác biệt duy nhất nằm ở cách dữ liệu được lưu trữ trên đĩa. Hình dưới đây là Column-orientated databases được lưu trữ:

Dữ liệu được đặt trong các nhóm cột thay vì từng hàng, và mỗi mục từ mỗi cột được đặt cùng nhau. Nó sẽ trở nên phức tạp hơn nhiều nếu chúng ta thêm một hàng mới vào bảng. Bây giờ cơ sở dữ liệu phải tìm một khoảng trống trên đĩa nằm trong cùng khu vực với các cột khác hoặc phải di chuyển mọi thứ xung quanh để vừa khít hơn thay vì tìm phần cuối cùng của hàng cuối cùng và thêm dữ liệu mới vào đó. Điều này sẽ làm giảm đáng kể số lượng dữ liệu mới được thêm vào. Nếu bạn muốn đọc hầu hết các cột trong bảng, bạn sẽ phải chuyển sang nhiều khu vực khác nhau trên đĩa, gây ra các vấn đề về hiệu suất.

Cơ sở dữ liệu định hướng theo cột hoạt động rất tốt khi trả về dữ liệu tổng hợp từ một hoặc hai cột, chẳng hạn như xác định độ tuổi trung bình của người dùng. Bây giờ nó chỉ cần tìm một khu vực trên đĩa và lấy nó. Cơ sở dữ liệu định hướng theo cột nhanh chóng và hiệu quả khi truy xuất các cột đơn lẻ được minh họa trong sơ đồ sau:

Tóm tắt lại, dữ liệu lưu trữ dạng cột có các đặc điểm sau:

  • Chậm hơn trong việc ghi dữ liệu

  • Không hiệu quả trong việc truy xuất dữ liệu khi bạn cần trả về phần lớn dữ liệu của hàng.

  • Hiệu quả khi bạn muốn truy vấn các cột đơn.

Key – Value database

Có 2 kiểu dữ liệu NoSQL:

  • Key-value databases: DB có một khóa (ví dụ: khóa chính) và các giá trị được lưu bên cạnh khóa. Khi dữ liệu của bạn chứa nhiều cột hoặc cấu trúc dữ liệu không được xác định rõ ràng và cần truy vấn nhanh chóng, cơ sở dữ liệu Key-value trị rất hữu ích. Cơ sở dữ liệu Key-value cho phép lưu trữ phần lớn dữ liệu trong value component mà không cần phải xác định dữ liệu cụ thể giống như với RDBMS.

  • Document databases: lưu trữ dữ liệu ở các định dạng như JavaScript Object Notation (JSON). JSON được sử dụng rộng rãi trong các ngôn ngữ lập trình, do đó, việc có cơ sở dữ liệu sử dụng cùng định dạng sẽ trở thành lựa chọn hiệu quả cho nhiều nhà phát triển.

Key – value database

Key – value database chỉ có hai thành phần chính: một value, có thể là hầu hết mọi thành phần dữ liệu hoặc thông tin, và một key, lưu trữ vị trí của nó. Nhiều ngôn ngữ lập trình có arrays hoặc maps sử dụng khái niệm tương tự. Nó có thể giống như mục lục của một cuốn sách với các địa điểm để tìm thông tin. Trong trường hợp này, phương pháp tương tự được sử dụng để xây dựng một kho lưu trữ cho thời gian dài. Cấu trúc của chúng được minh họa như sau:

Như bạn có thể thấy, ngay cả trong một bảng, các giá trị không nhất quán. Điều này rất linh hoạt khi thiết kế bảng vì bạn có thể thêm thông tin bổ sung hoặc bỏ qua chúng mà không cần phải thiết kế lại bảng.

Trong các trường hợp sau đây, cơ sở dữ liệu key – value là lựa chọn tốt nhất:

  • Khi ứng dụng của bạn chứa một số lượng lớn các lượt đọc nhỏ

  • Khi ứng dụng của bạn chứa dữ liệu không ổn định và thay đổi thường xuyên

  • Khi ứng dụng của bạn không yêu cầu truy vấn phức tạp, chẳng hạn như các phép join

Một số trường hợp sử dụng điển hình:

  • Giỏ hàng trên trang web chứa user_id làm khóa và nội dung giỏ hàng dưới dạng giá trị, chẳng hạn như item_id, số lượng và số lượng

  • Bảng điểm chơi trò chơi dành cho hàng triệu người dùng chứa user_id làm khóa và điểm làm giá trị

  • Thông tin phiên đăng nhập của trang web chứa session_id cho khóa và thông tin phiên dưới dạng các giá trị, chẳng hạn như pages_accessed, login_time và session_expiry_time

Một trong những lợi ích chính của cơ sở dữ liệu key – value so với RDBMS là do dữ liệu có khóa để trỏ đến các giá trị nên dữ liệu có thể được lưu trữ ở nhiều vị trí, thậm chí trên các máy chủ khác nhau. Điều này cho phép bạn chạy nhiều node để hỗ trợ chia tỷ lệ theo chiều ngang (trong đó bạn thêm nhiều máy chủ để phân bổ tải theo chiều ngang, trái ngược với chia tỷ lệ theo chiều dọc, nơi bạn thêm nhiều tài nguyên hơn vào một máy chủ). Do một trong những hạn chế chính của RDBMS là tắc nghẽn hiệu năng do số lượng tài nguyên tối đa bạn có thể cung cấp cho một máy chủ, nên rõ ràng cơ sở dữ liệu key – value có thể hoạt động tốt hơn RDBMS cho các tập dữ liệu lớn.

Tóm lại, đặc điểm chính của key – value database:

  • Đọc rất nhanh trên các tập dữ liệu lớn.

  • Khả năng mở rộng theo chiều ngang để hỗ trợ số lượng lớn đọc và ghi đồng thời.

  • Các giá trị có thể chứa hầu hết mọi dữ liệu mà không cần xác định trước, do đó, chúng mang lại sự linh hoạt cho việc thay đổi nhu cầu ứng dụng mà không cần thiết kế lại các bảng cơ sở dữ liệu.

  • Đọc dữ liệu chậm hơn nếu bạn cần lọc theo các giá trị.

  • Không có khả năng sử dụng các câu lệnh SQL phức tạp như các câu lệnh aggregates.

  • Không có khả năng trả về dữ liệu từ nhiều bảng cùng một lúc.

Document databases

Là một loại cơ sở dữ liệu key – value đặc biệt. Nó vẫn giữ dữ liệu theo cùng một mẫu: khóa cho con trỏ và một giá trị chứa một số dữ liệu hoặc thông tin – nhưng những cơ sở dữ liệu này yêu cầu dữ liệu phải được lưu trữ ở định dạng document. Điều đó nghĩa là gì? Định dạng document là gì? Định dạng document cho cơ sở dữ liệu key – value trị không có nghĩa là tài liệu Word hoặc Excel mà là định dạng JSON:

{
    "name":"Paul",
    "username":"pauls56",
    "books":[
        { "title":"War and Peace", "price":15 },
        { "title":"Of Mice and Men", "price":12 }
    ]
}

Graph và ledger databases

  • Graph databases: được sử dụng khi bạn muốn hiển thị kết nối giữa các mục trong cơ sở dữ liệu của mình. Ví dụ: hãy xem xét Facebook và cách họ sử dụng bạn của bạn bè để giúp xác định những người mà bạn có thể biết và có thể muốn kết nối. Đây sẽ là một ví dụ điển hình khi cơ sở dữ liệu graph có thể là một lựa chọn tốt.

  • Ledger databases: là cơ sở dữ liệu theo dõi mọi thay đổi đã từng được thực hiện. Cơ sở dữ liệu sẽ không bao giờ thay đổi bất kỳ dữ liệu hiện có nào mà sẽ thêm phiên bản mới bên cạnh phiên bản gốc. Điều này có thể rất hữu ích cho các hệ thống như giao dịch ngân hàng, nơi việc có các biện pháp kiểm soát kiểm toán đặc biệt là rất quan trọng.

Graph databases

Graph database tập trung vào việc lưu trữ dữ liệu bằng cách nhấn mạnh các kết nối giữa chúng. Chúng không có bảng truyền thống; thay vào đó, chúng có các node để hiển thị các mục dữ liệu và các edge để hiển thị các kết nối giữa chúng. Trong ví dụ Facebook, các node sẽ liên kết người dùng với những thứ họ thích, trong khi các edges liên kết người dùng với những thứ họ thích.

Sử dụng mô hình này, sẽ dễ dàng tìm thấy tất cả những người thích sách hoặc thậm chí phức tạp hơn là tìm thấy tất cả những người bạn của Justin cũng thích sách.

Đối với những người quen với RDBMS và thậm chí cả các cơ sở dữ liệu NoSQL khác, Graph database có vẻ rất phức tạp.

Các đặc điểm chính:

  • Truy vấn rất nhanh, bất kể lượng dữ liệu được tải là bao nhiêu. Thời gian truy vấn phụ thuộc vào số lượng kết nối (edge) hơn là số lượng node.

  • Có sự thể hiện rõ ràng về kết nối giữa các điểm dữ liệu.

  • Không có ngôn ngữ truy vấn thống nhất. Mỗi cơ sở dữ liệu đồ thị có một ngôn ngữ, điều này có thể gây khó khăn cho việc di chuyển các ứng dụng.

  • Kém linh hoạt hơn các công cụ NoSQL khác vì rất khó thay đổi mô hình dữ liệu sau khi bạn đã load dữ liệu.

Một số trường hợp sử dụng mà cơ sở dữ liệu đồ thị có thể phù hợp như sau:

  • Lập bản đồ hành vi mua hàng của người dùng trong các cửa hàng trực tuyến để đưa ra đề xuất tốt cho các sản phẩm khác

  • Kết nối và liên kết truyền thông xã hội giữa người dùng, tương tác và trang

Ledger databases

Ledger databases chỉ đơn giản là một cơ sở dữ liệu trong đó không có dữ liệu hiện có nào có thể bị xóa hoặc thay đổi; nó là bất biến. Tất cả các thay đổi hoặc dữ liệu mới đều được thêm vào bản ghi, giống như một phiên bản. Các phiên bản này có thể được truy vấn để bạn có thể xem dữ liệu trông như thế nào tại bất kỳ thời điểm nào nhằm xác minh tính nhất quán của nó.

Chúng có ba thành phần – một bảng state table hiện tại (C), mà bạn sẽ truy vấn tất cả các giao dịch thông thường, một bảng history table (H), hiển thị tất cả các phiên bản trước đó của các hàng và một journal (J), ghi lại tất cả các giao dịch. các lệnh đã được chạy. Ví dụ đơn giản sau đây cho thấy một bảng ô tô đang được cập nhật:

Bảng đầu tiên, C – ô tô, giữ trạng thái ban đầu của bảng sau khi hàng được chèn vào.
Bảng dưới cùng, J – Journal, hiển thị câu lệnh INSERT đã được chạy để điền vào bảng.

Sau đó, cập nhật giá trị của tất cả những chiếc xe do hãng Ford sản xuất thành 20000.
Bảng C – xe ô tô được cập nhật để phản ánh sự thay đổi đó.
Bảng H – car có một hàng được thêm vào, thể hiện sự thay đổi đã được thực hiện.
J – Nhật ký được cập nhật để hiển thị lệnh CẬP NHẬT đã chạy.

Bằng cách lưu trữ dữ liệu theo cách này, chúng ta duy trì tốc độ truy vấn trạng thái dữ liệu hiện tại trong bảng C trong khi ghi lại tất cả các thay đổi ở hai vị trí khác. Chúng ta cũng có thể truy vấn lịch sử, bảng H để nhanh chóng tìm ra những thay đổi đã được thực hiện. Nhật ký cũng chứa một chuỗi dài gọi là hàm băm (hash). Hàm băm này được cập nhật mỗi khi bảng được thay đổi và có thể được sử dụng để đảm bảo rằng dữ liệu được lưu trữ trong bảng không bị thay đổi bên ngoài các truy vấn cơ sở dữ liệu. Nếu bạn tạo một hàm băm của bảng lịch sử và so sánh nó với nhật ký thì chúng phải khớp nhau; nếu không, điều này có nghĩa là dữ liệu đã bị giả mạo. Đây là những gì làm cho nó bất biến và có thể kiểm chứng được.

Một số trường hợp sử dụng:

  • Cơ sở dữ liệu giao dịch có tính quan trọng cao như của ngân hàng, nơi chủ sở hữu dữ liệu phải có khả năng chứng minh rằng dữ liệu là chính xác và không bị thay đổi.

  • Một giải pháp thay thế cho công nghệ blockchain. Blockchain sử dụng công nghệ băm tương tự để đảm bảo dữ liệu. Tuy nhiên, theo thời gian, những chuỗi này có thể phát triển lâu dài và trở nên quá khó để làm việc. Cơ sở dữ liệu sổ cái có thể khắc phục vấn đề này

Nguồn: AWS Certified Database – Specialty (DBS-C01) Certification guide, Pack publishing

AWS