我们计划将后端的一些写入操作从RDBMS转移到NoSQL，因为我们预计它们将成为主要的瓶颈。
我们的业务流程有95%-99%的并发写入，平均只有1%-5%的并发读取。将涉及大量的数据，因此内存中的NoSQL数据库不适合使用。
磁盘上的哪个NoSQL数据库最适合这种情况？
谢谢！
如果并发写入正在创建冲突，并且数据完整性是一个问题，那么NoSQL可能不是你的选择。您可以使用支持"乐观并发"的数据管理轻松地测试这一点，因为这样您就可以测量现实生活中的锁定冲突并详细分析它们。
当你在没有任何进一步细节的情况下说你预计会出现问题时，我有点惊讶。让我给你一个答案：根据你给我们的事实。100000个来源是什么，写作场景是什么？MySQl不是处理可扩展并发写等的最佳示例。
如果你能提供一些用例或任何有助于详细理解问题的东西，那将是很有帮助的。
让我举两个例子：内存数据库具有高级写调度器、数据版本控制等功能，可以轻松地使用1M"写入程序"，写入程序是网络元素，应用程序是高级NMS系统。大量写入、无冲突、乐观并发、高达16GB的内存写入缓冲、对200多个虚拟磁盘轴(SSD或磁盘)的异步并行写入等。吃新数据的真正"傻瓜"！一位优秀的候选人，能够将表现发挥到极限。
第二个例子：MSC具有稀疏的号码空间，例如移动号码是号码的"簇"。巨大的数字空间，但最多有2亿个单独的地址。极少数情况下会出现相互冲突的写入。RDBMS被内存映射的稀疏文件所取代。性能改进接近1000倍，最好的情况下是1000倍，最坏的情况下"仅"是100倍。替换代码大约是300行C。这是一个True BigNoSQL，因为它非常适合要解决的问题。
所以，简而言之，在不了解更多细节的情况下，没有"银弹"可以回答你的问题。我们不是在追逐warewolves，这只是"大数据"。当我们不知道您的工作负载是否是"事务性的"时。数字或IO和延迟敏感，或"类似BLOB"的别名。流媒体、地理数据等，承诺任何事情都会给出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了解更多细节。