操作方法:Azure Service Fabric 有状态完整服务、可靠集合是否会取代 SQL-azure?



作为 Azure Service Fabric 新手,我有一个关于">可靠集合"的问题。

如果已经阅读了文档,我开始想知道如何使用可靠的集合?
- 它们会取代数据库系统吗?
- 它们是否仅支持 x 进程|节点状态共享方案?
- 它们是否应该仅用作优化的缓存?
- 可靠集合的典型大小是多少:MB/0-5GB/5-10GB?

它们会取代数据库系统吗?

不一定,这就像比较苹果和橙子。首先,有多种类型的数据库引擎,如关系引擎(SQL Server)和NoSQL引擎(如CosmosDB)。通常,可以从外部查询数据库,而可靠集合的典型方案是仅托管服务自身状态所需的数据。

例如,一个真实的数据库可以由多个 Service Fabric 服务使用。可靠的集合旨在由一个服务使用。

从文档中:

可靠集合与其他高可用性技术(如 Redis、Azure 表服务和 Azure 队列服务)之间的主要区别在于,状态在本地保存在服务实例中,同时还具有高可用性。

外部数据库引擎仍然有其位置,例如用于报告目的。

它们是否应该仅用作优化的缓存

不,有更好的缓存产品可以提供更好的功能,例如,在可靠集合中没有对自动缓存失效的支持。

Service Fabric 是用于构建微服务的非常棒的平台。在微服务理念中,每个微服务使用数据存储的概念占据了突出的位置。为了减少数据检索的延迟,可以使用可靠的集合。文档中也有概述

可靠集合的典型大小是多少:MB/0-5GB/5-10GB?

从文档中:

可靠服务通常是分区的,因此可以存储的数量仅受群集中计算机数量以及这些计算机上可用内存量的限制。

例如,假设您在具有 100 个分区和 3 个副本的服务中有一个可靠的集合,存储平均大小为 1 kb 的对象。现在假设您有一个 10 台计算机的群集,每台计算机具有 16gb 的内存。为简单起见和保守起见,假设操作系统和系统服务、Service Fabric 运行时以及你的服务占用其中的 6GB,每台计算机剩余 10gb 可用空间,群集占用 100 GB 空间。

最新更新