This was discussed in the recent webcast on ASE CE with roadmap. Actually, you can read/write data from any node - however, ASE/CE was not designed for horizontal scalability, consequently you get performance degradation in doing so - hence frequent updates/writes from other nodes is not a good idea and not recommended. When looking at it from a horizontal scalability aspect, the first question you really need to ask is "Why do I need horizontal scalability?". There are a variety of reasons that might come up - such as CPU saturation, memory limitation of a single node, etc. However, as I explained in the webcast, these all have underlying issues/solutions that are outside a shared disk clustering - e.g. distribute query processing (DQP)/federated query, data/app partitioning, etc. The most common horizontal scaling sites are those with heavy read intensive situations such as DSS systems - which really gets into DQP but also leveraging columnar store, etc. to minimize the IO bottleneck - which shared disk clusters such as RAC/ASE/DB2 all have (Exadata for example is RAC with MPP for IO to overcome this IO bottleneck). Prior to the acquisition by SAP, SY had a plan for enabling horizontal scalability which largely focused on running in-memory as the IO bottleneck really kills Shared Disk Cluster (SDC) performance overall.....however, with the acquisition by SAP, HANA's architecture already met a lot of the design goals for scale-out - particularly for analytics. Scale-out for OLTP is especially difficult for SDC's as the shared disk become a bottleneck (hence Exadata vs. RAC). Consequently, the plan for ASE/CE is to focus on availability and workload management while HANA focuses on scale-out, particularly for DSS/analytics. That is not to say, however, that we are not planning on features/functions to minimize the overhead of clustering - we are....but that doesn't imply we are working on horizontal scaling (we aren't).
↧