However, the challenge with a database cluster
is to build it in a way that all these properties are present at the same time. To be
able to give clients guarantees on both the consistency and the freshness of the data
accessed, we need some sort of coordination between the OLTP and OLAP.
For this reason, we introduce a coordination middleware on top of the cluster that
has complete knowledge about the system state. In particular, both OLTP and OLAP
requests are passing through this coordination middleware: updates are executed
immediately on one or more designated OLTP nodes and their effect is logged, while
queries are routed to one of the OLAP nodes. The system can route queries to only
one OLAP node because we assume that each cluster node holds its own copy of
the database. Hence, we are able to execute several OLAP requests in parallel on
different nodes without any internode communication or expensive distributed joins.
The coordinator further allows those copies to have different freshness, that is, to
represent different database snapshots. It uses those different database versions to
serve OLAP clients faster that agree to access older database snapshots.
Example.1: OLAP with a Database Cluster. All client requests, that is
both OLTP and OLAP workloads, are passing the coordination middleware.
OLTP transactions are immediately forwarded to the OLTP nodes,
and the effects and timestamps of successful updates are logged.
Pages:
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440