Upstash bắt đầu hành trình của mình với sứ mệnh trở thành tùy chọn cơ sở dữ liệu tốt nhất cho các chức năng AWS Lambda của bạn. Trong khi đó, chúng tôi đã phát hiện ra một tùy chọn tuyệt vời khác để xây dựng các chức năng không cần máy chủ của bạn:Cloudflare worker. Đây là một sản phẩm thú vị vì nó hứa hẹn sẽ có độ trễ tốt hơn trên toàn thế giới với chi phí thấp hơn và không bắt đầu nguội. Nhưng nó có nhiều hạn chế khi so sánh với AWS Lambda. Các hạn chế bổ sung làm cho danh sách các tùy chọn cơ sở dữ liệu ngắn hơn. Chúng tôi coi đây là một cơ hội để định vị Upstash như một giải pháp tuyệt vời cho câu hỏi:CF Workers are stateless. Where should I keep my data then?
Thử thách
Khả năng truy cập
Cloudflare Công nhân là một môi trường khép kín hơn. Nó không giống AWS. Bạn không thể thiết lập cơ sở dữ liệu của riêng mình vào cùng một khu vực và truy cập nó qua VPC. Vì vậy, bạn cần truy cập cơ sở dữ liệu của mình từ chức năng Công nhân. Cloudflare worker sử dụng V8 Isolates làm thời gian chạy. Nó không cho phép kết nối TCP. Vì vậy, cơ sở dữ liệu sẽ có thể truy cập được qua HTTP.
Global Replication
Công nhân có lợi thế là được triển khai ở khắp mọi nơi. Mặc dù chức năng của bạn có thể truy cập được với độ trễ thấp từ khắp nơi trên thế giới; bạn không nên dành hàng trăm mili giây để truy cập cơ sở dữ liệu của mình. Cơ sở dữ liệu của bạn phải gần với nơi thực thi chức năng của bạn. Điều này có thể thực hiện được bằng cách sao chép dữ liệu của bạn sang nhiều vùng và lục địa.
Độ trễ thấp
Các nhà phát triển thích các giải pháp điện toán biên vì chúng cung cấp độ trễ thấp ở mọi nơi. Cơ sở dữ liệu không nên là một nút cổ chai. Cơ sở dữ liệu trong bộ nhớ như Redis cung cấp độ trễ dưới mili giây.
Hành trình thăng hoa
API REST
Chúng tôi đã khởi chạy Upstash với hỗ trợ API Redis gốc. Tất cả các ứng dụng Redis đều được hỗ trợ, điều này là hoàn hảo cho các ứng dụng Redis kế thừa. Nhưng ngay sau đó chúng tôi bắt đầu thấy người dùng gặp sự cố kết nối trên các chức năng không có máy chủ. Ngoài ra, nó không thể truy cập được từ Cloudflare worker. Vì vậy, lần đầu tiên chúng tôi triển khai API GraphQL. Nhưng chúng tôi không hài lòng với API GraphQL do chi phí hiệu suất do lớp proxy. Ngoài ra GraphQL không phải là cách dễ nhất để chạy các lệnh Redis. Chúng tôi quyết định xây dựng một máy chủ REST bên trong công cụ cơ sở dữ liệu để giảm thiểu chi phí hiệu suất. Chúng tôi nghĩ REST phù hợp hơn với Redis. Chúng tôi đã khởi chạy API REST và thấy rằng nó khá phổ biến trong số các nhà phát triển muốn truy cập Redis từ Cloudflare worker và Webassembly.
Edge Caching
Nhờ API REST, Người lao động có thể truy cập Upstash nhưng độ trễ không lý tưởng. Một số nhà phát triển đã cố gắng sử dụng bộ nhớ đệm của riêng Cloudflare để lưu vào bộ nhớ cache các phản hồi của Redis. Nhưng đó là một giải pháp phức tạp. Redis chắc đã rất nhanh, vì vậy không cảm thấy thoải mái khi cache Redis ở một nơi khác. Đó là lý do tại sao chúng tôi quyết định xây dựng bộ nhớ đệm cạnh nơi chúng tôi lưu vào bộ nhớ cache phản hồi REST của Redis ở tất cả các vị trí cạnh. Chúng tôi đã sử dụng các nhà cung cấp CDN để lưu vào bộ nhớ cache các phản hồi của Redis. Đây là một cải tiến đáng kể ở độ trễ cạnh, tăng hiệu suất lên đến 80%.
Cơ sở dữ liệu toàn cầu
Bộ nhớ đệm cạnh là một giải pháp tuyệt vời cho vấn đề độ trễ toàn cầu nhưng nó có một số hạn chế đối với một số trường hợp sử dụng. Trước hết, nó không hỗ trợ vô hiệu bộ nhớ cache (thanh lọc). Nếu thời gian hết hạn của bộ nhớ cache là 30 giây; sau đó có một cửa sổ 30 giây nơi khách hàng của bạn có thể đọc dữ liệu cũ. Điều này có thể được chấp nhận bởi nhiều trường hợp sử dụng web nhưng không phải tất cả. Thứ hai, bộ nhớ đệm cạnh chỉ được hỗ trợ cho API REST. Các ứng dụng khách của Redis không thể hưởng lợi từ bộ nhớ đệm cạnh. Vì vậy, chúng tôi quyết định thiết kế một kiểu cơ sở dữ liệu mới sao chép dữ liệu sang nhiều vùng. Rất khó để thiết kế nó có tính khả dụng cao và đủ nhất quán. Hiện tại Upstash có cung cấp cơ sở dữ liệu toàn cầu sao chép dữ liệu của bạn tới 5 khu vực AWS khác nhau (Đông và Tây Bắc Mỹ, Châu Âu, Châu Á, Nam Mỹ). Cơ sở dữ liệu toàn cầu không phải là bộ nhớ cache nên nó không gặp sự cố làm mất hiệu lực bộ nhớ cache. Các bản ghi được sao chép ngay lập tức cho tất cả các bản sao. Vì lợi ích của hiệu suất và tính khả dụng, Cơ sở dữ liệu toàn cầu được thiết kế để cuối cùng nhất quán.
Edge Caching so với Global Database (hoặc cả hai)
Nếu bạn chỉ cần một bộ nhớ đệm cho giải pháp cạnh của mình thì bộ nhớ đệm Edge có thể là một giải pháp tốt. Nhưng nếu bạn cần ghi của mình để làm mất hiệu lực bộ nhớ đệm ngay lập tức, bạn nên thích Cơ sở dữ liệu toàn cầu. Bên cạnh bộ nhớ đệm, Cơ sở dữ liệu toàn cầu có thể được sử dụng như một kho dữ liệu toàn cầu có tính khả dụng cao. Cũng nên nhớ rằng bộ nhớ đệm Edge chỉ khả dụng cho các cuộc gọi REST. Nếu bạn đang sử dụng ứng dụng khách Redis, Cơ sở dữ liệu toàn cầu là tùy chọn duy nhất có độ trễ thấp.
Cả Edge caching và Global database đều được thiết kế để giảm thiểu độ trễ khi đọc. Nếu trường hợp sử dụng của bạn là 90% ghi thì thiết lập một vùng sẽ có ý nghĩa hơn. Các ghi có cùng độ trễ cho cả cơ sở dữ liệu đa vùng và đơn lẻ, nhưng chúng đắt hơn 5 lần trong thiết lập Toàn cầu.
Khi bộ nhớ đệm cạnh được bật, Upstash tìm nạp yêu cầu đầu tiên từ nguồn gốc, sau đó lưu vào bộ nhớ đệm ở cạnh. Nếu điểm gốc không ở gần thì độ trễ sẽ cao. Nếu bạn muốn độ trễ tốt nhất cho mọi trường hợp; bạn có thể sử dụng cả hai bằng cách bật Edge Caching trên Cơ sở dữ liệu toàn cầu.
Xem ứng dụng điểm chuẩn so sánh độ trễ của bộ nhớ đệm cạnh và cơ sở dữ liệu toàn cầu.
Tiếp theo là gì?
Dưới đây là một số điều mà chúng tôi có thể thực hiện để cải thiện Upstash at Edge:
- Độ trễ thấp khi ghi:Hiện tại, Cơ sở dữ liệu toàn cầu được thiết kế để tối ưu hóa độ trễ đọc với một kiến trúc thủ lĩnh duy nhất. Chúng tôi nghĩ rằng điều này bao gồm phần lớn các trường hợp sử dụng. Nhưng tùy thuộc vào phản hồi của bạn và các trường hợp sử dụng mới, chúng tôi có thể làm việc trên một kiến trúc mang lại độ trễ thấp khi ghi cũng như đọc.
- Hỗ trợ của Kafka:Chúng tôi đang có kế hoạch ra mắt Kafka cùng với Redis trong những tuần tới. Kafka sẽ kích hoạt các trường hợp sử dụng mới hiện nay, chẳng hạn như phân tích luồng nhấp chuột hoặc đẩy nhật ký sang kafka từ các chức năng không có máy chủ / cạnh.
Chúng tôi tiếp tục cải thiện và phát triển Upstash được hướng dẫn bởi phản hồi của bạn. Hãy cho chúng tôi biết suy nghĩ của bạn trên Twitter hoặc Discord.