I feel like it's an awful idea for the next reasons: 1. You completely kill any chance of data analytics based on db queries - you have to move all the data you need to the logs 2. In a containerized world, the footprint needs to be small, the in memory model couldn't keep years of data in memory without a big overhead. 3. A database can handle multiple connections, our containers that load up in memory would be isolated, if they're not isolated and it's a common persistence layer, how will it handle reads and writes? What about ACID principles that you learn in faculty? Are there any people that use these and we can get some data, case study, FAQ?
1. It doesn't kill data analytics, he mentioned it can be combined with common practices. 2. Solutions is either to archive it or use a long-term storage, both can be applied without the installation of a Database. (Disk management). You are right it might be a problem to some applications. 3. Shared memory synchronization or locking of some data, what he talks about is more the serialization part - the ability to store objects. In either way there are good solutions for that. We use this kind of in-memory solutions mainly for caching or keeping up local copies. "Multiple connections" are a problem to DBs as well, we had ton of issues because of multiple connections. Nothing is a silver bullet, sometimes the cost of a DB exceeds the need of a real DB. 1 TB harddrives aren't expensive, and you can keep in memory + Paged + Synced files for you applications as long as they are small. Conventionally - scaling it is much harder and better solutions exist for scale. Another term to think about is the design process - Too many products are designing around a DB instead of focus on business solution - leaving SQL everywhere and data classes which match the DB architecture. Ultimately coupling itself into the DB. Your App is not your DB.
@@TNothingFree I think you complete missunderstood the goal of a sql or nosql database. There is lot of stuff there. Multi tendandcy User and userright management ACID Multi data regions Data history tracking Data indexining The goal of an approach like microstream does can be well fit for comuptation models or level2 caching for example. But it wil be never ever replace a database. Until you make all your apis serialisable 😀
Another awesome and inspirational talk from Rudy ...
I feel like it's an awful idea for the next reasons:
1. You completely kill any chance of data analytics based on db queries - you have to move all the data you need to the logs
2. In a containerized world, the footprint needs to be small, the in memory model couldn't keep years of data in memory without a big overhead.
3. A database can handle multiple connections, our containers that load up in memory would be isolated, if they're not isolated and it's a common persistence layer, how will it handle reads and writes? What about ACID principles that you learn in faculty?
Are there any people that use these and we can get some data, case study, FAQ?
1. It doesn't kill data analytics, he mentioned it can be combined with common practices.
2. Solutions is either to archive it or use a long-term storage, both can be applied without the installation of a Database. (Disk management).
You are right it might be a problem to some applications.
3. Shared memory synchronization or locking of some data, what he talks about is more the serialization part - the ability to store objects.
In either way there are good solutions for that.
We use this kind of in-memory solutions mainly for caching or keeping up local copies.
"Multiple connections" are a problem to DBs as well, we had ton of issues because of multiple connections.
Nothing is a silver bullet, sometimes the cost of a DB exceeds the need of a real DB.
1 TB harddrives aren't expensive, and you can keep in memory + Paged + Synced files for you applications as long as they are small.
Conventionally - scaling it is much harder and better solutions exist for scale.
Another term to think about is the design process -
Too many products are designing around a DB instead of focus on business solution - leaving SQL everywhere and data classes which match the DB architecture.
Ultimately coupling itself into the DB.
Your App is not your DB.
@@TNothingFree
I think you complete missunderstood the goal of a sql or nosql database.
There is lot of stuff there.
Multi tendandcy
User and userright management
ACID
Multi data regions
Data history tracking
Data indexining
The goal of an approach like microstream does can be well fit for comuptation models or level2 caching for example.
But it wil be never ever replace a database.
Until you make all your apis serialisable 😀
Interesting. Excited to know how it will scale
We used to have a similar thing: Netflix hollow. Let's forget about it, and never let it out again.
This is interesting