[]
推荐阅读
技术决策者 | 项目经理 | 高级技术人员 | 初级技术人员 | 测试人员 |
---|---|---|---|---|
√ | √ |
type=info
对于运行时间以十年记的企业软件而言,数据量注定要在某一天超过我们今天的预期。好在这些数据的价值和使用场景并不尽相同,我们可以“分而治之”,将计算资源有效集中在最需要它们的地方。
业务数据根据写入和读取等活动的频率不同,可以分为热数据和冷数据。在企业管理软件领域,因为“月结/年结”的存在,业务数据的活动频率通常与时效性紧密相关,热数据通常指近一两年的数据(可以类比为互联网应用中的“温数据”),更早的数据则被称为冷数据。在设计冷热数据分析的系统时,您需要对业务做深入调研,下面是一些建议,供参考:
根据业务特点确定“冷热分界线”,如财务相关的单据可设置为1年,销售相关的单据设置为3年等。
除非数据量过大,统计数据和主数据均不建议做归档
主数据需采用标记删除法,不建议提供直接删除功能,如果必须做删除,则需要同时检查被删除条目在冷热数据中的引用情况
为了简化系统开发,冷热数据结构建议保持一致
数据归档操作建议放在系统维护期(非业务高峰期)自动执行,推荐采用数据库归档工具(如 用于MySQL的 pt-archiver)或ETL工具(如Kettle、DataX),这部分业务需求相当固定,不建议使用活字格定制开发。
和所有数据删除操作一样,数据归档也会对带来索引碎片,建议定期检查索引质量,及时执行索引重建
在功能和交互设计上,尽量避免对归档数据进行更新或删除操作,如果必要,需确保同步更新该归档数据对应的统计数据
对比项目 | 热数据 | 冷数据 |
---|---|---|
读取频率 | 高 | 低 |
典型的读取方式 | 查询/列表 | 查找/单条 |
写入频率 | 高 | 很低 |
数据量 | 小 | 大 |
开发流程:
首先,您需要分别创建存放热数据库的当前数据库和存放冷数据的归档数据库,两个数据库的版本、排序等需要保持一致。除非预算不足,我们推荐您将两个数据库分别部署在同一内网中不同的服务器上。
在多数企业软件场景中,冷热数据可以按照按财年划分,将最近几年的数据定义为热数据,较远的数据定义为冷数据。每个财年结算后,通过自动或者手动触发的方式,将需要归档的年度的单据从存放热数据的当前数据库“剪切”到存放冷数据的归档数据库,同时将主数据从热数据库“复制”到归档数据库。
在开发阶段时,您需要为支持数据归档的单据分别设计“业务操作页面”和“历史记录查询页面”,分别从当前数据库和归档数据库中读取数据。为了确保数据的一致性(冷数据对应的统计数据存放在当前数据库中,难以通过事务来保证),冷数据通常是只读的。
在主数据层面,请勿依赖数据库的外键来做删除前检查(因为部分单据已经被转移到了归档库)。推荐对数据归档相关的主数据采用标记性删除的做法,而不是直接删除。
通常情况下,不推荐对统计数据做归档,这意味着您需要针对统计报表相关页面做专门的处理,推荐使用服务端命令对来自不同数据库的数据进行聚合。当然,使用Wyn商业智能工具提供的多源数据整合功能来提供更强大的数据分析能力也是一个很不错的选项。
type=info
温馨提示
企业级低代码开发最佳实践是活字格官方面向进阶开发者推出的产品技术资源,旨在帮助对活字格基本功能有一定了解的开发者快速提升应用开发能力,保质保量做好企业级项目交付。如果您是初次接触活字格,这些内容可能会有些艰深难懂,这也是正常的。如果您有软件开发经验,推荐您学习《面向程序员的活字格入门课程》;否则,您也可以免费报名参加新手训练营直播课程或购买阅读《低代码开发实战:基于低代码平台构建企业级应用》(机械工业出版社),快速上手低代码开发。