我从事一个项目超过半年，从头开始构建医疗保健软件。当我加入时，MySQL被选为主要数据存储。
几个月后，我们开始研究替代数据存储，它们可以提供我们记录关键和不断变化的医疗保健数据所需的灵活性。
我们已经研究过许多NoSQL解决方案; MongoDB吸引了我们最多的注意力。能够存储结构化的嵌入式数据将是一个巨大的好处。然而，我们一直被数据丢失/可靠性问题的报告所吓倒。
我遇到过一些“NewSQL”数据存储，特别感兴趣的是VoltDB。
我很想知道是否有人对Volt有过任何经验，或者已经看过它在项目中实施过。
修改
数据完整性和一致性是最重要的。对于患者信息丢失可能是非常有害的，他们可能会接受不正当的治疗等。
数据量会有所不同;我们可能会先支持小做法。 700个用户 总计 之类的东西。但即使我们扩展到医院，我们也不会像交通一样关注社交媒体。
关于您的问题，是的数据结构将会发展。除了必须更改现有结构以捕获新输入或修改输入之外，我们还必须将现有数据的结构保留为快照。我们只能用MySQL做这种EAV风格。
感谢您的反馈。
答案 0 :(得分：34)
我们去年推出了使用VoltDB的应用程序。我们每天使用kfactor = 1 4服务器集群（256 GB内存/服务器）存储大约15亿条记录并处理5千万到9千万条交易。鉴于VoltDB的性能，我们可以轻松地每天处理10亿笔交易。
到目前为止，我们没有遇到与VoltDB软件相关的问题。我们的经验是它真正符合ACID标准。通过添加命令日志记录功能，我相信您可以配置日志记录参数以防止丢失任何事务。
其他强大的功能包括其可扩展性（以及添加容量的相对简单性）。
选择VoltDB时的一个重要考虑因素是了解VoltDB的分区方案。使用VoltDB实现极高的事务处理速率取决于通过数据分区实现的并行性。分区对您的应用程序是透明的，但您的应用程序数据必须能够进行分区以获得最大性能。如果您的数据不适用于分区，我认为主要影响是吞吐量（即交易率）降低 - 而不是显示阻塞。
最后 - 关于存储过程的说明。 VoltDB允许您在不停止数据库的情况下替换存储过程。此外，每次调用存储过程都构成一个事务。我们利用存储过程以便能够在不停止数据库的情况下修改/更新应用程序逻辑。
答案 1 :(得分：0)
目前的问题非常主观，但更多信息可以帮助我们指出正确的方向。
您的要求到底是什么？该系统是否具有交易需求，其中数据完整性和一致性至关重要，例如交易和财务应用程序中的那些？什么是数据量，以及多少并发用户？性能要求是什么？
另外，您提到ever-changing healthcare data，这是否意味着数据结构在不断变化和发展？如果是这样，考虑到严格模式的性质，您可能希望远离关系数据库，而是考虑Mongo等文档存储，其中无模式数据结构提供了更大的灵活性。
顺便说一句，
不要害怕Mongo的可靠性故事;你几乎可以找到任何产品的恐怖故事，包括开源和商业;这些糟糕的评论往往与产品关系不大，而与客户实施不当有关。
VoltDB，我检查过，要求所有持久性逻辑都被编码为存储过程。这种方法的明显缺点是代码可见性和模块化程度较低，维护需求较高。除此之外，Voltdb非常快，因为传统关系数据库中的大部分开销（例如锁定等）都从核心数据库引擎中消除。
答案 2 :(得分：0)
问题有点陈旧，但我提供了一些反馈，因为我们很长一段时间以来一直在使用MongoDB，而且我们正在寻找VoltDB，但出于完全不同的原因：
关于mongoDB：我们从4年开始在生产中使用mongoDB，我们从未丢失任何单字节数据。 “mongodb不可靠”似乎是一个神话，至少对我而言。我们每天都在mongoDB中管理数百万条新条目，没有任何问题
我们期待VoltDB提供不同的用例：提供大量的实时分析。 MongoDB在提供分析方面并不擅长，但是当您超越数百万条要分析的条目时，它开始变得有点慢。 VoltDB在这方面要好得多，但我建议你不要用它来存储数据，尤其是高价值数据....我们使用另一个数据库来存储数据。