Khoảng 2 tuần trước, chúng tôi đã so sánh hiệu suất và chi phí của Cloudflare KV và Upstash Redis. Lần này chúng ta sẽ xem xét Deno KV, một kho lưu trữ khóa gốc Deno chạy trong mạng biên toàn cầu của họ.
Deno KV có kiến trúc tương tự như Upstash Redis. Cả hai cửa hàng đều có một khu vực chính nơi tất cả các thao tác ghi được gửi đến và sau đó được sao chép sang tất cả các khu vực khác. Quá trình đọc được thực hiện từ khu vực gần nhất với máy khách. Có nhiều điểm khác biệt trong các tính năng sẵn có vì Redis có nhiều tính năng mà KV không có, nhưng hiện tại chúng ta sẽ chỉ tập trung vào các thao tác đọc và ghi đơn giản.
Chúng tôi sẽ tiến hành hai điểm chuẩn khác nhau, cả hai đều sử dụng Deno Deploy để chạy mã. Trong cả hai trường hợp, cửa hàng KV và Redis sẽ kích hoạt tất cả các vùng đọc có sẵn.
- Gọi từ 20 khu vực trên thế giới bằng Planetfall.io.
- Gọi từ một vùng duy nhất có tải cao hơn nhiều.
Sau đó, chúng ta sẽ so sánh kết quả và thảo luận về sự đánh đổi và định giá.
Điểm chuẩn
Đây là cách thiết lập, về cơ bản giống như trên Cloudflare, chỉ được cập nhật để sử dụng Deno KV.
- 1000 phím
- 4 KB - Kích thước dữ liệu 64 KB (ngẫu nhiên)
- TTL 60 giây trên tất cả các phím
- 20 vùng gọi hàm
- ~10 yêu cầu mỗi giây
Tôi đã chọn một không gian phím khá nhỏ để đảm bảo chúng tôi nhận được một số lần truy cập vào bộ nhớ đệm mà không cần phải tăng RPS quá mức.
Mã
Bản thân chức năng này rất đơn giản; nó chỉ đọc từ Redis, đọc từ KV rồi trả về những độ trễ đó để đánh giá sau.
main.tsapp.get("/test", async (c) => {
const key = Math.floor(Math.random() * 1_000).toString()
const minValueSize = 4 * 1024
const maxValueSize = 64 * 1024
const data = randomBytes(minValueSize, maxValueSize)
const ttlSeconds = 60
const beforeRedis = performance.now()
const redisResponse = await fetch(Deno.env.get("UPSTASH_REDIS_REST_URL")!, {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": `Bearer ${Deno.env.get("UPSTASH_REDIS_REST_TOKEN")}`,
},
body: JSON.stringify(["GET", key])
})
const redisLatency = performance.now() - beforeRedis
if (!redisResponse) {
await fetch(Deno.env.get("UPSTASH_REDIS_REST_URL")!, {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": `Bearer ${Deno.env.get("UPSTASH_REDIS_REST_TOKEN")}`,
},
body: JSON.stringify(["SET", key, data, "EX", ttlSeconds])
})
}
const kv = await Deno.openKv();
const beforeKV = performance.now()
const kvResponse = await kv.get([key])
const kvLatency = performance.now() - beforeKV
if (!kvResponse.value) {
const setRes = await kv.set([key], data, { expireIn: ttlSeconds })
console.log({ setRes })
}
return c.json({
redisLatency,
kvLatency,
});
});Kết quả - Độ trễ toàn cầu
Sau 30 phút là có kết quả. Độ trễ đo được ở đây chỉ tính từ chức năng trên Deno Deploy đến cửa hàng, không bao gồm các lượt khứ hồi mạng để gọi chức năng.
Bấm vào hình để xem kích thước đầy đủ
Deno KV chậm hơn đáng kể khi đọc dữ liệu từ KV. Suy nghĩ đầu tiên của tôi là có thể họ không có đủ vùng đọc phân bổ trên toàn cầu. Tại thời điểm đánh giá điểm chuẩn này, họ có gpc-us-east4 , gpc-asia-southeast1 , gcp-europe-west3 , gcp-southamerica-east1 và gcp-us-west2 .
Có lẽ một số lượng đáng kể các yêu cầu cần phải đi qua nhiều khu vực để tìm nạp dữ liệu, điều này giải thích cho độ trễ cao, loại bỏ hiệu quả lợi thế của Deno trong việc kiểm soát cả điện toán và lưu trữ bên trong cùng một đám mây và trung tâm dữ liệu. Mặt khác, Upstash đang chạy trên AWS và tất cả các yêu cầu từ Deno đến Redis đều đi qua biên giới của nhà cung cấp đám mây.
Một vùng
Để kiểm tra lý thuyết này, tôi đã chạy điểm chuẩn thứ hai, trong đó tôi chỉ gọi hàm từ một địa điểm duy nhất (nhà của tôi) và tất cả các yêu cầu đều đi qua Frankfurt. Cả Deno KV và Upstash Redis đều có bản sao đọc ở đó gcp-europe-west3 và eu-central-1 tương ứng cho GCP và AWS.
Bấm vào hình để xem kích thước đầy đủ
Cả hai dịch vụ đều nhanh hơn nhiều trong trường hợp này, nhưng Deno KV vẫn chậm hơn Upstash Redis. Dưới đây là độ trễ cho một khu vực, với độ trễ từ delta đến toàn cầu trong ngoặc đơn:
154 mili giây chắc chắn tốt hơn nhiều so với 494 mili giây, nhưng với giả định rằng tất cả lưu lượng truy cập của tôi đến từ một khu vực duy nhất, điều này đi ngược lại toàn bộ ý tưởng về mạng biên toàn cầu. Nếu đang chạy API toàn cầu, bạn sẽ có lưu lượng truy cập đến từ khắp nơi trên thế giới và mọi yêu cầu cần truy cập vào dữ liệu trong KV sẽ bị chậm lại do điều này.
Giá cả
Cả Deno và Upstash đều tính phí chủ yếu cho việc sử dụng của bạn. Cả hai đều có cấp độ miễn phí tốt nên bạn có thể dùng thử mà không phải trả bất kỳ khoản nào.
Sự khác biệt chính là giá của Deno không minh bạch như tôi mong đợi vì tôi cần biết yêu cầu của mình sẽ lớn đến mức nào để tính toán chi phí. Đây không phải là vấn đề với Upstash vì tất cả các yêu cầu đều được tính phí như nhau. Theo mặc định trên Upstash, bạn có thể đọc hoặc ghi tối đa 1 MB cho mỗi yêu cầu và chúng tôi cho phép bạn tăng mức này với một khoản phí cố định.
Điểm mấu chốt là nếu bạn đang đọc nhiều hơn 8kb cho mỗi yêu cầu thì Upstash rất có thể sẽ rẻ hơn.
Kết luận
Sử dụng Deno KV cho cảm giác khá tốt vì nó hoạt động trên cùng một nền tảng; bạn không cần quản lý một tài khoản riêng và việc sử dụng tài khoản đó không yêu cầu bất kỳ thiết lập bổ sung nào. Tuy nhiên, hiệu suất và chi phí không bằng Upstash. Nó cũng bị hạn chế về những gì bạn có thể làm với nó. Việc thiết lập và nhận các giá trị, mặc dù là những thao tác phổ biến nhất, nhưng không phải là tất cả những gì bạn có thể làm với Redis. Hãy xem các ví dụ của chúng tôi để tìm ra nhiều ý tưởng và cách sử dụng cho Redis.
Hãy đến chào và đặt câu hỏi về bất kỳ vấn đề nào trong số này trong Discord của chúng tôi hoặc trên X.