我之前已经谈到过RavenDB的MapReduce索引及其将结果输出到集合以及RavenDb的ETL流程的能力,以及如何使用它们将某些数据推送到另一个数据库(RavenDB数据库或关系数据库)。

当您开始谈论全局分布式处理时,将这两个功能结合在一起可能会非常有用。
一个具体的例子可能会使它更容易理解。

想象一下一家鞋店(我们将与Gary的鞋一起使用),该店需要跟踪大量地点的销售情况。
由于无论连接状态如何都必须处理销售,因此每个商店都托管一个RavenDB服务器来记录其销售。
这是商店的地理分布:

菊花链式数据流在ravendb中

为了正确地管理这家商店链,我们需要能够查看所有商店中的数据。
一种方法是设置从每个存储位置到中央服务器的外部复制。
这样,所有数据都被汇总到一个位置。
在大多数情况下,这是很自然的事情。
实际上,您可能希望对大多数数据进行双向复制,以便仅通过查看其库存的本地副本就可以确定给定商店是否有特定的鞋子库存。
但是出于讨论的目的,我们假设鞋销售量足够大,我们实际上并不希望复制所有的销售量。

我们只需要一些汇总的数据,但是我们希望这些数据在所有商店中汇总,而不仅仅是在单个商店中。
处理方法如下:我们将定义一个索引,该索引将汇总我们关注的各个维度(模型,日期,受众特征等)的销售额。
)。
该索引可以回答我们想要的查询类型,但是它是在数据库中为每个商店定义的,因此它只能提供有关本地销售的信息,而不能提供所有商店的情况。
解决这个问题。
我们将更改索引以具有输出集合。
这将导致其将所有输出作为文档写入专用集合。

为什么这么重要?
这些文档将仅由索引写入,但是由于它们是文档,因此它们遵循所有通常的规则,并且可以像其他任何文档一样执行。
特别是,这意味着我们可以对其应用ETL流程。
这是此ETL脚本的外观。

实时同步数据库

菊花链式数据流在ravendb中

该脚本将汇总的销售(由MapReduce索引生成的集合)发送到中央服务器。
请注意,我们还添加了一些静态字段,这些字段将对远程服务器有帮助,以便能够区分每个汇总销售来自哪个商店。
在中央服务器上,您可以将这些汇总的销售单据与每个商店的详细信息一起使用,也可以再次汇总它们以查看整个连锁店的状态。

这种方法的优点是功能及其最终结果的结合。
在本地级别,您拥有独立的服务器,可以与不可靠的网络无缝协作。
他们还为商店经理提供了有关其所在州以及其内部商店正在发生的事情的良好概览。

同时,在整个链中,我们拥有ETL流程,该流程将不断更新有关销售状态详细信息的中央服务器。
如果出现网络故障,服务将不会中断(除非特定商店的销售明细显然不是最新的)。
解决网络问题后,中央服务器将接受所有丢失的数据并更新其报告。

整个过程完全依赖于RavenDB中已经存在且易于访问的功能。
最终结果是一个分布式,高度可靠且具有容错能力的MapReduce流程,该流程可让您以极少的成本获得整个链上的销售汇总视图。

相关文章:

  • 2021-09-18
  • 2022-12-23
  • 2021-07-19
  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2021-05-03
猜你喜欢
  • 2022-01-09
  • 2021-10-22
  • 2022-12-23
  • 2021-05-29
  • 2022-12-23
  • 2021-04-28
  • 2021-04-11
相关资源
相似解决方案