其中并发读/写操作的数据库策略

Question

我有 6 个服务与同一个数据库 SQL Server 2016（支付）通信，其中一些服务正在执行写入操作，而一些正在执行读取操作。数据库服务器包含其他数据库以及付款数据库。我们在支付数据库上没有任何归档工作。我们最近遇到了 99% 的 CPU 使用率以及数据库服务器上的内存问题。

我可以采取的明显步骤，包括

1. 创建存档作业以将旧数据迁移到存档数据库
2. 可以扩展数据库服务器。

但仍想探索其他最佳解决方案。我有以下问题。

1. 我们能否为读写操作创建不同的数据库，如果可以，如何？
2. 我们能否将数据从 RDBMS 动态迁移到 NoSql 数据库，因为它的读取操作速度更快？
3. 对于发生并发读写操作的此类应用程序，最佳设计是什么？

Answer 1

存储就是权衡取舍，因此要找到正确的“存储”解决方案而不深入研究延迟、可用性、并发性、访问模式和安全要求等不同方面是非常棘手的。在这种特殊情况下，正在存储的支付数据应该是保密的，并且直接删除了一些存储解决方案。一般来说，你应该

1. 缓存读取的数据，但如果正在修改相同的数据 这总是行不通的。缓存也不能很好地工作 您的阅读不是公开的（即，不能在多个 读取调用，最好是跨多个用户），在这种情况下这是可能的，因为我们正在处理支付数据。
2. 读/写主数据库和只读从属模式也是扩展读取的“常见”模式。但它不会扩展写入。这又取决于应用程序是否可以处理“复制滞后”。
3. 分片是扩展写入的常用访问模式。它带来了跨节点查询聚合等的其他负担（在某些数据库中）。
4. 最后，基于数据访问模式，重构架构 并使用不同的数据库。 CQRS（命令查询责任） 隔离）是实现它的一种方法，但它有它的 自己的优点和缺点。更多详情：https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

几年前，我读了这本书，它极大地帮助我理解了这些概念：https://www.amazon.com/Scalability-Startup-Engineers-Artur-Ejsmont/dp/0071843655