Re:Peloton – a relational database designed for autonomous o...
by mamcx on Sunday January 22, 2017 @11:22AM
(#13455792)
Is very rare to have a DB that not need both oltp/olap workloads.
All db-based apps end fast the need requeriments for transactional code and move into "infinity-reporting-requests".
For certain ERP I work on in the past, it have at least 300 reports in the base package. Most request was for more reports specialized for each customers. And additions to the transactional code was in part driven by the need to add more data for the reports!
So, I think have both styles is exactly what "everyone" want. Even folks that get stuck with NOSQL databases.
---
I have thinking very much about this, I consider the ideal architecture is a relational-db with decoupled modules that work like this:
All db-based apps end fast the need requeriments for transactional code and move into "infinity-reporting-requests".
For certain ERP I work on in the past, it have at least 300 reports in the base package. Most request was for more reports specialized for each customers. And additions to the transactional code was in part driven by the need to add more data for the reports!
So, I think have both styles is exactly what "everyone" want. Even folks that get stuck with NOSQL databases.
---
I have thinking very much about this, I consider the ideal architecture is a relational-db with decoupled modules that work like this:
Write:
Commands -> WAL -> WaLProcessorAndRejector -> EventLog -> EventLogDispatchToOneOrMoreOf:
- Nothing. EventLog just is history - Caches - Relational Tables for up-to-date view on data - Columnar/Index for speed up part of the reports
Read:
ReadRequest -> ReadDispatchToOneOf:
- EventLog - Caches - Relational Tables - Columnar/Index
The need to be modular is that what is need can change by need.