Xin chào cư dân Khabrovsk. Như thường lệ, chúng tôi tiếp tục chia sẻ tài liệu thú vị trước khi bắt đầu các khóa học mới. Hôm nay, đặc biệt dành cho bạn, chúng tôi đã xuất bản một bài viết về Google Cloud Spanner trùng với thời điểm ra mắt khóa học .
Được xuất bản lần đầu ở .
Là công ty cung cấp nhiều giải pháp POS dựa trên đám mây cho các nhà bán lẻ, nhà hàng và người bán trực tuyến trên khắp thế giới, Lightspeed sử dụng một số loại nền tảng cơ sở dữ liệu khác nhau cho nhiều trường hợp sử dụng giao dịch, phân tích và tìm kiếm. Mỗi nền tảng cơ sở dữ liệu này đều có điểm mạnh và điểm yếu riêng. Do đó, khi Google giới thiệu Cloud Spanner ra thị trường - những tính năng đầy hứa hẹn chưa từng thấy trong thế giới cơ sở dữ liệu quan hệ, chẳng hạn như khả năng mở rộng theo chiều ngang hầu như không giới hạn và thỏa thuận cấp độ dịch vụ (SLA) 99,999%, - chúng tôi không thể bỏ lỡ cơ hội để có được nó!
Để cung cấp cái nhìn tổng quan toàn diện về trải nghiệm của chúng tôi với Cloud Spanner, cũng như các tiêu chí đánh giá mà chúng tôi đã sử dụng, chúng tôi sẽ đề cập đến các chủ đề sau:
- Tiêu chí đánh giá của chúng tôi
- Tóm tắt về Cloud Spanner
- Đánh giá của chúng tôi
- Sự tìm kiếm của chúng ta
1. Tiêu chí đánh giá của chúng tôi
Trước khi đi sâu vào chi tiết cụ thể của Cloud Spanner, những điểm tương đồng và khác biệt của nó với các giải pháp khác trên thị trường, trước tiên hãy nói về các trường hợp sử dụng chính mà chúng tôi đã nghĩ đến khi xem xét nơi triển khai Cloud Spanner trong cơ sở hạ tầng của mình:
- Thay thế cho giải pháp cơ sở dữ liệu SQL truyền thống (chiếm ưu thế)
- Cách giải pháp OLTP với sự hỗ trợ của OLAP
Lưu ý: Để đơn giản và dễ so sánh, bài viết này so sánh Cloud Spanner với các biến thể MySQL của dòng giải pháp GCP Cloud SQL và Amazon AWS RDS.
Sử dụng Cloud Spanner để thay thế cho giải pháp cơ sở dữ liệu SQL truyền thống
Trong môi trường cổ truyền cơ sở dữ liệu, khi thời gian phản hồi truy vấn cơ sở dữ liệu đạt đến hoặc thậm chí vượt quá ngưỡng ứng dụng được xác định trước (chủ yếu do số lượng người dùng và/hoặc yêu cầu tăng lên), có một số cách để giảm thời gian phản hồi xuống mức có thể chấp nhận được. Tuy nhiên, hầu hết các giải pháp này đều liên quan đến sự can thiệp thủ công.
Ví dụ: bước đầu tiên cần thực hiện là xem xét các tham số cơ sở dữ liệu liên quan đến hiệu suất khác nhau và điều chỉnh chúng để phù hợp nhất với các mẫu trường hợp sử dụng ứng dụng. Nếu điều này vẫn chưa đủ, bạn có thể chọn chia tỷ lệ cơ sở dữ liệu theo chiều dọc hoặc chiều ngang.
Việc mở rộng quy mô theo chiều dọc của một ứng dụng đòi hỏi phải nâng cấp phiên bản máy chủ, thường bằng cách thêm nhiều bộ xử lý/lõi, nhiều RAM hơn, bộ nhớ nhanh hơn, v.v. Việc thêm nhiều tài nguyên phần cứng hơn sẽ dẫn đến hiệu suất cơ sở dữ liệu tăng lên, chủ yếu được đo bằng các giao dịch trong giây và độ trễ giao dịch cho hệ thống OLTP. Các hệ thống cơ sở dữ liệu quan hệ (sử dụng cách tiếp cận đa luồng) như MySQL có khả năng mở rộng theo chiều dọc.
Có một số nhược điểm của phương pháp này, nhưng rõ ràng nhất là kích thước máy chủ tối đa trên thị trường. Khi đạt đến giới hạn của phiên bản máy chủ lớn nhất, chỉ còn một tùy chọn: chia tỷ lệ theo chiều ngang.
Chia tỷ lệ theo chiều ngang là một cách tiếp cận trong đó nhiều máy chủ hơn được thêm vào một cụm, lý tưởng nhất là tăng hiệu suất một cách tuyến tính khi số lượng máy chủ được thêm vào. Số đông cổ truyền Hệ thống cơ sở dữ liệu không có quy mô tốt theo chiều ngang hoặc không có quy mô nào cả. Ví dụ: MySQL có thể chia tỷ lệ theo chiều ngang cho các hoạt động đọc bằng cách thêm các trình đọc nô lệ, nhưng không thể chia tỷ lệ theo chiều ngang cho việc ghi.
Mặt khác, do tính chất của nó, Cloud Spanner có thể dễ dàng mở rộng quy mô theo chiều ngang với sự can thiệp tối thiểu.
Đầy đủ tính năng DBMS như một dịch vụ phải được đánh giá từ nhiều góc độ khác nhau. Để làm cơ sở, chúng tôi đã lấy DBMS phổ biến nhất trên đám mây - cho Google, GCP Cloud SQL và cho Amazon, AWS RDS. Trong đánh giá của chúng tôi, chúng tôi tập trung vào các loại sau:
- Ánh xạ tính năng: phạm vi SQL, DDL, DML; thư viện/trình kết nối kết nối, hỗ trợ giao dịch, v.v.
- Hỗ trợ phát triển: phát triển và thử nghiệm dễ dàng.
- Hỗ trợ quản trị: quản lý phiên bản - ví dụ: tăng/giảm quy mô và nâng cấp phiên bản; SLA, sao lưu và phục hồi; kiểm soát truy cập/bảo mật.
Sử dụng Cloud Spanner làm giải pháp OLTP hỗ trợ OLAP
Mặc dù Google không tuyên bố rõ ràng rằng Cloud Spanner được thiết kế để xử lý phân tích nhưng nó có chung một số thuộc tính với các công cụ khác như Apache Impala & Kudu và YugaByte, được thiết kế cho khối lượng công việc OLAP.
Ngay cả khi chỉ có một khả năng nhỏ là Cloud Spanner đã bao gồm một công cụ HTAP (xử lý phân tích/giao dịch kết hợp) mở rộng nhất quán với một bộ tính năng OLAP có thể sử dụng được (ít nhiều), chúng tôi nghĩ rằng nó sẽ đáng để chúng tôi chú ý.
Với ý nghĩ này, chúng tôi đã xem xét các loại sau:
- Hỗ trợ tải dữ liệu, lập chỉ mục và phân vùng
- Hiệu suất truy vấn và DML
2. Tóm tắt về Cloud Spanner
Google Spanner là một hệ thống quản lý cơ sở dữ liệu quan hệ phân cụm (RDBMS) mà Google sử dụng cho một số dịch vụ của riêng mình. Google đã cung cấp rộng rãi cho người dùng Google Cloud Platform vào đầu năm 2017.
Dưới đây là một số thuộc tính của Cloud Spanner:
- Cụm RDBMS có khả năng mở rộng nhất quán cao: Sử dụng đồng bộ hóa thời gian phần cứng để đảm bảo tính nhất quán của dữ liệu.
- Hỗ trợ giao dịch trên nhiều bảng: Giao dịch có thể trải rộng trên nhiều bảng - không nhất thiết phải giới hạn ở một bảng duy nhất (không giống như Apache HBase hoặc Apache Kudu).
- Các bảng dựa trên khóa chính: Tất cả các bảng phải có khóa chính được khai báo (PC), khóa này có thể bao gồm nhiều cột trong bảng. Dữ liệu dạng bảng được lưu trữ theo thứ tự PC, giúp việc tìm kiếm trên PC rất hiệu quả và nhanh chóng. Giống như các hệ thống dựa trên PC khác, việc triển khai phải được mô hình hóa với các trường hợp sử dụng được thiết kế trước để đạt được .
- Bảng sọc: Các bảng có thể có sự phụ thuộc vật lý với nhau. Các hàng trong bảng con có thể được so khớp với các hàng trong bảng cha. Cách tiếp cận này tăng tốc việc tìm kiếm các mối quan hệ có thể được xác định trong giai đoạn lập mô hình dữ liệu, chẳng hạn như khách hàng cùng định vị và hóa đơn của họ.
- Chỉ mục: Cloud Spanner hỗ trợ các chỉ mục phụ. Chỉ mục bao gồm các cột được lập chỉ mục và tất cả các cột PC. Nếu muốn, chỉ mục cũng có thể chứa các cột không được lập chỉ mục khác. Chỉ mục có thể được xen kẽ với bảng cha để tăng tốc độ truy vấn. Một số hạn chế áp dụng cho chỉ mục, chẳng hạn như số lượng cột bổ sung tối đa được lưu trữ trong chỉ mục. Ngoài ra, các truy vấn thông qua chỉ mục có thể không đơn giản như trong các RDBMS khác.
“Cloud Spanner chỉ tự động chọn một chỉ mục trong một số ít trường hợp. Đặc biệt, Cloud Spanner không tự động chọn chỉ mục phụ nếu truy vấn yêu cầu bất kỳ cột nào không được lưu trữ trong '.
- Thỏa thuận cấp độ dịch vụ (SLA): Triển khai trong một khu vực với SLA là 99,99%; triển khai đa khu vực với 99,999% SLA. Mặc dù bản thân SLA chỉ là một thỏa thuận chứ không phải là sự đảm bảo dưới bất kỳ hình thức nào nhưng tôi tin rằng những người ở Google có một số dữ liệu chắc chắn để đưa ra tuyên bố mạnh mẽ như vậy. (Để tham khảo, 99,999% nghĩa là 26,3 giây không có dịch vụ mỗi tháng.)
- Thêm:
Lưu ý: Dự án Apache Tephra bổ sung hỗ trợ giao dịch nâng cao cho Apache HBase (hiện cũng được triển khai trong Apache Phoenix dưới dạng beta).
3. Đánh giá của chúng tôi
Vì vậy, tất cả chúng ta đều đã đọc các tuyên bố của Google về lợi ích của Cloud Spanner - khả năng mở rộng theo chiều ngang hầu như không giới hạn trong khi vẫn duy trì tính nhất quán cao và SLA rất cao. Mặc dù trong mọi trường hợp, những yêu cầu này cực kỳ khó đạt được nhưng mục tiêu của chúng tôi không phải là bác bỏ chúng. Thay vào đó, hãy tập trung vào những thứ khác mà hầu hết người dùng cơ sở dữ liệu quan tâm: tính chẵn lẻ và khả năng sử dụng.
Chúng tôi đã đánh giá Cloud Spanner như một sự thay thế cho Sharded MySQL
Google Cloud SQL và Amazon AWS RDS, hai trong số các DBMS OLTP phổ biến nhất trên thị trường đám mây, có một bộ tính năng rất lớn. Tuy nhiên, để mở rộng quy mô các cơ sở dữ liệu này vượt quá kích thước của một nút đơn lẻ, bạn cần thực hiện phân vùng ứng dụng. Cách tiếp cận này tạo thêm sự phức tạp cho cả ứng dụng và quản trị. Chúng tôi đã xem xét cách Spanner phù hợp với kịch bản kết hợp nhiều phân đoạn vào một phiên bản duy nhất và những tính năng nào (nếu có) có thể cần phải hy sinh.
Hỗ trợ SQL, DML và DDL, cũng như trình kết nối và thư viện?
Đầu tiên, khi bắt đầu với bất kỳ cơ sở dữ liệu nào, bạn cần tạo mô hình dữ liệu. Nếu bạn nghĩ rằng bạn có thể kết nối JDBC Spanner với công cụ SQL yêu thích của mình, bạn sẽ thấy rằng bạn có thể truy vấn dữ liệu của mình bằng nó, nhưng bạn không thể sử dụng nó để tạo bảng hoặc sửa đổi (DDL) hoặc bất kỳ thao tác chèn/cập nhật/xóa nào hoạt động (DML). JDBC chính thức của Google không hỗ trợ một trong hai điều này.
"Trình điều khiển hiện không hỗ trợ câu lệnh DML hoặc DDL."
Tài liệu cờ lê
Tình hình cũng không khá hơn với bảng điều khiển GCP - bạn chỉ có thể gửi truy vấn CHỌN. May mắn thay, có một trình điều khiển JDBC có sự hỗ trợ cho DML và DDL từ cộng đồng, bao gồm cả các giao dịch . Mặc dù trình điều khiển này cực kỳ hữu ích nhưng việc thiếu trình điều khiển JDBC của riêng Google là điều đáng ngạc nhiên. May mắn thay, Google cung cấp hỗ trợ khá rộng rãi cho các thư viện máy khách (dựa trên gRPC): C#, Go, Java, node.js, PHP, Python và Ruby.
Việc sử dụng API tùy chỉnh Cloud Spanner gần như bắt buộc (do thiếu DDL và DML trong JDBC) dẫn đến một số hạn chế đối với các vùng mã liên quan như nhóm kết nối hoặc khung liên kết cơ sở dữ liệu (ví dụ: Spring MVC). Thông thường, khi sử dụng JDBC, bạn có thể tự do lựa chọn nhóm kết nối yêu thích của mình (ví dụ: HikariCP, DBCP, C3PO, v.v.) đã được kiểm tra và hoạt động tốt. Trong trường hợp API Spanner tùy chỉnh, chúng tôi phải dựa vào các khung/nhóm liên kết/phiên mà chúng tôi đã tự tạo.
Thiết kế tập trung vào khóa chính (PC) cho phép Cloud Spanner truy cập dữ liệu qua PC rất nhanh nhưng cũng gây ra một số vấn đề về truy vấn.
- Bạn không thể cập nhật giá trị khóa chính; Trước tiên, bạn phải xóa mục nhập khỏi PC ban đầu và lắp lại nó với giá trị mới. (Điều này tương tự với các công cụ lưu trữ/cơ sở dữ liệu định hướng PC khác.)
- Mọi câu lệnh UPDATE và DELETE đều phải chỉ định PC trong WHERE, do đó không thể để trống DELETE tất cả các câu lệnh - phải luôn có một truy vấn con, ví dụ: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Thiếu tùy chọn tăng tự động hoặc bất cứ thứ gì tương tự để đặt trình tự cho trường PC. Để tính năng này hoạt động, giá trị tương ứng phải được tạo ở phía ứng dụng.
Chỉ số phụ?
Google Cloud Spanner có hỗ trợ tích hợp cho các chỉ mục phụ. Đây là một tính năng rất hay mà không phải lúc nào các công nghệ khác cũng có. Apache Kudu hiện hoàn toàn không hỗ trợ các chỉ mục phụ và Apache HBase không hỗ trợ các chỉ mục trực tiếp nhưng có thể thêm chúng thông qua Apache Phoenix.
Các chỉ mục trong Kudu và HBase có thể được mô hình hóa thành một bảng riêng biệt với thành phần khóa chính khác nhau, nhưng tính nguyên tử của các thao tác được thực hiện trên bảng cha và các bảng chỉ mục liên quan phải được thực hiện ở cấp ứng dụng và không hề đơn giản để triển khai chính xác.
Như đã đề cập trong bài đánh giá Cloud Spanner, các chỉ mục của nó có thể khác với các chỉ mục của MySQL. Do đó, cần đặc biệt cẩn thận khi xây dựng các truy vấn và lập hồ sơ để đảm bảo rằng chỉ mục thích hợp được sử dụng khi cần thiết.
Đại diện?
Một đối tượng rất phổ biến và hữu ích trong cơ sở dữ liệu là các khung nhìn. Chúng có thể hữu ích cho nhiều trường hợp sử dụng; hai mục yêu thích của tôi là lớp trừu tượng logic và lớp bảo mật. Thật không may, Cloud Spanner KHÔNG hỗ trợ chế độ xem. Tuy nhiên, điều này chỉ hạn chế chúng tôi một phần vì không có mức độ chi tiết về quyền truy cập ở cấp cột nơi chế độ xem có thể là giải pháp khả thi.
Xem tài liệu Cloud Spanner để biết phần nêu chi tiết về hạn ngạch và hạn chế (), có một vấn đề đặc biệt có thể gây rắc rối cho một số ứng dụng: Cloud Spanner ngay từ đầu có giới hạn tối đa 100 cơ sở dữ liệu cho mỗi phiên bản. Rõ ràng, đây có thể là một nút thắt cổ chai lớn đối với cơ sở dữ liệu được thiết kế để mở rộng quy mô lên hơn 100 cơ sở dữ liệu. May mắn thay, sau khi trao đổi với đại diện kỹ thuật của Google, chúng tôi phát hiện ra rằng giới hạn này có thể tăng lên hầu hết mọi giá trị thông qua Bộ phận hỗ trợ của Google.
Hỗ trợ phát triển?
Cloud Spanner cung cấp hỗ trợ ngôn ngữ lập trình khá tốt để làm việc với API của nó. Các thư viện được hỗ trợ chính thức nằm trong các lĩnh vực C#, Go, Java, node.js, PHP, Python và Ruby. Tài liệu này khá chi tiết, nhưng cũng như các công nghệ tiên tiến khác, cộng đồng này khá nhỏ so với các công nghệ cơ sở dữ liệu phổ biến nhất, điều này có thể khiến bạn mất nhiều thời gian hơn để giải quyết các trường hợp hoặc vấn đề sử dụng ít phổ biến hơn.
Vậy còn việc hỗ trợ phát triển địa phương thì sao?
Chúng tôi chưa tìm được cách tạo phiên bản Cloud Spanner tại chỗ. Thứ gần nhất chúng tôi có được là hình ảnh Docker. , về nguyên tắc thì giống nhau nhưng thực tế lại rất khác nhau. Ví dụ: CockroachDB có thể sử dụng PostgreSQL JDBC. Vì môi trường phát triển phải càng gần với môi trường sản xuất càng tốt, Cloud Spanner không lý tưởng vì nó phải dựa vào một phiên bản Spanner đầy đủ. Để tiết kiệm chi phí, bạn có thể chọn phiên bản một khu vực.
Hỗ trợ quản lý?
Việc tạo một phiên bản Cloud Spanner rất đơn giản. Bạn chỉ cần chọn giữa việc tạo một phiên bản nhiều vùng hoặc một vùng, chỉ định (các) vùng và số lượng nút. Trong vòng chưa đầy một phút, phiên bản của bạn sẽ thiết lập và chạy.
Một số số liệu thô sơ có thể truy cập trực tiếp từ trang Spanner trong Google Console. Các chế độ xem chi tiết hơn có sẵn thông qua Stackdriver, nơi bạn cũng có thể đặt ngưỡng số liệu và chính sách cảnh báo.
Truy cập vào tài nguyên?
MySQL cung cấp các cài đặt mở rộng và rất chi tiết cho quyền/vai trò của người dùng. Bạn có thể dễ dàng định cấu hình quyền truy cập vào một bảng cụ thể hoặc thậm chí chỉ là một tập hợp con các cột của bảng đó. Cloud Spanner sử dụng công cụ Identity & Access Management (IAM) của Google, công cụ này chỉ cho phép bạn đặt chính sách và quyền ở mức rất cao. Tùy chọn chi tiết nhất là độ phân giải cấp cơ sở dữ liệu, tùy chọn này không phù hợp với hầu hết các trường hợp sử dụng sản xuất. Hạn chế này buộc bạn phải thêm các biện pháp bảo mật bổ sung vào mã, cơ sở hạ tầng của mình hoặc cả hai để ngăn chặn việc sử dụng trái phép tài nguyên Spanner.
Sao lưu?
Nói một cách đơn giản, không có bản sao lưu nào trong Cloud Spanner. Mặc dù các yêu cầu SLA cao của Google có thể đảm bảo rằng bạn không mất bất kỳ dữ liệu nào do lỗi phần cứng hoặc cơ sở dữ liệu, lỗi của con người, lỗi ứng dụng, v.v. Tất cả chúng ta đều biết quy tắc: tính sẵn sàng cao không thể thay thế cho chiến lược sao lưu âm thanh. Hiện tại, cách duy nhất để sao lưu dữ liệu là truyền dữ liệu theo chương trình từ cơ sở dữ liệu sang môi trường lưu trữ riêng.
Hiệu suất truy vấn?
Chúng tôi đã sử dụng Yahoo! để tải dữ liệu và kiểm tra các truy vấn. Điểm chuẩn phục vụ đám mây. Bảng bên dưới hiển thị khối lượng công việc B của YCSB với tỷ lệ đọc là 95% và tỷ lệ ghi là 5%.
* Thử nghiệm tải được chạy trên Công cụ điện toán n1-standard-32 (CE) (32 vCPU, bộ nhớ 120 GB) và phiên bản thử nghiệm chưa bao giờ là nút cổ chai trong các thử nghiệm.
** Số lượng luồng tối đa trong một phiên bản YCSB là 400. Phải chạy tổng cộng sáu phiên bản thử nghiệm YCSB song song để có được tổng số 2400 luồng.
Nhìn vào kết quả benchmark, đặc biệt là sự kết hợp giữa tải CPU và TPS, chúng ta có thể thấy rõ rằng Cloud Spanner có quy mô khá tốt. Tải nặng do số lượng lớn luồng tạo ra sẽ được bù đắp bằng số lượng lớn nút trong cụm Cloud Spanner. Mặc dù độ trễ có vẻ khá cao, đặc biệt là khi chạy với 2400 luồng, nhưng việc kiểm tra lại với 6 phiên bản nhỏ hơn của công cụ điện toán có thể cần thiết để có được con số chính xác hơn. Mỗi phiên bản sẽ chạy một thử nghiệm YCSB thay vì một phiên bản CE lớn với 6 thử nghiệm song song. Bằng cách này, sẽ dễ dàng hơn để phân biệt giữa độ trễ yêu cầu Cloud Spanner và độ trễ được thêm vào bởi kết nối mạng giữa Cloud Spanner và phiên bản CE đang chạy thử nghiệm.
Cloud Spanner hoạt động như một OLAP như thế nào?
Phân vùng?
Chia dữ liệu thành các phân đoạn độc lập về mặt vật lý và/hoặc logic, được gọi là phân vùng, là một khái niệm rất phổ biến được tìm thấy trong hầu hết các công cụ OLAP. Các phân vùng có thể cải thiện đáng kể hiệu năng truy vấn và khả năng bảo trì cơ sở dữ liệu. Đi sâu hơn vào việc phân vùng sẽ là một (các) bài viết riêng, vì vậy chúng ta hãy chỉ đề cập đến tầm quan trọng của việc có sơ đồ phân vùng và phân vùng phụ. Khả năng chia dữ liệu thành các phân vùng và thậm chí thành các phân vùng phụ là chìa khóa cho hiệu suất truy vấn phân tích.
Cloud Spanner không hỗ trợ các phân vùng như vậy. Nó chia dữ liệu nội bộ thành cái gọi là chia-s dựa trên phạm vi khóa chính. Việc phân vùng được thực hiện tự động để cân bằng tải trong cụm Cloud Spanner. Một tính năng rất hữu ích của Cloud Spanner là phân chia tải cơ sở của bảng cha (bảng không xen kẽ với bảng khác). Cờ lê tự động phát hiện xem nó có chứa chia dữ liệu được đọc thường xuyên hơn dữ liệu ở những dữ liệu khác chia-ah, và có thể quyết định chia tay thêm nữa. Bằng cách này, nhiều nút hơn có thể tham gia vào một yêu cầu, điều này cũng làm tăng thông lượng một cách hiệu quả.
Đang tải dữ liệu?
Phương pháp Cloud Spanner dành cho dữ liệu số lượng lớn cũng giống như phương pháp tải thông thường. Để đạt được hiệu suất tối đa, bạn cần tuân theo một số nguyên tắc, bao gồm:
- Sắp xếp dữ liệu của bạn theo khóa chính.
- Chia chúng cho 10*số lượng nút các phần riêng biệt.
- Tạo một tập hợp các tác vụ công việc tải dữ liệu song song.
Việc tải dữ liệu này sử dụng tất cả các nút Cloud Spanner.
Chúng tôi đã sử dụng khối lượng công việc A của YCSB để tạo tập dữ liệu gồm 10 triệu hàng.
* Thử nghiệm tải được chạy trên công cụ điện toán n1-standard-32 (32 vCPU, bộ nhớ 120 GB) và phiên bản thử nghiệm chưa bao giờ là nút thắt cổ chai trong các thử nghiệm.
**Không nên thiết lập một nút cho bất kỳ khối lượng công việc sản xuất nào.
Như đã đề cập ở trên, Cloud Spanner tự động xử lý các phần phân tách dựa trên tải của chúng, do đó kết quả sẽ được cải thiện sau nhiều lần lặp lại thử nghiệm liên tiếp. Các kết quả được trình bày ở đây là kết quả tốt nhất mà chúng tôi thu được. Nhìn vào những con số ở trên, chúng ta có thể thấy Cloud Spanner có quy mô như thế nào khi số lượng nút trong cụm tăng lên. Những con số nổi bật là độ trễ trung bình cực thấp, trái ngược với kết quả của khối lượng công việc hỗn hợp (95% đọc và 5% ghi) như được mô tả trong phần trên.
Chia tỷ lệ?
Việc tăng và giảm số lượng nút Cloud Spanner chỉ là tác vụ bằng một cú nhấp chuột. Nếu muốn tải dữ liệu nhanh chóng, bạn có thể cân nhắc việc tăng phiên bản của mình lên mức tối đa (trong trường hợp của chúng tôi là 25 nút ở khu vực Đông Mỹ) và sau đó giảm số lượng nút đủ điều kiện cho tải thông thường của bạn sau khi tất cả dữ liệu đã được đưa vào cơ sở dữ liệu, đề cập đến giới hạn 2TB/nút.
Chúng tôi đã được nhắc nhở về giới hạn này ngay cả với cơ sở dữ liệu nhỏ hơn nhiều. Sau nhiều lần chạy kiểm tra tải, cơ sở dữ liệu của chúng tôi có kích thước khoảng 155 GB và khi thu nhỏ xuống phiên bản 1 nút, chúng tôi đã nhận được lỗi sau:
Chúng tôi đã cố gắng giảm quy mô từ 25 xuống còn 2 phiên bản nhưng bị kẹt ở hai nút.
Việc tăng và giảm số lượng nút trong cụm Cloud Spanner có thể được tự động hóa bằng API REST. Điều này có thể đặc biệt hữu ích để giảm tải hệ thống tăng lên trong những giờ làm việc bận rộn.
Hiệu suất của các truy vấn OLAP?
Ban đầu, chúng tôi dự định dành nhiều thời gian để đánh giá Spanner về phần này. Sau vài lần SELECT COUNT, chúng tôi ngay lập tức nhận ra rằng quá trình thử nghiệm sẽ diễn ra trong thời gian ngắn và Spanner sẽ KHÔNG phải là công cụ phù hợp cho OLAP. Bất kể số lượng nút trong cụm là bao nhiêu, chỉ cần chọn số lượng hàng trong bảng 10M hàng sẽ mất từ 55 đến 60 giây. Ngoài ra, mọi truy vấn yêu cầu nhiều bộ nhớ hơn để lưu trữ kết quả trung gian đều không thành công do lỗi OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Một số con số cho truy vấn TPC-H có thể được tìm thấy trong bài viết của Todd Lipcon , slide 42 và 43. Những con số này phù hợp với kết quả của chúng tôi (thật không may).
4. Kết luận của chúng tôi
Với trạng thái hiện tại của các tính năng của Cloud Spanner, thật khó để tưởng tượng đây là một giải pháp thay thế đơn giản cho giải pháp OLTP hiện tại của bạn, đặc biệt khi nhu cầu của bạn tăng cao hơn. Sẽ phải dành một lượng thời gian đáng kể để xây dựng giải pháp khắc phục những thiếu sót của Cloud Spanner.
Khi bắt đầu đánh giá Cloud Spanner, chúng tôi kỳ vọng các tính năng quản lý của nó ngang bằng hoặc ít nhất là không quá khác biệt so với các giải pháp Google SQL khác. Nhưng chúng tôi rất ngạc nhiên vì hoàn toàn thiếu bản sao lưu và khả năng kiểm soát rất hạn chế đối với quyền truy cập vào tài nguyên. Chưa kể không có chế độ xem, không có môi trường phát triển cục bộ, các trình tự không được hỗ trợ, JDBC không hỗ trợ DML và DDL, v.v.
Vậy ai đó cần mở rộng quy mô cơ sở dữ liệu giao dịch sẽ đi đâu? Dường như không có một giải pháp duy nhất trên thị trường phù hợp với mọi trường hợp sử dụng. Có nhiều giải pháp nguồn đóng và nguồn mở (một số giải pháp được đề cập trong bài viết này), mỗi giải pháp đều có điểm mạnh và điểm yếu riêng, nhưng không giải pháp nào trong số đó cung cấp SaaS với SLA 99,999% và tính nhất quán cao. Nếu SLA cao là mục tiêu chính của bạn và bạn không có ý định xây dựng giải pháp nhiều đám mây tùy chỉnh thì Cloud Spanner có thể là giải pháp bạn đang tìm kiếm. Nhưng bạn nên nhận thức được tất cả những hạn chế của nó.
Công bằng mà nói, Cloud Spanner chỉ được phát hành ra công chúng vào mùa xuân năm 2017, vì vậy thật hợp lý khi kỳ vọng rằng một số thiếu sót hiện tại của nó cuối cùng có thể biến mất (hy vọng) và khi chúng biến mất, nó có thể thay đổi cuộc chơi. Suy cho cùng, Cloud Spanner không chỉ là một dự án phụ của Google. Google sử dụng nó làm cơ sở cho các sản phẩm khác của Google. Và khi Google gần đây thay thế Megastore trong Google Cloud Storage bằng Cloud Spanner, điều đó đã cho phép Google Cloud Storage trở nên nhất quán cao độ đối với danh sách các đối tượng trên quy mô toàn cầu (điều này vẫn chưa xảy ra đối với ).
Vì vậy, vẫn còn hy vọng... chúng tôi hy vọng.
Đó là tất cả. Giống như tác giả bài viết, chúng tôi cũng tiếp tục hy vọng nhưng bạn nghĩ sao về điều này? Viết trong phần bình luận
Chúng tôi mời mọi người đến thăm trong đó chúng tôi sẽ cho bạn biết chi tiết về khóa học từ OTUS.
Nguồn: www.habr.com