These are possible future directions for Cassandra Storage Engine. This is mostly brainstorming, nobody has committed to implementing this.
Unlike MySQL/MariaDB, Cassandra is not suitable for transaction processing. (the only limited scenario that they handle well is append-only databases)
Instead, they focus on ability to deliver real-time analytics. This is achieved via the following combination:
In other words, Cassandra encourages creation/use of materialized VIEWs. Having lots of materialized VIEWs makes updates expensive, but their low cost and non-conflicting nature should offset that.
How does one use Cassandra together with an SQL database? I can think of these use cases:
As an example, one can think of a web shop, which provides real-time peeks into analytics data, like amazon's "people who looked at this item, also looked at ..." , or "*today*'s best sellers in this category are ...", etc
Generally, CQL (Cassandra Query Language) allows to query Cassandra's data in an SQL-like fashion.
Access through a storage engine will additionally allow:
Suppose, all of the system's data is actually stored in an OLTP SQL database.
Cassandra is only used as an accelerator for analytical queries. Cassandra won't allow arbitrary, ad-hoc dss-type queries, it will require the DBA to create and maintain appropriate column families (however, it is supposed to give a nearly-instant answers to analytics-type questions).
Tasks that currently have no apparent solutions:
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.