3.1 Sự xuất hiện của AXIT
ACID viết tắt lần đầu tiên xuất hiện vào năm 1983 trong một bài báo của Theo Haerder và Andreas Reuter. Để đơn giản hóa văn bản và làm cho nó thuyết phục hơn, tôi sẽ đưa ra bản dịch một đoạn của bài viết này (với sự rút gọn nhẹ). Đoạn mã này sử dụng một ví dụ về giao dịch ngân hàng trong đó tiền được chuyển từ tài khoản này sang tài khoản khác.
Khái niệm về một giao dịch, trong ví dụ này bao gồm tất cả các tương tác với cơ sở dữ liệu giữa $BEGIN_TRANSACTIONvà $COMMIT_TRANSACTION, yêu cầu tất cả các hành động được thực hiện không thể chia cắt: hoặc tất cả các hành động được phản ánh chính xác trong trạng thái của cơ sở dữ liệu hoặc không có gì xảy ra. Nếu tại bất kỳ thời điểm nào trước khi tiếp cận, $COMMIT_TRANSACTIONngười dùng nhập một câu lệnh ERRORcó chứa $RESTORE_TRANSACTION, thì không có thay đổi nào được phản ánh trong cơ sở dữ liệu.
Để đạt được tính không thể chia cắt này, một giao dịch phải có bốn thuộc tính sau:
Tính nguyên tử (Atomicity). Giao dịch phải thuộc loại tất cả hoặc không có gì được mô tả ở trên và bất kể điều gì xảy ra, người dùng phải biết giao dịch đang ở trạng thái nào.
Tính nhất quán (Consistency). Một giao dịch đạt đến kết thúc giao dịch bình thường (EOT) và do đó cam kết kết quả của nó sẽ duy trì tính nhất quán của cơ sở dữ liệu. Nói cách khác, mọi giao dịch thành công, theo định nghĩa, chỉ cam kết kết quả hợp lệ. Điều kiện này là cần thiết để hỗ trợ tài sản thứ tư - độ bền.
Cách ly (Cô lập). Các sự kiện xảy ra trong một giao dịch phải được ẩn khỏi các giao dịch đang thực hiện đồng thời khác. Nếu điều kiện này không được đáp ứng, thì vì những lý do nêu trên, giao dịch sẽ không thể quay lại từ đầu. Để đạt được sự cô lập, các phương pháp được gọi là đồng bộ hóa được sử dụng ...
Độ bền (Độ bền). Khi một giao dịch đã hoàn thành và đưa kết quả của nó vào cơ sở dữ liệu, hệ thống phải đảm bảo rằng những kết quả đó tồn tại sau bất kỳ lỗi nào sau đó. Do không có phạm vi kiểm soát mở rộng các tập hợp giao dịch nên hệ thống quản lý cơ sở dữ liệu (DBMS) không có quyền kiểm soát ngoài ranh giới của các giao dịch.
Do đó, người dùng phải được đảm bảo rằng nếu hệ thống thông báo cho anh ta rằng có điều gì đó đã xảy ra, thì "điều gì đó" này đã thực sự xảy ra. Vì theo định nghĩa, bất kỳ giao dịch nào (đã hoàn thành thành công - S.K.) đều đúng, nên kết quả của việc chắc chắn xuất hiện các giao dịch không chính xác (tức là các giao dịch chứa dữ liệu sai) chỉ có thể được loại bỏ bằng giao dịch "đối tác" tương ứng (giao dịch đối ứng).
3.2 Sự xuất hiện của các giao dịch
Bốn thuộc tính này—Nguyên tử, Tính nhất quán, Cách ly và Độ bền (ACID)—mô tả các tính năng cốt lõi của mô hình giao dịch ảnh hưởng đến nhiều khía cạnh của thiết kế hệ thống cơ sở dữ liệu. Do đó, chúng tôi tin rằng khả năng hỗ trợ giao dịch của bất kỳ hệ thống nào là tiêu chuẩn (thử nghiệm ACID) về chất lượng của hệ thống này.
Một chương trình PL/1-SQL đơn giản giúp chuyển tiền từ tài khoản này sang tài khoản khác.
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */Tôi đã cung cấp một ví dụ về mã này để nhắc bạn rằng, trên thực tế, các thuộc tính ACID, một mặt, có thể được coi là yêu cầu đối với bất kỳ DBMS nào tuyên bố hỗ trợ giao dịch và mặt khác, là định nghĩa của giao dịch trong một hệ thống cơ sở dữ liệu . Định nghĩa này hoàn toàn phù hợp với thực tiễn thế gian. Ví dụ, thật khó để tưởng tượng rằng một khách hàng thực hiện giao dịch ngân hàng (dù với sự hỗ trợ của nhân viên giao dịch trực tiếp hay sử dụng ngân hàng qua Internet) lại không mong đợi ngân hàng đáp ứng tất cả các thuộc tính của ACID. Một ngân hàng không hỗ trợ các thuộc tính ACID cho các giao dịch của mình, tốt nhất là sẽ mất khách hàng và tệ nhất là phá sản.
3.3 Kết nối ACID
Điều rất quan trọng là các thuộc tính ACID không thể tách rời, việc loại bỏ bất kỳ thuộc tính nào trong số chúng sẽ khiến sự kết hợp còn lại trở nên vô nghĩa. Cụ thể, nếu chúng ta loại bỏ thuộc tính nhất quán (theo nghĩa nó được sử dụng trong đoạn trích dẫn trên), thì chúng ta sẽ mất tiêu chí về tính đúng đắn của giao dịch. Hệ thống cơ sở dữ liệu sẽ không thể quyết định theo bất kỳ cách có ý nghĩa nào về việc các giao dịch được phép hay không được thực hiện và tất cả các kiểm tra tính chính xác của các hoạt động được thực hiện trong trạng thái hiện tại của cơ sở dữ liệu sẽ phải được thực hiện trong mã ứng dụng.
Bạn cần hiểu rằng trong trường hợp này chúng ta đang nói về tính nhất quán logic. Khách hàng của ngân hàng cần ngân hàng làm việc theo các quy tắc do anh ta thiết lập và khách hàng biết, để không thể thực hiện bất kỳ giao dịch nào vi phạm các quy tắc này, để giao dịch tiếp theo của cùng một khách hàng được thực hiện trong một môi trường đã được thống nhất phù hợp với các quy tắc này.
Khách hàng của cửa hàng trực tuyến cần hàng hóa do anh ta đặt hàng và thanh toán để được giao cho anh ta một cách kịp thời (theo các quy tắc được thiết lập và biết cho khách hàng). Nếu không, anh ta sẽ không tin tưởng cửa hàng này. Đồng thời, cả khách hàng của ngân hàng và khách hàng của cửa hàng Internet đều không quan tâm đến bếp nội bộ của doanh nghiệp, những hành động nội bộ nào được thực hiện để hoàn thành giao dịch của mình. Khách hàng không quan tâm đến cách duy trì tính nhất quán vật lý của doanh nghiệp này, cách các hoạt động được thực hiện ở lớp vật lý.
Nếu DBMS quan tâm đến việc duy trì tính nhất quán logic của các giao dịch (và cơ sở dữ liệu), thì các ứng dụng sẽ trở nên đơn giản hơn, dễ hiểu hơn và đáng tin cậy hơn. Tất cả logic của khu vực ứng dụng (ngân hàng, cửa hàng, nhà kho, v.v.) liên quan đến các giao dịch và trạng thái hợp lệ của dữ liệu đều được đưa vào hệ thống cơ sở dữ liệu. Và các yêu cầu đối với hệ thống này rất đơn giản: hỗ trợ các giao dịch ACID, có tính đến các quy tắc nhất quán được ứng dụng cung cấp trong cơ sở dữ liệu. Theo quan điểm của tôi, việc từ chối các giao dịch ACID tạo ra những khó khăn quá lớn cho các nhà phát triển ứng dụng, những người, dù muốn hay không, sẽ phải tự thực hiện một cái gì đó tương tự để đáp ứng nhu cầu tự nhiên của khách hàng.
Và một lần nữa tôi lưu ý rằng trên thực tế, các thuộc tính ACID xác định khái niệm về một giao dịch. Theo tôi, để có ít nhất một số khả năng nói về một hệ thống quản lý dữ liệu giao dịch trong đó thuộc tính nhất quán của giao dịch không được hỗ trợ, nhất thiết phải xác định ý nghĩa của thuật ngữ giao dịch trong trường hợp này.
Thật không may, ngày nay, trong nhiều trường hợp (đặc biệt, đây là đặc điểm của hướng NoSQL), mọi người nói về việc hỗ trợ các ứng dụng OLTP mà không chỉ rõ ý nghĩa của loại giao dịch nào. Do đó, trong bài viết này, tôi sẽ sử dụng thuật ngữ giao dịch ACID kết hợp để chỉ các giao dịch thực và thuật ngữ giao dịch không đủ tiêu chuẩn sẽ được sử dụng theo nghĩa không chính thức, khác nhau trong các ngữ cảnh khác nhau.
Bây giờ chúng ta hãy giải quyết "định lý" của CAP và cố gắng tìm hiểu ý nghĩa của tính nhất quán theo nghĩa của Brewer.