Databases are inherently limited by the capacity of the hardware they run on. Despite these limitations, partitioning offers a way for databases to scale out by splitting the data and putting it on different machines. More machines mean additional resources to manage more requests for more data.
There are two main architectural approaches to partitioning:
- “Shared Nothing” approach - where each partition is handled by just one server. Each node is self-sufficient, and there is no single point of contention across the system. An example of a “shared nothing” database is IBM’s DB2 solution, a partitioned database in which every partition is in charge of only a slice of the database.
- ”Shared Everything” - where the database is not partitioned — all the data is managed by all the nodes in tandem. The worker nodes are identical and each of them can access each piece of data. A notable example of “shared everything” database is Oracle’s commercial solution, RAC.
Partitioning has two major benefits:
- You can scale very effectively for write purposes
- You can easily fetch information from the server if you know how the data is split between different partitions
The Xeround approach to Partitioning:
Xeround offers a Cloud DB for MySQL apps, which is based on a “shared nothing” architecture and wheredata is partitioned spread across numerous servers.
There are two primary challenges with the “shared nothing” approach:
- Sometimes your partitioning scheme needs to change. Let’s say you have a database of Social Security numbers and server A contains SSNs from 1-10,000. If there’s suddenly an influx of people with SSNs in that range the server will become overloaded and you’ll have to introduce a new partitioning scheme. Repartitioning is a major task that involves doing a lot of administrative work and taking down the database, which results in downtime and inaccessibility for users.
- Trying to access data that doesn’t follow the partitioning scheme takes more time and energy. Using the Social Security database example above, let’s say you’re looking for all the people named “Mary” in the database, regardless of their SSN. Because the servers are divided by SSN and not first names, finding everyone named Mary is a trickier task because then all the servers and machines must be scanned using a different criteria.
Xeround circumvents the aforementioned obstacles by introducing virtual partitions as another layer between the hardware and the partition. Xeround’s patented technology allows users to enjoy all the benefits partitioning offers (more scale!) without the burdens of reassigning hardware to data – which means less administrative annoyance and code changes to your apps.
As you scale, your partitioning schema is bound to scale as well and become more complex. Handling its logic and on-going maintenance is a major headache.. :) Good thing this is what we do here at Xerond – allowing you to easily plug in to a DBaaS that’s always-on and supports your changing scalability needs.
Want to go under the hood? Take a look at our Technical Whitepaper for more information on Xeround’s unique technology and architecture.
Register for our Private Beta to experience Xeround MySQL Cloud Database for yourself.
You may also be interested in:
RSS
Email
I like the idea of virtual and flexible partitions but how does that impact indexes?
Excellent question Giorgio, thanks. In a nutshell – we do have indexes and they actually perform very well.
Although our indexes probably merit a post of their own, let me attempt to briefly describe Xeround’s indexing strategy. It is common practice in shared-nothing, partitioned DBMSs to store index data alongside the data that is indexed. The upside of this approach is that it allows for near-trivial index management mechanisms since updates, both of data and of indexes, are carried out solely by the partition’s manager. However, the flipside is that for each use of these partitioned indexes the DBMS has to touch all of its partitions since the partitioning scheme is useless when it comes to locating the indexed values. This results in poor performance of secondary indexes in partitioned DBMSs.
Although Xeround is a partitioned (albeit virtually so) database, we took a slightly different approach to the subject. We like to call it the “Shared Something” approach :) Our indexes are actually also partitioned using a partitioning scheme much like that of data itself. This means that index data for any of the database’s partitions is stored across all of the database’s partitions. While this increases the complexity and robustness of our index management mechanisms, it allows us for extremely efficient use of the indexes as our indexed read basically consists of only two, by-partitioning-scheme read operations – one to fetch the index and one for the data itself.
Thanks Itamar for taking the time to answer me. So you’re saying that a partial index is kept in each partitions?
Quoting:
> This means that index data for any of the database’s partitions is stored across all of the database’s partitions.
My pleasure Giorgio. Indeed – the actual data of which an index consists (i.e., indexed value and pointer to row) is partitioned and therefore each of the database’s partitions stores only a part (ition) of the entire index’s data.