我们的应用程序允许用户查看企业的总销售额,按产品划分的总计,按地区划分的总数,按地区x产品划分的总数,按地区划分的总数等.您可以了解相关信息.有许多值需要聚合以获得许多无法动态计算的总数 – 我们必须预先聚合它们以提供合适的响应时间,这个过程大约需要5分钟.
问题,我们认为是一个常见的问题,但没有参考,是如何在不关闭用户的情况下允许更新各种销售.此外,用户无法接受最终的一致性 – 如果他们总共向下钻取12个,他们最好看到总计为12的数字.因此,我们需要一致性可用性.
到目前为止,我们提出的最佳解决方案是将所有查询定向到冗余数据库,“B”(针对查询进行了优化),同时将更新定向到主数据库“A”.当我们决定花5分钟更新所有聚合时,我们更新数据库“C”,这是另一个冗余数据库,就像“B”一样.然后,新用户会话被定向到“C”,而现有用户会话继续使用“B”.最后,警告任何人使用“B”,我们杀死“B”上的会话并在那里重新聚合,交换“B”和“C”的角色.典型的排水停止方案.
我们感到惊讶的是,我们无法找到任何关于此的讨论,并担心我们过度设计这个问题,或者可能不是我们认为的问题.任何建议都非常感谢.
这是一个有趣的问题,所以我在火车上考虑过这个问题,我想出了为汇总的数据库中的每一行存储时间戳的想法. (我认为这种技术有一个名字,但它逃脱了我,谷歌搜索没有找到它…)时间戳将指示何时插入此行.此外：
– 如果可以更新行,那么您将同时拥有该行的两个“版本”,一个比另一个更新.
– 如果可以删除行,则需要有一个“删除版本”行,用于指定何时删除它.
现在你可以做以下事情：
1)假设您在2000年1月1日午夜更新聚合.您可以拥有该表的视图返回表的数据,就像它是在2000年1月1日午夜,忽略所有插入/更新/删除更新.现在,聚合与视图中的数据一样是最新的,您可以继续向基础表添加数据.
2)我不知道如何可行/容易保证它是可靠的,但你可以有’差异计算聚合’在2000年1月2日午夜,你采取2000年1月1日午夜的聚合,并仅使用自那时起已经改变的数据 – 节省您重新计算如此多的历史数据. (当然,一旦考虑更新或删除超过24小时的行,它会变得更加毛茸茸)
3)每当您更新聚合时,您可以将更新和删除的行与旧版本合并,并删除旧版本,因此您只需要保留重复的行,当您需要它们来分隔已经存在的行时聚合和非行的行(这也意味着,例如,如果所有聚合一次运行,并且您快速连续三次更新行,则只需保留最新的更新指示行)