Tạo dịch vụ dữ liệu thân thiện với nhà phát triển với Apache Cassandra

Tất cả các ứng dụng phụ thuộc vào dữ liệu, tuy nhiên các nhà phát triển ứng dụng không muốn nghĩ về cơ sở dữ liệu. Việc học các nội dung bên trong và ngôn ngữ truy vấn của một cơ sở dữ liệu cụ thể sẽ bổ sung thêm tải nhận thức và yêu cầu chuyển đổi ngữ cảnh làm giảm năng suất. Tuy nhiên, các ứng dụng thành công phải đáp ứng nhanh, linh hoạt và có thể mở rộng — tất cả các đặc điểm sẽ được quyết định bởi việc lựa chọn cơ sở dữ liệu.

Vậy thì, nhà phát triển ứng dụng nên cân bằng những cân nhắc này như thế nào?

Điều gì sẽ xảy ra nếu chúng ta có thể thay đổi cán cân, cung cấp dịch vụ dữ liệu theo các thành ngữ thân thiện với nhà phát triển, thay vì mong đợi các nhà phát triển học các thành ngữ dành riêng cho cơ sở dữ liệu?

Tại dự án Stargate, cổng dữ liệu API nguồn mở được thiết kế để hoạt động với Apache Cassandra , chúng tôi rất vui mừng được bắt đầu nói chuyện công khai về API JSON sắp tới của chúng tôi để đáp ứng các nhà phát triển định hướng JSON theo các điều khoản của họ. Đây không chỉ là tin tuyệt vời cho các nhà phát triển định hướng JSON, mà kỹ thuật mà chúng tôi đã theo dõi tạo thành một mẫu thiết kế mới để tận dụng API dữ liệu và lập mô hình dữ liệu nâng cao để tạo ra các dịch vụ dữ liệu.

Trong bài viết này, tôi sẽ thảo luận cách cung cấp các thành ngữ thân thiện với nhà phát triển bằng cách sử dụng Cassandra cùng với Stargate và cách chúng tôi đang làm việc để làm điều đó cho JSON .

Mô hình dữ liệu: Khả năng tương tác so với thành ngữ

Trong những ngày đầu, Cassandra đôi khi được mô tả là “một cỗ máy lập chỉ mục”. Đây là minh chứng cho khả năng phục hồi và tính linh hoạt vốn có của Cassandra, một loại đất sét có thể tạo nên những cấu trúc vững chắc hơn. Cassandra ngày nay là một loại đất sét phong phú hơn với nhiều khả năng hơn.

Nó không chỉ là một cơ sở dữ liệu tuyệt vời mà còn là một cỗ máy tuyệt vời để tạo cơ sở dữ liệu. Tại dự án Stargate, chúng tôi đang sử dụng API JSON để chứng minh đây là ví dụ đầu tiên về mô hình mới trong phát triển cơ sở dữ liệu.

Không có gì lạ khi một cơ sở dữ liệu được xây dựng từ cơ sở dữ liệu khác. Ngay cả MongoDB cũng được xây dựng trên WiredTiger , nếu bạn tìm hiểu đủ sâu. AWS nổi tiếng với việc sử dụng rộng rãi MySQL ở hậu trường, bao gồm cả việc sử dụng công cụ lưu trữ MySQL cho DynamoDB . Vì vậy, ý tưởng sử dụng Cassandra, với khả năng mở rộng và hiệu suất vốn có của nó, làm khối xây dựng cho các hệ thống dữ liệu khác có ý nghĩa.

Tuy nhiên, các nhà phát triển ứng dụng không thực sự tương tác với cơ sở dữ liệu. Ngay cả khi tổ chức của bạn quản lý cơ sở hạ tầng cơ sở dữ liệu của riêng mình và xây dựng các ứng dụng dựa trên cơ sở hạ tầng đó, bước đầu tiên thường là xác định và triển khai các mô hình dữ liệu mà ứng dụng của bạn yêu cầu.

Những mô hình dữ liệu đó làm trung gian giữa ứng dụng và cơ sở dữ liệu. Theo một nghĩa nào đó, mô hình hóa dữ liệu giới hạn một cơ sở dữ liệu; nó sử dụng đất sét không định hình, và do đó, có mục đích chung, và nhào nặn nó thành một thứ gì đó được xây dựng có mục đích cho một thành ngữ ứng dụng cụ thể. Chúng tôi hy sinh khả năng tương tác cho một cái gì đó thành ngữ.

Có phải là một ý tưởng tốt để đánh đổi một thứ gì đó thành ngữ và từ bỏ một thứ gì đó có thể tương tác được không? Nếu bạn muốn vượt qua mức trung bình, thì câu trả lời là “có”. Chúng tôi không nghĩ theo cách này nhiều khi chọn cơ sở dữ liệu, nhưng chúng tôi đã nghĩ theo cách này từ lâu khi chọn ngôn ngữ lập trình.

Ý tưởng này đã được Paul Graham thể hiện rất rõ từ nhiều thập kỷ trước khi ông giải thích cách Viaweb giành chiến thắng trong cuộc đua dot-com thời kỳ đầu để tạo ra nền tảng thương mại điện tử dựa trên web thành công rộng rãi đầu tiên.

Viaweb không nhất thiết phải là nền tảng thương mại điện tử nhanh nhất hoặc có khả năng mở rộng nhất. Theo cách nói của Graham, đó là “hiệu quả hợp lý”. Thay vào đó, Graham lập luận rằng, đối với các ngôn ngữ lập trình, trên quy mô từ máy đọc được đến con người có thể đọc được, ngôn ngữ càng dễ đọc (và do đó ở cấp độ cao hơn) càng mạnh mẽ hơn vì chúng cải thiện năng suất của nhà phát triển. Và vào thời của Viaweb, Graham nghĩ rằng ngôn ngữ mạnh mẽ nhất là Lisp . Điểm mấu chốt trong lập luận của Graham là:

“Giả thuyết của chúng tôi là nếu chúng tôi viết phần mềm của mình bằng Lisp, chúng tôi sẽ có thể hoàn thành các tính năng nhanh hơn đối thủ cạnh tranh và cũng có thể làm những việc trong phần mềm của chúng tôi mà họ không thể làm được. Và vì Lisp ở mức cao nên chúng tôi sẽ không cần một nhóm phát triển lớn, vì vậy chi phí của chúng tôi sẽ thấp hơn. Nếu đúng như vậy, chúng tôi có thể cung cấp một sản phẩm tốt hơn với số tiền ít hơn mà vẫn tạo ra lợi nhuận. Cuối cùng thì chúng tôi sẽ có được tất cả người dùng, còn các đối thủ cạnh tranh của chúng tôi sẽ không có gì và cuối cùng sẽ phá sản.”

Mở khóa năng suất của nhà phát triển

Graham đã viết những lời đó cách đây 20 năm và năng suất của nhà phát triển vẫn là Ngôi sao phương Bắc định hướng phần lớn sự đổi mới trong công nghệ. Khi Graham nói về sức mạnh của các ngôn ngữ cấp cao hơn, chúng tôi thể hiện khái niệm tương tự như việc cung cấp cho các nhà phát triển các công cụ phù hợp hơn với trải nghiệm phát triển phần mềm của họ.

Graham ca ngợi Lisp (đúng), và kể từ thời dot-com, chúng ta đã chứng kiến sự gia tăng của các ngôn ngữ cấp cao mới: Ruby và Rust, đó là một vài ví dụ. Chúng ta cũng đã chứng kiến sự ra đời và phổ biến của các ngôn ngữ và khuôn khổ dành cho nhà phát triển thiết bị di động, chẳng hạn như Swift, Flutter và Dart.

Vậy tại sao các ngôn ngữ như C và C++ vẫn quan trọng? Trò đùa cũ về C nắm giữ một sự thật quan trọng: “Kết hợp sức mạnh của ngôn ngữ lắp ráp với tính dễ sử dụng của ngôn ngữ lắp ráp.” Nếu bạn muốn viết một trình biên dịch, thì bạn cần tiến gần hơn đến thành ngữ ngôn ngữ máy và tránh xa thành ngữ ngôn ngữ tự nhiên.

Nói cách khác, trong số những ưu điểm khác, C và C++ là những cỗ máy để xây dựng ngôn ngữ mới. Điều dễ dàng bỏ qua trong lời khen ngợi Lisp của Graham là Lisp cũng có một số đặc điểm của “máy xây dựng ngôn ngữ” này.

Lisp là ngôn ngữ được sử dụng rộng rãi đầu tiên để giới thiệu khái niệm về macro, và khái niệm về macro thường gây khó khăn cho những người mới sử dụng Lisp. Khi bạn hiểu về macro, bạn sẽ hiểu rằng Lisp giống một siêu ngôn ngữ hơn là một ngôn ngữ và macro đó có thể được sử dụng để xây dựng một ngôn ngữ có mục đích cho một miền vấn đề cụ thể.

Thiết kế và tạo một bộ macro ban đầu là một công việc khó khăn và đầy thách thức về mặt trí tuệ. Nhưng một khi Graham và nhóm Viaweb đã làm điều đó, thì thực tế là họ đã có một ngôn ngữ lập trình thương mại điện tử để làm việc và điều đó đã giải phóng năng suất của nhà phát triển giúp họ vượt qua đối thủ cạnh tranh.

Hai mươi năm sau, tất cả những điều này dường như đủ rõ ràng trong bối cảnh ngôn ngữ lập trình. Vì vậy, những gì đã xảy ra trong thế giới cơ sở dữ liệu? Câu trả lời ngắn gọn là cơ sở dữ liệu đã phát triển chậm hơn.

Cuộc cách mạng API dữ liệu

Nếu dữ liệu dạng bảng là ngôn ngữ lắp ráp của thế giới cơ sở dữ liệu, thì SQL là ngôn ngữ truy vấn C/C++. Chúng tôi đã phát triển cấu trúc dữ liệu dạng bảng và khái niệm chuẩn hóa dữ liệu trong thời đại mà tính toán và lưu trữ đắt đỏ cũng như dành cho các trường hợp sử dụng được xác định rõ ràng với các thay đổi giản đồ tương đối hiếm. Trong bối cảnh đó, để hoạt động hiệu quả ở bất kỳ quy mô nào, cơ sở dữ liệu cần mô phỏng chặt chẽ cách máy tính lưu trữ và truy cập thông tin.

Thế giới ngày nay thì ngược lại, khiến thời gian trước đó có vẻ cổ xưa khi so sánh: Chi phí điện toán và lưu trữ được hàng hóa hóa cao, nhưng trong thế giới dữ liệu thời gian thực kết hợp với học máy và trí tuệ nhân tạo, các trường hợp sử dụng là kết thúc mở và các thay đổi lược đồ là thường xuyên.

Cuộc cách mạng gần đây nhất trong công nghệ cơ sở dữ liệu là cuộc cách mạng NoSQL, một phản ứng trực tiếp đối với tiêu chuẩn dữ liệu dạng bảng, được chuẩn hóa do các bậc thầy cao cấp của thế giới cơ sở dữ liệu quan hệ đặt ra. Khi nói đến “cuộc cách mạng NoSQL”, chúng ta đề cập đến giai đoạn từ năm 2004, khi Google phát hành sách trắng MapReduce , cho đến năm 2007, khi Amazon xuất bản sách trắng Dynamo .

Điều nổi lên từ thời kỳ này là một họ cơ sở dữ liệu đã đạt được tốc độ, khả năng mở rộng và khả năng phục hồi chưa từng có bằng cách loại bỏ hai nguyên lý quan hệ ấp ủ: Cơ sở dữ liệu NoQuery ưu tiên dữ liệu không chuẩn hóa hơn chuẩn hóa dữ liệu và ưu tiên tính nhất quán cuối cùng hơn tính nhất quán trong giao dịch. Cassandra, được phát hành lần đầu tiên vào năm 2008, nổi lên từ cuộc cách mạng này.

API dữ liệu sẽ là cuộc cách mạng lớn tiếp theo trong công nghệ cơ sở dữ liệu, một cuộc cách mạng mới chỉ bắt đầu. Những thay đổi trong thế giới cơ sở dữ liệu có xu hướng tụt hậu so với những thay đổi trong ngôn ngữ lập trình và phát triển ứng dụng. Vì vậy, mặc dù các API RESTful đã xuất hiện được một thời gian và đã giúp mở ra kiến trúc cho các ứng dụng hướng dịch vụ phân tán, nhưng chúng ta chỉ mới bắt đầu thấy các API dữ liệu hiển thị như một phần quan trọng của cơ sở hạ tầng ứng dụng.

Để hiểu tầm quan trọng của cuộc cách mạng này và làm thế nào, 20 năm sau tuyên bố của Paul Graham, thế giới cơ sở dữ liệu cuối cùng đã mang lại năng suất cho nhà phát triển, chúng ta hãy xem câu chuyện của chính Stargate. Nó bắt đầu bằng cách quay lại chủ đề có thể tương tác so với thành ngữ.

Stargate: Trải nghiệm dành cho nhà phát triển thành ngữ, có độ trung thực cao

Khi chúng tôi quyết định rằng hệ sinh thái Cassandra cần một cổng dữ liệu, chúng tôi đã xây dựng bộ API Stargate ban đầu với tinh thần cấp bách. Điều đó có nghĩa là một kiến trúc nguyên khối; đá nguyên khối được xây dựng nhanh hơn, nhưng không phải lúc nào cũng tốt hơn. Chúng tôi đã ra mắt với API Ngôn ngữ truy vấn Cassandra (CQL), API REST và API Tài liệu RESTful. Chúng tôi đã nhanh chóng thêm GraphQL làm API bổ sung. Cho đến nay, Stargate đã có thể tương tác được; mọi thứ từ Stargate được lưu trữ bằng mô hình dữ liệu CQL riêng, vì vậy về nguyên tắc, bạn có thể truy vấn bất kỳ bảng nào từ bất kỳ API nào.

Chúng tôi đã học được rằng trong thực tế, không ai thực sự làm điều này. Các nhà phát triển dính vào thành ngữ cụ thể của họ. Bằng cách ưu tiên khả năng tương tác, chúng tôi đã đưa Cassandra-isms vào trải nghiệm của nhà phát triển, do đó cản trở năng suất của nhà phát triển. Bởi vì phiên bản gốc của Stargate yêu cầu các nhà phát triển hiểu cấu trúc dữ liệu dạng bảng rộng của Cassandra, để hiểu các không gian phím và phân vùng, chúng tôi đã neo quá gần với thành ngữ máy và quá xa thành ngữ con người.

Cái bẫy về khả năng tương tác là ưu tiên mục đích chung hơn là tư duy thiết kế tích hợp theo mục đích. Chúng tôi đã chuyển sang suy nghĩ về mặt xây dựng có mục đích, thứ đánh đổi một số khả năng chung để lấy một phương thức biểu đạt cụ thể hơn, đưa chúng ta đến gần hơn với thành ngữ của con người và xa hơn thành ngữ máy móc. Và vì vậy chúng tôi bắt đầu suy nghĩ: Liệu chúng tôi có thể cung cấp trải nghiệm phát triển thành ngữ có độ trung thực cao trong khi vẫn giữ được những ưu điểm của nền tảng NoSQL của Cassandra (quy mô, tính khả dụng và hiệu suất) không?

Chìa khóa nằm ở mô hình hóa dữ liệu. Để biến Cassandra thành “Lisp của cơ sở dữ liệu”, chúng tôi cần một mô hình dữ liệu có thể phục vụ mục đích tương tự như macro Lisp, cùng với API Stargate cho phép các nhà phát triển tương tác một cách tự nhiên với mô hình dữ liệu đó. Chúng tôi bắt đầu với JSON, mẫu số chung lớn nhất của cấu trúc dữ liệu giữa các nhà phát triển ứng dụng và do đó bắt đầu xây dựng API JSON cho Stargate. Sau đó, chúng tôi phải tìm ra cách tốt nhất để lập mô hình JSON trong Cassandra.

Stargate đã có API Tài liệu, nhưng trong API Tài liệu ban đầu của Stargate, chúng tôi đã sử dụng mô hình dữ liệu mà chúng tôi gọi là "băm nhỏ " để hiển thị tài liệu JSON dưới dạng bảng Cassandra. Mô hình này ánh xạ một tài liệu tới nhiều hàng trong một bảng Cassandra duy nhất và duy trì khả năng tương tác. Nếu bạn sử dụng CQL để truy vấn bảng kết quả, bạn sẽ nhận được kết quả có ý nghĩa.

Mô hình dữ liệu băm nhỏ ban đầu này có nhược điểm. Nó không bảo toàn siêu dữ liệu về một tài liệu. Ví dụ: đối với bất kỳ tài liệu nào có chứa mảng, một khi tài liệu được viết, chúng ta sẽ không biết gì về kích thước mảng nếu không kiểm tra toàn bộ tài liệu. Quan trọng hơn, chúng tôi đã khác với kỳ vọng của Cassandra về việc lập chỉ mục. Cassandra lập chỉ mục trên các hàng, nhưng hiện tại chúng tôi đã trải rộng tài liệu của mình trên nhiều hàng, khiến cho việc lập chỉ mục tài liệu của Cassandra không thể thực hiện được.

Để biến Cassandra thành một công cụ lưu trữ phù hợp cho JSON, chúng tôi sẽ cần một mô hình dữ liệu mới, một thứ vượt trội hơn so với việc băm nhỏ. Chúng tôi gọi nó là "siêu vụn". Bạn có thể tìm hiểu thêm về siêu băm nhỏ tại buổi nói chuyện về Hội nghị thượng đỉnh Cassandra của Aaron Morton vào tháng 12, nhưng đây là một đoạn giới thiệu nhỏ: Chúng tôi tận dụng bản chất cột rộng của Cassandra để lưu trữ một tài liệu trên mỗi hàng, biết rằng một hàng Cassandra có thể xử lý thậm chí rất lớn các tài liệu.

Chúng tôi cũng có một tập hợp các cột trong hàng đó rõ ràng để lưu trữ các đặc điểm siêu dữ liệu tiêu chuẩn của tài liệu JSON. Bây giờ chúng tôi có thứ gì đó dễ lập chỉ mục hơn, cũng như phương tiện bảo quản và truy xuất siêu dữ liệu.

Đóng góp lại cho Cassandra

Có, để tất cả những thứ này hoạt động trên quy mô lớn, chúng tôi sẽ cần một số thay đổi cơ bản đối với Cassandra. Accord, mà Apple đang đóng góp cho Cassandra 5, sẽ giúp chúng tôi xử lý các thay đổi dữ liệu theo cách giao dịch nhiều hơn. Lập chỉ mục được gắn vào bộ lưu trữ (SAI) và Sắp xếp toàn cầu, mà DataStax đang đóng góp cho Cassandra 5 , sẽ giúp chúng tôi xử lý các truy vấn có phạm vi đối với các tài liệu JSON theo cách hiệu quả hơn.

Cassandra không phải là một phần mềm tĩnh; đó là một dự án nguồn mở sôi động và đang phát triển. Vì vậy, chúng tôi cũng đang tiếp tục truyền thống lâu đời của Cassandra về việc sử dụng các yêu cầu xuất hiện ở phía máy khách để thúc đẩy các thay đổi ở phía cơ sở dữ liệu. Nhu cầu của người dùng đã thúc đẩy các đề xuất cho Accord, SAI và Global Sort. Những điều này sẽ không chỉ làm cho API JSON của Stargate tốt hơn mà còn làm cho Cassandra tốt hơn. Đây là một lời nhắc nhở tuyệt vời rằng các kỹ sư dữ liệu và nhà phát triển ứng dụng không phải là hai cộng đồng khác nhau, mà là các nhóm bổ sung của cộng đồng Cassandra mở rộng.

Và JSON chỉ là bước đầu tiên. Về cơ bản, chúng tôi sẽ xây dựng cơ sở dữ liệu tài liệu mà bạn tương tác thông qua API JSON từ Cassandra, Stargate và mô hình dữ liệu Cassandra hiệu quả hợp lý. Siêu băm nhỏ là macro của chúng tôi. Cách tiếp cận này biến Cassandra thành một cỗ máy để tạo cơ sở dữ liệu.

Cơ sở dữ liệu khác ngoài Cassandra có thể áp dụng cách tiếp cận này không? Không dễ dàng, và đây là lý do tại sao. Có một loại cơ sở dữ liệu tương tự định luật thứ hai của nhiệt động lực học hoạt động có lợi cho Cassandra. Chúng tôi bắt đầu với thứ gì đó nhanh, có thể mở rộng và linh hoạt, nhưng không phải là thành ngữ cho các nhà phát triển. Trong giới hạn của hiệu quả hợp lý, chúng tôi đánh đổi một số tốc độ, quy mô và khả năng phục hồi đó để lấy một giao diện đặc trưng hơn để trình bày cho các nhà phát triển. Điều mà một người không thể dễ dàng làm là đi theo hướng ngược lại. Bắt đầu với thứ gì đó mang tính thành ngữ cao và sau đó cố gắng tìm ra cách làm cho nó nhanh, có thể mở rộng và linh hoạt là một nhiệm vụ khó khăn thậm chí có thể không thực hiện được.

Nguyên lý nhiệt động lực học đó là lý do tại sao API dữ liệu là cuộc cách mạng cơ sở dữ liệu mới và tại sao Cassandra là cơ sở dữ liệu sẽ thúc đẩy cuộc cách mạng này.

Cũng được xuất bản ở đây.