Cơ sở dữ liệu gốc Kubernetes: TiDB Vs. DataStax Astra DB

A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB.

Cuộc cách mạng điện toán đám mây đã truyền cảm hứng và hưởng lợi từ nhiều xu hướng có liên quan với nhau. Tính khả dụng của cơ sở hạ tầng đám mây công cộng, tự phục vụ đã giúp thúc đẩy việc áp dụng kiến trúc vi dịch vụ và thực tiễn DevOps, bao gồm tự động hóa và khả năng quan sát.

Động lực hướng tới container hóa và điều phối container đã dẫn đến việc áp dụng rộng rãi Kubernetes như một môi trường để quản lý các ứng dụng gốc trên đám mây.

Nhưng một trong những lĩnh vực tụt hậu trong cuộc cách mạng này là cơ sở hạ tầng dữ liệu và dữ liệu. Đã từ lâu, dữ liệu là thứ tồn tại bên ngoài Kubernetes, dẫn đến việc các nhà phát triển phải nỗ lực và phức tạp hơn rất nhiều trong việc triển khai các ứng dụng gốc trên đám mây.

Một tiên đề thường được lặp đi lặp lại trong những năm đầu của Kubernetes là nó chưa sẵn sàng cho khối lượng công việc có trạng thái. Rất may, một sự thay đổi lớn đã được tiến hành một cách lặng lẽ và đã đạt đến điểm trưởng thành.

Quá trình chuyển đổi ban đầu diễn ra chậm chạp, bắt đầu bằng nỗ lực chứa các cơ sở dữ liệu hiện có. Điều này hoạt động tương đối tốt trong các cơ sở dữ liệu nhỏ chạy trên một nút điện toán hoặc cơ sở dữ liệu đã được thiết kế trong thế giới dựa trên đám mây, như Apache Cassandra và DynamoDB, nhưng vẫn còn những thách thức.

Trong hai đến ba năm qua, một thế hệ cơ sở dữ liệu mới đã xuất hiện. Các cơ sở dữ liệu “Kubernetes gốc” này đã được thiết kế từ đầu để chạy trên hệ thống điều phối nguồn mở này.

Tại đây, chúng ta sẽ xác định các phẩm chất tạo nên cơ sở dữ liệu gốc Kubernetes và lợi ích của việc áp dụng cơ sở dữ liệu gốc Kubernetes. Để làm điều đó, chúng ta sẽ xem xét hai cơ sở dữ liệu có nhãn gốc Kubernetes: TiDB và DataStax Astra DB.

Kubernetes MySQL gốc với TiDB

Đầu tiên, hãy kiểm tra một cơ sở dữ liệu với sự nhấn mạnh về quan hệ: TiDB (viết tắt của Cơ sở dữ liệu Titanium). TiDB là một hệ thống nguồn mở do PingCAP xây dựng, cung cấp cơ sở dữ liệu tương thích với MySQL và cơ sở dữ liệu dạng cột để hỗ trợ xử lý phân tích và giao dịch kết hợp (gọi tắt là HTAP).

Như thể hiện trong Hình 1 bên dưới, TiDB có thiết kế microservice. Lớp truy vấn TiDB, cơ sở dữ liệu TiKV MySQL, cơ sở dữ liệu cột TiFlash, nút Spark và quản lý siêu dữ liệu đều được triển khai dưới dạng các dịch vụ siêu nhỏ có thể mở rộng trong các cụm của chúng. Thiết kế này tách biệt công việc sử dụng nhiều điện toán với công việc sử dụng nhiều dung lượng lưu trữ, vì các lớp truy vấn và cơ sở dữ liệu có thể mở rộng độc lập.

Một cam kết quan trọng mà những người tạo TiDB đã thực hiện là cơ sở dữ liệu chỉ chạy trên Kubernetes.

Điều đó có đủ để biến Kubernetes thành bản địa không?

Hãy tìm hiểu sâu hơn một chút.

Đầu tiên, TiDB được triển khai và quản lý bởi nhà điều hành Kubernetes bằng cách sử dụng các tài nguyên tùy chỉnh (CRD). TiDB CRD bao gồm TiDBCluster, cho phép bạn chỉ định quy mô và cấu hình của từng vi dịch vụ cũng như cách các thành phần lớp cơ sở dữ liệu sử dụng lưu trữ thông qua Kubernetes Persistent Volumes. CRD bổ sung được sử dụng để triển khai các công cụ giám sát và quản lý các tác vụ vận hành như sao lưu và khôi phục.

TiDB cũng có một tiện ích mở rộng bộ lập lịch tùy chọn có giao diện với bộ lập lịch mặc định của K8 để đưa ra nhiều quyết định lập lịch dựa trên ứng dụng hơn. Sự nhấn mạnh này vào việc sử dụng các khả năng Kubernetes hiện có nếu có là dấu hiệu của cơ sở dữ liệu gốc Kubernetes.

Kubernetes Native Cassandra với DataStax Astra DB

Bây giờ, hãy xem một cơ sở dữ liệu gốc Kubernetes khác và lưu ý một số điểm tương đồng và khác biệt.

Cassandra là một cơ sở dữ liệu NoSQL có khả năng mở rộng cao , là một trong những cơ sở dữ liệu đầu tiên tuyên bố là có nguồn gốc từ đám mây, nhưng việc triển khai Cassandra trong Kubernetes trông như thế nào?

DataStax Astra DB là một phiên bản của Cassandra đã được đưa vào các vi dịch vụ, như thể hiện trong Hình 2.

Giống như TiDB, cơ sở dữ liệu bao gồm các vi dịch vụ liên quan đến xử lý truy vấn và lưu trữ dữ liệu, cũng như các dịch vụ để nhận dạng và kiểm soát truy cập, sửa chữa dữ liệu và sao lưu/khôi phục.

Các dịch vụ dữ liệu đặc biệt thú vị trong việc sử dụng lưu trữ của chúng, với Kubernetes Persistent Volumes chỉ được sử dụng cho bộ nhớ đệm và lưu trữ đối tượng được sử dụng để duy trì lâu dài hơn. Việc tách tính năng nén thành dịch vụ của nó cho phép quá trình xử lý điện toán chuyên sâu này diễn ra trong nền mà không ảnh hưởng đến hiệu suất của các dịch vụ dữ liệu phục vụ lưu lượng đọc và ghi.

Astra DB được cung cấp dưới dạng dịch vụ được quản lý có sẵn ở nhiều vùng đám mây. Mỗi khu vực chứa một mặt phẳng dữ liệu bao gồm các dịch vụ được đề cập ở trên, được quản lý bởi nhà điều hành Kubernetes, cũng như các dịch vụ cơ sở hạ tầng, bao gồm ngăn xếp Kube-Promethus để có thể quan sát và v.v. để quản lý siêu dữ liệu.

Các mặt phẳng dữ liệu được quản lý bởi một mặt phẳng điều khiển có thể chạy trong một hoặc nhiều đám mây để quản lý tài khoản và cơ sở dữ liệu của khách hàng, đồng thời cung cấp các cụm Kubernetes ở các khu vực mới.

Một khía cạnh mới lạ của Astra DB là kiến trúc nhiều bên thuê, trong đó nhiều cơ sở dữ liệu người dùng có thể chia sẻ cùng một vi dịch vụ và cơ sở hạ tầng hỗ trợ, giảm tính kinh tế đơn vị cho người dùng quy mô nhỏ hơn.

Khi người dùng phát triển ứng dụng của mình, họ có thể chuyển sang các tài nguyên chuyên dụng để đạt được hiệu suất tối ưu trên quy mô lớn, tất cả đều dựa trên cơ sở “ trả theo mức sử dụng ”.

Nguyên tắc cơ sở dữ liệu gốc Kubernetes

Dựa trên những quan sát của chúng tôi về TiDB và Astra DB, chúng tôi có thể rút ra một số ý tưởng về những gì tạo nên cơ sở dữ liệu Kubernetes gốc. Nhiều trong số này tương ứng với danh sách các nguyên tắc dành cho dữ liệu gốc trên đám mây mà tôi đã mô tả trong bài viết trước :

• Kiến trúc vi dịch vụ có thể kết hợp: Đầu tiên, cơ sở dữ liệu được chia thành các vi dịch vụ cấu thành cho phép mỗi dịch vụ được mở rộng một cách độc lập. Một số loại xử lý chuyên sâu về điện toán thậm chí có thể được thu nhỏ về 0 đối với một giải pháp không có máy chủ thực sự, đặc biệt là khi được kết hợp với thiết kế nhiều bên thuê.
• Xử lý điện toán, mạng và lưu trữ dưới dạng hàng hóa: Các vi dịch vụ bao gồm cơ sở dữ liệu gốc Kubernetes sẽ tận dụng tối đa các API Kubernetes để quản lý các tài nguyên cơ bản của các ứng dụng gốc trên đám mây: các tài nguyên điện toán như StatefulSets và triển khai để quản lý khối lượng công việc, hệ thống con Khối lượng liên tục để lưu trữ , lối vào Kubernetes và các dịch vụ để hiển thị quyền truy cập mạng vào dữ liệu, v.v. Điều này bao gồm tận dụng các khả năng đã có trong Kubernetes, chẳng hạn như etcd để quản lý siêu dữ liệu, thay vì mang theo các thành phần có chức năng trùng lặp.
• Tận dụng các phương pháp hay nhất của Kubernetes: Việc tuân theo các mẫu phổ biến cho ứng dụng Kubernetes sẽ mang lại nhiều lợi ích hoạt động, ví dụ: hiển thị kiểm tra mức độ sẵn sàng và hoạt động trên từng dịch vụ siêu nhỏ để hỗ trợ tính khả dụng và hiển thị số liệu thông qua API Prometheus PromQL để có thể quan sát được . Theo mặc định, Kubernetes tự đặt ra một ví dụ tuyệt vời mà cơ sở dữ liệu nên tuân theo về cách bảo mật: sử dụng Kubernetes Secrets để phân phối thông tin đăng nhập bảo mật, chỉ hiển thị các cổng khi cần, v.v.
• Quản lý khai báo thông qua toán tử: Cơ sở dữ liệu gốc Kubernetes phải thể hiện các nguyên tắc quản lý khai báo Kubernetes thông qua toán tử và tài nguyên tùy chỉnh, thay vì dựa vào UI và CLI quản lý cơ sở dữ liệu cũ. Khi cần thiết, các điểm mở rộng Kubernetes, chẳng hạn như tiện ích mở rộng bộ lập lịch, có thể được sử dụng để thêm hành vi dành riêng cho ứng dụng . Mục tiêu là tách biệt rõ ràng chức năng mặt phẳng dữ liệu (quản lý dữ liệu) khỏi chức năng mặt phẳng điều khiển (quản lý cơ sở dữ liệu).

Cơ sở dữ liệu và cơ sở hạ tầng dữ liệu khác áp dụng trung thực các nguyên tắc này sẽ mang lại lợi ích, bao gồm hiệu suất cao với chi phí tối ưu ở mọi quy mô , độ phức tạp vận hành thấp hơn dẫn đến thời gian đưa ra thị trường nhanh hơn và các giải pháp tuân thủ tiêu chuẩn đáp ứng nhu cầu bảo mật và tính khả dụng cao hiện nay.

Tương lai của cơ sở hạ tầng dữ liệu bản địa Kubernetes

Nhiều tiến bộ vẫn đang được thực hiện và nó không chỉ giới hạn ở cơ sở dữ liệu. Các nguyên tắc gốc của Kubernetes có thể được áp dụng cho các loại cơ sở hạ tầng dữ liệu khác, bao gồm phát trực tuyến, phân tích và học máy.

Các giải pháp gốc của Kubernetes sẽ tiếp tục đạt được những bước tiến trong triển khai đa cụm và đa đám mây để mở rộng quy mô toàn cầu và sẽ áp dụng các nguyên tắc đa nhiệm và không có máy chủ để tối ưu hóa chi phí tốt hơn.

Bản thân Kubernetes có chỗ để cải thiện trong việc bổ sung tính linh hoạt hơn cho StatefulSets và hỗ trợ cho liên kết đa cụm.

Chìa khóa để tiếp tục tiến bộ là cộng tác cởi mở. Cộng đồng Dữ liệu trên Kubernetes là một nhóm chuyên viên dữ liệu rất tích cực tập hợp những người xây dựng ứng dụng sử dụng nhiều dữ liệu và cơ sở hạ tầng hỗ trợ chúng.

Tham gia với chúng tôi để nói về các ý tưởng như phát triển các toán tử có thể sử dụng lại để có thể quản lý nhiều cơ sở dữ liệu hoặc xác định một bộ CRD chung cho các khái niệm như sao lưu/khôi phục và tải dữ liệu. Chúng ta sẽ cùng nhau tiếp tục thúc đẩy chân trời của điện toán đám mây vì lợi ích của tất cả mọi người.

Tìm hiểu thêm về cơ sở dữ liệu riêng của Kassandra và nhiều thông tin khác tại hội nghị kỹ thuật số Cassandra Forward vào ngày 14 tháng 3 năm 2023.

Bài viết này dựa trên Chương 7, “Cơ sở dữ liệu gốc Kubernetes,” từ cuốn sách O'Reilly “ Quản lý dữ liệu gốc trên đám mây trên Kubernetes ” của Jeff Carpenter và Patrick McFadin.

[

Bởi Jeff Carpenter, DataStax

Jeff Carpenter đã làm việc với tư cách là kỹ sư phần mềm và kiến trúc sư trong nhiều ngành và là người ủng hộ nhà phát triển tại DataStax, giúp các kỹ sư thành công với Apache Cassandra. Anh ấy tham gia vào nhiều dự án nguồn mở trong hệ sinh thái Cassandra và Kubernetes, bao gồm Stargate và K8ssandra. Anh ấy là đồng tác giả của các cuốn sách O'Reilly "Cassandra: The Definitive Guide" và "Managing Cloud Native Data on Kubernetes."