我已经在一个项目上工作了半年多，从头开始构建医疗保健软件。当我加入时，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 允许您在不停止数据库的情况下替换存储过程。此外，存储过程的每次调用都构成一个事务。我们以这样一种方式利用存储过程，我们能够在不停止数据库的情况下修改/更新我们的应用程序逻辑。
就目前而言，这个问题非常主观，但更多信息可以帮助我们为您指明正确的方向。
您的具体要求是什么？该系统是否具有数据完整性和一致性至关重要的事务需求，例如交易和金融应用程序？数据量是多少，有多少并发用户？性能要求是什么？
另外，您提到ever-changing healthcare data，这是否意味着数据结构在不断变化和发展？如果是这样，考虑到刚性模式的性质，您可能希望远离关系数据库，而是考虑像 Mongo 这样的文档存储，其中无模式数据结构提供了更大的灵活性。
顺便提一句，
不要害怕 Mongo 的可靠性故事；您几乎可以找到任何产品的恐怖故事，包括开源和商业；很多时候，这些差评与产品的关系不大，而与客户执行不力有关。
我上次检查的 VoltDB 要求将所有持久性逻辑编码为存储过程。这种方法的明显缺点是代码可见性和模块化程度较低，维护需求较高。除此之外，Voltdb 速度非常快，因为在传统关系数据库中发现的大部分开销，例如锁定等，都从核心数据库引擎中消除了。
这个问题有点老了，但我给出了一些反馈，因为我们已经使用 MongoDB 很长时间了，我们正在寻找 VoltDB，但出于完全不同的原因：
关于 mongoDB：我们在生产中使用 mongoDB 已有 4 年了，我们从未丢失过任何单个字节的数据。“mongodb 不可靠”似乎是一个神话，至少对我来说是这样。我们每天在 mongoDB 中管理数百万个新条目，没有任何问题
我们正在寻找 VoltDB 的不同用例：提供大量实时分析。MongoDB 在提供分析方面并不差，但是当您超过数百万个要分析的条目时，它开始有点慢。VoltDB 在这方面要好得多，但我不建议你用它来存储数据，尤其是高价值数据……我们使用另一个数据库来存储数据。