Cassandra được thiết kế như một sự kết hợp của cả hai hệ thống để đáp ứng các yêu cầu lưu trữ quy mô lớn, cả về kích thước dữ liệu và khối lượng truy vấn.. Khi cần không gian lưu trữ tra
Đánh giá chung
STT Họ và tên MSSV Tổng số công việc Đánh giá
Từng giai đoạn
Giai đoạn 1
Giai đoạn 1 Tìm hiểu công nghệ và lý thuyết
Phạm Châu Thanh Tùng Thiết kế giao diện người dùng 1 1
Thiết kế database và ERD 1
Phân chia công việc, xác định application domain và chọn DBMS để thực hiện ứng dụng
– Phân chia công việc cho mỗi thành viên trong nhóm Yêu cầu mỗi thành viên chọn 1 trong 6 topic được đưa ra trong yêu cầu đề BTL
– Xác định application domain cho hệ thống và công nghệ sử dụng
– Chọn giữa SQL và NoSQL để hiện thực ứng dụng, đối với nhóm chọn giữa MySQL và Apache Cassandra
– Mỗi thành viên được phân chia topic như sau:
∗ Lê Nguyên Chương: Data storage & management
∗ Vũ Xuân Mai Trung: Query processing
∗ Phạm Châu Thanh Tùng: Concurrency control
– Application domain của hệ thống: Hệ thống banking
∗ Backend: Node.js, NestJS, Docker, MySQL (Database)
∗ Frontend: Vite, React, TypeScript, shadcn
– DBMS được sử dụng để hiện thực ứng dụng: MySQL
– Tìm hiểu lý thuyết về topic đã được phân chia
– Xây dựng source cho chương trình
Giai đoạn 2
Giai đoạn 2 Hiện thực ứng dụng
Giai đoạn 3
Giai đoạn 2 Làm báo cáo và thuyết trình
Chuẩn bị nội dung thuyết trình 1 1 1 1 1
Hoàn chỉnh slide thuyết trình 1 1 1
Chỉnh sửa và xuất video thuyết trình 1 1
Hoàn chỉnh báo cáo và phân công thuyết trình
– Hoàn chỉnh báo cáo chung của nhóm
– Phân chia công việc cho buổi thuyết trình
– Thống nhất ngày giờ báo cáo thuyết trình
– Cả nhóm đọc sơ qua bài báo cáo
– Sửa lỗi trong hệ thống
– Mỗi thành viên tự hoàn chỉnh phần nội dung của mình trong bài báo cáo
– Mỗi thành viên chuẩn bị nội dung và thiết bị để quay video báo cáo thuyết trình
– Một thành viên trong nhóm đứng ra tổng hợp các video thuyết trình của nhóm, chỉnh sửa và gộp lại thành một video duy nhất để nộp
Trong thời đại công nghệ số, dữ liệu trở thành nguồn tài nguyên cốt lõi giúp tổ chức và doanh nghiệp ra quyết định chính xác và hiệu quả Việc thu thập, lưu trữ và phân tích dữ liệu không chỉ giúp xác định xu hướng và cải thiện quy trình hoạt động mà còn tạo ra lợi thế cạnh tranh Để quản lý khối lượng dữ liệu lớn một cách an toàn và hiệu quả, Hệ Quản trị Cơ sở Dữ Liệu là công cụ thiết yếu, cung cấp nền tảng tổ chức, lưu trữ và truy xuất dữ liệu có hệ thống Hệ thống này đảm bảo tính toàn vẹn, bảo mật và khả năng truy cập nhanh chóng, giúp doanh nghiệp tối ưu hóa quy trình làm việc, nâng cao chất lượng dịch vụ và đáp ứng tốt hơn nhu cầu của người dùng.
Trong các Hệ Quản trị Cơ sở Dữ Liệu hiện nay, có hai loại đang phổ biến hơn cả đó là SQL và NoSQL.
Cả hai loại đều có khả năng đáp ứng các nhu cầu khác nhau trong quản lý và xử lý dữ liệu.
Hệ Quản trị Cơ sở Dữ Liệu SQL sử dụng mô hình bảng để tổ chức dữ liệu thành các hàng và cột, từ đó cung cấp khả năng truy vấn mạnh mẽ Việc này không chỉ giúp đảm bảo tính toàn vẹn mà còn duy trì sự nhất quán của dữ liệu thông qua việc tuân thủ các nguyên tắc ACID.
Hệ Quản trị Cơ sở Dữ Liệu NoSQL được tối ưu hóa để xử lý dữ liệu phi cấu trúc và bán cấu trúc, mang lại khả năng mở rộng linh hoạt Với schema không cố định, NoSQL cho phép lưu trữ dữ liệu dưới nhiều dạng khác nhau như document-based (ví dụ: MongoDB), key-value (ví dụ: Redis), column-family (ví dụ: Cassandra) và graph-based (ví dụ: Neo4j).
Việc lựa chọn giữa SQL và NoSQL phụ thuộc vào tính chất dữ liệu và nhu cầu dự án, giúp tối ưu hóa quản lý và khai thác dữ liệu Bài tập lớn của nhóm sẽ phân tích chi tiết các khía cạnh của Hệ Quản trị Cơ sở Dữ Liệu SQL và NoSQL, cụ thể là MySQL cho SQL và Cassandra cho NoSQL Ngoài ra, nhóm cũng sẽ áp dụng những phân tích lý thuyết để phát triển một ứng dụng cụ thể dựa trên Hệ Quản trị Cơ sở Dữ Liệu đã chọn.
TỔNG QUAN VỀ HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU MYSQL VÀ
Chương này sẽ giới thiệu tổng quan về MySQL và Cassandra Thông tin của chương này được tham khảo từ [2] và [3]
Hệ Quản trị Cơ sở Dữ Liệu MySQL
Tổng quan về MySQL
MySQL là một hệ quản trị cơ sở dữ liệu SQL mã nguồn mở phổ biến nhất, được phát triển, phân phối và hỗ trợ bởi Oracle Corporation.
MySQL có các đặc điểm sau:
Hệ Quản trị Cơ sở Dữ Liệu (CSDL) là một hệ thống lưu trữ và tổ chức dữ liệu có cấu trúc, từ những danh sách đơn giản như danh sách mua sắm cho đến các tập dữ liệu phức tạp trong mạng lưới doanh nghiệp lớn.
Cơ sở dữ liệu trong MySQL là cơ sở dữ liệu quan hệ, nơi dữ liệu được lưu trữ trong các bảng riêng biệt và được tổ chức một cách tối ưu để tăng tốc độ truy xuất MySQL sử dụng ngôn ngữ chuẩn SQL (Structured Query Language) để truy cập và quản lý cơ sở dữ liệu hiệu quả.
Phần mềm mã nguồn mở cho phép người dùng tải xuống, sử dụng và chỉnh sửa miễn phí, không phải chi trả bất kỳ khoản phí nào.
Ngoài ra, MySQL có khá nhiều kiểu Storage Engine khác nhau do kiến trúc mà MySQL sử dụng là
"Pluggable Storage Engine" Trong phạm vi Bài tập lớn, ta chỉ đề cập và sử dụng loại Storage Engine mặc định của MySQL là InnoDB.
Tổng quan về Storage Engine: InnoDB
InnoDB là động cơ lưu trữ mặc định của MySQL 8.4, cung cấp tính toàn vẹn giao dịch (ACID) và bảo vệ dữ liệu người dùng thông qua các tính năng như commit, rollback và phục hồi sau sự cố Động cơ này sử dụng khóa cấp dòng và chỉ mục phân cụm để nâng cao hiệu suất và khả năng xử lý Ngoài ra, InnoDB cũng hỗ trợ các ràng buộc FOREIGN KEY nhằm bảo đảm tính toàn vẹn của dữ liệu.
Lược đồ sau biểu thị kiến trúc của InnoDB Storage Engine.
Hình 3.1: Lược đồ kiến trúc của InnoDB
Hệ Quản trị Cơ sở Dữ Liệu Cassandra
Apache Cassandra là một cơ sở dữ liệu NoSQL phân tán mã nguồn mở sử dụng mô hình lưu trữ dạng cột.
Cassandra được phát triển tại Facebook với kiến trúc Staged Event-Driven (SEDA), kết hợp giữa kỹ thuật lưu trữ và sao chép phân tán của Amazon (Dynamo) và mô hình dữ liệu cùng động cơ lưu trữ của Google (Bigtable) Cả Dynamo và Bigtable đều được thiết kế để đáp ứng nhu cầu về hệ thống lưu trữ mở rộng, đáng tin cậy và có độ sẵn sàng cao, tuy nhiên, mỗi hệ thống đều tồn tại những hạn chế riêng.
Cassandra được phát triển để kết hợp ưu điểm của cả hai hệ thống lưu trữ, nhằm đáp ứng nhu cầu lưu trữ quy mô lớn về kích thước dữ liệu và khối lượng truy vấn Khi các ứng dụng yêu cầu sao chép dữ liệu đầy đủ cùng với khả năng đọc và ghi nhanh chóng, việc thiết kế một mô hình cơ sở dữ liệu mới trở nên cần thiết, vì các hệ thống cơ sở dữ liệu quan hệ không còn đủ khả năng đáp ứng các yêu cầu của ứng dụng quy mô toàn cầu.
Cassandra ra đời đề giải quyết những khó khăn đó, và được thiết kế để hướng đến các mục tiêu:
• Nhân đôi đầy đủ cơ sở dữ liệu
• Tính sẵn sàng toàn cầu với độ trễ thấp
• Khả năng mở rộng trên phần cứng thông thường
• Tăng thông lượng tuyến tính với mỗi bộ xử lý bổ sung
• Cân bằng tải trực tuyến và tăng trưởng theo cụm
• Truy vấn theo hướng Partitioned key-oriented
• Lược đồ dữ liệu linh hoạt Ảnh sau mô tả cho các phần cơ bản của Cassandra, bao gồm Node, Data Center và Cluster.
Hình 3.2: Node, Data Center và Cluster trong Cassandra
Storage engine trong MySQL - InnoDB
In-memory structures
Buffer Pool, hay vùng đệm, là khu vực trong bộ nhớ chính mà InnoDB sử dụng để lưu trữ dữ liệu và chỉ mục khi được truy cập Thay vì xử lý trực tiếp trên bộ nhớ sơ cấp, buffer pool giúp tăng tốc độ xử lý bằng cách lưu trữ dữ liệu thường xuyên truy cập vào bộ nhớ thứ cấp Đối với các máy chủ database chuyên dụng, phần lớn bộ nhớ thứ cấp được sử dụng làm buffer pool cho các hệ cơ sở dữ liệu.
Buffer pool được chia thành các trang có khả năng chứa nhiều bản ghi, và được triển khai dưới dạng danh sách các trang liên kết Dữ liệu ít được sử dụng sẽ bị loại bỏ theo thuật toán LRU (Least Recently Used) Khi cần không gian lưu trữ cho trang mới trong vùng đệm, trang có tần suất sử dụng thấp nhất sẽ bị xóa, và trang mới sẽ được thêm vào giữa danh sách, nhằm đảm bảo hiệu suất tối ưu cho việc quản lý bộ nhớ.
• Phần đầu danh sách, hay được gọi là new sublist, chứa các trang mới được truy cập gần đây nhất
• Phần cuối của danh sách, hay được gọi là old sublist, chứa các trang cũ ít được truy cập gần đây
Hình 4.2: Lược đồ kiến trúc của Buffer Pool
Theo đó, thuật toán này sẽ hoạt động theo nguyên lý sau:
• Ít nhất 3/8 của vùng đệm được dành ra cho old sublist
• Phần giữa của danh sách là điểm giao nhau giữa new sublist và old sublist
• Liên tục thêm vào vị trí giữa của vùng đệm trong quá trình thực thi các câu lệnh SQL
Khi hệ thống cần truy cập một trang trong old sublist, nó sẽ được chuyển đến đầu của new sublist để đáp ứng yêu cầu của người dùng hoặc yêu cầu read-ahead từ InnoDB.
Trong quá trình hoạt động, các trang ít được truy cập sẽ dần được chuyển xuống cuối danh sách, hay còn gọi là old sublist, cho đến khi chúng bị loại bỏ hoàn toàn bởi InnoDB.
Trong điều kiện lý tưởng, kích thước vùng đệm nên được tối ưu hóa để hệ thống có thể truy cập nhanh chóng các trang thường dùng, từ đó nâng cao độ phản hồi và tránh phân trang Một vùng đệm lớn giúp MySQL hoạt động như một hệ cơ sở dữ liệu in-memory, cho phép dữ liệu chỉ cần được đọc từ bộ nhớ sơ cấp một vài lần và sau đó thực hiện các truy vấn trong bộ nhớ thứ cấp Kích thước mặc định của buffer pool là 128 MB (134217728 bytes).
Hình 4.3: Lược đồ kiến trúc của Change Buffer
Bộ đệm thay đổi (change buffer) là một cấu trúc dữ liệu quan trọng, dùng để lưu trữ các thay đổi đối với các chỉ mục phụ khi chúng không nằm trong vùng đệm Những thay đổi này thường là kết quả của các thao tác DML như INSERT, UPDATE và DELETE, được kết hợp khi các trang dữ liệu được tải vào vùng đệm thông qua các thao tác đọc.
Khác với chỉ mục phân cụm, chỉ mục phụ thường không yêu cầu tính độc nhất và việc chèn dữ liệu vào chúng diễn ra một cách ngẫu nhiên Các thao tác xoá và cập nhật có thể ảnh hưởng đến các trang chỉ mục phụ không liền kề trong cây chỉ mục Việc lưu trữ các thay đổi trong bộ nhớ đệm và hợp nhất chúng khi tải lên bộ nhớ thứ cấp giúp giảm thiểu lượng truy cập I/O tới bộ nhớ sơ cấp, so với việc tải tất cả các trang mỗi khi có yêu cầu chỉnh sửa Khi hệ thống ở trạng thái rỗi hoặc tắt, các thay đổi này sẽ được ghi vào bộ nhớ sơ cấp, và việc ghi hàng loạt thay đổi cùng lúc hiệu quả hơn so với ghi từng thay đổi ngay lập tức.
Vùng đệm log, hay log buffer, là bộ nhớ lưu trữ dữ liệu ghi vào các file log trên bộ nhớ sơ cấp và được ghi định kỳ xuống bộ nhớ này Kích thước mặc định của vùng đệm là 16 MB, và việc tăng kích thước này giúp các giao dịch lớn thực hiện mà không cần ghi log xuống bộ nhớ sơ cấp trước khi cam kết Tương tự như các vùng đệm khác, việc mở rộng kích thước log buffer sẽ giảm thiểu chi phí I/O lên đĩa do không phải ghi liên tục xuống bộ nhớ sơ cấp.
On-disk structures
Trong cơ sở dữ liệu sử dụng InnoDB, các bảng được lưu trữ trong bộ nhớ sơ cấp dưới dạng các file dữ liệu gọi là tablespaces Mỗi tablespace có khả năng chứa dữ liệu của một hoặc nhiều bảng cùng với các chỉ mục tương ứng.
Một vài loại tablespace có thể được kể tới bao gồm:
System Tablespace là khu vực lưu trữ dữ liệu cho toàn bộ hệ thống, không chỉ riêng cho từng bảng Thay vì lưu trữ dữ liệu trong các bảng riêng lẻ, InnoDB sử dụng System Tablespace để quản lý data dictionary, change buffer và undo logs Khu vực này có thể bao gồm một hoặc nhiều datafile, giúp tối ưu hóa việc quản lý và truy xuất dữ liệu.
Tablespace File-Per-Table được sử dụng để lưu trữ dữ liệu cho từng bảng và chỉ mục tương ứng, với mặc định là lưu trữ trong một datafile duy nhất trên filesystem của hệ điều hành.
Double-write buffer là khu vực lưu trữ đệm của InnoDB, nơi ghi lại các trang dữ liệu trước khi chúng được lưu vào các tệp dữ liệu Nếu hệ điều hành, hệ thống lưu trữ, hoặc tiến trình mysqld gặp sự cố, InnoDB có thể phục hồi dữ liệu từ bản sao lưu trong double-write buffer, đảm bảo tính toàn vẹn của dữ liệu trong quá trình phục hồi.
Redo và Undo log là dữ liệu quan trọng trong bộ nhớ sơ cấp, hỗ trợ phục hồi hệ thống sau sự cố Chúng giúp sửa chữa dữ liệu hoặc các trang bị ghi bởi giao dịch ngay khi hệ thống gặp sự cố Redo log được lưu trữ dưới dạng các tệp redo log, bao gồm các bản ghi dữ liệu bị ảnh hưởng.
Storage engine trong Apache Cassandra
CommitLog
CommitLog là nơi lưu trữ các thay đổi trên một node local trong Cassandra, hoạt động như một log chỉ cho phép thêm dữ liệu mà không xóa Tất cả dữ liệu trước khi được lưu vào node sẽ được ghi vào commit log, đảm bảo tính bền vững cho hệ thống trong trường hợp xảy ra sự cố Khi Cassandra khởi động, mọi thay đổi còn tồn đọng trong commit log sẽ được chuyển xuống memtables.
Memtables
Memtables là cấu trúc lưu trữ trong bộ nhớ, hoạt động như vùng đệm cho InnoDB Mỗi bảng trong hệ thống đều có một memtable riêng Khi hệ thống hoạt động, các memtables sẽ được ghi xuống bộ nhớ sơ cấp và chuyển đổi thành các SSTables bất biến.
SSTables
SSTables là các tệp dữ liệu bất biến mà Cassandra sử dụng để lưu trữ thông tin trên đĩa Dữ liệu trong SSTables được ghi từ memtables hoặc lấy từ các nút khác trong hệ thống Khi dữ liệu được ghi vào bộ nhớ chính, Cassandra nén các SSTables này thành một tệp duy nhất.
Cơ sở lý thuyết
Chỉ mục đơn mức
Chỉ mục đơn mức là công cụ giúp cải thiện hiệu quả tìm kiếm bản ghi trong tệp dữ liệu Nó thường được áp dụng cho một hoặc nhiều trường khác nhau, với cấu trúc bao gồm một trường chứa giá trị chỉ mục và một trường khác là con trỏ đến bản ghi Các mục trong chỉ mục này thường được sắp xếp theo giá trị của trường.
Chỉ mục có thể phân loại thành chỉ mục dày đặc (dense) hoặc thưa thớt (sparse):
• Chỉ mục dày đặc (dense): có entry cho mọi giá trị search key trong tệp tin dữ liệu.
• Chỉ mục thưa thớt (sparse): chỉ có entry cho một vài giá trị search key trong tệp tin dữ liệu.
Các loại chỉ mục đơn mức bao gồm: Chỉ mục sơ cấp (Primary Index), Chỉ mục thứ cấp (Secondary Index), Chỉ mục cụm (Clustering Index)
5.1.1.1 Chỉ mục sơ cấp (Primary Index)
• Là loại chỉ mục được định nghĩa trên một tập tin đã được sắp thứ tự theo trường khóa.
• Mỗi index entry tương ứng với 1 block trong tập tin dữ liệu, và bản ghi đầu tiên hoặc cuối cùng trong block được gọi là block anchor.
Hình 5.1: Chỉ mục sơ cấp - Primary Index
5.1.1.2 Chỉ mục cụm (Clustering Index)
• Là loại chỉ mục được định nghĩa trên một tập tin đã được sắp thứ tự theo trường không phải khóa.
• Mỗi entry là một giá trị phân biệt, entry này sẽ trỏ tới block dữ liệu chứa bản ghi có giá trị đó.
Hình 5.2: Chỉ mục cụm - Clustering Index
5.1.1.3 Chỉ mục thứ cấp (Secondary Index)
Index được sử dụng để đánh chỉ mục cho các tệp tin dữ liệu chưa được sắp xếp, cho phép truy cập nhanh chóng và hiệu quả Nó có thể áp dụng cho bất kỳ trường nào trong cơ sở dữ liệu, bao gồm cả các trường khóa và không khóa.
• Tập tin chỉ mục sẽ được sắp thứ tự, và bản ghi sẽ có 2 trường chính:
– Trường con trỏ trỏ tới bản ghi hoặc block chứa giá trị tương ứng.
Hình 5.3: Chỉ mục thứ cấp trên trường khóa - Secondary Index on Key Field
Hình 5.4: Chỉ mục thứ cấp trên trường không khóa - Secondary Index on non-Key Field
Chỉ mục đa mức
Ta có thể lập chỉ mục cho tệp tin chỉ mục để tạo thành chỉ mục đa mức (Multilevel Index).
Tập tin chỉ mục ban đầu được gọi là chỉ mục cấp 1, trong khi chỉ mục của nó được xác định là cấp 2 Quá trình này sẽ tiếp tục cho đến khi kích thước của tập tin chỉ mục phù hợp với kích thước của một block đĩa.
• Chỉ mục đa mức có thể được tạo dựa trên bất kỳ loại chỉ mục đơn mức nào.
Hình 5.5: Chỉ mục đa mức - Multilevel Index
Indexing trong InnoDB (MySQL)
Column Index
Index cột là loại index phổ biến nhất, cho phép truy vấn nhanh dữ liệu theo từng cột có index Với cấu trúc dữ liệu B-Tree, MySQL có khả năng tìm kiếm giá trị cụ thể, tập hợp giá trị hoặc phạm vi giá trị thông qua các toán tử như =, >, < trong mệnh đề WHERE Các loại index trong index cột bao gồm: Index prefixes, Fulltext indexes, Spatial indexes và Index trong Memory của Storage Engine.
Chúng tôi sử dụng chỉ mục này cho các trường kiểu chuỗi, cho phép tạo chỉ mục cho N ký tự đầu tiên của cột, từ đó giúp giảm đáng kể chi phí lưu trữ cho tập tin chỉ mục.
5.2.1.2 Fulltext Indexes Đây là loại index sử dụng cho việc tìm kiếm dữ liệu dạng chuỗi đầy đủ.
5.2.1.3 Spatial Indexes Đây là chỉ mục hỗ trợ cho các kiểu dữ liệu Spatial (loại dữ liệu được sử dụng để lưu trữ thông tin liên quan đến vị trí, hình dạng, và mối quan hệ không gian của các đối tượng trong không gian địa lý).
5.2.1.4 Index trong Memory của Storage Engine
Index trong Memory của Storage Engine mặc định sử dụng HASH index, nhưng cũng có hỗ trợBTREE Index.
Multiple-Column Index
MySQL hỗ trợ chỉ mục nhiều cột (Composite Index), cho phép một chỉ mục bao gồm tối đa 16 cột Tuy nhiên, đối với một số kiểu dữ liệu, chỉ có thể sử dụng chỉ mục trên một phần giá trị của cột.
Invisible Index
MySQL hỗ trợ chỉ mục vô hình (Invisible Index), loại chỉ mục không được bộ tối ưu hóa sử dụng Tính năng này có thể áp dụng cho các chỉ mục trên các trường khác ngoài khóa chính, bao gồm cả khóa chính rõ ràng và ngầm định.
Index mặc định luôn hiển thị, nhưng để kiểm soát tính hiển thị, bạn có thể sử dụng từ khóa VISIBLE hoặc INVISIBLE trong các lệnh tạo bảng, cập nhật bảng hoặc tạo index.
Descending Index
MySQL hỗ trợ Descending Index, từ khóa DESC trong khi định nghĩa index sẽ lưu trữ các giá trị khóa theo thứ tự giảm dần.
Indexing trong Cassandra
Storage-Attached Indexing (SAI)
Storage-Attached Indexing cho phép tạo các chỉ mục phụ (2i) trên một hoặc nhiều trường trong bảng dữ liệu, với mỗi chỉ mục có thể là một cột bất kỳ, mà không cần thiết phải áp dụng trên cột chứa partition key Ưu điểm của Storage-Attached Indexing là tăng cường hiệu suất truy vấn và tối ưu hóa việc tìm kiếm dữ liệu.
• Cho phép tìm kiếm vector cho các ứng dụng AI
• Chia sẻ dữ liệu chỉ mục chung giữa nhiều chỉ mục trên cùng một bảng
• Giảm thiểu các vấn đề mở rộng trong quá trình ghi dữ liệu
• Giảm đáng kể việc sử dụng đĩa
• Hiệu suất vượt trội cho phạm vi số học
• Truyền phát chỉ mục với cơ chế zero-copy
Loại chỉ mục này cũng hỗ trợ cho việc lọc các dữ liệu dựa trên:
• Logic AND/OR cho các kiểu dữ liệu số và văn bản
• Logic IN (sử dụng mảng giá trị) cho các kiểu dữ liệu số và văn bản
• Các kiểu dữ liệu số có độ dài cố định
• So sánh bằng cho kiểu văn bả
• Logic CONTAINS (dành cho tập hợp dữ liệu)
• Dữ liệu đã được mã hóa token
• Đường dẫn truy vấn nhận diện theo dòng
• Phân biệt chữ hoa/thường (tùy chọn)
• Chuẩn hóa Unicode (tùy chọn)
Secondary indexes (2i)
Chúng ta có thể tạo Secondary Index (2i) trên một hoặc nhiều trường của bảng dữ liệu, ngoại trừ cột chứa partition key Mặc dù là chỉ mục nguyên bản của Cassandra, nhưng hiệu năng của nó hiện được đánh giá là kém và độ trễ cao, do đó Storage-Attached Indexing được khuyến khích hơn Secondary Index nên được sử dụng cho bảng có nhiều dòng chứa giá trị được chỉ mục; càng nhiều giá trị duy nhất trong cột, việc truy vấn và duy trì chỉ mục sẽ tốn nhiều tài nguyên hơn Ví dụ, trong một bảng chứa hàng tỷ mục nhập cho các tay đua, nếu muốn tra cứu thứ hạng theo tay đua, cột năm đua sẽ là lựa chọn tốt để lập Secondary Index Tuy nhiên, cũng có những trường hợp không nên sử dụng loại chỉ mục này.
• Trên các cột có nhiều giá trị duy nhất khi truy vấn một khối lượng lớn bản ghi, nhưng lại chỉ cần một số ít kết quả.
• Bảng sử dụng cột counter.
• Trên cột thường xuyên được cập nhật hoặc xóa.
• Tìm kiếm một hàng dữ liệu trên một phân vùng rộng mà không thu hẹp khoảng truy vấn lại.
• Không dùng chung Search Index với Secondary Index.
Indexing giữa MySQL và Cassandra trong ngữ cảnh Ứng dụng Ngân hàng
Tính toàn vẹn dữ liệu (ACID)
Trong ứng dụng ngân hàng, tính toàn vẹn dữ liệu đóng vai trò quan trọng vì nó đảm bảo rằng các giao dịch tài chính liên quan đến tiền tệ và tài khoản diễn ra chính xác, tránh xảy ra lỗi trong quá trình giao dịch phức tạp.
MySQL là một hệ quản trị cơ sở dữ liệu tuân thủ chặt chẽ các nguyên tắc ACID Trong trường hợp có lỗi xảy ra trong quá trình ghi dữ liệu hoặc cập nhật chỉ mục, MySQL sẽ thực hiện rollback để hủy giao dịch Điều này đảm bảo rằng dữ liệu và chỉ mục luôn đồng bộ, nghĩa là hoặc cả hai đều được cập nhật thành công, hoặc không có thay đổi nào được thực hiện.
Cassandra không hỗ trợ ACID đầy đủ mà chỉ cung cấp Lightweight Transactions (LWT) Giao dịch trong Cassandra được thực hiện theo mô hình ghi không đồng bộ, cho phép ghi dữ liệu vào bảng một cách nhanh chóng Tuy nhiên, việc cập nhật chỉ mục, chẳng hạn như Secondary Index, có thể diễn ra ở một tiến trình khác và không đồng bộ, dẫn đến khả năng không khôi phục dữ liệu khi xảy ra lỗi trong quá trình cập nhật chỉ mục.
Các loại chỉ mục hỗ trợ
Hai hệ quản trị cơ sở dữ liệu đều có khả năng cung cấp các chỉ mục hỗ trợ cho việc truy vấn dữ liệu.
• Đối với MySQL: Primary Index, Secondary Index Ngoài ra còn có Full-Text Index hỗ trợ tìm kiếm trên các trường có kiểu VARCHAR.
Cassandra chỉ hỗ trợ Primary Index trên khóa phân vùng (partition key), trong khi Secondary Index có thể được hỗ trợ nhưng hiệu suất kém khi làm việc với dữ liệu lớn hoặc dữ liệu phân tán.
Hiệu năng đọc dữ liệu
Trong ứng dụng ngân hàng, việc truy cập và đọc dữ liệu một cách nhanh chóng và chính xác là rất quan trọng, đặc biệt khi người dùng cần kiểm tra số dư tài khoản, lịch sử giao dịch và các thông tin quan trọng khác.
MySQL cung cấp hiệu suất đọc tối ưu khi áp dụng kỹ thuật indexing cho các trường phù hợp Việc tối ưu hóa các truy vấn, dù đơn giản hay phức tạp, có thể đạt được thông qua việc sử dụng indexing trên các trường này.
Cassandra tối ưu hóa hiệu suất truy vấn khi sử dụng partition key Nếu truy vấn không dựa vào partition key, hệ thống sẽ phải quét dữ liệu trên nhiều node, dẫn đến giảm hiệu năng truy vấn.
Hiệu năng ghi dữ liệu
Các ứng dụng ngân hàng cần xử lý nhiều giao dịch trong thời gian ngắn, vì vậy hiệu suất ghi rất quan trọng để đảm bảo hệ thống có thể xử lý hàng triệu giao dịch mỗi ngày mà không bị trễ và đảm bảo độ chính xác cao.
Khi sử dụng MySQL, việc có nhiều chỉ mục có thể ảnh hưởng đến hiệu suất ghi dữ liệu, vì hệ thống phải cập nhật tất cả các chỉ mục liên quan Điều này có thể làm giảm hiệu suất ghi, đặc biệt trong các tình huống xử lý hàng loạt giao dịch liên tục.
Cassandra nổi bật với hiệu suất ghi cao nhờ vào mô hình ghi append-only, cho phép dữ liệu được ghi thêm mà không cần cập nhật nhiều chỉ mục khi có giao dịch mới.
Kết luận
Việc sử dụng index trong MySQL và Cassandra mang lại những lợi ích và hạn chế riêng Trong ngữ cảnh ngân hàng, MySQL được xem là lựa chọn ưu việt hơn.
Sử dụng Index trong ứng dụng Ngân hàng
Bảng Users
Đây là bảng lưu trữ thông tin người dùng trên hệ thống Các trường được sử dụng index bao gồm:
ID là trường khóa chính trong bảng, có vai trò quan trọng trong việc tìm kiếm người dùng khi tạo tài khoản hoặc trong quá trình xử lý logic ở backend thông qua việc tra cứu theo ID.
• username: trường tên đăng nhập của ứng dụng Được sử dụng để tìm kiếm nhanh người dùng khi xác thực.
Bảng Transactions
Đây là bảng lưu trữ thông tin các giao dịch trên hệ thống Các trường được sử dụng index bao gồm:
• id: là trường khóa chính của bảng Được sử dụng để tìm kiếm giao dịch theo id khi muốn truy vấn lại thông tin giao dịch.
• type: là trường loại giao dịch Được sử dụng để hỗ trợ truy vấn tìm kiếm các loại giao dịch như rút tiền (deposit), chuyển tiền (transfer),
• account: là trường số tài khoản thực hiện giao dịch Được sử dụng để hỗ trợ truy vấn các giao dịch theo số tài khoản.
Bảng Accounts
Đây là bảng lưu trữ thông tin tài khoản giao dịch của người dùng trong ứng dụng Các trường được sử dụng index bao gồm:
• id: là trường khóa chính của bảng Được sử dụng để tìm kiếm tài khoản theo id trong xử lý logic ở tầng backend.
• account_number: là trường số tài khoản giao dịch Được sử dụng để tìm kiếm, truy vấn thông tin tài khoản giao dịch.
Bảng Loans
Đây là bảng lưu trữ thông tin về khoản vay của tài khoản Các trường được sử dụng index bao gồm:
• id: là trường khóa chính của bảng Được sử dụng để tìm kiếm khoản vay theo id.
• account_id: là trường id của tài khoản giao dịch tạo khoản vay Được sử dụng để truy vấn các khoản vay theo id của tài khoản giao dịch.
Bảng Loan Payments
Đây là bảng lưu trữ thông tin về thông tin trả nợ khoản vay của tài khoản giao dịch Các trường được sử dụng index bao gồm:
• id: là trường khóa chính của bảng Được sử dụng để tìm kiếm khoản trả nợ theo id.
• loan_id: là trường id của khoản vay liên quan đến khoản trả Được sử dụng để truy vấn các khoản trả dựa trên khoản vay.
Giới thiệu về Query Processing
Truy vấn trong cơ sở dữ liệu là câu lệnh được viết bằng ngôn ngữ chuyên dụng như SQL, nhằm yêu cầu hệ thống cơ sở dữ liệu cung cấp một tập hợp bản ghi theo điều kiện tìm kiếm cụ thể.
Xử lý truy vấn trong hệ cơ sở dữ liệu là quá trình mà hệ quản trị cơ sở dữ liệu (DBMS) thực hiện để chuyển đổi và thực thi các truy vấn từ người dùng hoặc ứng dụng Mục tiêu chính của xử lý truy vấn là tìm ra phương pháp hiệu quả nhất để truy xuất dữ liệu yêu cầu, đồng thời đảm bảo độ chính xác và tối ưu hóa thời gian thực hiện.
Query Processing trong MySQL
Xử lý truy vấn trong hệ quản trị cơ sở dữ liệu SQL như MySQL bao gồm các bước nhận, phân tích, tối ưu hóa và thực thi các câu lệnh SQL từ người dùng hoặc ứng dụng.
Hình 6.1: Block Diagram mô tả Query Processing của SQLTrong MySQL, quá trình xử lý truy vấn bao gồm các bước chính sau:
1 Parsing (Phân tích cú pháp)
Khi người dùng gửi một truy vấn, MySQL tiếp nhận dưới dạng chuỗi văn bản và sử dụng trình phân tích cú pháp (parser) để kiểm tra tính hợp lệ của câu truy vấn theo cú pháp SQL tiêu chuẩn.
◦ Xây dựng một cây phân tích cú pháp (parse tree), biểu diễn cấu trúc logic của câu truy vấn.
◦ Kiểm tra xem câu truy vấn có hợp lệ không, ví dụ:
- Lệnh có tuân thủ cú pháp SQL không?
- Các từ khóa SQL được sử dụng đúng cách không?
◦ Nếu cú pháp không đúng, MySQL trả về thông báo lỗi với thông tin vị trí xảy ra lỗi.
◦ Nếu đúng, hệ thống chuyển sang bước tiếp theo.
• Mô tả:Sau khi cú pháp được xác nhận, MySQL kiểm tra ngữ nghĩa và quyền truy cập.
◦ Kiểm tra quyền truy cập: Xác minh người dùng hiện tại có quyền truy cập vào các bảng, cột hoặc đối tượng khác được tham chiếu.
◦ Kiểm tra tồn tại: Đảm bảo tất cả các bảng, cột, và hàm được đề cập trong truy vấn tồn tại.
◦ Kiểm tra kiểu dữ liệu: Kiểm tra tính tương thích của kiểu dữ liệu trong các toán tử (ví dụ: WHERE, JOIN).
◦ Nếu không có lỗi, truy vấn sẽ được chuẩn bị để tối ưu hóa.
◦ Nếu phát hiện lỗi (như bảng không tồn tại hoặc quyền truy cập bị từ chối), truy vấn sẽ bị dừng.
3 Query Optimization (Tối ưu hóa truy vấn)
• Mô tả:MySQL tối ưu hóa câu truy vấn để giảm thiểu thời gian và tài nguyên cần thiết cho việc thực thi.
◦ Tạo các chiến lược thực thi: MySQL xác định tất cả các cách có thể để thực hiện truy vấn (execution plans).
◦ Đánh giá chi phí (cost): Đo lường chi phí của từng chiến lược dựa trên:
- Số lượng hàng phải quét (row scan).
- Sử dụng chỉ mục (indexes).
- Loại join (nested loop join, hash join, v.v.).
• Chọn chiến lược tốt nhất:Dựa trên chi phí thấp nhất, MySQL chọn kế hoạch thực thi tối ưu nhất.
◦ EXPLAIN: Cho phép người dùng xem kế hoạch thực thi và cách MySQL dự định xử lý câu truy vấn.
4 Query Execution (Thực thi truy vấn)
• Mô tả:MySQL thực hiện câu truy vấn theo kế hoạch thực thi đã được tối ưu hóa.
◦ Gửi yêu cầu tới Storage Engine: Lấy dữ liệu từ các bảng được lưu trữ trong các StorageEngine (như InnoDB, MyISAM).
◦ Thực hiện các phép toán: Áp dụng các toán tử như WHERE, GROUP BY, ORDER BY, hoặc JOIN.
◦ Kết hợp dữ liệu: Xử lý các phép kết hợp bảng (joins), tính toán các giá trị tổng hợp (aggregate), hoặc áp dụng điều kiện lọc.
• Kết quả:Kết quả truy vấn (dữ liệu) được chuẩn bị để trả về cho client.
5 Result Return (Trả về kết quả)
• Mô tả:Sau khi dữ liệu được xử lý xong, MySQL trả kết quả về client (người dùng hoặc ứng dụng).
◦ Nếu cần, MySQL sẽ định dạng lại dữ liệu (chuyển đổi kiểu dữ liệu, sắp xếp lại kết quả).
◦ Truyền kết quả qua giao thức MySQL tới client.
• Kết quả:Dữ liệu hiển thị trên ứng dụng của người dùng hoặc được sử dụng để tiếp tục xử lý.
Query Processing trong Apache Cassandra
Xử lý truy vấn trong hệ quản trị cơ sở dữ liệu NoSQL như Apache Cassandra khác biệt rõ rệt so với các hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) như MySQL, bởi vì Cassandra là một cơ sở dữ liệu phân tán không tuân thủ mô hình quan hệ Quá trình này được tối ưu hóa để lưu trữ dữ liệu phi cấu trúc và truy xuất nhanh chóng trong môi trường phân tán Các đặc điểm chính của quá trình xử lý truy vấn trong Cassandra bao gồm khả năng mở rộng linh hoạt, hiệu suất cao trong việc xử lý khối lượng lớn dữ liệu và hỗ trợ cho các truy vấn phức tạp mà không cần đến cấu trúc bảng cố định.
• Phân tán:Truy vấn được phân phối tới nhiều node trong cụm, mỗi node chứa một phần dữ liệu.
Cassandra không sử dụng một kế hoạch truy vấn cố định như SQL do tính phân tán và cấu trúc dữ liệu linh hoạt Thay vào đó, kế hoạch truy vấn được xác định một cách động, tùy thuộc vào dữ liệu và cấu hình của cụm.
• Tối ưu hóa dựa trên dữ liệu:Cassandra tối ưu hóa truy vấn dựa trên cách dữ liệu được phân bố và cách các cột được lập chỉ mục.
Cassandra cung cấp cho người dùng khả năng lựa chọn giữa các cấp độ nhất quán khác nhau, từ nhất quán mạnh mẽ đến nhất quán cuối cùng, nhằm đáp ứng các yêu cầu cụ thể của ứng dụng.
Dưới đây là các bước chi tiết trong quá trình xử lý truy vấn trong Apache Cassandra:
• Câu truy vấn được viết bằng CQL (Cassandra Query Language), tương tự SQL.
• Người dùng hoặc ứng dụng gửi truy vấn tớiCoordinator Nodetrong cụm Cassandra Vai trò của Coordinator Node:
• Là node nhận truy vấn và chịu trách nhiệm xử lý nó.
• Coordinator không cần là node lưu dữ liệu, nó chỉ điều phối truy vấn tới các node lưu trữ thích hợp.
• Coordinator sử dụngCQL Parserđể kiểm tra cú pháp và tính hợp lệ của câu truy vấn Bao gồm:
◦ Kiểm tra các thành phần như bảng, cột có tồn tại không.
◦ Đảm bảo truy vấn phù hợp với mô hình dữ liệu được định nghĩa trước.
• Cassandra không hỗ trợ các truy vấn phức tạp như JOIN, GROUP BY hoặc quét toàn bộ bảng mà không có điều kiện cụ thể (WHERE).
• Cassandra sử dụng một thuật toán băm (hashing) để phân phối dữ liệu trên các node.
• Mỗi giá trịpartition key được băm thành một giá trị hash, từ đó xác định token range mà dữ liệu thuộc về.
◦ Coordinator tính toán token của partition key từ truy vấn
◦ Dựa trên token, Coordinator xác định node (hoặc các node) lưu trữ dữ liệu cần thiết.
• Dựa trên token range, Coordinator xác định các node lưu trữ bản sao (replica nodes) của dữ liệu.
• Số lượng bản sao được xác định bởi Replication Factor (RF) trong cấu hình Cassandra.
Ví dụ: Nếu RF=3, dữ liệu sẽ được sao chép trên 3 node trong cụm.
5 Gửi Truy Vấn Tới Replica Nodes
• Coordinator gửi truy vấn tới tất cả các replica nodes chịu trách nhiệm lưu trữ dữ liệu.
◦ Cassandra sử dụnggiao thức Gossipđể duy trì thông tin trạng thái của các node trong cụm.
◦ Truy vấn được gửi qua giao thứcBinary Protocol.
◦ Quorum Read: Coordinator cần phản hồi từ đa số các replica nodes.
◦ One Read: Chỉ cần phản hồi từ một node.
◦ All Read:Tất cả replica nodes phải phản hồi.
6 Xử Lý Tại Replica Nodes
• Replica nodes truy xuất dữ liệu từSSTablesvàMemtables.
• Dữ liệu từ nhiều nguồn có thể được hợp nhất để trả về bản ghi đúng nhất (dựa trên cơ chế Last Write Wins).
7 Coordinator Tổng Hợp Kết Quả
• Sau khi nhận phản hồi từ các replica nodes:
◦ Coordinator kiểm tra tính nhất quán (dựa trên cơ chếConsistency Level).
◦ Nếu dữ liệu không đồng nhất giữa các node, Coordinator có thể yêu cầu Read Repair để sửa lỗi.
8 Trả Kết Quả Cho Client
• Sau khi tổng hợp và xác minh kết quả, Coordinator trả dữ liệu về client.
So sánh và đánh giá
So sánh
Tiêu chí MySQL Apache Cassandra
Ngôn ngữ truy vấn Sử dụngSQL (Structured Query
Language)với hỗ trợ đầy đủ cho truy vấn phức tạp
CQL (Cassandra Query Language) là ngôn ngữ truy vấn tương tự như SQL, nhưng có những hạn chế đối với các truy vấn phức tạp Các truy vấn trong CQL được xử lý bởi một máy chủ trung tâm, giúp tối ưu hóa hiệu suất và quản lý dữ liệu hiệu quả.
Truy vấn được gửi tớiCoordinator Node, điều phối truy vấn trên các node trong cụm.
Truy vấn JOIN Hỗ trợ truy vấn JOIN giữa các bảng Không hỗ trợ JOIN; cần thiết kế schema phù hợp để tránh nhu cầu ghép bảng.
Xử lý WHERE Có thể sử dụng các phép so sánh và biểu thức phức tạp trong điều kiện WHERE.
Hệ thống chỉ hỗ trợ câu lệnh WHERE dựa trên khóa phân vùng hoặc các cột đã được lập chỉ mục, do đó không thực hiện quét toàn bộ bảng Ngoài ra, thứ tự dữ liệu được hỗ trợ giúp sắp xếp và tìm kiếm dữ liệu trực tiếp từ bảng một cách hiệu quả.
Dữ liệu được sắp xếp theo clustering columns; cần lập kế hoạch trước khi tạo bảng
Tính nhất quán mạnh mẽ theo ACID (Atomicity, Consistency, Isolation, Durability).
Hỗ trợ tính nhất quán có thể điều chỉnh (từ ONE đến ALL) dựa trên yêu cầu của ứng dụng.
Tốc độ xử lý Chậm hơn khi xử lý lượng lớn dữ liệu hoặc truy vấn phức tạp.
Nhanh hơn nhờ thiết kế phân tán và tối ưu hóa cho đọc/ghi quy mô lớn. Partition Key Không có khái niệm partition key rõ ràng.
Bắt buộc sử dụng partition key để truy vấn nhanh và tránh quét toàn bộ bảng.
Query Cache Hỗ trợ cache kết quả truy vấn để tăng tốc các truy vấn lặp lại.
Không hỗ trợ cache kết quả truy vấn; tập trung vào tốc độ truy xuất phân tán.
Bảng 6.1: Bảng so sánh quá trình xử lý truy vấn giữa MySQL và Apache Cassandra
Từ bảng so sánh trên, ta có thể kết luận chung như sau:
MySQL là lựa chọn lý tưởng cho các ứng dụng truyền thống yêu cầu xử lý truy vấn phức tạp, quản lý giao dịch chặt chẽ và đảm bảo tính nhất quán cao Tuy nhiên, MySQL có thể gặp khó khăn về hiệu suất khi phải xử lý dữ liệu lớn hoặc khi cần mở rộng quy mô.
Apache Cassandra được phát triển để đáp ứng nhu cầu mở rộng cao và xử lý khối lượng dữ liệu phân tán lớn, đồng thời cung cấp khả năng điều chỉnh tính nhất quán một cách linh hoạt Tuy nhiên, để tối ưu hóa hiệu suất truy vấn, việc thiết kế schema một cách cẩn thận là rất cần thiết.
Đánh giá
Quá trình xử lý truy vấn là yếu tố then chốt trong hệ thống ngân hàng, đặc biệt là các dịch vụ Internet Banking Mỗi loại hệ quản trị cơ sở dữ liệu (DBMS) có mức độ phù hợp khác nhau trong bối cảnh này, ảnh hưởng trực tiếp đến hiệu suất và trải nghiệm người dùng.
◦ Xử lý truy vấn phức tạp:MySQL hỗ trợ các truy vấn với JOIN, GROUP BY, và ORDER
BY, rất cần thiết trong các trường hợp như:
- Lấy lịch sử giao dịch của khách hàng.
- Tính toán số dư tài khoản dựa trên các giao dịch trước đó.
- Thống kê giao dịch trong một khoảng thời gian cụ thể.
◦ Tối ưu hóa sử dụng chỉ mục:
- MySQL sử dụng chỉ mục để tăng tốc các truy vấn, đặc biệt với các cột thường xuyên được tìm kiếm (ví dụ: số tài khoản, ngày giao dịch).
- Cung cấp công cụ EXPLAIN PLAN để phân tích hiệu suất truy vấn và tối ưu hóa chúng.
- Hỗ trợ các giao dịch đa bước, đảm bảo tất cả các bước trong truy vấn đều thành công hoặc bị hủy (Atomicity).
- Hỗ trợ locking (khóa) để bảo vệ dữ liệu trong các truy vấn đồng thời.
Query Cache cung cấp khả năng lưu trữ kết quả của các truy vấn, giúp tăng tốc độ xử lý cho những truy vấn lặp lại Điều này đặc biệt hữu ích cho các báo cáo hoặc kiểm tra số dư tài khoản diễn ra thường xuyên, mang lại hiệu suất cao hơn cho hệ thống.
◦ Khi dữ liệu lớn hoặc yêu cầu truy vấn trên nhiều server, MySQL có thể gặp khó khăn nếu không sử dụng clustering hoặc sharding.
Cassandra tối ưu hóa hiệu suất truy vấn bằng cách tập trung vào partition key, cho phép xử lý nhanh chóng các truy vấn đơn giản.
- Truy xuất lịch sử giao dịch của một tài khoản cụ thể.
- Kiểm tra trạng thái tài khoản theo ID.
- Hỗ trợ sắp xếp dữ liệu theo clustering columns, nhưng cần được thiết kế trước khi tạo bảng.
Truy vấn được phân tán trên nhiều node giúp tối ưu hiệu suất trong môi trường phân tán, nhưng cần điều chỉnh mức Consistency Level để đảm bảo độ chính xác cao trong thời gian thực.
◦ Không tối ưu cho các truy vấn yêu cầu tính toán hoặc xử lý liên bảng.
◦ Tính nhất quán trong truy vấn phụ thuộc vào cấu hình Consistency Level, nhưng ngay cả mức ALL cũng không đảm bảo mạnh như MySQL.
◦ Phải thiết kế schema phù hợp ngay từ đầu cho từng loại truy vấn cụ thể, hạn chế sự linh hoạt khi yêu cầu thay đổi.
Cassandra không hỗ trợ các phép toán phức tạp như JOIN, GROUP BY và các hàm tổng hợp, điều này có thể làm giảm hiệu quả trong việc tổng hợp dữ liệu hoặc đối soát tài khoản.
MySQL là sự lựa chọn tối ưu cho hệ thống Internet Banking nhờ khả năng xử lý các truy vấn phức tạp, hỗ trợ giao dịch hiệu quả và đảm bảo tính chính xác cao.
Apache Cassandra phù hợp cho các tình huống cụ thể như lưu trữ log giao dịch và xử lý các truy vấn đơn giản với khối lượng dữ liệu lớn và yêu cầu phân tán cao Tuy nhiên, nó không đủ mạnh để thay thế MySQL cho toàn bộ hệ thống.
Giới thiệu về transaction
Giao tác (Transaction) là khái niệm quan trọng trong hệ quản trị cơ sở dữ liệu, bao gồm các thao tác như thêm, sửa, xóa và truy vấn dữ liệu, được coi là một đơn vị công việc logic duy nhất Mục tiêu chính của giao tác là duy trì trạng thái nhất quán của dữ liệu, ngay cả khi có lỗi hoặc sự cố hệ thống xảy ra.
Transaction trong SQL
Cơ sở lý thuyết
Các hệ quản trị cơ sở dữ liệu SQL như MySQL, PostgreSQL và Oracle được thiết kế để tuân thủ mô hình ACID, bao gồm bốn đặc tính chính: Tính nguyên tử (Atomicity), Tính nhất quán (Consistency), Tính cách ly (Isolation) và Tính bền vững (Durability).
Atomicity (Tính bảo toàn) đảm bảo rằng mọi câu lệnh trong một nhóm lệnh đều phải được thực hiện thành công Nếu có bất kỳ câu lệnh nào gặp lỗi, giao dịch sẽ bị hủy bỏ ngay tại thời điểm xảy ra lỗi, và tất cả các thao tác trước đó sẽ được khôi phục về trạng thái ban đầu.
Tính nhất quán là yếu tố quan trọng trong cơ sở dữ liệu, đảm bảo rằng sau mỗi giao dịch, trạng thái của cơ sở dữ liệu vẫn được duy trì Điều này có nghĩa là các ràng buộc và quy tắc đã được định nghĩa, như khóa chính và khóa ngoại, sẽ không bị vi phạm khi giao dịch hoàn tất.
Tính cô lập trong các transaction đảm bảo rằng chúng được thực thi độc lập và không ảnh hưởng lẫn nhau Dù có nhiều transaction chạy song song, kết quả cuối cùng vẫn giống như chúng được thực hiện tuần tự, giúp ngăn chặn các lỗi như đọc dữ liệu chưa được cam kết (dirty read), dữ liệu bị thay đổi giữa các lần đọc (phantom read), và dữ liệu không nhất quán trong cùng một transaction (non-repeatable read).
Tính bền vững trong cơ sở dữ liệu đảm bảo rằng sau khi một giao dịch được cam kết, mọi thay đổi sẽ được ghi lại vĩnh viễn, bất chấp các sự cố như mất điện hay lỗi hệ thống Điều này thường được thực hiện thông qua các cơ chế sao lưu và ghi log hiệu quả.
Mô hình ACID là yếu tố cốt lõi trong các cơ sở dữ liệu quan hệ, đảm bảo rằng các giao dịch được thực hiện một cách đáng tin cậy và chính xác, đồng thời tránh xung đột Nhờ vào nguyên tắc ACID, các hệ thống cơ sở dữ liệu SQL có khả năng duy trì tính toàn vẹn của dữ liệu trong các ứng dụng phức tạp như tài chính, ngân hàng, thương mại điện tử và quản lý chuỗi cung ứng.
Minh họa trong MySQL
Trong MySQL, cơ chế transaction được hỗ trợ chủ yếu bởi các storage engine như InnoDB, đồng thời tuân thủ nghiêm ngặt các thuộc tính của mô hình ACID Bài viết sẽ mô tả chi tiết các lệnh sử dụng để quản lý transaction trong MySQL.
• START TRANSACTION/BEGIN:Bắt đầu một transaction mới Từ thời điểm này, tất cả các thao tác SQL sẽ thuộc về transaction hiện tại cho đến khiCOMMIT hoặcROLLBACKđược gọi.
• COMMIT:Xác nhận transaction hiện tại, lưu tất cả thay đổi vào cơ sở dữ liệu vĩnh viễn Sau khi commit, transaction sẽ kết thúc.
• ROLLBACK:Hủy bỏ tất cả các thay đổi được thực hiện trong transaction hiện tại, đưa cơ sở dữ liệu về trạng thái trước khi bắt đầu transaction.
• SAVEPOINT:Tạo điểm lưu tạm thời (savepoint) trong transaction để có thể rollback một phần thay vì toàn bộ transaction.
ROLLBACK TO SAVEPOINT cho phép quay lại một savepoint đã được tạo trong giao dịch, giúp hủy bỏ tất cả các thay đổi được thực hiện kể từ savepoint đó, trong khi vẫn giữ nguyên giao dịch đang mở.
Khi chế độ AUTOCOMMIT được kích hoạt, mỗi lệnh SQL sẽ được xử lý như một giao dịch độc lập và sẽ tự động được xác nhận sau khi hoàn tất Ngược lại, nếu AUTOCOMMIT bị tắt, người dùng cần phải sử dụng các lệnh COMMIT hoặc ROLLBACK để xác nhận hoặc hủy bỏ giao dịch.
SET TRANSACTION cho phép người dùng đặt mức độ cô lập cho giao dịch hiện tại hoặc thiết lập mặc định cho các giao dịch sau Có tổng cộng 4 mức độ cô lập, chi tiết về từng mức độ sẽ được trình bày trong Chương 8.
– READ UNCOMMITTED: Cho phép đọc dữ liệu chưa được commit.
– READ UNCOMMITTED: Chỉ đọc được dữ liệu đã được commit.
Mức độ cô lập REPEATABLE READ đảm bảo rằng dữ liệu đọc không thay đổi trong suốt quá trình giao dịch, trong khi SERIALIZABLE là mức độ cô lập cao nhất, cho phép các giao dịch được xử lý tuần tự Để hiểu rõ hơn về cách thức hoạt động của các lệnh này, nhóm sẽ cung cấp ví dụ cơ bản với các bước thực hiện giao dịch trên MySQL Command Line Interface (CLI).
1 Tạo bảng accounts với account_id là primary key và balance là số dư tài khoản Chọn Engine là InnoDBđể hỗ trợ cho transaction
Hình 7.1: Tạo bảng accounts với các trường thuộc tính
2 Thêm các dữ liệu mẫu và kiểm tra trạng thái ban đầu của bảng.
Hình 7.2: Thêm giá trị mẫu
3 Bắt đầu transaction và thực hiện cập nhật số tiền cho hai tài khoảnAvàB
Hình 7.3: Khởi tạo transaction và cập nhật giá trị
4 Thực hiệnCOMMITvà xem lại trạng thái bảng
Hình 7.4: Trạng thái bảng sau khi đãCOMMIT
5 Thực hiện cập nhật tương tự với hai tài khoảnCvàD, nhưng sử dụngROLLBACKđể hủy thay đổi.
Hình 7.5: Cập nhật giá trị cho bảng
Hình 7.6: Sử dụngROLLBACKđể hủy thay đổi
6 Sử dụngSAVEPOINTđể đánh dấu tại vị trí hoàn thành cập nhật tài khoản C.
Hình 7.7: Sử dụngSAVEPOINT để đánh dấu điểm cập nhật
7 Thực hiệnROLLBACK TO SAVEPOINTđến vị trí đã dánh dấu vàCOMMIT Khi đó những thay đổi trước điểm đánh dấu sẽ được lưu lại
Hình 7.8: Sử dụng ROLLBACK TO SAVEPOINTđể quay lại vị trí đã đánh dấu
Transaction trong NoSQL
Cơ sở lý thuyết
Các hệ cơ sở dữ liệu NoSQL như MongoDB, Cassandra và Redis thường không tuân thủ các nguyên tắc ACID Thay vào đó, chúng áp dụng mô hình BASE (Basically Available, Soft state, Eventual consistency), trong đó hiệu suất và khả năng mở rộng được ưu tiên hơn tính nhất quán ngay lập tức.
Giao dịch trong NoSQL thường không nghiêm ngặt và có thể không hỗ trợ đầy đủ các tính chất ACID, đặc biệt là trong các hệ thống phân tán Thay vào đó, mô hình BASE được xác định qua ba yếu tố chính.
Hệ thống phân tán được thiết kế để luôn sẵn sàng đáp ứng yêu cầu của người dùng, ngay cả khi xảy ra sự cố tại một số nút Tuy nhiên, cần lưu ý rằng kết quả trả về không nhất thiết phải là kết quả cuối cùng, do sự nhất quán có thể chưa được đảm bảo ngay lập tức.
Trạng thái mềm (Soft state) đề cập đến tình trạng của hệ thống có khả năng thay đổi theo thời gian, ngay cả khi không có thao tác ghi nào diễn ra, do quá trình đồng bộ hóa giữa các nút trong hệ thống phân tán Điều này khác biệt với mô hình ACID, trong đó dữ liệu luôn được xem là cố định và chính xác.
Nhất quán cuối cùng (Eventual Consistency) là khái niệm trong đó dữ liệu không được nhất quán ngay lập tức trên toàn hệ thống, nhưng sẽ đạt được sự nhất quán sau một khoảng thời gian nhất định Đây là sự đánh đổi giữa tính nhất quán và hiệu suất, phù hợp với các hệ thống yêu cầu khả năng mở rộng lớn.
Minh họa trong Cassandra
Cassandra không hỗ trợ giao dịch theo cách truyền thống như các cơ sở dữ liệu quan hệ (RDBMS), nhưng nó cung cấp các công cụ và cơ chế để quản lý các thao tác nhất quán trên dữ liệu Các công cụ này giúp người dùng thực hiện các thao tác tương tự như giao dịch trong Cassandra, đảm bảo tính nhất quán và hiệu quả trong việc quản lý dữ liệu.
Cassandra sử dụng cơ chế sao chép dữ liệu để đảm bảo khả năng phục vụ các yêu cầu đọc/ghi ngay cả khi một số nút trong hệ thống gặp sự cố hoặc không khả dụng Dữ liệu được sao chép và lưu trữ trên nhiều nút, giúp đảm bảo rằng khi một nút gặp lỗi, luôn có một nút khác sẵn sàng xử lý yêu cầu Hệ thống này hỗ trợ hai chiến lược sao chép dữ liệu.
SimpleStrategy là một phương pháp được áp dụng cho trung tâm dữ liệu và cấu trúc rack Ban đầu, Cassandra sử dụng logic phân vùng để xác định nút nơi đặt hàng, sau đó thực hiện việc đặt các bản sao bổ sung vào các nút tiếp theo theo hướng kim đồng hồ trong vòng.
NetworkTopologyStrategy là một chiến lược lý tưởng cho các hệ thống có nhiều trung tâm dữ liệu và nhiều rack Chiến lược này cho phép người dùng chỉ định hệ số sao chép khác nhau cho từng trung tâm dữ liệu, đồng thời phân bổ các bản sao giữa các rack khác nhau trong cùng một trung tâm dữ liệu, nhằm tối ưu hóa tính khả dụng.
Tính nhất quán trong hệ thống phân tán là một thách thức lớn, đặc biệt khi Cassandra ưu tiên tính khả dụng hơn là tính nhất quán Thay vì tối ưu hóa tính nhất quán, Cassandra cho phép người dùng điều chỉnh mức độ nhất quán theo từng trường hợp sử dụng cụ thể Trong nhiều tình huống, Cassandra áp dụng nguyên tắc Eventual Consistency để đảm bảo dữ liệu được đồng bộ hóa theo thời gian.
Tunable Consistency là một cơ chế trong nhóm Eventual Consistency của mô hình BASE, cho phép thiết lập mức độ nhất quán cho các hoạt động đọc hoặc ghi theo yêu cầu của ứng dụng khách Mỗi hoạt động có thể có mức độ nhất quán khác nhau, tùy thuộc vào nhu cầu, quyết định số lượng bản sao cần xác nhận để hoạt động đọc hoặc ghi thành công Cơ chế này sử dụng Consistency Level để thể hiện các mức độ nhất quán phổ biến.
∗ ALL: Dữ liệu phải được ghi/đọc từ tất cả các bản sao Đây là mức đảm bảo nhất quán cao nhất.
∗ QUORUM:Dữ liệu được ghi/đọc từ đa số (n/2 + 1) các bản sao.
∗ LOCAL_QUORUM:Tương tựQUORUM, nhưng chỉ áp dụng trong datacenter local.
∗ ONE:Ghi/đọc từ một bản sao duy nhất Mức này ưu tiên hiệu suất hơn tính nhất quán.
∗ ANY:Dữ liệu có thể được ghi vào bất kỳ node nào, kể cả một node hint (dùng khi node chính tạm thời không khả dụng).
Tính nhất quán tuyến tính (Linearizable consistency) thuộc nhóm Nhất quán mạnh (Strong Consistency), thường liên quan đến các mô hình đồng bộ hóa dữ liệu mạnh mẽ hơn Cơ chế này đảm bảo rằng tất cả các thao tác đọc và ghi trên một đối tượng cụ thể được thực hiện theo thứ tự thời gian xảy ra Khi một giá trị được ghi vào hệ thống, mọi thao tác đọc tiếp theo phải ngay lập tức thấy giá trị mới Mặc dù tính nhất quán tuyến tính không phải là mặc định trong Cassandra, nhưng nó có thể được đảm bảo trong một số trường hợp cụ thể.
∗ Sử dụng Lightweight Transactions (LWT), vốn dựa trên giao thức Paxos.
∗ Kết hợp mức độ nhất quán SERIAL(cho ghi) và SERIALhoặc LOCAL_SERIAL (cho đọc).
– Tính toán mức độ nhất quán:
∗ Cho rằng: ã Rlà mức độ nhất quỏn của cỏc hoạt động đọc ã Wlà mức độ nhất quỏn của cỏc hoạt động ghi ã Nlà số bản sao
∗ Strong Consistency (nhất quán mạnh) được đảm bảo khi điều kiện sau thỏa mãn:
∗ Eventual Consistency (tính nhất quán cuối cùng)xảy ra nếu điều kiện sau là đúng:
Cassandra hỗ trợ Giao dịch Nhẹ (LWT) thông qua các câu lệnh như IF EXISTS và IF NOT EXISTS, cho phép kiểm tra điều kiện trước khi thực hiện ghi hoặc cập nhật dữ liệu Phương pháp này đảm bảo tính nhất quán mạnh mẽ cho các giao dịch cụ thể, tuy nhiên, nó cũng đi kèm với chi phí hiệu năng cao hơn.
Cassandra supports the BATCH statement, enabling multiple write operations to be executed within a single transaction This feature ensures that all commands are executed consistently and operate within a separate partition, providing a level of isolation.
– Consistency Level: Sử dụng các Consistency Levelđể thiếp lập mức độ nhất quán cho các thao tác
Minh họa cáchCassandraquản lý sự nhất quán dữ liệu:
1 Xây dựng bảng users, với user_id là primary key, các thuộc tính bao gồm name, email, phone và last_update_timestamp.
2 Batch Statementsđảm bảo tất cả các thao tác trong batch được thực thi cùng nhau (best-effort atomicity)
Hình 7.10: Sử dụngBATCHđể đảm bảo các lệnh đều được thực thi
3 LWTCung cấp tính năngCompare-and-Set(CAS), giúp đảm bảo rằng dữ liệu chỉ được ghi nếu đáp ứng điều kiện nhất định Ở đây điều kiện được áp dụng để kiểm tra nếu dữ liệu đã tồn tại trong bảng, nếu đã có sẽ không cho phép ghi vào bảng.
Hình 7.11: Kiểm tra điều kiện của dữ liệu
4 Cassandra cho phép cấu hình Consistency Level cho mỗi thao tác để kiểm soát mức độ đồng nhất dữ liệu giữa các node trong cluster Ở đây mức độ nhất quán được chọn làALL, nghĩa là khi tương tác dữ liệu yêu cầu tất cả các node phải duyệt qua.
Hình 7.12: Mức độ đồng nhất dữ liệu
