How to select a data-store

I have probably mentioned a couple of times. My company is currently in the process of selecting a new data-store which is supposed to replace MySQL for some applications that produce a lot of data. Cassandra is right now the hottest candidate and favored by my development team and also by the system administrators. Since replacing the database is obviously something bigger, we had to present this to some of the managers. They seemed to be interested as well and decided to make this a venture. This means we are getting hardware, people, resources etc. but it also means we have to follow a certain venture process that starts with a pre-study. To make it even more complicated (or bureaucratic) there is even a pre-study for the pre-study. Actually it is not as bad as it sounds. One of the architects called for a meeting today. The purpose was to find all the open questions that we have to answer in the pre-study document. It will then be this document which will be presented to the people who decided about the venture.

The meeting was actually very productive. Here is some stuff that is worth thinking about if you are in a similar situation.

Alternatives: this is almost a 100% question you will get. What are the alternatives? Why have you selected product X? I was thinking that maybe we could come up with some sort of comparison matrix from which it will be obvious why we favor Cassandra (otherwise we have to ask us why our selfs probably).

Product: The product you are evaluating. What tools does it have to offer? Which changes are required for the development and the test environments? For instance many of our testers look up and compare results directly in the database using MySQL query browser. What can we give them instead? Also an interesting aspect is competence. How do you build it up? Are there any trainings you can participate or is there a company from which you can buy professional support? In the case of open-source software, how active is the community and how certain is it that the product is not gonna die within two years?

Operations: What hardware setup do we need? How do we backup and restore? How do you monitor in the system and what do you monitor? What are the requirements on high-availability and scalability? Talking about scalability: can we add and removes nodes on the fly and how long does it take to replicate / re-balance our data onto these nodes? Do we have a disaster recovery strategy?

Impact: The most interesting part for me. How do we have to adapt existing applications in order to integrate with Cassandra? What client library is to prefer? How flexible is the new data-store when it comes to changes? For instance we always have big-time trouble if we need to alter our MySQL schema's without downtime - a process for which Facebook even has a special name: Online Schema Change. Another interesting question, how can you effectively unit test an application using Cassandra. I guess running an in-process Cassandra, that starts up inside a unit test on a single node, is not catching all errors. Is it realistic to believe, that we can come up with a comprehensive list of use-cases to describe how the data is used in our system. Such a list would greatly influence or data-model. Since there really is only one physical way to store data, how do we handle alternative access. Do we retain a bunch of MySQL indexes to support Cassandra or do we also store these secondary access paths in the main data-store?

I do not remember all the open questions we came up with during the meeting. This is a good start at least. I hope we can create a great pre-study document to get everyone in the company on board.