对于主要编写应用程序，推荐使用哪种NoSQL解决方案？

Question

我们计划将后端的一些写操作从关系型数据库迁移到NoSQL，因为我们预计它们将成为主要的瓶颈。

我们的业务流程有95%-99%的并发写入，平均只有1%-5%的并发读取。这将涉及大量数据，因此内存中的NoSQL DB将无法容纳。

哪种NoSQL DB on-disk最适合这种情况？

谢谢!

Answer 1

如果并发写入造成了冲突，并且数据完整性是一个问题，那么NoSQL可能不是您的解决方案。您可以使用支持“乐观并发”的数据管理轻松地测试这一点，因为这样您就可以测量现实生活中的锁定冲突并对其进行详细分析。

当你说你预计会有问题“没有更多的细节”时，我有点惊讶。让我给你一个答案:基于你给我们的事实。什么是100,000源，什么是编写场景? MySQl不是处理可伸缩并发写入等的最好例子。

如果你能提供一些用例或任何有助于详细理解问题的东西，这将是有帮助的。

让我举两个例子:在内存数据库中有一个高级的写分派器，数据版本控制等，可以很容易地采取1M“写入器”，写入器是网络元素和应用程序是一个先进的网管系统。大量的写入，没有冲突，乐观的并发，高达16 or的内存写入缓冲，异步并行写入200+虚拟磁盘轴(固态硬盘或磁盘)等。一个真正的“吸盘”吃新数据！一个将性能扩展到极限的优秀候选者。

第二个例子: MSC具有稀疏的数字空间，例如移动号码是数字的“集群”。巨大的数字空间，但最大。2亿个独立地址。存在冲突写入的非常罕见的情况。RDBMS已替换为内存映射稀疏文件。性能提升接近1000倍，在最好的情况下是1000倍，在最坏的情况下是100倍。替换代码大约有300行C代码，这是一个真正的BigNoSQL，因为它非常适合要解决的问题。

因此，简而言之，在不了解更多细节的情况下，没有“银弹”来回答您的问题。我们不是在找数据仓库，这只是“大而坏的数据”。当我们不知道你的工作负载是否是“事务性的”时。数量或IO和延迟敏感，或“像斑点”又名。流媒体，地理数据等，它会给出100%错误的结果来承诺任何事情。带宽和io速率/延迟/事务在现实生活中或多或少是一种权衡。

有关更详细的信息，请参见例如http://publib.boulder.ibm.com/infocenter/soliddb/v6r3/index.jsp?topic=/com.ibm.swg.im.soliddb.sql.doc/doc/pessimistic.vs.optimistic.concurrency.control.html。