Regatta elasticity in more detail

Elasticity in Regatta means that you can change almost all your configuration rules and settings, including for example schema definitions, partitioning rules, data placement rules, and node configurations. Regatta consequently executes the necessary actions to transform the configuration smoothly and non-disruptively.

Suppose a large table is defined to be distributed across a pool of nodes. You decide to add a node to that pool. As a result, Regatta will non-disruptively migrate some of the existing table rows to the new node, thus rebalancing the table across the node-pool. Similarly, you could instruct to remove a certain node, add or remove disks to/from a pool, and rows would non-disruptively migrate accordingly.

Unlike databases that rely on manual sharding, Regatta can automatically kick-off rebalancing operations whenever the cluster’s data distribution becomes too unbalanced and risks surpassing available capacity or hurting performance. For example, Regatta may choose to move a partition that may have outgrown its node out of that node, to split the increased partition and to move some of its fragments out of the node, and so forth.

Furthermore, with Regatta developers can define horizontal partitioning criteria that keeps certain data rows together in partitions, whose locations are determined by the placement rules. For example, a Trades table may be partitioned by the table’s User_ID field. According to the table’s partition placement rule, partitions associated with users that have a Paying-User indication in the associated Users table must be placed on fast flash media while the Free-User partitions should be placed on slower magnetic disks. If a transaction changes a user’s status from Free-User to Paying-User, Regatta will automatically and non-disruptively move the user’s related partition from the magnetic to the flash pool.

Realizing the type of above-mentioned Total Elasticity capabilities is challenging. Truly non-disruptive elasticity requires transactions and queries to execute in an uninterrupted manner even if the data that they are addressing is moving “below the surface” at the same time. Regatta realizes Total Elasticity while guaranteeing minimal impact to the ongoing transactions and queries.

Regatta’s Total Elasticity eliminates the need for careful capacity planning in advance. Instead, Regatta allows you to start with your “best guess” configuration and to fine-tune later, according to changes in workload.

In addition, Total Elasticity enables application developers to focus on business logic only, by eliminating the need to deal with challenges – like changes in data locations, node capacity overflow failures, cluster performance challenges, and so forth – in the application code.

Schemas in many relational databases are rigid. Changing schema definitions is often disruptive and often requires large and lengthy data reformatting. In Regatta, changing schemas is easy and completely non-disruptive.

< Back to blog

Sign up for the newsletter

    Thanks for subscribing!

    You’re already a subscriber – thank you!

    Latest Blogs

    Is dev/database hate inevitable?

    Commonly one of the first things one does when learning a new language and using a new framework is to build a basic…

    Sharding – some dirty little secrets

    An examination of the dirty secrets of sharding (and some pseudo-distributed database systems)

    What goes around, indeed.

    In June, Michael Stonebreaker and Andy Pavlo published a whitepaper that really hit home for me. Suggestion: take a…

    The art and science of scaling out a transactional relational database

    Why are we talking about this? Relational transactional database systems provide data with rich functionality and strong…
    Showing 1-3 of 8 articles
    Skip to content