我已经在一个项目上工作了半年多，从头开始构建医疗保健软件。当我加入时，MySQL 被选为主要数据存储。
几个月和许多令人头疼的事情之后，我们开始研究替代数据存储，这些存储可以提供我们记录关键且不断变化的医疗保健数据所需的灵活性。
我们研究了许多 NoSQL 解决方案； MongoDB 吸引了我们最多的注意力。能够存储结构化的嵌入式数据将是一个巨大的好处。然而，我们被数据丢失/可靠性问题的报告吓到了。
我遇到了一些“NewSQL”数据存储，我特别对 VoltDB 感兴趣。
我很想知道是否有人对 Volt 有任何经验或见过它在项目中实现。
编辑:
数据完整性和一致性是最重要的。丢失患者信息可能非常有害，他们可能会接受不当治疗等。
数据量会有所不同；我们可能会首先支持小型实践。大约 700 个用户 总计 .但即使我们扩大到医院，我们也不会像交通一样关注社交媒体。
关于你的问题，是的，数据结构会发展。除了必须更改现有结构以捕获新的或修改过的输入之外，我们还必须将现有数据的结构保留为一种快照。我们只能用 MySQL 来做这种 EAV 风格。
感谢您的反馈意见。
最佳答案
我们去年上线了一个使用 VoltDB 的应用程序。我们使用 kfactor=1 4 服务器集群(256 GB 内存/服务器)每天存储大约 15 亿条记录并处理 50-9000 万笔交易。鉴于 VoltDB 的性能，我们每天可以轻松处理 10 亿笔交易。
迄今为止，我们没有遇到与 VoltDB 软件相关的问题。我们的经验是它真正符合 ACID。通过添加命令日志记录功能，我相信您可以配置日志记录参数以防止丢失任何事务。
其他强大的功能包括其可扩展性(以及添加容量的相对简单性)。
选择 VoltDB 时的一个重要考虑因素是了解 VoltDB 的分区方案。使用 VoltDB 实现极高的事务率取决于通过数据分区实现的并行性。分区对您的应用程序是透明的，但您的应用程序数据必须有助于进行分区以获得最大性能。如果您的数据不适合分区，我相信主要影响将是吞吐量(即交易率)降低 - 而不是阻碍。
最后 - 关于存储过程的说明。 VoltDB 允许您在不停止数据库的情况下替换存储过程。此外，存储过程的每次调用都构成一个事务。我们以这样一种方式利用了存储过程，我们能够在不停止数据库的情况下修改/更新我们的应用程序逻辑。
关于voltdb - 成功的 VoltDB 实现，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9285335/