问题标签 [aggregates]

假设，假设我在数据仓库设置中有一个星型模式。有一个非常非常长的事实表（想想数十亿到数万亿行）和几个低基数维度表（想想 100 个维度表）。每个指向维度表主键的事实表外键都被位图索引。每个维度表的主键也是位图索引的。这都是为了快速加入。都很标准。

假设数据仓库开始出现性能下降。从位图连接返回结果所需的时间越长，事实表越长。业务需求是事实表不断增长（我们不能将超过一年的数据移至归档存储）

我正在考虑以下解决方案：

1. 哈希分区事实表，但这只是暂时阻止了不可避免的增长问题。
2. 数据库将物理星型模式数据库划分为多个模式/数据库。1..N 个事实表及其维度副本，每个都保存通过 hash(1..N) 函数分配给它们的数据，该函数在单独的 ETL 暂存数据库中执行以确定事实行的数据库/模式（由 ETL 产生过程）将进入。如果任何维度发生更改，请将更改复制到其他数据库对应的维度。同样，这不会作为永久解决方案。
3. 折叠维度并将所有维度值直接存储在事实表中。然后，将事实表导入到 HBASE on Hadoop。你得到一个巨大的 HBASE 表，没有维度表的键值存储。我会这样做是因为连接在 HBASE 中的成本过高（因此实际上没有维度连接，只需在维度列上强制执行维度值）。

以前有人做过吗？

有人对解决方案＃3有任何提示吗？

就通过快速读取进行扩展而言，HBASE 解决方案是最优的吗？

就写入而言，我不关心快速写入，因为它们会在下班时间作为批处理过程完成。

如果有人选择了解决方案 1 或 2，是否有人使用了一致的散列算法（如果更多分区、散列键是动态创建的，以避免像在普通旧散列中那样重新映射）？没有完整重新映射的分区数量的动态增长可能不是一个选项（就分区表而言，我还没有看到它在实践中完成）所以在我看来，任何分区解决方案都会导致扩展问题。

将具有多维的巨型事实表（传统的 DW 星型模式）移动到 HBASE 巨型无量纲表有什么想法、建议和经验？

相关问题：

如何在数据中聚合传统上驻留在物化视图中的数据集合（或者作为链接到与最细粒度的事实表相同的维度的单独事实表 - 即每小时/每天/每周/每月，其中基本事实表是每小时一次）仓库映射到 HBASE？

我的想法是，由于 HBASE 中没有物化视图，因此聚合数据集合存储为 HBASE 表，这些表在最细粒度、最低级别的事实表发生更改时随时更新/插入。

对 HBASE 中的聚合表有什么想法吗？是否有人使用 Hive 脚本从本质上模仿物化视图的行为，以在更改最细粒度的事实表时更新存储在其中的聚合数据的辅助 HBASE 表中的聚合列数据（即daily_aggregates_fact_table、weekly_aggregates_fact_table、monthly_aggregates_fact_table）？

大约一年前，我建立了一个由 ASP.Net MVC 3（现在）表示层、应用程序层、域层和基础设施层（横切材料和数据）组成的解决方案。我决定将域模型与域逻辑保持在一个单独的项目中，并通过传递域实体而不是 DTO 对表示层使用一种轻松的方法，因为我们现在实际上只有一个前端。

除了我们的主网站之外，我们将很快为分布式层提供服务，我将在那里使用 DTO，但我也在考虑在主网站中使用 DTO。我还想知道我是否应该费心在域层（IRepository、IUnitOfWork、实体/值对象超类型等）中分解框架代码。那么在这里，让我列出我需要反馈的问题：

1) 我非常努力地避免没有贫血的领域模型，并且还注意特定于演示问题的行为。所需的大多数业务计算都在域实体上，表示层可以直接调用此行为还是应该调用应用程序服务，然后调用域实体？这向我表明，没有理由让表示层知道域实体，而是可以使用 DTO。或者，我可以让 DTO 公开这些行为，但是我觉得我在抢劫域实体。所以我猜这是最好的 3 个选项（直接调用丰富的域对象、服务层或具有行为的 dto）？

2）现在我有一个领域项目，它具有领域服务、规范和逻辑，由应用层和单独的领域模型项目（由表示层和应用层使用）编排。我这里还有通用存储库和工作单元模式的框架接口。我是否应该将框架内容分解为一个单独的项目并将其余部分合并为一个项目？

3）我想将我的领域层重组为聚合，现在所有的领域模型都是由模块组织的，基本上每个模块的所有类型都在一个命名空间中。通过聚合来组织实体、价值对象、服务和其他东西会更好吗？

4) 对于基本上是 .net 框架助手库类型的基础设施服务，我应该使用分离接口模式吗？例如配置对象或验证运行器？这样做有什么好处？

5) 最后，我所见过的使用域实体接口的例子并不多。由于依赖的原因，我几乎所有的对象都喜欢传递接口，它使测试变得更加容易。使用接口而不是混凝土是否有效？我应该提到我们使用 EF 4.3.1（即将升级到最新版本），我似乎记得 EF 在使用接口或其他东西时遇到了问题。我应该公开接口而不是域实体吗？

非常感谢您提前。

项目结构：

说明：Presentation.Web（MVC3 Web 项目）

应用程序——编排领域层并响应来自表示层的请求的服务层（获取此更新）。这是按模块组织的，例如，如果我有一个客户模块，我将拥有 Application.Customer，其中包含所有应用程序服务

域——包含域服务、规范、计算和其他不作为域实体行为公开的域逻辑。例如，涉及多个域实体的计算，这些实体公开为应用层调用的域服务。-- 还包含规范框架的框架代码和通用存储库和工作单元模式的主要接口。

Domain.Model -- 包含域实体和枚举。按模块组织。例如，如果我可能有一个客户模块，它有一个客户实体、客户订单实体等。这是从域项目中分离出来的，以便应用程序和表示层可以使用这些对象。

Infrastructure.Security -- 用于身份验证和授权的安全基础设施

Infrastructure.Core - 由多个层（验证器、日志记录、配置、扩展、IoC、电子邮件等）使用的横切内容。大多数项目依赖于该项目中的接口（除了domain.model）来提供基础设施服务。

Infrastructure.Data——通过 LINQ 和 EF 4.3.1 的存储库实现、映射层、工作单元实现。接口在域项目中（分离接口模式）

我对 DDD 相当陌生，对我来说，我实际上是在寻找一个好的聚合函数。我有一长串用户 ( User) 并为此创建了一个聚合 ( UserAggregate)。

现在在我看来，我可能会根据不同的标准显示用户。假设在这里我没有对我的数据库查询中的列表进行排序，可以在聚合中进行排序吗？我无法想出可以正确执行此操作的应用程序的另一部分，但我可能会误解聚合的功能。

顺便说一下，过滤也是如此。当我阅读有关 DDD 聚合的信息时，我立即想到了Doctrine\Common\Collections\Collection（链接）。对我来说，那种东西看起来像是一个聚合体。所以DDD专家，请赐教:-)

更新

顺便说一句，我想的唯一方法是使聚合相当不相互，并让助手创建新的聚合。但这似乎不是要走的路：

第二个聚合是一个新实例，所以助手看起来像这样：

我的理解是 Kendo 不支持自定义聚合，但您可以在 footerTemplate 中调用函数。然后，该函数可以提供数据计算，甚至可以引用剑道定义的聚合。所以，例如，

如果这是正确的，您将如何编写函数computeRange？它将使用最大最小聚合。

另外，您将如何编写 computeMedian 函数？

在此先感谢您的帮助。

我有一个表，其中包含有关 fieldmeasurement 的元数据，其中字段“startDate”的类型为日期时间。当没有可用信息时，该值可以为空。我想在这个字段上运行一些统计数据，并获得最小值和最大值（即所有记录中最旧的测量值）。Max 没有问题，但 Min 聚合返回 None（空字段中的值）。

所以我的想法是在运行聚合之前从查询集中过滤这些记录。我找不到如何做到这一点。

我试过了

知道出了什么问题，或者如何做到这一点？

编辑：更多测试表明：

我的查询中需要有两个聚合函数，但不知道如何过滤。

我需要样本数和大于1的样本数。

就像是：

我可以做一个子查询，但是有没有更好的过滤方式？

我有一个温度计，每天早上只要我的机器打开，它就会开始记录数据。

我想选择最低、最高和平均温度，以及机器每天打开和关闭时的温度。

我的表结构如下：

时间记录、日期记录、温度

我按记录的日期分组以获取当天的聚合，但我似乎找不到在记录的第一个和最后一个时间戳处选择温度的好方法。

有什么帮助吗？

我实际上在 DDD 和 NoSql 领域徘徊。我现在有一个疑问：我需要从聚合中生成事件，并且我想使用 NoSql 存储。但是我如何确保事件保存在存储中并且聚合根上的更改没有事务？这有意义吗？有没有办法在不被迫使用事件源或事务数据库的情况下做到这一点？实际上我正在考虑实现一个两阶段提交算法，但从性能的角度来看它似乎很重......我是否以错误的方式解决问题？充满了问题......感谢恩里科的每一个建议

PS我是stackoverflow的新手，所以任何建议/批评/......都非常欢迎Enrico

编辑 1

那么我需要事件来通知聚合发生了一些事情，我他们应该对变化做出反应。当此类事件对业务逻辑很重要时，就会出现问题。据我了解，经过一夜的思考，我不能使用nosql存储来做这样的事情。让我解释一下（大声思考：P）：

• 使用 ES（第一景）：我保存数据的“差异”。然后我产生一个与之相关的事件。2 操作。
• 使用 ES（第二景）：我保存数据的“差异”。一个进程，观察 ES 并产生事件。但我只拥有一个观察者进程来确保事件的正确顺序。
• 使用 ES（3d 场景）：幂等事件。事件可以由状态推断，并且事件的每次重新应用只能导致消费者发生一次更改，可以有多个“出队”过程，不可能发生重复。1的操作，但它给消费者带来了很大的限制。
• 一般来说：我保存聚合的数据。然后我产生一个与之相关的事件。2 操作。

现在问题变得更广泛了恕我直言，当域事件是业务流程的基本部分时，是否可以使用域事件和 nosql？我认为这可能是一个更好的选择关系......即使我需要添加相当多的机器来获得相同的性能。

编辑2 为了完整起见，在google上搜索“域事件nosql幂等”：http: //svendvanderveken.wordpress.com/2011/08/26/transactional-event-based-nosql-storage/

我的团队需要找到解决以下问题的方法：

我们的应用程序允许用户查看企业的总销售额、产品总数、区域总数、区域 x 产品总数、区域 x 部门总数等。你明白了。有太多的值需要聚合才能得到其中许多无法即时计算的总数——我们必须预先聚合它们以提供合适的响应时间，这个过程大约需要 5 分钟。

这个问题，我们认为是一个常见的问题，但找不到参考，是如何在不关闭用户的情况下允许更新各种销售。此外，用户不能接受最终的一致性——如果他们向下钻取总共 12 个，他们最好看到加起来为 12 的数字。所以我们需要一致性 + 可用性。

到目前为止，我们提出的最佳解决方案是将所有查询定向到冗余数据库“B”（针对查询进行了优化），而将更新定向到主数据库“A”。当我们决定花 5 分钟更新所有聚合时，我们更新数据库“C”，它是另一个冗余数据库，就像“B”一样。然后，新用户会话被定向到“C”，而现有用户会话继续使用“B”。最终，警告任何使用“B”离开的人，我们终止“B”上的会话并在那里重新聚合，交换“B”和“C”的角色。典型的排水停止场景。

我们很惊讶我们找不到任何关于此的讨论，并担心我们过度设计了这个问题，或者这可能不是我们认为的问题。非常感谢任何建议。

我有一张桌子，上面记录着坦克的时间和液位。

12:00 | 85

12:01 | 77

12:02 | 78

12:03 | 82

12:05 | 79

12:06 | 75

12:07 | 85

等等

你怎么能写一个查询来得到一天中油箱低于 80 的时间？我正在使用 sql server 2008