我们计划将后端将执行的一些写入从 RDBMS 转移到 NoSQL，因为我们预计它们将成为主要瓶颈。
我们的业务流程平均有 95%-99% 的并发写入，而平均只有 1%-5% 的并发读取。将涉及大量数据，因此内存中的 NoSQL DB 不适合。
哪种 NoSQL DB 磁盘最适合这种情况？
谢谢！
【问题讨论】：
标签： concurrency nosql
如果并发写入造成冲突并且数据完整性是一个问题，那么 NoSQL 可能不是您要走的路。您可以使用支持“乐观并发”的数据管理轻松对此进行测试，然后您可以测量现实生活中的锁定冲突并对其进行详细分析。
当你说你预计会出现问题时，我有点惊讶，没有任何进一步的细节。让我给你一个答案：根据你给我们的事实。什么是 100,000 个来源，写作场景是什么？MySQl 是不是处理可扩展并发写入等的最佳示例。
如果您能提供某种用例或任何有助于详细了解问题的内容，将会很有帮助。
让我举两个例子：在内存数据库中，具有先进的写入调度程序、数据版本控制等，可以轻松地容纳 100 万个“写入器”，写入器是网络元素，应用程序是高级 NMS 系统。大量写入，无冲突，乐观并发，内存写入缓冲高达 16GB，异步并行写入 200 多个虚拟主轴（SSD 或磁盘）等。吃新数据的真正“吸盘”！将性能扩展到极限的绝佳候选者。
第二个例子：MSC 有一个稀疏的数字空间，例如手机号码是数字的“集群”。巨大的数字空间，但最大。 2 亿个个人地址。写入冲突的情况非常罕见。 RDBMS 被内存映射的稀疏文件取代。性能提升接近 1000 倍，是的，在最好的情况下是 1000 倍，在最坏的情况下“只有”100 倍。替换代码大约是 300 行 C。这是一个真正的 BigNoSQL，因为它非常适合要解决的问题。
因此，简而言之，在不了解更多细节的情况下，没有“灵丹妙药”可以回答您的问题。我们不是在追捕狼人，这只是“大坏数据”。当我们不知道您的工作量是否是“事务性”时。数字或 IO 和延迟敏感，或“类似 BLOB”。流媒体、地理数据等，承诺任何事情都会给出 100% 错误的结果。带宽和 io-rate/latency/transactions 在现实生活中或多或少是一种权衡。
【讨论】：