this is for specific use cases, this is not how "every database in the future would (or should) work", they even outlined that the appropriate data pattern is bulk operations
That's not exactly the case. A database with a distributed write cache implemented via Raft and a local read cache, while storing data in S3, can achieve the same performance as running on SSDs. Of course, at the I/O layer interacting with S3, bulk I/O is definitely preferred.
There will be a lot of read/write operations which ultimately be much costly then previous databases only because of s3 data cost. People will realize this very soon.
Well till now I never really focused that s3 wasn’t appendable but now you just told that it will start supporting append. I got the sense that why our lambda always used to overwrite the files instead of appending reporting data for the current day 😢 Bro please keep posting this content It just makes us good devs 🙌
How would something like search query like search by regex name would work. I personally think, for secondary caching data it may be good, not for primary data. (Get record by user id, get course detail by courses id) on S3. Like per user or course can have per file, on every write operation, update db and then update s3 file from DB. A interface for S3 for it. (Good for application where read are high and write are less).
With the humongous increase in data generation and processing distributed databases have emerged I wonder whats your take on DBs like Yugabyte,CockroachDB who are replicating data across multiple nodes claiming high availability and low latency?
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
this is for specific use cases, this is not how "every database in the future would (or should) work", they even outlined that the appropriate data pattern is bulk operations
That's not exactly the case. A database with a distributed write cache implemented via Raft and a local read cache, while storing data in S3, can achieve the same performance as running on SSDs. Of course, at the I/O layer interacting with S3, bulk I/O is definitely preferred.
There will be a lot of read/write operations which ultimately be much costly then previous databases only because of s3 data cost. People will realize this very soon.
Well till now I never really focused that s3 wasn’t appendable but now you just told that it will start supporting append. I got the sense that why our lambda always used to overwrite the files instead of appending reporting data for the current day 😢 Bro please keep posting this content It just makes us good devs 🙌
Curious on why you shifted to GCP for fermion after running codedamn on AWS.
How would something like search query like search by regex name would work.
I personally think, for secondary caching data it may be good, not for primary data. (Get record by user id, get course detail by courses id) on S3.
Like per user or course can have per file, on every write operation, update db and then update s3 file from DB.
A interface for S3 for it.
(Good for application where read are high and write are less).
Could you make a video about how youtube video downloader work
that might go against youtube tos
With the humongous increase in data generation and processing distributed databases have emerged I wonder whats your take on DBs like Yugabyte,CockroachDB who are replicating data across multiple nodes claiming high availability and low latency?
*This how every database would work in the future
Meanwhile some successful company still rocking MySQL 5.7
No I don’t think every database would work like that. Not in the near future, not ever.