That is minimal vs the performance / latency issue you called out, which is why Iβm suggesting you re-think your key design. Batch reads are not a panacea.
the use case is, i have a request that requires several megabytes of data from a postgresql database. i cache as much as i can in the worker memory, but for a fresh worker, i have to get all that data out of postgres.
i have 1 query that tells me all the keys that have new data (something like last updated timestamp), and then another query that gets the new data for all the keys that have seen updates.
my postgres database started getting bandwidth throttled (blue line) because of the workers fetching so much data from it. so i started storing the data for each key + last updated in kv and fetch from kv first
the batch endpoint will definitely speed things up and separately i think it's also not great that multiple requests will simultaneously update the cache
Is it normal for put() to take several minutes? I executed it with seemingly no errors or issues maybe 5 minutes ago or so and they still don't show up on the cloudflare dashboard
I would normally agree with you, but KV is designed to handle blobs up to 25MiB and will be a fair bit faster than R2 if you do (and more expensive so depends on priorities I guess)
True! In my head I always avoid putting files in any database/kv store because then my code has to deal with retrieving, potentially decoding and then serving it up instead of offloading it to the/a static file CDN (although you might still want a worker for generating a signed S3 URL).
There wonβt be any βAPIβ changes - βKV 2.0β was only a name folks really used here. Weβre working on the underlying storage improvements but I think β2.0β implies breaking changes / a migration / etc, which isnβt the case (and would be painful).
To expand on Mattβs message and to eliminate any confusion, βKV 2.0β wasnβt really a name just used here. The primary architect behind it tweeted about it, and it was on the beta signups at bare minimum.
I do agree that 2.0 is probably a bad name to describe underlying changes that will improve things but incur no breaking behaviour for end-users, but thatβs not really whatβs being discussed.
The initial changes were rolled back after KV experienced a large number of sequential incidents around the changes, and it was decided that was enough was enough. You can read the details of that here: https://blog.cloudflare.com/workers-kv-restoring-reliability
As for when to expect those changes again, or other underlying storage improvements, thereβs no public info here, but I imagine any updates will be shared here and on the blog when ready. Hopefully weβll hear something in the new year!
is it faster to retrive the KV data thru binding or thru rest api?
and how long usually it takes, to retrive data thru binding? I tried it myself, and I got 200+ ms it's slower than getting the data from another endpoint hosted in aws EC2(70ms) the size of the data is the same
API goes back to core, which is either US West/EU or just US West, not sure but eitherway not optimal. Using a worker is much better as its the local dc. Still though, KV's main benefit is cache. First request may be slow, espec if you're far away from one of the two central stores in us/eu, but future requests should be cached https://developers.cloudflare.com/kv/learning/how-kv-works/
KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflareβs β¦
thanks guys @celestial @Chaika @MattD | WorkersKV,Queues I will try again with warm request and compare it to api hosted in my ec2. hopefully, it can manage to be faster.
thank you I initially plan to use postgre for this, but just want to try if worker KV can do this too. D1, is no for a moment, cause it's still in beta, and I am the only developer so no time if I had to refactor my code if somehow the realease version of D1 is dramatically different than the beta
There is https://developers.cloudflare.com/workers/platform/storage-options/ KV is better for read heavy work loads and is eventually consistent, which means a write from one DC can take time before reaching a different one. DO are strongly consistent and do transactional storage so they are better if you need to share the same data across the globe. Also depending on your data then D1 is also an option
You're in the #kv channel, I feel like #durable-objects would fit better here. Durable objects are serverless. There are no non-serverless durable objects, at least not that Cloudflare offers.