Các giao dịch ACID đang đến với Apache Cassandra: Đây là lý do tại sao chúng tôi rất phấn khích

An extraordinary computer science breakthrough called Accord is bringing globally available, general-purpose ACID transactions to the next Cassandra release

Hãy lấy phần hay nhất trước. Các giao dịch ACID đang đến với Apache Cassandra.

Các giao dịch có mục đích chung, có sẵn trên toàn cầu hoạt động theo cách hoạt động của Cassandra. Đây không phải là một thủ thuật nào đó với bản in đẹp hoặc việc áp dụng các kỹ thuật cũ.

Đó là nhờ một bước đột phá phi thường về khoa học máy tính có tên là Accord từ một nhóm tại Apple và Đại học Michigan. Nó sẽ giúp Cassandra thay đổi cách chúng ta nghĩ về dữ liệu bằng cách mở ra các trường hợp sử dụng mới.

Đây là ý nghĩa của điều này đối với những người không tìm hiểu sâu về dự án Cassandra và các tính năng của nó. Không có gì quan trọng hơn việc bạn có thể đưa một ứng dụng vào sản xuất nhanh như thế nào. Nhưng các nhà phát triển muốn hỗ trợ quy mô, khả năng phục hồi và hỗ trợ trung tâm đa dữ liệu huyền thoại của Cassandra để hoạt động trên những thứ như giao dịch tài chính phải mã hóa một loạt các giải pháp phức tạp vào ứng dụng của họ. Chẳng hạn, sự đánh đổi so với việc sử dụng Oracle là rất đáng kể.

Với Hiệp định? Không đánh đổi. Cassandra giờ đây sẽ hỗ trợ mọi thứ đã khiến nó trở nên tuyệt vời trong khi chuyển hỗ trợ giao dịch sang cơ sở dữ liệu, giảm đáng kể độ phức tạp của mã.

Con mắt của người quan sát

Một hệ thống cơ sở dữ liệu có các chức năng thiết yếu, chẳng hạn như lưu trữ dữ liệu đáng tin cậy và sẵn sàng cho truy vấn. Quản lý các thay đổi trong dữ liệu không phải lúc nào cũng là một chức năng của cơ sở dữ liệu. Trong trường hợp có nhiều hệ thống NoSQL, gánh nặng quản lý thay đổi được chuyển cho người dùng. Người quan sát sự thay đổi dữ liệu là người chỉ định tầm quan trọng của tính độc quyền.

Giả sử điểm là tích số liệu như đã cho. Trong trường hợp đó, người quan sát phải biết dữ liệu đã được nhận và lưu trữ lâu dài — ví dụ: dữ liệu mã cổ phiếu trong đó mọi điểm dữ liệu là duy nhất và tích lũy. Không cần độc quyền.

Trong các hoạt động nhạy cảm hơn, người quan sát thay đổi dữ liệu cần cảm thấy như họ là quy trình duy nhất sử dụng cơ sở dữ liệu. Đó là một khái niệm trong khoa học máy tính được gọi là “cô lập”; đó là chữ “tôi” trong ACID (tính nguyên tử, tính nhất quán, tính cô lập, độ bền).

Một ví dụ kinh điển là chuyển khoản ngân hàng trong đó tiền được trừ từ một tài khoản ngân hàng và sau đó được thêm vào một tài khoản khác — theo đúng thứ tự đó. Quá trình quan sát cần tính độc quyền để tránh các quá trình khác thực hiện các thay đổi có thể dẫn đến sự không nhất quán hoặc bất ngờ.

Những điều ngạc nhiên bao gồm việc vô tình cho phép chuyển khoản từ một tài khoản dưới 0 đô la.

Sự cô lập đảm bảo chỉ một quy trình có thể thực hiện thay đổi tại một thời điểm và nếu hai quy trình đang cạnh tranh cho cùng một dữ liệu, một trong số chúng sẽ phải đợi quy trình kia hoàn thành.

Ôm lấy sự lười biếng của bạn

Các nhà phát triển cần di chuyển nhanh chóng với một hệ thống mà họ có thể tin tưởng. Các giao dịch ACID đã trở thành tiêu chuẩn tin cậy vàng trong các hệ thống cơ sở dữ liệu trong gần 50 năm. Các nhà phát triển làm việc thông qua sự đánh đổi dựa trên các yêu cầu, đôi khi khiến họ phải làm việc với các hệ thống không hỗ trợ giao dịch ACID.

Với các hệ thống NoSQL, các thành kiến đánh đổi trong lịch sử có xu hướng nghiêng về quy mô và thời gian hoạt động trong khi hy sinh các giao dịch.

Đưa các giao dịch ACID đến với Cassandra là nhằm giảm thiểu sự đánh đổi. Cassandra đã có danh tiếng vững chắc về quy mô tuyến tính trong khi vẫn duy trì thời gian hoạt động trong các tình huống xấu nhất.

Cassandra là sự lựa chọn khi bạn cần một cơ sở dữ liệu chứa đựng những gì internet có thể cung cấp. Không có gì ngạc nhiên khi nhu cầu giao dịch là nguồn gốc của xung đột đánh đổi đối với các nhà phát triển.

Chúng ta có thể có được sự đồng thuận?

Trong các hệ thống phân tán, mỗi nút thành viên trong cụm lớn hơn có thể hoạt động độc lập hoặc cần phối hợp với các nút khác. Trong một giao dịch mà ở đó, “Này, tất cả chúng ta cần phải đồng ý về một điều gì đó,” các nhà khoa học máy tính gọi đây là sự đồng thuận và việc phát triển các giao thức đó là một lĩnh vực cải tiến liên tục.

Paxos là một giao thức đồng thuận lâu đời được Cassandra áp dụng vào năm 2013 cho “các giao dịch nhẹ”.

Nhẹ vì nó đảm bảo rằng một thay đổi dữ liệu phân vùng duy nhất được tách biệt trong một giao dịch, nhưng nhiều hơn một bảng hoặc phân vùng không phải là một tùy chọn. Ngoài ra, Paxos yêu cầu nhiều chuyến đi khứ hồi để đạt được sự đồng thuận, điều này tạo ra nhiều độ trễ bổ sung và bản in rõ ràng về thời điểm sử dụng các giao dịch nhẹ trong ứng dụng của bạn.

Giao thức Raft được phát triển như là thế hệ tiếp theo để thay thế Paxos và một số hệ thống như Etcd, CockroachDB và DynamoDB đã sử dụng giao thức này. Nó làm giảm các chuyến đi vòng quanh bằng cách tạo ra một nhà lãnh đạo được bầu chọn.

Nhược điểm của Cassandra trong cách tiếp cận này là các đường dẫn sẽ không bao trùm các trung tâm dữ liệu, do đó cần có nhiều đường dẫn (xem Spanner ).

Việc có một nhà lãnh đạo được bầu chọn cũng vi phạm nguyên tắc “không chia sẻ gì” của Cassandra và sẽ đặt ra các yêu cầu mới về xử lý lỗi.

Nếu một nút bị hỏng, một nhà lãnh đạo mới phải được bầu.

Các cơ sở dữ liệu khác - chẳng hạn như FaunaDB và FoundationDB - đã đi theo con đường cố gắng giải quyết vấn đề đa lãnh đạo bằng cách rút gọn thành một lãnh đạo toàn cầu duy nhất, như được mô tả trong bài báo của Calvin .

Bởi vì chúng được xây dựng cho các cơ sở dữ liệu khác với các yêu cầu khác nhau, các phương pháp được sử dụng trong những trường hợp đó không đáp ứng được tiêu chí mà Cassandra mong đợi với các chế độ lỗi.

Cassandra giả định lỗi là một phần của việc chạy một hệ thống phân tán rộng rãi. Một hoặc nhiều nút ngoại tuyến sẽ không gây ra các vấn đề về tính khả dụng hoặc suy giảm hiệu suất nhanh chóng. Chúng tôi cần một cách tiếp cận khác.

Chúng ta đã đạt được một Hiệp định chưa?

Chúng ta có thể rất cứng nhắc về những gì có thể chấp nhận được đối với dự án Cassandra. Tiêu chí của chúng tôi là giữ đúng niềm tin cốt lõi về cách các hệ thống phân tán nên chạy. Hiệu suất và tỷ lệ phải luôn được bảo toàn trong khi vận hành nhiều nút trên một hoặc nhiều trung tâm dữ liệu. Chúng tôi có thể khá khắt khe, nhưng đây là điều khiến Cassandra trở thành sự lựa chọn của rất nhiều tổ chức.

Các lần lặp lại trước đây của các giao thức đồng thuận đã giải quyết các phần khác nhau của vấn đề, nhưng mỗi lần đưa ra một sự đánh đổi sẽ vi phạm một số giá trị của Cassandra. Người ta nói bước đột phá lớn tiếp theo cách lần trước hai bài báo. Trong trường hợp này, tờ báo là Accord , và nó đã có một bước tiến lớn trong việc loại bỏ sự đánh đổi.

Accord giải quyết hai vấn đề chưa được giải quyết trong các giao thức đồng thuận trước đây: Làm thế nào chúng ta có thể có sự đồng thuận sẵn có trên toàn cầu và đạt được nó trong một chuyến đi khứ hồi? Cơ chế mới lạ đầu tiên là bộ đệm sắp xếp lại.

Giả sử phần cứng hàng hóa đang được sử dụng, sự khác biệt về đồng hồ giữa các nút là không thể tránh khỏi. Bộ đệm sắp xếp lại đo lường sự khác biệt giữa các nút cũng như độ trễ giữa chúng. Mỗi bản sao có thể sử dụng thông tin này để sắp xếp chính xác dữ liệu từ mỗi nút và tính đến sự khác biệt, đảm bảo sự đồng thuận một chiều với giao thức dấu thời gian.

Cơ chế khác là bầu cử nhanh. Các chế độ thất bại có thể tạo ra độ trễ khi bầu một nhà lãnh đạo mới trước khi tiếp tục. Các đơn vị bầu chọn đường dẫn nhanh sử dụng các tính năng có sẵn trong Cassandra với một số triển khai mới để duy trì đường dẫn nhanh không có người lãnh đạo đến số đại biểu dưới cùng mức độ thất bại mà Cassandra chấp nhận. Thông tin chi tiết có thể được đọc trong đề xuất .

Làm thế nào nó hoạt động?

Tác động lớn nhất sẽ là năng suất của nhà phát triển, vì vậy hãy xem điều đó trông như thế nào trong thực tế. Xem xét ví dụ chuyển khoản ngân hàng sau đây mà chúng tôi đã đề cập trước đó:

Đầu tiên là cú pháp mới mà bạn sẽ thấy trong Cassandra Query Language (CQL). Các giao dịch được chứa trong một tuyên bố BEGIN TRANSACTION và COMMIT TRANSACTION . Mọi thứ bên trong các điểm đánh dấu giao dịch sẽ diễn ra nguyên tử tách biệt với các quy trình khác. Chúng tôi sẽ chuyển $20 từ tài khoản của Alice cho Bob trong ví dụ này. Nó không có được bất kỳ cổ điển hơn thế!

Trong phần A, chúng ta có thể chọn dữ liệu từ một bản ghi hiện có và gán kết quả cho một bộ (nhiều mục được lưu trữ trong một biến). Tùy thuộc vào số lượng cột trong mệnh đề SELECT , bạn có thể lưu trữ một hoặc nhiều giá trị trong bộ dữ liệu. Các giá trị này sẽ được sử dụng trong phần B để kiểm tra các điều kiện trước khi thực hiện thay đổi dữ liệu.

Trong trường hợp này, chúng tôi sẽ kiểm tra xem Alice có $20 trong tài khoản của mình hay không trước khi chuyển cho Bob. Nếu đúng như vậy, thì UPDATE sẽ giảm số dư tài khoản của Alice đi 20 đô la và sau đó tăng số dư tài khoản của Bob lên 20 đô la. Nếu Alice có ít hơn 20 đô la thì những thay đổi sẽ không xảy ra.

Đằng sau hậu trường là một tập hợp các lệnh cơ sở dữ liệu được tuần tự hóa thực thi độc quyền, như được thấy từ quá trình quan sát. Trên một hoặc nhiều trung tâm dữ liệu, giao dịch chỉ yêu cầu một chuyến khứ hồi để đạt được sự đồng thuận và nếu có bất kỳ nút nào ngoại tuyến, thì hành động vẫn sẽ xảy ra nếu có ít nhất một số bản sao.

Đây chính xác là cách Cassandra thích làm việc, nhưng chúng tôi vừa nâng cấp trò chơi của mình bằng một giao dịch có sẵn trên toàn cầu.

Cái gì tiếp theo

Accord và tất cả các công việc đi kèm với nó vẫn đang được tiến hành và dự kiến sẽ được đưa vào bản phát hành Cassandra tiếp theo. Vì đây là tất cả trong nguồn mở, những người trong số các bạn không thể chờ đợi có thể sao chép một bản sao của nhánh cep-15-accord từ kho lưu trữ Cassandra và tạo bản sao của riêng bạn.

Đối với những người còn lại, khi gần đến thời điểm phát hành, chúng tôi sẽ có sẵn các bản dựng để bạn sử dụng và thử nghiệm. Nó sẽ là một yếu tố thay đổi cuộc chơi đối với Cassandra, và tôi chắc rằng bạn sẽ muốn tự mình xem nó.

Tôi rất muốn nghe từ cộng đồng về những trường hợp sử dụng mà bạn sẽ tìm thấy với một giao dịch có sẵn trên toàn cầu đang chạy ở tốc độ và khả năng phục hồi mà bạn mong đợi từ Cassandra. Cuối cùng đã đến lúc bỏ qua những khối lượng công việc cơ sở dữ liệu quan hệ cuối cùng đó chưa?

Chúng tôi cũng rất nóng lòng muốn nghe phản hồi của bạn trên tất cả các kênh của chúng tôi, bao gồm cả Apache Software Foundation Slack hoặc danh sách gửi thư của dự án . Các tính năng trong một dự án mã nguồn mở không ngừng phát triển để đáp ứng nhu cầu của người dùng. Đó là lý do tại sao bạn có vai trò quan trọng trong việc định hình Apache Cassandra cho tương lai.

Và hãy theo dõi để biết thêm thông tin và trường hợp sử dụng khi chúng tôi phát triển tính năng mới thú vị này. Bạn có thể mong đợi rằng sẽ có một số cuộc thảo luận về vấn đề này tại hội nghị thượng đỉnh kỹ thuật số Cassandra Forward diễn ra vào ngày 14 tháng 3. Bạn sẽ không muốn bỏ lỡ những cuộc thảo luận đó.

Bởi Patrick McFadin, DataStax

Patrick McFadin là đồng tác giả của cuốn sách O'Reilly 'Quản lý dữ liệu gốc trên đám mây trên Kubernetes'. Anh ấy hiện đang làm việc tại DataStax trong lĩnh vực quan hệ với nhà phát triển và là người đóng góp cho dự án Apache Cassandra. Patrick đã làm việc với tư cách là người truyền bá chính cho Apache Cassandra (anh ấy cũng là một người đi làm Cassandra mới được đúc kết!) và là cố vấn cho DataStax, nơi anh ấy đã có thời gian tuyệt vời để xây dựng một số triển khai lớn nhất trong sản xuất.