Transaction trong sql có các thuộc tính thường được viết tắt là acid nghĩa là gì?

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh

Khái niệm transaction trong database là một khái niệm quan trọng mà tất cả các lập trình viên nên biết bởi vì chúng ta sẽ làm việc rất nhiều với khái niệm này. Trong bài viết này, mình xin trình bày với các bạn về khái niệm này!

Để dễ hình dung, mình xin lấy một ví dụ như sau: chúng ta đang làm việc với một ứng dụng bên ngân hàng, ứng dụng này có một tính năng đó là chuyển tiền giữa các tài khoản ngân hàng với nhau, ví dụ chuyển tiền cho tài khoản A sang tài khoản B. Đây là một tính năng mà quá trình xử lý sẽ gồm 2 bước:

Tuyển database lương cao hấp dẫn trên TopDev

Tuyển dụng IT lương cao nhiều ngành nghề

• Thứ nhất là trừ tiền trong tài khoản A
• Và bước thứ hai là cộng tiền vào tài khoản B.

Rõ ràng, như các bạn thấy, đây là một quá trình nếu gọi là thành công thì bắt buộc 2 bước trên phải thành công, hoặc nếu thất bại thì bắt buộc 2 bước trên cũng phải thất bại luôn. Nếu chỉ một trong 2 bước trên thành công hoặc thất bại thì chúng ta sẽ gặp vấn đề ngay. Và chúng ta khi xây dựng ứng dụng cũng phải đảm bảo 2 điều kiện trên.

Đây chính là ý tưởng chính của khái niệm transaction trong database. Trong database, một transaction là một tập hợp các thao tác mà ở đó hoặc là các thao tác đó được thực hiện thành công, hoặc là không một thao tác nào được thực hiện thành công cả. Khi các bạn suy nghĩ về transaction trong database, các bạn hãy hình dung nó là “hoặc là tất cả hoặc là không gì hết”.

Ở đây, chúng ta có một chữ viết tắt ACID [Atomicity, Consistency, Isolation, Durability] định nghĩa các tính chất của một transaction trong database.

Trong đó:

• Atomicity: tính chất này thể hiện khái niệm “hoặc là tất cả hoặc là không gì hết”. Toàn bộ các bước được thực hiện trong một transaction nếu thành công thì phải thành công tất cả, nếu thất bại thì tất cả cũng phải thất bại. Nếu một transaction thành công thì tất cả những thay đổi phải được lưu vào database. Nếu thất bại thì tất cả những thay đổi trong transaction đó phải được rollback về trạng thái ban đầu.

Trong ví dụ của mình, rõ ràng khi đã trừ tiền trong tài khoản A thì bắt buộc việc cộng tiền vào tài khoản B phải xảy ra. Còn không thì không có gì xảy ra hết, đã không trừ tiền trong tài khoản A thì chắc chắn rồi, việc cộng tiền vào tài khoản B cũng không xảy ra.

• Consistency: dữ liệu từ thời điểm start transaction với lúc kết thúc phải nhất quán.

Trong ví dụ của mình thì, nếu đã trừ 10$ trong tài khoản A thì trong tài khoản B phải được cộng 10$.

• Isolation: nếu chúng ta có nhiều transaction cùng một lúc thì phải đảm bảo là các transaction này xảy ra độc lập, không tác động lẫn nhau trên dữ liệu.

Trong ví dụ của mình, giả sử cùng môt lúc xảy ra 2 transaction như trên thì rõ ràng chúng ta không xác định được trạng thái của tài khoản A và tài khoản B sau khi thực hiện cùng 1 lúc. Mà điều này thì rất nguy hiểm.

• Durability: điều này có nghĩa dữ liệu sau khi thực hiện transaction sẽ không thay đổi nếu chúng ta gặp vấn đề gì đó liên quan đến database.

Ví dụ sau khi chuyển tiền vào tài khoản B thành công thì dù database có gặp bất cứ vấn đề gì thì tài khoản B vẫn đảm bảo đã nhận đủ 10$.

Bài viết gốc được đăng tải tại huongdanjava.com

Có thể bạn quan tâm:

Hôm nay tôi muốn đưa bạn tất cả trở lại cho một trong những câu hỏi phỏng vấn về  cơ rất độc đáo mà tôi thấy thường xuyên sử dụng trong các buổi phỏng vấn. Tôi đã từng viết về tính chất ACID này. Trong sự nghiệp của tôi, tôi đã thấy nó trong hàng ngàn cuộc phỏng vấn. Một trong những dịch vụ phổ biến nhất của tôi là giúp mọi người với những câu hỏi phỏng vấn và câu các trả lời. Tôi thường quan sát thấy khi phỏng vấn hết các câu hỏi để hỏi và suy nghĩ của các câu hỏi tiếp theo, họ thường hỏi câu hỏi về thuộc tính  ACID của các cơ sở dữ liệu.

Câu hỏi: ACID là gì trong cơ sở dữ liệu?

Trả lời:

ACID [viết tắt của Atomicity, Consistency, Isolation, Durability] là một khái niệm cơ sở dữ liệu mà các chuyên gia thường tìm kiếm khi đánh giá các cơ sở dữ liệu và kiến trúc ứng dụng. Đối với một cơ sở dữ liệu đáng tin cậy tất cả bốn thuộc tính cần đạt được.

Atomicity là một đề xuất tất cả hoặc không có gì. Tính chất này đảm bảo rằng khi một giao dịch liên quan đến hai hay nhiều xử lý, hoặc là tất cả các xử lý được thực hiện hoặc không có xử lý được thực hiện.
Consistency đảm bảo rằng một giao dịch không bao giờ được thông qua cơ sở dữ liệu của bạn trong tình trạng dở dang. Tính chất này, hoặc là tạo ra toàn bộ trạng thái mới hoặc rollback tất cả các xử lý để về trạng thái ban đầu, nhưng không bao giờ thông qua cơ sở dữ liệu trong trạng thái dở dang.
Isolation giữ giao dịch tách rời nhau cho đến khi chúng đã hoàn tất. Tính chất này đảm bảo rằng hai hoặc nhiều giao dịch không bao giờ được trộn lẫn với nhau, tạo ra dữ liệu không chính xác và không phù hợp.
Durability đảm bảo rằng cơ sở dữ liệu sẽ theo dõi các thay đổi cấp phát trong một cách mà các máy chủ có thể phục hồi từ một sự kết thúc bất thường. Tính chất này đảm bảo rằng trong trường hợp thất bại hay dịch vụ khởi động lại các dữ liệu có sẵn trong  trước khi gặp lỗi.

Các tính chất ACID của cơ sở dữ liệu được mô tả trong ISO / IEC 10.026-1: 1992 phần 4. Ghi số này nếu bạn muốn gây ấn tượng với người phỏng vấn với kiến thức của bạn. Bạn biết rằng anh ta sẽ hỏi câu hỏi này, tốt hơn sẵn sàng để trả lời câu hỏi này chính xác và gây ấn tượng với anh ấy / cô ấy.

Trích nguồn từ: [//blog.sqlauthority.com/2016/04/10/acid-properties-database-interview-question-week-066/]

Transaction là một tiến trình xử lý có xác định điểm đầu và điểm cuối, được chia nhỏ thành các operation [phép thực thi] , tiến trình được thực thi một cách tuần tự và độc lập các operation đó theo nguyên tắc hoặc tất cả đều thành công hoặc một operation thất bại thì toàn bộ tiến trình thất bại. Nếu việc thực thi một operation nào đó bị fail [hỏng] đồng nghĩa với việc dữ liệu phải rollback [trở lại] trạng thái ban đầu.

Các tính chất của Transaction

Một transaction đòi hỏi phải có 4 tính chất ACID. ACID là viết tắt của cụm từ Atomicity [nguyên tử], Consitency [nhất quán], Isolation [Cô lập], và Durability [Lâu bền]. Đây là các thuộc tính mà mọi transaction đều được đảm bảo bởi SQL Server.

• Atomicity: Mọi thay đổi về mặt dữ liệu phải được thục hiện trọn vẹn khi transaction thực hiện thành công hoặc không có bất kì sự thay đổi nào về mặt dữ liệu nếu có xẩy ra sự cố.
• Consistency: Sau khi một transaction kết thúc thì tất cả dữ liệu phải được nhất quán dù thành công hay thất bại.
• Isolation: Các transaction khi đông thời thực thi trên hệ thống thì không có bất kì ảnh hưởng gì tời nhau.
• Durability: Sau khi một transaction thành công thì tác dụng mà nó tạo ra phải bền vững trong cơ sở dữ liệu cho dù hệ thống có xẩy ra lỗi.

Cấu trúc transaction

Một transaction được định nghĩa dựa trên:

• BEGIN TRANSACTION: Bắt đầu một transaction
• SAVE TRANSACTION: Đánh dấu vị trí trong transaction[điểm đánh dấu]
• ROLLBACK TRANSACTION: Quay lui lại đầu transaction hoặc điểm đánh dấu trước đó trong transaction.
• COMMIT TRANSACTION: Đánh dấu điểm kết thúc của một transaction, khi câu lệnh này thực thi có nghĩa là transaction thực hiện thành công.
• ROLLBACK WORK: Quay lui lại đầu transaction.
• COMMIT WORK: Đánh dấu kết thúc transaction.

Một số vấn đề xuất hiện khi có hai transaction cùng hoạt động

Cùng một lúc, DB có thể được truy cập bởi nhiều clients. Nếu các clients cùng truy xuất vào một phần dữ liệu, thì sẽ nảy sinh các vấn đề liên quan đến tình trạng tranh chấp.Để giải quyết các vấn đề tranh chấp nêu trên, hệ quản trị cơ sở dữ liệu cần sử dụng các phương thức khóa, nhờ vậy mà khi có tranh chấp xảy ra hệ quản trị cơ sở dữ liệu có thể quyết định transaction nào được thực hiện và transaction nào phải chờ.

Trong môi trường truy xuất đồng thời, có thể xảy ra một số vấn đề như sau:

• Mất dữ liệu cập nhật [Dirty Write]

• Tình trạng này xảy ra khi có nhiều hơn một giao tác cùng thực hiện cập nhật trên 1 đơn vị dữ liệu. Khi đó, tác dụng của giao tác cập nhật thực hiện sau sẽ đè lên tác dụng của thao tác cập nhật trước.

• Đọc dữ liệu chưa commit [Uncommitted data, Dirty read]

• Xảy ra khi một giao tác thực hiện đọc trên một đơn vị dữ liệu mà đơn vị dữ liệu này đang bị cập nhật bởi một giao tác khác nhưng việc cập nhật chưa được xác nhận.

• Giao tác đọc không thể lặp lại [Unrepeatable data]

• Tình trạng này xảy ra khi một giao tác T1 vừa thực hiện xong thao tác đọc trên một đơn vị dữ liệu [nhưng chưa commit] thì giao tác khác [T2] lại thay đổi [ghi] trên đơn vị dữ liệu này. Điều này làm cho lần đọc sau đó của T1 không còn nhìn thấy dữ liệu ban đầu nữa.

• Là tình trạng mà một giao tác đang thao tác trên một tập dữ liệu nhưng giao tác khác lại chèn thêm các dòng dữ liệu vào tập dữ liệu mà giao tác kia quan tâm.

Giải pháp xử lý

• Thực hiện cơ chế Transaction và cơ chế khóa. Một transaction khi muốn cập nhật bất cứ bản ghi nào, sẽ phải giữ lock cho bản ghi đó, lock này chỉ được trả lại sau khi transaction đã commit hoăc bị rollback. Nếu lock của bản ghi đang bị giữ bởi transaction khác, transaction hiện tại sẽ phải đợi cho tới khi lock đó được trả lại.
• Trước khi transaction đọc hoặc chỉnh sửa dữ liệu, nó cần được bảo vệ và tránh ảnh hưởng của các transaction khác đang chỉnh sửa cùng dữ liệu.
• Transaction yêu cầu khóa dữ liệu đang dùng.
• Có nhiều Mode khóa khác nhau phụ thuộc vào mức độ phụ thuộc dữ liệu của transaction.
• Sẽ không có transaction nào được cấp khóa nếu gây xung đột với mode khóa đã được cấp trên cùng dữ liệu cho một transaction khác trước đó.
• Nếu transaction yêu cầu một mode khóa xung đột , DBMS sẽ bắt transaction này dừng lại cho đến khi transaction trước đó được giải phóng.
• Tất cả các khóa sẽ được giải phóng khi transaction hoàn thành.
• Hầu hết các DBMS đa người dùng đều tự động thực thi các thủ tục khóa.
• Lock Manager có nhiệm vụ gán và tạo chính sách khóa cho các transaction.
• Khi cần phải sử dụng câu lệnh SQL, query processor sẽ xác định tài nguyên nào được truy xuất, loại khóa nào cần dùng, thiết lập mức độ cô lập [Isolation level] cho transaction. Kế đến query processor yêu cầu một khóa phù hợp từ lock manager. Lock Manager sẽ cấp khóa nếu không có xung đột.

Tài liệu tham khảo //kipalog.com/posts/DB-Transaction //techmaster.vn/posts/26316/transaction-la-gi