guys is KV reliable enough for storing account states?
guys is KV reliable enough for storing account states?
IReliable: yes, KV is reliable. However KV is not consistent, changes may take 60 seconds (or longer in case of failure scenarios) to sync across the world.
IThe second point means if you write in one location and then write in another the first write will be overwritten.
TAll the docs are on Github AFAIK; they take PRs.
TBenefit of Astro; you can mix & match frameworks, React for 1 page, Vue for another, SolidJS, MDX, etc...
Ris it ok to use KV for long storage too?
ZSure. It's a bit more expensive than r2 per gb, but yea there's no reason you wouldn't be able to use it for that.
RYou should also consider the data size when storing in KV, the data store has a limit of 10MB per key-value pair.
Ris this still the limit on it ?
ZIt's 25mb, but yes.
ZOh sorry misread your question, no the limit is 25mb.
Iis the following achievable with KV?
if not i would be really grateful if you could suggest a good DB for this.
i was using mongoDB atlas up until now but read speeds are very slow ~1 sec
i desperately need a solution
if not i would be really grateful if you could suggest a good DB for this.
i was using mongoDB atlas up until now but read speeds are very slow ~1 sec
i desperately need a solution
ZHave you checked out #d1-open-alpha ? That might be exactly what you're looking for
ID1 was exactly what i needed. thanks.
Ii did not know cloudflare had sql db
ZIt's currently still in Alpha. If you can work with the size limit and can accept the increased latency, it's perfectly usable for hobby projects right now (imo).
Iwhat is the approx latency?
Ithat should do. thanks!
T"Back in my day, 1 second was FAST!"
If you only wanted to query by name, then just put the name as the first few characters at the 'key'. But since you need complex queries, then yea SQL or a tuned NoSQL to do that.
Other options are SupaBase, or a Graph db if you need relations.
If you only wanted to query by name, then just put the name as the first few characters at the 'key'. But since you need complex queries, then yea SQL or a tuned NoSQL to do that.
Other options are SupaBase, or a Graph db if you need relations.
KRemove the
awaitctx.waitUntilKNo idea if it is that, but it's unnecessary
KwaitUntilawait.put before the result is passed to waitUntilSpecifically with regards to
waitUntilWithout
waitUntilawaitBut w/ waitUntil, just give it a Promise as-is
TIs it recommended for an app to use several kv Namespaces/buckets for different types of data (since I'm using several different workers for different views), or just keep it all in 1 bucket, but make the key a bit longer by adding a flag to the key start?
I'm leaning towards separate, but I'd like to hear from those who tried both.
I'm leaning towards separate, but I'd like to hear from those who tried both.
TAlso, what characters are legal in Keys please?
JI'd say it really comes down to preferences vs "best". I personally use buckets as grouping tools:
- user_profile_photos
- user_files
- etc
Tthanks
Yes I was thinking to use buckets as 'grouping' also. OK to use several buckets in the same Worker script?
Yes I was thinking to use buckets as 'grouping' also. OK to use several buckets in the same Worker script?
Eseveral buckets is fine, they'll need their own bindings each
PI believe I read in the docs (and indeed confirmed here) that once something is saved to KV for the first time, anyone from any region should be able to retrieve that object - is that true?
As I understand it, the limitation (eventually consistent) is that updates may take awhile to propagate.
Is that just for updates, or also for the initial value when it's first created?
I'm seeing situations where customers from other regions hit my endpoint and the KV lookup returns nothing, but if I have them a few minutes later, they can access the object as expected.
What gives?
As I understand it, the limitation (eventually consistent) is that updates may take awhile to propagate.
Is that just for updates, or also for the initial value when it's first created?
I'm seeing situations where customers from other regions hit my endpoint and the KV lookup returns nothing, but if I have them a few minutes later, they can access the object as expected.
What gives?
KEventual consistency is because the minimum amount of time a value is cached on the edge is 60 seconds.
KIf I read from KV in PoP A, that value is cached in PoP A for a minimum of 60 seconds.
20 seconds pass.
If I write to KV in PoP B, that is cached in PoP B and persisted to the central KV stores.
20 seconds pass.
Reads in PoP A will still show the old value, as it is still cached in PoP A - and reads from PoP B or PoP
20 seconds pass.
If I write to KV in PoP B, that is cached in PoP B and persisted to the central KV stores.
20 seconds pass.
Reads in PoP A will still show the old value, as it is still cached in PoP A - and reads from PoP B or PoP
nThere is no propagation with updates - KV is pull-based, not push-based.
KI'm seeing situations where customers from other regions hit my endpoint and the KV lookup returns nothing, but if I have them a few minutes later, they can access the object as expected.
Reads that indicate the key does not exist are also cached for the minimum amount of time.
PI see, thank you for the reply.
According to: https://developers.cloudflare.com/workers/learning/how-kv-works/
In my case, I write my value to KV, take the uuid I assigned to it and send it back to the recipient - the recipient then sends that uuid directly to the consumer, who reaches out to a workers endpoint that retrieves that uuid from KV
That should be an initial read, right?
My application can't have a situation where someone tries to read the value from KV beforeit's actually saved the writer request completes
According to: https://developers.cloudflare.com/workers/learning/how-kv-works/
Initial reads from a location do not have a cached value. The data must be read from the nearest central data store, resulting in a slower response.
In my case, I write my value to KV, take the uuid I assigned to it and send it back to the recipient - the recipient then sends that uuid directly to the consumer, who reaches out to a workers endpoint that retrieves that uuid from KV
That should be an initial read, right?
My application can't have a situation where someone tries to read the value from KV before
THow will 'someone else' know the correct key if the the write did not complete?
PActually that's a great way to demonstrate my point; they can't
The key is generated in the POST request that saves the value to KV, so it's not possible for someone to GET that same key before the save has completed
The key is generated in the POST request that saves the value to KV, so it's not possible for someone to GET that same key before the save has completed
PPOST -> workers -> uuid generated -> save body to KV with the UUID as the key -> respond with
then, we send the UUID to the consumer, who does something like:
GET -> workers -> request the UUID from KV
200, <key/uuid>then, we send the UUID to the consumer, who does something like:
GET -> workers -> request the UUID from KV
TFor what I'm building now, people can guess the key sometimes. But IDK; I'm just pushing KV's boundries to test, & will likely refactor later to something else IF I get early customers.
PI'm starting to think this is a bug with KV - logs don't show the very first GET returning a 404
KDo you have code to reproduce it?