azure 最佳实践 -- 使用正确的数据存储

使用正确的数据存储


选择最佳的数据存储方案并正确使用
把所有的数据都放入一个很大的关系型SQL数据库的时代已经过去。关系数据库所擅长做的-为关系数据交易提供ACID保证。但同时也有一些代价：
- 查询可能会包含昂贵的联接。
- 数据必须被归一化并符合预定义的模式（写入模式）。
- 锁可能会影响性能。


在大型解决方案中，单一的数据存储技术可能无法满足所有需求。关系数据库的替代方案主要有键/值存储，文档数据库，搜索引擎数据库，时间序列数据库，列数据库和图数据库。每种都有利弊。
例如，您可以将产品目录存储在文档数据库中，例如CosmosDB，它的数据模型更灵活。在这种情况下，每个产品描述记录都是一个独立的文档。而对于整个目录的查询，需要对目录创建索引并将索引存储在AzureSearch中。而产品库存可以放入SQL数据库，因为这些数据需要ACID的保证。
数据不仅包括可持久化的应用程序数据。它还包括应用程序日志，事件，消息和缓存。


建议做法
不要使用关系数据库来存所有数据。酌情考虑使用其他数据存储方案。可参阅选择正确的数据存储。
多种数据持久化方案。在任何大型解决方案中，单个数据存储技术可能无法满足您的所有需求。
数据的类型。例如，将事务数据放入SQL中，将JSON文档放入文档数据库，将远程控制数据放入时间序列数据库，将应用程序日志放入Elasticsearch，并将Blob放入Azure Blob Storage。
可用性优先于（强）一致性。CAP定理提到了分布式系统必须在可用性和一致性之间进行权衡。 （网络分区，即CAP定理的另一方面，永远不能完全避免）。通常，可以通过采用接受最终一致性模型来获得更高的可用性。
开发团队的技能。使用多种数据持久化有优势，但也可能超出了团队的技能范围。采用新的数据存储技术需要一套新技能。开发团队必须了解如何使用这些技术。他们必须了解如何适当的使用模式，如何优化查询，调整性能等。
使用补偿事务。多种数据持久化的副作用是单一事务可能将数据写入多个存储。如果出现故障，可使用补偿事务来回滚任何已完成的步骤。
上下文。有界的上下文是领域驱动设计的术语。有界的上下文是域模型的边界，并定义模型应用于域的哪些部分。理想情况下，有界上下文映射到业务域的子域。在多数据持久化方案中考虑有界上下文是很自然的。例如，“产品”可能会同时出现在“产品目录”域和“产品库存”域中，但这两个域很可能对存储，更新和查询产品有不同的要求。