Sometimes the quality of the application’s work really depends on the quality of its database. In this post we are going to focus on the key points when running a Database on Bare Metal and give you some pieces of advices which will really simplify your life:
- Being able to utilize the cloud to scan a new structure that was designed from the very beginning to be horizontally scalable and measure its action in the reality of making traffic is a really effective policy. As a result of virtualization against real hardware, the level of performance per instance will be lower than optimum. Nevertheless from the time you are able to scale horizontally, you are supposed to stand required level of traffic for request. You will receive helpful hard numbers for doing capacity programming and will have an opportunity to return the data base structure to real hardware in case you need this. Make also a note of Zynga Company, whose policy has something in common with the strategy we’ve proposed: their idea is in rolling out new games in EC2 and as soon as they find out the amount of visitors of this game, they return it to the datacenter.
- The cloud isn’t prepared for conventional and intensive transactional databases yet, as an examples we can take MySQL or PostgreSQL (these systems need horizontally scalable sharding). The main reason for this is in the really poor performance of I/O, which is received on virtual instances in a cloud (made from shared net work storehouse like EBS). If you decide to redesign the architecture of your database, we recommend you to use HBase, Riak or even Cassandra, as here you can be sure that some new node added to the cluster will cause fewer problems than in the manual sharding and scalable script. But still we give you an advance notice that this is not a guarantee that you will not need to spend your money on lots of instances as a compensation for poor I/O per instance. Probably SmartMachines of Joyent Cloud Software will prove to be more useful in this field.
- One more advice about using RDBMS technologies: if you do aim to have more successful predictions of the capacity needs and feel confident in the set of tools for monitoring and operational analysis, you should choose those technologies, which architecture is clear for you.
- Don’t base your disaster recovery policy in EC2 nearby EBS volumes, particularly if you’ve got a write-intensive database. The result of it can be dynamic instability of performance or even its loss. As proved experience shows, the following instruction works better: first transform the transient disks of an m1.xlarge EC2 instance into a RAID 0 array, place LVM on the top of that, then make use of it for storing different file types of MySQL; next you can make LVM fast shots of that volume and upload then to S3. For building another slave, you can restore the fast snap from S3 and overtake the replication with a master.