Tại sao khóa lạc quan nhanh hơn khóa bi quan?

Cả hai hình thức khóa đều khiến một quá trình chờ đợi một bản sao chính xác của hồ sơ nếu nó đang được sử dụng bởi một quy trình khác. Với khóa bi quan, cơ chế khóa xuất phát từ chính DB (đối tượng khóa gốc), trong khi với khóa tối ưu, cơ chế khóa là một dạng phiên bản hàng giống như dấu thời gian để kiểm tra xem bản ghi có bị "cũ" hay không.

Nhưng cả hai gây ra một quá trình thứ 2 để treo. Vì vậy, tôi hỏi: tại sao khóa lạc quan thường được coi là nhanh hơn / vượt trội hơn so với khóa bi quan? Và, có những trường hợp sử dụng mà bi quan được ưa thích hơn lạc quan? Cảm ơn trước!

Câu hỏi trùng lặp từ:

/programming/129329/optimistic-vs-pessimistic-locking

Sao chép / dán câu trả lời từ liên kết trên:

Khóa lạc quan là một chiến lược mà bạn đọc bản ghi, ghi lại số phiên bản và kiểm tra xem phiên bản chưa thay đổi trước khi bạn viết lại bản ghi. Khi bạn viết lại bản ghi, bạn lọc bản cập nhật trên phiên bản để đảm bảo nó là nguyên tử. (tức là chưa được cập nhật giữa khi bạn kiểm tra phiên bản và ghi bản ghi vào đĩa) và cập nhật phiên bản trong một lần nhấn.

Nếu bản ghi bị bẩn (tức là phiên bản khác với bản ghi của bạn), bạn hủy bỏ giao dịch và người dùng có thể khởi động lại nó.

Chiến lược này được áp dụng nhiều nhất cho các hệ thống khối lượng lớn và kiến ​​trúc ba tầng mà bạn không nhất thiết phải duy trì kết nối với cơ sở dữ liệu cho phiên của mình. Trong tình huống này, máy khách thực sự không thể duy trì các khóa cơ sở dữ liệu vì các kết nối được lấy từ một nhóm và bạn không thể sử dụng cùng một kết nối từ một truy cập đến tiếp theo.

Khóa bi quan là khi bạn khóa bản ghi để sử dụng độc quyền cho đến khi bạn hoàn thành nó. Nó có tính toàn vẹn tốt hơn nhiều so với khóa lạc quan nhưng đòi hỏi bạn phải cẩn thận với thiết kế ứng dụng của mình để tránh Deadlocks. Để sử dụng khóa bi quan, bạn cần kết nối trực tiếp với cơ sở dữ liệu (thường là trong trường hợp ứng dụng máy chủ hai tầng) hoặc ID giao dịch có sẵn bên ngoài có thể được sử dụng độc lập với kết nối.

Trong trường hợp sau, bạn mở giao dịch với TxID và sau đó kết nối lại bằng ID đó. DBMS duy trì các khóa và cho phép bạn chọn phiên sao lưu thông qua TxID. Đây là cách các giao dịch phân tán sử dụng giao thức cam kết hai pha (như XA hoặc COM + Giao dịch) hoạt động.

Chỉnh sửa (Thêm thông tin để giải quyết câu hỏi về hiệu suất):

Hiệu suất khôn ngoan nó phụ thuộc vào môi trường của bạn. Lấy các yếu tố sau để quyết định:

bạn sẽ thấy lạc quan sẽ tốt hơn do đồng thời trong hầu hết các tình huống. Tuy nhiên, tùy thuộc vào RDBMS và môi trường, điều này có thể ít hoặc nhiều hiệu suất hơn. Thông thường với khóa Optimistic bạn sẽ thấy rằng giá trị cần phải được phiên bản ở đâu đó.

Ví dụ, với MS SQL Server, nó được chuyển sang TempDB và một cái gì đó trong khoảng từ 12 đến 14 byte được thêm vào cuối cột. Bật khóa tối ưu với mức cô lập như Cách ly ảnh chụp có thể gây ra sự phân mảnh và hệ số lấp đầy của bạn sẽ cần được điều chỉnh vì các hàng hiện có thêm dữ liệu ở cuối có thể khiến trang gần đầy gây ra sự phân tách trang, sẽ giảm hiệu suất của bạn. Nếu TempDB của bạn được tối ưu hóa thì điều này sẽ không nhanh như vậy.

Vì vậy, tôi đoán một danh sách kiểm tra là:

• -Bạn có đủ IO ​​/ tài nguyên để xử lý hình thức phiên bản hàng không? Nếu không, bạn đang thêm chi phí. Nếu vậy, nếu bạn đang đọc dữ liệu thường xuyên trong khi bạn thường khóa nó để ghi, bạn sẽ nhận thấy sự cải thiện tốt về đồng thời qua đọc và ghi (mặc dù ghi sẽ vẫn chặn ghi, đọc sẽ không còn chặn ghi và ngược lại)
• -Là mã của bạn dễ bị bế tắc hay bạn có bị khóa không? Nếu bạn không gặp phải các khóa dài hoặc nhiều bế tắc, thì chi phí bổ sung của khóa Lạc quan sẽ không khiến mọi thứ nhanh hơn, tất nhiên, trong hầu hết các trường hợp chúng ta đang nói chuyện một phần nghìn giây ở đây.
• -Nếu DB của bạn lớn (hoặc trên phần cứng rất hạn chế) và các trang dữ liệu của bạn đã gần đầy, tùy thuộc vào RDBMS, bạn có thể gây ra sự phân tách trang lớn và phân mảnh dữ liệu, vì vậy hãy đảm bảo xem xét việc lập lại sau khi bật.

Đó là những suy nghĩ của tôi về vấn đề này, mở để nghe nhiều hơn từ cộng đồng.

Bạn hiểu lầm khóa lạc quan.

Khóa tối ưu không khiến các giao dịch phải chờ đợi nhau.

Khóa tối ưu có thể khiến giao dịch thất bại, nhưng nó không có "khóa" nào được thực hiện. Và nếu một giao dịch thất bại vì khóa lạc quan, người dùng được yêu cầu bắt đầu lại từ đầu. Từ "lạc quan" xuất phát từ chính xác kỳ vọng rằng điều kiện khiến các giao dịch không thành công vì lý do này, sẽ chỉ xảy ra rất đặc biệt. Khóa "lạc quan" là cách tiếp cận có nội dung "Tôi sẽ không thực hiện khóa thực tế vì tôi hy vọng chúng sẽ không cần thiết nữa. Nếu hóa ra tôi đã sai về điều đó, tôi sẽ chấp nhận thất bại không thể tránh khỏi".

Khóa tối ưu thường nhanh hơn vì thực tế không có khóa từ quan điểm cơ sở dữ liệu. Hoàn toàn tùy thuộc vào việc ứng dụng có tôn trọng cột phiên bản (hoặc cột giả, như ora_rowscn) hay không. Thông thường bạn có nhiều ứng dụng được kết nối với cùng một cơ sở dữ liệu, do đó db trở thành tài nguyên được chia sẻ và nếu nó bị treo, tất cả các máy khách sẽ bị ảnh hưởng.

Với chiến lược khóa lạc quan, 'treo' xảy ra ở phía khách hàng và không ảnh hưởng đến người khác.

Tuy nhiên, nếu một bản ghi được cập nhật thường xuyên, bạn có thể sẽ đọc lại nó quá nhiều lần (trong trường hợp khóa lạc quan), do đó đánh bại hầu hết các lợi ích của chiến lược lạc quan.

Tôi không đồng ý về tính ưu việt của một trong hai cách tiếp cận; cả hai đều có thể bị lạm dụng. Pessimistic dễ bị lỗi hơn chỉ vì nó nguy hiểm hơn: khóa xảy ra ở cấp độ db, tùy thuộc vào RDMS mà bạn có thể không kiểm soát được khóa bị khóa (leo thang khóa), bạn cần cẩn thận với lệnh khóa thủ công.

Lạc khóa giả định giao dịch đồng thời có thể hoàn thành mà không ảnh hưởng lẫn nhau. Vì vậy, khóa Optimistic nhanh hơn vì không có khóa nào được thực thi trong khi thực hiện giao dịch. Đó là ngăn ngừa gây ra vấn đề tương tranh không chữa được. Giao dịch chỉ xác minh (ba cách Bộ dữ liệu, Kiểu dữ liệu dấu thời gian, Kiểm tra giá trị cũ và mới) dữ liệu mà không có giao dịch nào khác đã sửa đổi dữ liệu. Trong trường hợp sửa đổi, giao dịch được khôi phục.

Khóa Pessimistic giả định rằng các giao dịch đồng thời sẽ xung đột với nhau, do đó, nó yêu cầu khóa, nó được thực hiện bằng cách chỉ định mức ISOLATION (Đọc không cam kết, Đọc cam kết, Đọc lặp lại và Nối tiếp) của quản lý giao dịch. các khóa phục vụ để bảo vệ các tài nguyên hoặc đối tượng được chia sẻ (Bảng, Hàng dữ liệu, Khối dữ liệu, Các mục được lưu trong bộ nhớ cache, Kết nối và Toàn bộ hệ thống). Chúng tôi có nhiều loại khóa như khóa chia sẻ, khóa cập nhật, khóa nội bộ, khóa độc quyền, khóa giao dịch, khóa DML, khóa lược đồ và khóa sao lưu phục hồi.

để có thêm ý tưởng

Thật sai lầm khi nói rằng khóa bi quan là chậm hơn là lạc quan hoặc nói rằng lạc quan là nhanh hơn. Một truy vấn cổ điển để thể hiện lối suy nghĩ không phù hợp này là thực hiện tổng hợp trên các RDBMS khác nhau, như:

SELECT COUNT(*) FROM atable

Bạn sẽ thấy rằng, trong RDBMS hỗ trợ phương pháp tiếp cận lạc quan, thời gian của truy vấn này có ý nghĩa hơn nhiều so với những người có khóa bi quan thực sự

Chẳng hạn, trên PC của tôi, cùng một truy vấn mất 27 ms trên SQL Server và 109 trên PostGreQuery ...

Chi phí hoạt động thêm cần thiết trong việc đọc các phiên bản chết của các hàng MVCC và không tính các bản ghi ma trong tổng hợp làm tăng thêm chi phí mà người bi quan không có!