I've been working on a project for over half a year now, building healthcare software from the ground up. When I joined up, MySQL had been chosen as the primary data store.
A few months and many headaches later, we've begun to investigate alternative data stores that can offer the flexibility we need to record our critical and ever-changing healthcare data.
We've looked at many NoSQL solutions; MongoDB drawing the most of our attention. Being able to store structured, embedded data would be a huge benefit. We've been scared off by reports of data loss/reliability issues, however.
I've come across a few "NewSQL" data stores and I'm interested in VoltDB in particular.
I'm curious to know if anyone has any experience with Volt or has seen it implemented in a project.
Edit:
Data integrity and consistency are most important. It could be very harmful for a patients information to be lost, they may receive improper treatment etc.
Data volume will vary; we will likely support small practices first. Something like 700 users total. But even when we scale up to hospitals, we're not looking at social media like traffic.
Regarding your question, yes data structures will evolve. On top of having to change the existing structure to capture new or modified inputs, we have to preserve the structure of the existing data as a sort of snap-shot. We've only been able to do this EAV style with MySQL.
Thanks for your feedback.
Answer
We went live last year with an application that uses VoltDB. We're storing around 1.5 billion records and processing 50-90 million transactions a day with a kfactor=1 4 server cluster ( 256 GB memory/server ). Given the performance of VoltDB, we could easily be handing 1 billion transactions a day.
To date, we have had no problems related to the VoltDB software. Our experience is that it is truly ACID compliant. With the addition of the Command Logging feature, I believe you can configure the logging parameters to preclude the loss of any transactions.
Other strong features include its scalability ( and the relative simplicity to add capacity ).
An important consideration when choosing VoltDB is understanding VoltDB's partitioning scheme. Achieving the extremely high transaction rates possible with VoltDB depends on the parallelism achieved through data partitioning. The partitioning is transparent to your application, but your application data must lend itself to being partitioned to get the maximum performance. If your data does not lend itself to partitioning, I believe the primary impact would be reduced throughput ( i.e. transaction rates ) - not a show-stopper.
Finally - a note concerning stored procedures. VoltDB allows you to replace stored procedures without stopping the database. Also, each invocation of a stored procedure constitutes a single transaction. We have leveraged stored procedures in such a way that we are able to modify/update the our application logic without stopping the database.