Share This
Google just announced their Beta ‘Cloud Spanner,’ a “horizontally scalable, globally consistent, relational database service.” This impressive hosted technology addresses a long-standing market request: “How can we make our SQL databases scale both writes and reads past a single server?” This is the very important difference between “scale up” and “scale out.” Can adding additional database servers add write scale? Or do those additional servers just add read scale? MySQL “read slaves” (MySQL, MariaDB, Percona, etc), and Amazon Aurora “read replicas” only provide read scale.
Adding additional write scale–once you’ve migrated your database to the biggest server available–usually requires some version of “sharding.” This means your data tables get partitioned across multiple different database servers, i.e., separate RDBMSs. This allows each subset of your data to enjoy the full write and read horsepower of its own server. However, this means cross-partition (“shard”) transactions don’t have a coordinating RDBMS to guarantee ACID and referential integrity. Either your application loses that level of transactional robustness, or your application stack needs to rebuild those guarantees the database (shards) can no longer provide. Finally, data rebalancing across the array of shards is an ongoing maintenance requirement. Many production sharded databases need to schedule periodic downtime to redistribute the data to ensure storage capacity and avoid hotspots.
Click here to read the full blog on Clustrix.com!