You then just need to persist that cache, somewhere using some DB APIs. This process can be done asynchronously, in background.
Obviously, we also need to have some database functionalities around the cache, at least:
- Transaction management.
- Locking mechanisms for concurrency.
- Query engine.
- Metamodel management.
Questions:
- What about crash recovery?
- The cache also requires some kind of logging, like in a database.
- What about triggers, stored procedures?
- Are they managed by the cache, by applications?
- What about security?
- Is that managed by the cache or somewhere else. I tend to agree that security must be managed externally through a dedicated component, and database is definitley not the right place to define security policies.
- What about Referential Integrity?
- Is that managed by the cache or only by the applications?
- What about bulk load and bulk updates?
- What about huge volume of data (hundreds of GB and more)?
- What is the best API between the application and the cache?
- SQL?
- POJO detachment?
- SDO?
- Something else?
- Database engines have built-in caches integrated.
- In this case, why accessing a distributed cache would me significantly much faster than accessing a distributed database engine?
- I remember an old article from TimesTen in the 90's where they said it is more efficient because there is no huge OS code (IO, thread management, etc.) in the cache system, and thus this memory mangement by itself is more efficient.
I really think we need some kind of specific, optimized protocols between the applications and the cache if we want to make this kind of new attractive architectures scalable. Otherwise updating the cache won't be much more efficient than talking to the database server itself.
It would be definitely interesting to think and experiment about the integration of such in-memory persistence interface and a DAS.
No comments:
Post a Comment