Not every company or application needs an elastic database. Some applications can get by just fine on a single database server, rendering database elasticity moot from their perspective. To make this determination, simply ask yourself:
1. Will I need more than a single database server?
Look at your current load and your projected growth and ask yourself whether it will exceed the capacity of a single server. If it doesn’t now, nor will it in the future, then you don’t need an elastic database.
2. Will my load fluctuate sufficiently to warrant the investment in elasticity?
If your database requirements won’t experience fluctuations in demand—e.g. daily, weekly, monthly, seasonal changes in the number of servers required—then elasticity isn’t important. For example, if you have a social networking application that requires 2 database nodes 24x7, but peaks at 10 nodes for 2 hours a night, then elasticity is important. If your database has a steady load that requires 3 database nodes and that load doesn’t change, then elasticity isn’t important.
3. Will my database load grow with time?
I your database load will grow with time, then you need to evaluate the growth pattern and ask yourself whether you can handle this expansion manually, or if you simply want to rely on an elastic database to grow seamlessly.
If your answer to these three questions is no, then you don’t really need an elastic database. Now there are certainly other reasons to consider ScaleDB (e.g. high-availability, eliminate partitioning/sharding, eliminate master-slave issues, etc.) but elasticity may not be one of them.
Posts
This is, in my mond, quite a bit of oversimplification. There are reasons that you want an elastic database, if if your current load doesn't and stays the same (but hopefully useage, and hence load, will grow and your business flourish).
ReplyDelete1) Well, there may well be many reasons for en elastics implementation, even if your load doesn't change and 1 server is enough. It may well be that 2 or even more smaller servers in an elaastic configuration is more cost-effective that your current setup.
2. Databases don't live in a vacuum, so the extra load might well come from somewhere else in the system. And if you are running in a cloud already, increased load from the ones you are sharing the resources with might well mean that you need to scale out, even though nothing in your own setup changes.
3. Will me database grow woth time+ Well, as a DBA I think you really should assume that this will happen.
4. The effort of moving to an elastic application setup, after the fact that you have already assumed to elasticity wasn't need (i.e. you assumed that in the world of IT, nothing will change), will be significant, probably more so that if you took the effort of assuming an elastic setup from the start.
/Karlsson
Anders, My question #1 above could have been expanded to address a "larger" server as well. My point being that if you run on a small instance and it more than handles your needs now and in the future--inclusive of load fluctuation--then elasticity may not be a concern.
ReplyDeleteThat said, one never know exactly what the future holds. So you may add complexity, your users and data may grow, etc. In those cases it is much better if you have built-in elasticity. With that I certainly agree with you. Being in the elastic database business, it is hard not to agree with you on that ;-). My only point is that if your DB usage is minimal and will never fluctuate or grow beyond a single simple server...you're fine without elasticity. Hopefully, those are rare cases.