subject: Database Sharding Is A Popular Concept Used For Scaling Databases [print this page] However, writing sharding code is difficultHowever, writing sharding code is difficult. It requires you to rewrite most of your Data Access Layer from scratch. And while its difficult to do when you write your own SQL code, its even more complex when using O/R mapping tools, as most are not sharding oriented.
But even after writing the initial sharding code, you might run into issues. For instance, a common problem occurs when scaling requires adding more shards. Usually, internally written sharding code supports a fixed number of shards, and adding shards requires massive code rewrites as well as the major downtime required when moving data from one shard to another.
Other parts of the infrastructure also change when using a sharded database. For example, the reporting application must now be aware of the sharding logic, since you want to collect data from multiple databases rather than just one. And if the reporting application is an off-the-shelf product, youre out of luck. Youll have to write the reporting application from scratch.
Backup is an issue. Database Administration is an issue. And more complexities just continue to pop up.
So Database Sharding is a great solution for Database scaling, but its complex and costly. Unfortunately, most of the costs are hidden and only come up after the initial sharding is performed.
Scalebase Transparent Sharding
Luckily, theres ScaleBase. Our unique ScaleBase software solution handles all of the Database Sharding heavy lifting for you, without changing a single line of your code. And since its not embedded inside your application, your BI, DBA team and backup tools can use it, too no infrastructure change.
All you have to do to scale with Database Sharding is download the ScaleBase solution. Install it, and off you go. Our analysis model will automatically suggest the best sharding policy for you, and our management console makes sharding configuration a snap.
And even more ScaleBase also provides the ability to scale your database using read/write splitting, meaning that copies of the database can now serve for read operations, while only one database is used for the writes. Who said that database replicas are useless machines only used for high availability? Now they can be used for scaling as well.
