On 5 June 2018 at 17:14, MauMau <maumau307@gmail.com> wrote:
> Furthermore, an extra hop and double parsing/planning could matter for
> analytic queries, too. For example, SAP HANA boasts of scanning 1
> billion rows in one second. In HANA's scaleout architecture, an
> application can connect to any worker node and the node communicates
> with other nodes only when necessary (there's one special node called
> "master", but it manages the catalog and transactions; it's not an
> extra hop like the coordinator in XL). Vertica is an MPP analytics
> database, but it doesn't have a node like the coordinator, either. To
> achieve maximum performance for real-time queries, the scaleout
> architecture should avoid an extra hop when possible.
Agreed. When possible.
When is it possible?
Two ways I know of are:
1. have pre-knowledge in the client of where data is located
(difficult to scale)
2. you must put data in all places the client can connect to (i.e. multimaster)
Perhaps there are more?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
