Skip to main content

Throwing more Hardware vs developer time in tuning on a single db

Last weekend I read two interesting articles on scaling up vs scaling out and then I read Jeff atwood's .  By the way I am a big fan of Jeff Atwood and if you guys haven't read him you should start reading him :).

But at our company we planned for a scale out model because being a startup sometimes management wont order hardware worth 100-200K or more in one shot and also if you have a table with 1B rows and you are doing agile programming then you are ought to build something and throw it in prod and then refine it. This can sometime lead to alter tables and data migration. While scaling up is good, doing alter table to add a column with default value on even 100M row table will incur significant downtime and we cant afford that. So when I designed our metadata db we chose to scale out.  As of now we are storing billions of rows in mysql database and last weekend we finally started chucking cassandra also out and moving this also to mysql. This would for sure add billions of more rows to the database and we are 30% done migrating the data and this weekend we would probably reach 80% ( this would be an interesting weekend). 

As highlighted in the  that the approach we take for a new feature is to put it in global non sharded db and if it doesn't scale we move it to sharded db.  So for our event store database that we are migrating from cassandra I was 100% sure that it would need sharding because we had billions of rows but for one other functionality the engineer was confident that he would have < 1M rows as he would delete the rows fast.

As it turns out there were other factors out of  control and even with 30% of the nodes the table reached 10M rows on Thanksgiving weekend and man it was chaos.

On Saturday morning   the load on db that always used to be 1-2 shot up to 10-15 and there was everyone from VP engg to CTO to VP of Ops and the developer.  There were some indexes missing so we added them and that brought the load down to 7-10 but still we can't put more nodes on this code.

Then we found that for debugging purpose we were keeping data for 1 week and almost half the table was completed task so we cronned a job that would move the completed data to some archive table and that brought the load down to 5.

But still we cant put more nodes so on Sunday we changed the real time polling of table to every 30 sec, which defeats the purpose of the final functionality, I mean indexing was still better than before but its not the performance we wanted.

Ultimately we decided that in 1-2 weeks we would change the code to move to the sharded db. But was it worth it, I mean initially during when proposed to the idea of writing the code to sharded db, one argument that was made that do we need this complexity and other was that he can scale it on a single db table.  I mean I also know that people store Billions of rows in a single mysql instance like what the above links of Plentyoffish and stackexchange team did, but these guys are may be exceptions and think about spending almost 1-2 days coordinating so many people on a single issue and a 1 week delay to adding more nodes to the system and that also on Thanks giving(every one in family was raising eyebrows). If you incur all the costs I am definitely sure we can buy 2-3 mysql servers in that cost :).

So in short if I have a slight hint that this feature wont scale on a single db then I would rather throw more hardware on it by adding it to sharded db from start.  Anyways in 1-2 weeks we would move to sharded db and all problems would be solved.

Soon I think this sharded db would require more mysql servers as we are going to outrun the current 12 Mysql master/slave pairs but with some automation and graphite we can predict when to add more servers. Right now as these servers have spare capacity so that buys me some time to work on some other critical infrastructure changes but soon I will come back to this to scale it to next level.


Popular posts from this blog

RabbitMQ java clients for beginners

Here is a sample of a consumer and producer example for RabbitMQ. The steps are
Download ErlangDownload Rabbit MQ ServerDownload Rabbit MQ Java client jarsCompile and run the below two class and you are done.
This sample create a Durable Exchange, Queue and a Message. You will have to start the consumer first before you start the for the first time.

For more information on AMQP, Exchanges, Queues, read this excellent tutorial
import com.rabbitmq.client.Connection; import com.rabbitmq.client.Channel; import com.rabbitmq.client.*; public class RabbitMQProducer { public static void main(String []args) throws Exception { ConnectionFactory factory = new ConnectionFactory(); factory.setUsername("guest"); factory.setPassword("guest"); factory.setVirtualHost("/"); factory.setHost(""); factory.setPort(5672); Conne…

Logging to Graphite monitoring tool from java

We use Graphite as a tool for monitoring some stats and watch trends. A requirement is to monitor impact of new releases as build is deployed to app nodes to see if things like
1) Has the memcache usage increased.
2) Has the no of Java exceptions went up.
3) Is the app using more tomcat threads.
Here is a screenshot

We changed the installer to log a deploy event when a new build is deployed. I wrote a simple spring bean to log graphite events using java. Logging to graphite is easy, all you need to do is open a socket and send lines of events.
import org.slf4j.Logger;import org.slf4j.LoggerFactory; import; import; import; import java.util.HashMap; import java.util.Map; public class GraphiteLogger { private static final Logger logger = LoggerFactory.getLogger(GraphiteLogger.class); private String graphiteHost; private int graphitePort; public String getGraphiteHost() { return graphiteHost; } public void setGraphite…

What a rocky start to labor day weekend

Woke up by earthquake at 7:00 AM in morning and then couldn't get to sleep. I took a bath, made my tea and started checking emails and saw that after last night deployment three storage node out of 100s of nodes were running into Full GC. What was special about the 3 nodes was that each one was in a different Data centre but it was named same app02.  This got me curious I asked the node to be taken out of rotation and take a heap dump.  Yesterday night a new release has happened and I had upgraded spymemcached library version as new relic now natively supports instrumentation on it so it was a suspect. And the hunch was a bullseye, the heap dump clearly showed it taking 1.3G and full GCs were taking 6 sec but not claiming anything.

I have a quartz job in each jvm that takes a thread dump every 5 minutes and saves last 300 of them, checking few of them quickly showed a common thread among all 3 data centres. It seems there was a long running job that was trying to replicate pending…