Chào mọi người! Tên tôi là Golov Nikolay. Trước đây, tôi đã làm việc tại Avito và quản lý Nền tảng dữ liệu trong sáu năm, tức là tôi đã làm việc trên tất cả các cơ sở dữ liệu: phân tích (Vertica, ClickHouse), phát trực tuyến và OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Trong thời gian này, tôi đã xử lý một số lượng lớn cơ sở dữ liệu - rất khác nhau và bất thường, cũng như các trường hợp sử dụng chúng không theo tiêu chuẩn.
Hiện tại tôi đang làm việc tại ManyChat. Về bản chất, đây là một công ty khởi nghiệp - mới, đầy tham vọng và đang phát triển nhanh chóng. Và khi tôi mới gia nhập công ty, một câu hỏi kinh điển đã nảy sinh: “Một công ty khởi nghiệp trẻ hiện nay nên làm gì từ thị trường cơ sở dữ liệu và DBMS?”
Trong bài viết này, dựa trên báo cáo của tôi tại , Tôi sẽ trả lời câu hỏi này. Phiên bản video của báo cáo có sẵn tại .
Cơ sở dữ liệu phổ biến 2020
Đó là năm 2020, tôi nhìn quanh và thấy ba loại cơ sở dữ liệu.
Loại đầu tiên - cơ sở dữ liệu OLTP cổ điển: PostgreSQL, SQL Server, Oracle, MySQL. Chúng đã được viết từ lâu nhưng vẫn còn phù hợp vì chúng đã quá quen thuộc với cộng đồng nhà phát triển.
Loại thứ hai là căn cứ từ "không". Họ đã cố gắng tránh xa các mẫu cổ điển bằng cách từ bỏ SQL, cấu trúc truyền thống và ACID, bằng cách thêm phân đoạn tích hợp sẵn và các tính năng hấp dẫn khác. Ví dụ: đây là Cassandra, MongoDB, Redis hoặc Tarantool. Tất cả những giải pháp này đều muốn cung cấp cho thị trường một cái gì đó mới về cơ bản và chiếm lĩnh vị trí thích hợp của chúng vì chúng cực kỳ thuận tiện cho một số nhiệm vụ nhất định. Tôi sẽ biểu thị các cơ sở dữ liệu này bằng thuật ngữ chung NOSQL.
“Số không” đã kết thúc, chúng tôi đã quen với cơ sở dữ liệu NOSQL và thế giới, theo quan điểm của tôi, đã thực hiện bước tiếp theo - tới cơ sở dữ liệu được quản lý. Các cơ sở dữ liệu này có cùng lõi với cơ sở dữ liệu OLTP cổ điển hoặc cơ sở dữ liệu NoSQL mới. Nhưng họ không cần DBA và DevOps và chạy trên phần cứng được quản lý trên đám mây. Đối với một nhà phát triển, đây “chỉ là một cơ sở” hoạt động ở đâu đó, nhưng không ai quan tâm nó được cài đặt trên máy chủ như thế nào, ai đã cấu hình máy chủ và ai cập nhật nó.
Ví dụ về cơ sở dữ liệu như vậy:
- AWS RDS là trình bao bọc được quản lý dành cho PostgreSQL/MySQL.
- DynamoDB là một AWS tương tự cơ sở dữ liệu dựa trên tài liệu, tương tự như Redis và MongoDB.
- Amazon Redshift là cơ sở dữ liệu phân tích được quản lý.
Về cơ bản, đây là những cơ sở dữ liệu cũ nhưng được xây dựng trong môi trường được quản lý mà không cần phải làm việc với phần cứng.
Ghi chú. Các ví dụ được lấy cho môi trường AWS, nhưng các ví dụ tương tự cũng tồn tại trong Microsoft Azure, Google Cloud hoặc Yandex.Cloud.
Có gì mới về điều này? Vào năm 2020, không có điều này.
Khái niệm không có máy chủ
Điều thực sự mới trên thị trường vào năm 2020 là các giải pháp serverless hoặc serverless.
Tôi sẽ cố gắng giải thích điều này có nghĩa là gì bằng cách sử dụng ví dụ về dịch vụ thông thường hoặc ứng dụng phụ trợ.
Để triển khai một ứng dụng phụ trợ thông thường, chúng tôi mua hoặc thuê máy chủ, sao chép mã vào đó, xuất bản điểm cuối ra bên ngoài và thường xuyên thanh toán tiền thuê, điện và dịch vụ trung tâm dữ liệu. Đây là sơ đồ tiêu chuẩn.
Còn cách nào khác không? Với các dịch vụ không có máy chủ, bạn có thể.
Trọng tâm của phương pháp này là gì: không có máy chủ, thậm chí không có việc thuê phiên bản ảo trên đám mây. Để triển khai dịch vụ, hãy sao chép mã (chức năng) vào kho lưu trữ và xuất bản mã đó đến điểm cuối. Sau đó, chúng tôi chỉ cần trả tiền cho mỗi lệnh gọi đến chức năng này, hoàn toàn bỏ qua phần cứng nơi nó được thực thi.
Tôi sẽ cố gắng minh họa cách tiếp cận này bằng hình ảnh.
Triển khai cổ điển. Chúng tôi có một dịch vụ với tải nhất định. Chúng tôi đưa ra hai phiên bản: máy chủ vật lý hoặc phiên bản trong AWS. Yêu cầu bên ngoài được gửi đến các trường hợp này và được xử lý ở đó.
Như bạn có thể thấy trong hình, các máy chủ không được xử lý như nhau. Một yêu cầu được sử dụng 100%, có hai yêu cầu và một yêu cầu chỉ ở mức 50% - không hoạt động một phần. Nếu không phải ba yêu cầu mà là 30 yêu cầu, thì toàn bộ hệ thống sẽ không thể đáp ứng được tải và sẽ bắt đầu chậm lại.
Triển khai không có máy chủ. Trong môi trường không có máy chủ, dịch vụ như vậy không có phiên bản hoặc máy chủ. Có một nhóm tài nguyên được làm nóng nhất định - các thùng chứa Docker nhỏ được chuẩn bị sẵn với mã chức năng được triển khai. Hệ thống nhận được các yêu cầu bên ngoài và đối với mỗi yêu cầu đó, serverless framework sẽ tạo ra một vùng chứa nhỏ có mã: nó xử lý yêu cầu cụ thể này và hủy bỏ vùng chứa đó.
Một yêu cầu - một container được nâng lên, 1000 yêu cầu - 1000 container. Và việc triển khai trên các máy chủ phần cứng đã là công việc của nhà cung cấp đám mây. Nó hoàn toàn bị ẩn bởi khung công tác không có máy chủ. Trong khái niệm này, chúng tôi trả tiền cho mọi cuộc gọi. Ví dụ: một cuộc gọi đến một ngày - chúng tôi trả tiền cho một cuộc gọi, một triệu cuộc gọi đến mỗi phút - chúng tôi trả tiền một triệu. Hoặc trong một giây, điều này cũng xảy ra.
Khái niệm xuất bản chức năng không có máy chủ phù hợp với dịch vụ không có trạng thái. Và nếu bạn cần một dịch vụ đầy đủ trạng thái (trạng thái), thì chúng tôi sẽ thêm cơ sở dữ liệu vào dịch vụ. Trong trường hợp này, khi làm việc với trạng thái, mỗi hàm trạng thái chỉ đơn giản là ghi và đọc từ cơ sở dữ liệu. Hơn nữa, từ cơ sở dữ liệu thuộc bất kỳ loại nào trong ba loại được mô tả ở đầu bài viết.
Hạn chế chung của tất cả các cơ sở dữ liệu này là gì? Đây là chi phí của một máy chủ phần cứng hoặc đám mây được sử dụng liên tục (hoặc một số máy chủ). Không quan trọng chúng tôi sử dụng cơ sở dữ liệu cổ điển hay được quản lý, cho dù chúng tôi có Devops và quản trị viên hay không, chúng tôi vẫn trả tiền thuê phần cứng, điện và trung tâm dữ liệu 24/7. Nếu chúng tôi có cơ sở cổ điển, chúng tôi sẽ trả tiền cho chủ và nô lệ. Nếu đó là cơ sở dữ liệu phân mảnh có tải cao, chúng tôi trả tiền cho 10, 20 hoặc 30 máy chủ và chúng tôi trả tiền liên tục.
Sự hiện diện của các máy chủ được đặt trước vĩnh viễn trong cơ cấu chi phí trước đây được coi là một điều xấu cần thiết. Cơ sở dữ liệu thông thường cũng có những khó khăn khác, chẳng hạn như giới hạn về số lượng kết nối, hạn chế mở rộng, sự đồng thuận phân tán theo địa lý - bằng cách nào đó chúng có thể được giải quyết trong một số cơ sở dữ liệu nhất định, nhưng không phải tất cả cùng một lúc và không lý tưởng.
Cơ sở dữ liệu không có máy chủ - lý thuyết
Câu hỏi của năm 2020: có thể tạo cơ sở dữ liệu không có máy chủ không? Mọi người đều đã nghe nói về backend không có máy chủ... hãy thử làm cho cơ sở dữ liệu không có máy chủ?
Điều này nghe có vẻ lạ, vì cơ sở dữ liệu là một dịch vụ đầy đủ trạng thái, không phù hợp lắm với cơ sở hạ tầng không có máy chủ. Đồng thời, trạng thái của cơ sở dữ liệu rất lớn: gigabyte, terabyte và trong cơ sở dữ liệu phân tích thậm chí là petabyte. Không dễ để nâng cấp nó trong các thùng chứa Docker nhẹ.
Mặt khác, hầu hết tất cả các cơ sở dữ liệu hiện đại đều chứa một lượng lớn logic và thành phần: giao dịch, phối hợp toàn vẹn, thủ tục, phụ thuộc quan hệ và rất nhiều logic. Đối với khá nhiều logic cơ sở dữ liệu, một trạng thái nhỏ là đủ. Gigabyte và Terabyte chỉ được sử dụng trực tiếp bởi một phần nhỏ logic cơ sở dữ liệu liên quan đến việc thực hiện trực tiếp các truy vấn.
Theo đó, ý tưởng là: nếu một phần logic cho phép thực thi không trạng thái, tại sao không chia cơ sở thành các phần Stateful và Stateless.
Serverless dành cho giải pháp OLAP
Chúng ta hãy xem việc cắt cơ sở dữ liệu thành các phần Stateful và Stateless có thể trông như thế nào bằng cách sử dụng các ví dụ thực tế.
Ví dụ: chúng tôi có cơ sở dữ liệu phân tích: dữ liệu bên ngoài (hình trụ màu đỏ ở bên trái), quy trình ETL tải dữ liệu vào cơ sở dữ liệu và nhà phân tích gửi truy vấn SQL đến cơ sở dữ liệu. Đây là một sơ đồ vận hành kho dữ liệu cổ điển.
Trong sơ đồ này, ETL được thực hiện có điều kiện một lần. Sau đó, bạn cần phải liên tục trả tiền cho các máy chủ nơi cơ sở dữ liệu chạy với dữ liệu chứa đầy ETL để có thứ gì đó cần gửi truy vấn tới.
Hãy xem xét một phương pháp thay thế được triển khai trong AWS Athena Serverless. Không có phần cứng chuyên dụng vĩnh viễn để lưu trữ dữ liệu đã tải xuống. Thay vì điều này:
- Người dùng gửi truy vấn SQL tới Athena. Trình tối ưu hóa Athena phân tích truy vấn SQL và tìm kiếm kho siêu dữ liệu (Siêu dữ liệu) để tìm dữ liệu cụ thể cần thiết để thực hiện truy vấn.
- Trình tối ưu hóa, dựa trên dữ liệu được thu thập, tải dữ liệu cần thiết từ các nguồn bên ngoài vào bộ lưu trữ tạm thời (cơ sở dữ liệu tạm thời).
- Một truy vấn SQL từ người dùng được thực thi trong bộ lưu trữ tạm thời và kết quả được trả về cho người dùng.
- Bộ nhớ tạm thời bị xóa và tài nguyên được giải phóng.
Trong kiến trúc này, chúng tôi chỉ trả tiền cho quá trình thực hiện yêu cầu. Không có yêu cầu - không có chi phí.
Đây là một phương pháp hiệu quả và được triển khai không chỉ trong Athena Serverless mà còn trong Redshift Spectrum (trong AWS).
Ví dụ về Athena cho thấy cơ sở dữ liệu Serverless hoạt động trên các truy vấn thực với hàng chục và hàng trăm Terabyte dữ liệu. Hàng trăm Terabyte sẽ yêu cầu hàng trăm máy chủ, nhưng chúng tôi không phải trả tiền cho chúng - chúng tôi trả tiền cho các yêu cầu. Tốc độ của mỗi yêu cầu là (rất) thấp so với cơ sở dữ liệu phân tích chuyên dụng như Vertica, nhưng chúng tôi không trả tiền cho thời gian ngừng hoạt động.
Cơ sở dữ liệu như vậy có thể áp dụng cho các truy vấn phân tích đặc biệt hiếm gặp. Ví dụ: khi chúng ta quyết định kiểm tra một giả thuyết một cách tự nhiên trên một lượng dữ liệu khổng lồ. Athena là sự lựa chọn hoàn hảo cho những trường hợp này. Đối với các yêu cầu thường xuyên, hệ thống như vậy rất tốn kém. Trong trường hợp này, hãy lưu trữ dữ liệu vào một số giải pháp chuyên dụng.
Serverless dành cho giải pháp OLTP
Ví dụ trước xem xét các nhiệm vụ OLAP (phân tích). Bây giờ hãy xem các nhiệm vụ OLTP.
Hãy tưởng tượng PostgreSQL hoặc MySQL có khả năng mở rộng. Hãy tạo một phiên bản PostgreSQL hoặc MySQL được quản lý thông thường với nguồn tài nguyên tối thiểu. Khi phiên bản nhận được nhiều tải hơn, chúng tôi sẽ kết nối các bản sao bổ sung mà chúng tôi sẽ phân phối một phần tải đọc. Nếu không có yêu cầu hoặc tải, chúng tôi sẽ tắt các bản sao. Phiên bản đầu tiên là bản chính và phần còn lại là bản sao.
Ý tưởng này được triển khai trong cơ sở dữ liệu có tên Aurora Serverless AWS. Nguyên tắc rất đơn giản: các yêu cầu từ ứng dụng bên ngoài được nhóm proxy chấp nhận. Nhận thấy tải tăng lên, nó phân bổ tài nguyên máy tính từ các phiên bản tối thiểu được làm ấm trước - kết nối được thực hiện nhanh nhất có thể. Việc vô hiệu hóa các trường hợp xảy ra theo cách tương tự.
Trong Aurora có khái niệm Đơn vị công suất Aurora, ACU. Đây là (có điều kiện) một phiên bản (máy chủ). Mỗi ACU cụ thể có thể là Master hoặc Slave. Mỗi Đơn vị công suất có RAM, bộ xử lý và ổ đĩa tối thiểu riêng. Theo đó, một là chính, còn lại là bản sao chỉ đọc.
Số lượng Đơn vị công suất Aurora đang chạy này là một tham số có thể định cấu hình. Số lượng tối thiểu có thể là XNUMX hoặc XNUMX (trong trường hợp này, cơ sở dữ liệu sẽ không hoạt động nếu không có yêu cầu).
Khi cơ sở nhận được yêu cầu, nhóm proxy sẽ tăng Đơn vị công suất Aurora, tăng tài nguyên hiệu suất của hệ thống. Khả năng tăng và giảm tài nguyên cho phép hệ thống “tung hứng” các tài nguyên: tự động hiển thị các ACU riêng lẻ (thay thế chúng bằng các ACU mới) và tung ra tất cả các bản cập nhật hiện tại cho các tài nguyên đã rút.
Cơ sở Aurora Serverless có thể mở rộng quy mô tải đọc. Nhưng tài liệu không nói trực tiếp điều này. Có thể có cảm giác như họ có thể nâng được một đa chủ. Không có phép thuật.
Cơ sở dữ liệu này rất phù hợp để tránh chi số tiền lớn cho các hệ thống có quyền truy cập không thể đoán trước. Ví dụ: khi tạo MVP hoặc tiếp thị các trang web danh thiếp, chúng tôi thường không mong đợi tải ổn định. Theo đó, nếu không có quyền truy cập, chúng tôi sẽ không thanh toán cho các phiên bản. Khi xảy ra tải bất ngờ, chẳng hạn như sau một hội nghị hoặc chiến dịch quảng cáo, có rất nhiều người truy cập trang web và tải tăng lên đáng kể, Aurora Serverless sẽ tự động nhận tải này và nhanh chóng kết nối các tài nguyên còn thiếu (ACU). Sau đó, hội nghị trôi qua, mọi người quên mất nguyên mẫu, máy chủ (ACU) ngừng hoạt động và chi phí giảm xuống XNUMX - thật tiện lợi.
Giải pháp này không phù hợp với tải trọng cao ổn định vì nó không mở rộng được tải lượng ghi. Tất cả các kết nối và ngắt kết nối tài nguyên này xảy ra tại cái gọi là “điểm quy mô” - một thời điểm khi cơ sở dữ liệu không được hỗ trợ bởi một giao dịch hoặc các bảng tạm thời. Ví dụ: trong vòng một tuần, điểm quy mô có thể không xảy ra và cơ sở hoạt động trên cùng các tài nguyên và đơn giản là không thể mở rộng hoặc thu hẹp.
Không có phép thuật nào - đó là PostgreSQL thông thường. Nhưng quá trình thêm máy và ngắt kết nối chúng được tự động hóa một phần.
Không có máy chủ theo thiết kế
Aurora Serverless là cơ sở dữ liệu cũ được viết lại cho đám mây để tận dụng một số lợi ích của Serverless. Và bây giờ tôi sẽ kể cho bạn nghe về nền tảng ban đầu được viết cho đám mây, dành cho cách tiếp cận không có máy chủ - Serverless-by-design. Nó ngay lập tức được phát triển mà không cần giả định rằng nó sẽ chạy trên các máy chủ vật lý.
Căn cứ này được gọi là Snowflake. Nó có ba khối chính.
Đầu tiên là khối siêu dữ liệu. Đây là dịch vụ trong bộ nhớ nhanh giúp giải quyết các vấn đề về bảo mật, siêu dữ liệu, giao dịch và tối ưu hóa truy vấn (hiển thị trong hình minh họa bên trái).
Khối thứ hai là tập hợp các cụm tính toán ảo để tính toán (trong hình minh họa có tập hợp các vòng tròn màu xanh).
Khối thứ ba là hệ thống lưu trữ dữ liệu dựa trên S3. S3 là bộ lưu trữ đối tượng không thứ nguyên trong AWS, giống như Dropbox không thứ nguyên dành cho doanh nghiệp.
Hãy xem Snowflake hoạt động như thế nào, giả sử có một khởi đầu lạnh lùng. Tức là có cơ sở dữ liệu, dữ liệu được tải vào đó, không có truy vấn nào đang chạy. Theo đó, nếu không có yêu cầu nào tới cơ sở dữ liệu thì chúng tôi đã nâng cấp dịch vụ Siêu dữ liệu nhanh trong bộ nhớ (khối đầu tiên). Và chúng tôi có bộ lưu trữ S3, nơi lưu trữ dữ liệu dạng bảng, được chia thành các phân vùng vi mô. Để đơn giản: nếu bảng chứa các giao dịch thì các phân vùng vi mô là ngày thực hiện các giao dịch. Mỗi ngày là một phân vùng riêng, một file riêng. Và khi cơ sở dữ liệu hoạt động ở chế độ này, bạn chỉ phải trả tiền cho dung lượng mà dữ liệu chiếm giữ. Hơn nữa, tỷ lệ mỗi chỗ ngồi rất thấp (đặc biệt có tính đến lực nén đáng kể). Dịch vụ siêu dữ liệu cũng hoạt động liên tục nhưng bạn không cần nhiều tài nguyên để tối ưu hóa các truy vấn và dịch vụ này có thể được coi là phần mềm chia sẻ.
Bây giờ hãy tưởng tượng rằng một người dùng đã truy cập cơ sở dữ liệu của chúng tôi và gửi một truy vấn SQL. Truy vấn SQL ngay lập tức được gửi đến dịch vụ Siêu dữ liệu để xử lý. Theo đó, khi nhận được yêu cầu, dịch vụ này sẽ phân tích yêu cầu, dữ liệu có sẵn, quyền của người dùng và nếu mọi việc đều ổn, sẽ lập kế hoạch xử lý yêu cầu.
Tiếp theo, dịch vụ sẽ bắt đầu khởi chạy cụm máy tính. Cụm máy tính là một cụm máy chủ thực hiện các phép tính. Nghĩa là, đây là một cụm có thể chứa 1 máy chủ, 2 máy chủ, 4, 8, 16, 32 - bao nhiêu tùy thích. Bạn đưa ra một yêu cầu và quá trình khởi chạy cụm này ngay lập tức bắt đầu. Nó thực sự mất vài giây.
Tiếp theo, sau khi cụm đã khởi động, các phân vùng vi mô cần thiết để xử lý yêu cầu của bạn sẽ bắt đầu được sao chép vào cụm từ S3. Nghĩa là, hãy tưởng tượng rằng để thực hiện một truy vấn SQL, bạn cần hai phân vùng từ một bảng và một phân vùng từ bảng thứ hai. Trong trường hợp này, chỉ có ba phân vùng cần thiết sẽ được sao chép vào cụm chứ không phải tất cả các bảng. Đó là lý do tại sao, và chính xác là vì mọi thứ đều nằm trong một trung tâm dữ liệu và được kết nối bằng các kênh rất nhanh, nên toàn bộ quá trình truyền tải diễn ra rất nhanh: tính bằng giây, rất hiếm khi tính bằng phút, trừ khi chúng ta đang nói về một số yêu cầu khủng khiếp . Theo đó, các phân vùng vi mô được sao chép vào cụm máy tính và sau khi hoàn thành, truy vấn SQL sẽ được thực thi trên cụm máy tính này. Kết quả của yêu cầu này có thể là một dòng, nhiều dòng hoặc một bảng - chúng được gửi ra bên ngoài tới người dùng để họ có thể tải xuống, hiển thị nó trong công cụ BI của mình hoặc sử dụng nó theo cách khác.
Mỗi truy vấn SQL không chỉ có thể đọc tổng hợp từ dữ liệu được tải trước đó mà còn có thể tải/tạo dữ liệu mới trong cơ sở dữ liệu. Nghĩa là, nó có thể là một truy vấn, chẳng hạn như chèn các bản ghi mới vào một bảng khác, dẫn đến sự xuất hiện của một phân vùng mới trên cụm máy tính, do đó, phân vùng này sẽ tự động được lưu trong một bộ lưu trữ S3.
Kịch bản được mô tả ở trên, từ khi người dùng đến đến khởi tạo cụm, tải dữ liệu, thực hiện truy vấn, lấy kết quả, được trả theo mức cho số phút sử dụng cụm điện toán ảo nâng cao, kho ảo. Mức giá thay đổi tùy thuộc vào vùng AWS và quy mô cụm, nhưng trung bình là vài đô la mỗi giờ. Cụm 16 máy đắt gấp đôi cụm 32 máy, cụm 5 máy vẫn đắt gấp đôi. Có sẵn các tùy chọn 10, XNUMX máy, tùy thuộc vào độ phức tạp của yêu cầu. Nhưng bạn chỉ trả tiền cho những phút đó khi cụm thực sự chạy, vì khi không có yêu cầu nào, bạn sẽ bỏ tay ra và sau XNUMX-XNUMX phút chờ đợi (một tham số có thể định cấu hình), nó sẽ tự tắt, giải phóng tài nguyên và trở nên tự do.
Một kịch bản hoàn toàn thực tế là khi bạn gửi một yêu cầu, cụm này bật lên, nói một cách tương đối, trong một phút, nó đếm thêm một phút nữa, sau đó là năm phút để tắt và cuối cùng bạn phải trả tiền cho bảy phút hoạt động của cụm này, và không phải trong nhiều tháng và nhiều năm.
Kịch bản đầu tiên được mô tả bằng cách sử dụng Snowflake trong cài đặt một người dùng. Bây giờ hãy tưởng tượng rằng có nhiều người dùng, điều này gần với kịch bản thực tế hơn.
Giả sử chúng tôi có rất nhiều nhà phân tích và báo cáo Tableau liên tục tấn công cơ sở dữ liệu của chúng tôi bằng một số lượng lớn các truy vấn SQL phân tích đơn giản.
Ngoài ra, giả sử rằng chúng ta có các Nhà khoa học dữ liệu đầy sáng tạo, những người đang cố gắng làm những điều khổng lồ với dữ liệu, hoạt động với hàng chục Terabyte, phân tích hàng tỷ nghìn tỷ hàng dữ liệu.
Đối với hai loại khối lượng công việc được mô tả ở trên, Snowflake cho phép bạn nâng cao một số cụm điện toán độc lập có công suất khác nhau. Hơn nữa, các cụm điện toán này hoạt động độc lập nhưng có chung dữ liệu nhất quán.
Đối với số lượng lớn truy vấn đơn giản, bạn có thể tạo 2-3 cụm nhỏ, mỗi cụm khoảng 2 máy. Hành vi này có thể được thực hiện, trong số những thứ khác, bằng cách sử dụng cài đặt tự động. Vì vậy bạn nói, “Bông tuyết, hãy trồng một cụm nhỏ. Nếu tải trên nó tăng lên trên một tham số nhất định, hãy tăng thứ hai, thứ ba tương tự. Khi gánh nặng bắt đầu giảm bớt, hãy dập tắt phần dư thừa.” Vì vậy, dù có bao nhiêu nhà phân tích đến và bắt đầu xem báo cáo thì mọi người đều có đủ nguồn lực.
Đồng thời, nếu các nhà phân tích ngủ quên và không ai xem báo cáo, các cụm có thể hoàn toàn chìm trong bóng tối và bạn ngừng trả tiền cho chúng.
Đồng thời, đối với các truy vấn nặng (từ Nhà khoa học dữ liệu), bạn có thể tạo một cụm rất lớn cho 32 máy. Cụm này cũng sẽ chỉ được thanh toán cho những phút và giờ khi yêu cầu khổng lồ của bạn đang chạy ở đó.
Cơ hội được mô tả ở trên cho phép bạn chia không chỉ 2 mà còn chia nhiều loại khối lượng công việc hơn thành các cụm (ETL, giám sát, cụ thể hóa báo cáo,...).
Hãy tóm tắt Bông tuyết. Cơ sở kết hợp một ý tưởng hay và cách thực hiện khả thi. Tại ManyChat, chúng tôi sử dụng Snowflake để phân tích tất cả dữ liệu chúng tôi có. Chúng tôi không có ba cụm như trong ví dụ mà có từ 5 đến 9 cụm có kích thước khác nhau. Chúng tôi có 16 máy thông thường, 2 máy và cả máy 1 máy siêu nhỏ cho một số nhiệm vụ. Họ phân phối tải thành công và cho phép chúng tôi tiết kiệm rất nhiều.
Cơ sở dữ liệu đã cân chỉnh thành công tải đọc và ghi. Đây là một sự khác biệt rất lớn và một bước đột phá lớn so với cùng loại “Aurora”, chỉ mang tải đọc. Snowflake cho phép bạn mở rộng quy mô khối lượng công việc viết của mình với các cụm điện toán này. Nghĩa là, như tôi đã đề cập, chúng tôi sử dụng một số cụm trong ManyChat, các cụm nhỏ và siêu nhỏ chủ yếu được sử dụng cho ETL, để tải dữ liệu. Và các nhà phân tích đã sống trên các cụm trung bình, hoàn toàn không bị ảnh hưởng bởi tải ETL nên họ làm việc rất nhanh.
Theo đó, cơ sở dữ liệu rất phù hợp cho các tác vụ OLAP. Tuy nhiên, thật không may, nó vẫn chưa được áp dụng cho khối lượng công việc OLTP. Thứ nhất, cơ sở dữ liệu này có tính chất cột, với tất cả các hậu quả tiếp theo. Thứ hai, bản thân cách tiếp cận, khi đối với mỗi yêu cầu, nếu cần, bạn sẽ nâng cao một cụm máy tính và tràn ngập dữ liệu vào đó, thật không may, vẫn chưa đủ nhanh để tải OLTP. Chờ vài giây cho các tác vụ OLAP là bình thường, nhưng đối với các tác vụ OLTP thì điều đó là không thể chấp nhận được; 100 ms sẽ tốt hơn hoặc 10 ms thậm chí còn tốt hơn.
Tổng
Cơ sở dữ liệu không có máy chủ có thể thực hiện được bằng cách chia cơ sở dữ liệu thành các phần Không trạng thái và Có trạng thái. Bạn có thể nhận thấy rằng trong tất cả các ví dụ trên, phần Stateful nói một cách tương đối là lưu trữ các phân vùng vi mô trong S3 và Stateless là trình tối ưu hóa, làm việc với siêu dữ liệu, xử lý các vấn đề bảo mật có thể phát sinh dưới dạng các dịch vụ Stateless nhẹ độc lập.
Việc thực thi các truy vấn SQL cũng có thể được coi là các dịch vụ trạng thái nhẹ có thể bật lên ở chế độ không có máy chủ, như cụm điện toán Snowflake, chỉ tải xuống dữ liệu cần thiết, thực hiện truy vấn và “ra ngoài”.
Cơ sở dữ liệu cấp độ sản xuất không có máy chủ đã có sẵn để sử dụng và chúng đang hoạt động. Các cơ sở dữ liệu không có máy chủ này đã sẵn sàng để xử lý các tác vụ OLAP. Thật không may, đối với các tác vụ OLTP, chúng được sử dụng... với nhiều sắc thái khác nhau vì có những hạn chế. Một mặt, đây là một điểm trừ. Nhưng mặt khác, đây là một cơ hội. Có lẽ một trong những độc giả sẽ tìm ra cách làm cho cơ sở dữ liệu OLTP hoàn toàn không có máy chủ, không có những hạn chế của Aurora.
Tôi hy vọng bạn thấy nó thú vị. Không có máy chủ là tương lai :)
Nguồn: www.habr.com