Is there a thread that I missed somewhere?
Is there a thread that I missed somewhere?
BUggh. Maybe I didn't do it right. Let me figure out Discord
DSupport for assets > 25 MiB in KV
OMG YES I NEED THIS
Neat
I need you to fix something else (please specify)Poll by beelzabub#0369
•2/24/23, 8:20 PM
BI replied in more detail, but TLDR it should be some amount of both. "cold" is even more complicated to discuss without describing what changes we made.
Sis there anyway to gzip/br json content before storing to kv and then decode on get?
KWorkers implements https://developer.mozilla.org/en-US/docs/Web/API/CompressionStream and https://developer.mozilla.org/en-US/docs/Web/API/DecompressionStream but those are things you'd have use with your own wrapper around KV - KV itself doesn't have any (de)compression options
UWrites have to go to central storage so yes thats normal
ZCache hits count has reads, so I would expect you to see 20 reads.
ZI believe so
JI request to Make a Realtime Key-Value storage model, like Firebase real-time database.
BFor KV, requests for the same key are satisfied within milliseconds and it doesn't matter where in the world you access this from. My understanding is that real-time databases have access time measured in hundreds of milliseconds and requests from other parts of the world are slower. Real time databases are great tech, but it's not comparable to the kind of storage KV offers (totally different pricing, totally different usage patterns optimized for, totally different invariants in terms of API).
If you can use KV, I think you'll see more value out of KV (cheaper & faster). It won't be suitable for every problem so YMMV. R2 is strongly consistent like firebase and will be cheaper than firebase, but it won't offer the database-like features if you need them (e.g. transactions).
It can sometimes be more helpful to describe your use-case @Jadugar_Jaggu rather than asking for a specific product. If you can help me understand the problem you're using a realtime database to solve for, it's possible there are other ways to accomplish that. If you're looking for a drop in replacement for Firebase, I don't think CF has anything like that at this time to talk about.
If you can use KV, I think you'll see more value out of KV (cheaper & faster). It won't be suitable for every problem so YMMV. R2 is strongly consistent like firebase and will be cheaper than firebase, but it won't offer the database-like features if you need them (e.g. transactions).
It can sometimes be more helpful to describe your use-case @Jadugar_Jaggu rather than asking for a specific product. If you can help me understand the problem you're using a realtime database to solve for, it's possible there are other ways to accomplish that. If you're looking for a drop in replacement for Firebase, I don't think CF has anything like that at this time to talk about.
JI am using KV on my service which has a total of 15 million traffic per month, It is working well, and Seriously KV helps me to achieve a 60% Profit margin from my business by lowering the various servers and management costs.
I am a KV user for 9 months approx
Now I was thinking of making a realtime application like you know about Trading and Fantasy Sports apps in which a large number of users perform action simultaneously.
I am a KV user for 9 months approx
Now I was thinking of making a realtime application like you know about Trading and Fantasy Sports apps in which a large number of users perform action simultaneously.
JThats Why I just requested if KV can be helpful in realtime database model it can save lots of expenses
JAnd Seriously I don't want to know how Cloudflare manages to lower the costs while delivering good performance, I just enjoy the profits 
AI think for real time, you need durable objects. See this video https://www.youtube.com/watch?v=Frqy7jqnjZs
YouTubeChangelog
From the "JS Party" podcast. More 
https://jsparty.fm/209
Subscribe for more!
Apple: https://jsparty.fm/apple
Spotify: https://jsparty.fm/spotify
Android: https://jsparty.fm/android
Overcast: https://jsparty.fm/overcast
Email: https://jsparty.fm/email
Twitter: https://twitter.com/jspartyfm
#js #javascript #webdev #webdevelopment #opensourc...
https://jsparty.fm/209Subscribe for more!
Apple: https://jsparty.fm/apple
Spotify: https://jsparty.fm/spotify
Android: https://jsparty.fm/android
Overcast: https://jsparty.fm/overcast
Email: https://jsparty.fm/email
Twitter: https://twitter.com/jspartyfm
#js #javascript #webdev #webdevelopment #opensourc...
BDO won't be able to keep up with that volume, not without serious sharding.
BIt depends on specifically your data patterns and what your application needs actually are. It's hard to say without learning more about what kind of actions users are performing, what consistency and transaction requirements are, etc.
BOne trick that's use-case dependent is to put the contents into the metadata and then access it with a single
list request. I would still recommend using separate KV requests as they're generally going to be much cheaper, faster, and more intuitive to use. For example, the advantages that KV 2.0 will bring are not available for list because that operation isn't really something that can be optimized.UBatch KV read is still much needed especially when you cannot list because of other access patterns and you want to get more than 6 values (max concurrent requests in workers) 
hopefully 
hopefully 
BThe important bit here is that it's 6 concurrent requests. But if all your values are cached, in practice that's going to not be much slower than with a concurrency of 100. There are some performance bottlenecks so there are reasons why a higher limit would be faster today. However, we're focused on fixing the bottlenecks right now which will make hot reads significantly faster while at the same time should also eliminate the performance advantage of a higher concurrency limit.
Organizing your KV reads along those lines will be more beneficial. Bulk KV read just isn't a thing I can see us supporting anytime soon. There's a similar request for R2 and it's unlikely to happen there either for very similar reasons.
Organizing your KV reads along those lines will be more beneficial. Bulk KV read just isn't a thing I can see us supporting anytime soon. There's a similar request for R2 and it's unlikely to happen there either for very similar reasons.
V
Hey @Workers KV developers, quick reminder, in case you haven't registered for KV 2.0 early beta testing, you can still do it by filling out: https://forms.gle/d1yrVjxpQNFSYYYf6Google Docs
KV 2.0 will be rolling out over the next month or so. Submit interest to get into an early beta before we turn this on globally.
BEveryone will be upgraded to 2.0. It’s backwards and forwards compatible. This is just an opportunity to highlight if we have a bug somewhere / making sure we’re confident in our observability of the system. It all depends on your risk profile.
BThe only thing it can impact really is consistency of reads (if we have some kind of subtle bug) and availability (some kind of subtle interaction at scale)
SWould KV lend itself as a server side cache such as redis in a Worker or should rather something else being used?
HThe Cache API is the best cache(because it is free), but KV is a good alternative if you want the cache to be persistent.
B@sly_de can you elaborate what Redis in a worker means to you? Do you mean from a latency prospective? Volume? Something else?
BYou can request to enroll only certain namespaces.
Once we start the march forward, everyone is going to start getting ramped transparently. The way it works is that we’ll opt in your key space by percentage. Some keys will use 1.0 while others go 2.0. It’s a transparent layer in the middle of KV internals. Think weeks not months. So opting in early is just a way where you’ll have my attention if there’s ANY issue. That becomes different at scale I can’t provide as much white glove support (I still try to but often observability at scale makes it harder to diagnose individual issues)
Once we start the march forward, everyone is going to start getting ramped transparently. The way it works is that we’ll opt in your key space by percentage. Some keys will use 1.0 while others go 2.0. It’s a transparent layer in the middle of KV internals. Think weeks not months. So opting in early is just a way where you’ll have my attention if there’s ANY issue. That becomes different at scale I can’t provide as much white glove support (I still try to but often observability at scale makes it harder to diagnose individual issues)
SLatency - Expensive calculations in third party api to be cached on server for a certain amount of time
DBear in mind that it does not replicate between colos, so you might see "more" misses depending on the distribution of visitors - for which you can use KV as a second option (BetterKV does this in https://flareutils.pages.dev)
BBetterKV is fine in terms of reducing your KV billing cost but I’m not a fan of it and it feels like an artifact of our billing than anything else. Is there any other features it has beyond “cache in front of Kv”?
BWhat’s the latency you need?
DOh absolutely, the main purpose is to remove the cost of cached KV reads, or at least this is what we use it for.
A quote from the website even says
A quote from the website even says
Save on your Workers bill by "manually" caching every response, without having to lift a finger!
BYeah. I hope to take a look at our billing in Q2 to see what actually makes sense. BetterKV feels technically superfluous and a recipe for subtle bugs at scale.
DWe were actually discussing this with @mrbbot (sorry) last week, whether it would make sense (from a user perspective) to only charge for cold/uncached reads - basically make KV Better 
, as now everything would be double-cached to cache at KV-level, and at Worker-level. From what I remember, the argument against was that it would result in less predictable billing, but the counter-argument to that is while less predictable, still bounded by the current number of reads.
, as now everything would be double-cached to cache at KV-level, and at Worker-level. From what I remember, the argument against was that it would result in less predictable billing, but the counter-argument to that is while less predictable, still bounded by the current number of reads.DFrom there (oh you will not like me for this), cache(+pull if stale) reads and force refresh reads could be separated out and billed separately, turning KV into a powerful key-value storage with a different type of push-pull consistency model than what you have today (with KV 2.0).
BI don’t know that the problem is unpredictability. And I don’t hate you because that’s very much along the lines of how I’m thinking about it.
BBut I do want to keep the API as-is and do the billing transparently. So I’m not sure yet what the new pricing would look like. And I also have 0 concrete idea of what that looks like. Once 2.0 rolls out fully I’ll have data to formulate an actual opinion
B- if it was just up to me, you know I like you guys. I’d just 0-rate everyone on here :D.