Elasticity (data store)

From HandWiki
Revision as of 13:10, 24 October 2022 by Wikisleeper (talk | contribs) (linkage)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The elasticity of a data store relates to the flexibility of its data model and clustering capabilities. The greater the number of data model changes that can be tolerated, and the more easily the clustering can be managed, the more elastic the data store is considered to be.[1]

Types

Clustering elasticity

Clustering elasticity is the ease of adding or removing nodes from the distributed data store. Usually, this is a difficult and delicate task to be done by an expert in a relational database system. Some NoSQL data stores, like Apache Cassandra have an easy solution, and a node can be added/removed with a few changes in the properties and by adding specifying at least one seed.[1]

Data-modelling elasticity

Relational databases are most often very inelastic, as they have a predefined data model that can only be adapted through redesign. Most NoSQL data stores, however, do not have a fixed schema. Each row can have a different number and even different type of columns. Concerning the data store, modifications in the schema are no problem. This makes this kind of data stores more elastic concerning the data model.[1] The drawback is that the programmer has to take into account that the data model may change over time.

References

  1. 1.0 1.1 1.2 "Let’s play with Cassandra… (Part 1/3)". OCTO Talk!. http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13/. Retrieved 2011-03-23. "Elasticity “Cassandra is liquid” would have written any marketer and [...] a lot of NoSQL solutions have been built upon this DNA. First of all, elasticity is at the data modeling level. Your data will live longer than your business rules and softness in the way your data schemas can evolve across the time is an interesting point. But elasticity is also about infrastructure and cluster sizing. Adding a new node to Cassandra is simple. Just turn on the AutoBootstrap property and specify at least one Seed of the current cluster. The node will hence be detected, added to the cluster and the data will be relocated (the needed time depends on the amount of data to transfer). Decommissioning a node is almost as simple as adding a node except you need to use the nodetool utility (which provides more options to visualize the streams between the nodes…) or a JMX command." 

See also