我们计划将后端的一些写操作从RDBMS移到NoSQL，因为我们期望它们成为主要的瓶颈。
我们的业务流程具有95％-99％的并发写入，并且平均只读取1％-5％的并发读取。将涉及大量数据，因此内存中的NoSQL DB将不适合。
对于这种情况，磁盘上的NoSQL DB是最佳的吗？
谢谢！
答案 0 :(得分：2)
如果并发写入产生冲突并且数据完整性是一个问题，NoSQL可能不是您的选择。您可以使用支持“乐观并发”的数据管理轻松测试，因为您可以测量实际锁定冲突并详细分析它们。
当你说你没有任何进一步的细节时，我会有点惊讶。让我给你一个答案：基于你给我们的事实。什么是100,000个来源和什么是写作场景？MySQl是不是处理可扩展并发写入等的最佳示例。
如果您提供某种用例或任何有助于详细了解问题的内容，将会很有帮助。
让我举两个例子：在具有高级写调度程序，数据版本控制等的内存数据库中，可以轻松地将1M“编写者”作为网络元素的编写者，将应用程序作为高级NMS系统。大量写入，没有冲突，乐观并发，内存写入缓冲高达16GB，异步并行写入200多个虚拟主轴（SSD或磁盘）等。吃新数据的真正“傻逼”！将性能扩展到极限的绝佳选择。
第二个例子：具有稀疏数字空间的MSC，例如移动号码是数字的“集群”。巨大的数字空间，但最大200M个人地址。非常罕见的写入冲突的情况。 RDBMS被内存映射的稀疏文件替换。并且性能提升接近1000倍，在最好的情况下是1000倍，在最坏的情况下“仅”100倍。替换代码大约是300行C.这是一个真正的BigNoSQL，因为它非常适合要解决的问题。
因此，简而言之，在不了解更多细节的情况下，没有“银弹”来回答你的问题。我们不是在这里的仓库之后，它只是“大坏数据”。当我们不知道你的工作量是否是“事务性的”时。数字或IO和延迟敏感，或“BLOB like”aka。流媒体，地理数据等，它会给出100％错误的结果来承诺任何事情。带宽和速率/延迟/交易或多或少是现实生活中的权衡。