Calling on Sales
I had an interesting experience two days ago. I actually had a sales person talk me out of using a rather expensive product. Really. And yes, this does relate to MySQL!!
We had been evaluating using the MySQL Cluster product here at work for an application we are developing. Since I have never used a cluster in production before we looked into support options as a failsafe if we run into problems. Turns out MySQL AB is the only option out there for real in-depth support when it comes to the clustering product.
So I called MySQL to see what was it was going to cost and such. Let me just say up-front that I do not like talking to sales people. In today’s marketing-driven world it is almost always an unpleasant experience of someone trying to sell you something that you don’t necessarily need.
I won’t blog the names of the two people I talked too. Mostly because I don’t remember. Sorry guys :(. I was connected to the actual salesperson first. We spent about five minutes talking about what my company was looking for and then he conferenced me in with a sales engineer. This is where it got interesting.
The sales engineer and I talked for maybe ten to fifteen minutes. During this time he asked me questions like:
- what is our current application like?
- total amount of data expected in the cluster down the road?
- why are we looking at a cluster solution?
After listening to my thoughts on our application and what we are trying to do he made the suggestion that a cluster might not really fit the project. There are two basic guidelines that he had that we did not really fit within:
- the dataset should be at most 80gb
- our queries should be fairly simple — not a lot of joins
While our dataset might be less than 80gb for quite some time I fully expect it to exceed that within a year to a year and a half. And unfortunately, due to the nature of the application, our queries will never be that simple. It looks like we are going to go with a more conventional solution.
MySQL AB does have a program were an engineer visits you on-site and very closely evaluates the needs of your company - running load tests and such on a cluster. While this certainly isn’t cheap it is a great option for companies that just aren’t sure if clustering is something for them.
I will try and write a wrap-up posting on clustering to hopefully help other people evaluate if it is appropriate for them. While I enjoyed working on our test/devel cluster my life would have been a little easier if I had realized some of this up front!
6 Comments so far
Leave a reply
I’m sorry to hear you spent so much time on it, only to realize it won’t work. Unfortunately, I think this is a pretty common experience. I hope your writeup helps others avoid the same path!
No worries. I was a little stressed about it for a while but we went into this with the understanding that it might not work. In retrospect I would have done things a little different but that is what growing up is all about right? Learning from your past?
So what did the sales engineer recommend, MySQL replication master-master with a LinuxHA or equivalent frontend?
I know the decision is probably in bed, however if you have a smaller portion of your db which needs the availability requirements
provided by MySQL Cluster and another larger portion that doesn’t, you could still do both, potentially have the MySQL Cluster
feed the large MySQL replication database.
For example, Cluster is small OLTP with must not lose any transactions requirements, most work done via primary key lookups, the transactions are replicated to a MySQL Replication group as you can setup MySQL replication from MySQL Cluster. All the complex query work happens in replication land.
Just a thought.
Yes, the decision is finalized. We actually deploy on Nov. 5. There was discussion with the sales engineer of hot standby with DRDB (I think that is the acronym). That doesn’t give us any additional scale out but it will provide for a better hot-standby solution. We will deploy with a standard Master - Slave setup. I will begin testing DRDB in the first quarter of next year and probably deploy that by the end of the quarter.
The developers are going to have to figure out a way to shard our users over multiple servers. I am estimating they will have 12 - 18 months from the time we initially deploy before this becomes a real problem. I can build a nice size HA server pair using DRDB with 32-gigs or so of RAM and a disk-array back end that would handle anything up until then. Of course we aren’t deploying that to start with but we have experience scaling somewhat. It is a solvable issue and we do have time, it is just a difficult problem. A problem, unfortunately, that we thought we could resolve using a cluster. Live and learn
Keith
Heya, just a note that it is DRBD (http://www.drbd.org).
Also, don’t stop using/testing MySQL Cluster because it just didn’t fit for that particular application! There are environments where it does make perfect sense.
Thanks for blogging about your experiences with Cluster, all the way up to Sales. Nice stuff
Hello,
In the future, for those that would like some best practices and tips getting started with MySQL Cluster, we’ve compiled a MySQL Cluster Evaluation Guide available at: http://www.mysql.com/why-mysql/white-papers/mysql_cluster_eval_guide.php
– Jimmy