Sharding is a way of partitioning your datastore to benefit from the computing power of more than one server. For instance many web-facing databases get sharded on user_id, the unique serial number your application assigns to each user on the website.
Sharding can bring you the advantages of horizontal scalability by dividing up data into multiple backend databases. This can bring tremendous speedups and performance improvements.
Sharding, however has a number of important costs.
- reduced availability
- higher administrative complexity
- greater application complexity
High Availability is a goal of most web applications as they aim for always-on or 24×7 by 365 availability. By introducing more servers, you have more components that have to work flawlessly. If the expected downtime of any one backend database is 1/2 hour per month and you shard across five servers, your downtime has now increased by a factor of five to 2.5 hours per month.
Administrative complexity is an important consideration as well. More databases means more servers to backup, more complex recovery, more complex testing, more complex replication and more complex data integrity checking.
Since Sharding keeps a chunk of your data on various different servers, your application must accept the burden of deciding where the data is, and fetching it there. In some cases the application must make alternate decisions if it cannot find the data where it expects. All of this increases application complexity and is important to keep in mind.
Sean Hull asks on Quora – What is Sharding and why is it important?
Scalability in the cloud depends a lot on application design. Keep these important points in mind when you are designing your web application and you will scale much more naturally and easily in the cloud.
** Original article — Intro to EC2 Cloud Deployments **
1. Think twice before sharding
- It increases your infrastructure and application complexity
- it reduces availability – more servers mean more outages
- have to worry about globally unique primary keys
2. Bake read/write database access into the application
- allows you to check for stale data, fallback to write master
- creates higher availability for read-only data
- gracefully degrade to read-only website functionality if master goes down
- horizontal scalability melds nicely with cloud infrastructure and IAAS
3. Save application state in the database
- avoid in-memory locking structures that won’t scale with multiple web application servers
- consider a database field for managing application locks
- consider stored procedures for isolating and insulating developers from db particulars
- a last updated timestamp field can be your friend
4. Consider Dynamic or Auto-scaling
- great feature of cloud, spinup new servers to handle load on-demand
- lean towards being proactive rather than reactive and measure growth and trends
- watch the procurement process closely lest it come back to bite you
5. Setup Monitoring and Metrics
- see trends over time
- spot application trouble and bottlenecks
- determine if your tuning efforts are paying off
- review a traffic spike after the fact
The cloud is not a silver bullet that can automatically scale any web application. Software design is still a crucial factor. Baking in these features with the right flexibility and foresight, and you’ll manage your websites growth patterns with ease.
Have questions or need help with scalability? Call us: +1-213-537-4465