广告

掌握敏捷查询驱动的NoSQL数据建模

事实证明,这种实践对于基于NoSQL的应用程序的成功甚至比关系世界几十年来的成功更为关键。

随着敏捷开发,精益方法和NoSQL技术的出现和成熟,“数据建模”领域已被重新发明,以在软件产品和项目的开发中发挥更大的作用。

但是,如果“数据建模”的名称保持不变,就生命周期,人员,流程和工具而言,它现在已经与数十年来在瀑布式开发环境中关系数据库的方法大不相同。与传统的标准化SQL数据库数据建模技术相比,NoSQL的模式设计已成为一门艺术,而转变思维对于充分利用NoSQL技术和敏捷开发的优势至关重要。

敏捷开发的专家们正确地认为,传统的“概念-> logical ->物理数据建模”过于线性和顺序化,无法适应sprint的快速循环,尤其是考虑到难以修改关系数据库的结构时。在将输出传递给开发人员之前,它过去是一个繁重的过程,需要早期的专门资源(通常是专用资源)来完成。如今,数据建模已成为分布在更多团队成员之间的连续,迭代和协作的过程。它以一种查询驱动的方法为中心,该方法迫使数据建模人员,设计人员和开发人员忘记过去的指导原则。

广告

数据建模不再只在项目的早期阶段有所帮助,而是在整个应用程序开发生命周期中一直扮演着持续的角色-在最初交付应用程序很长时间之后,在生产中的每个步骤(包括生产中)都提供价值。而且,由于敏捷团队成员具有多种技能,并且戴着很多帽子,因此架构设计成为一项共同的任务和责任,需要适用于技术和开发实践的新一代工具。

数据建模的好处很多而且可以量化。事实证明,与关系世界几十年来相比,NoSQL的数据建模对于基于NoSQL的应用程序的成功至关重要。

需求,技术和方法的转变

以前,组织将大多数结构化数据存储在关系数据库中,但是随着大数据的出现和数据库技术的进步,需求已发生了巨大变化。

众所周知,组织现在拥有来自各种来源的不同格式的结构化,半结构化和非结构化数据。这种新的动态特性是NoSQL的重要原因,而NoSQL以其灵活性和可伸缩性而闻名。

应用程序开发世界也一直在发生重大变化,因为它现在涉及的是最低限度可行的产品和快速迭代,因为开发人员旨在更早地为客户提供价值,更快的回报以及不断地对产品和业务模型进行微调。道路。

尽管在技术和方法论方面已发生了革命,但一些最佳实践和指导原则仍然具有现实意义。它仍然大大降低了总体拥有成本(TCO),并提高了质量和客户满意度,从而为应用程序制定了清晰的愿景。详细说明需求,工作流程和屏幕模型;并在应用程序开发生命周期的早期发现概念问题和缺陷。

同样,没有改变的是,每个应用程序下都有一个支持系统和业务的数据库。数据建模描述了对业务以及应用程序和数据库(无论是SQL还是NoSQL)的结构的理解。尽管蓝图可能会在开发过程中发生变化,但仍然必须保留适当的数据建模,以促进架构师,设计师,开发人员和最终用户在设计之前,之中和之后的交流与协作。

最佳实践

如今,数据建模已成为贯穿应用程序生命周期各个阶段以及在生产中的连续过程,因为数据治理和隐私法规要求通过持续不断地发展应用程序功能和基础数据来记录和维护法规遵从性,即使对于半结构化和非结构化数据也是如此。

数据建模发生在生命周期的不同步骤中,包括在域驱动设计(或概念建模)过程中;具有物理数据建模的应用程序设计;具有迭代演化的开发;进行测试并生成相关的测试数据;部署和优化;生产,同时保持数据治理和合规性;以及对文档的简化和对下一版本的简化。

随着敏捷的发展,团队成员具有多种技能和跨职能。这些基本技能之一就是数据建模。敏捷团队成员现在需要一小部分执行数据建模,然后致力于开发和实现该模型。但是,由于规模较小的团队具有自治权,因此事后捕获潜在影响(例如隐私或合规性要求)变得至关重要。得益于命令行界面,该界面可以基于大型生产数据集的采样来推断数据库架构,因此数据建模可以监视敏捷开发人员对新字段和结构的引入。

转向NoSQL时,仅复制关系数据结构是很愚蠢的。为了利用NoSQL的好处,有必要在编写时对数据进行规范化和联接。这种技术比一门科学更是一门艺术,因为对于如何去规范化没有明确的规则。取而代之的是,有许多不同的模式可以使数据非规范化,但只有一个目标:以最重要的方式(最重要的是在用户需要访问数据时)存储数据,从而最好地服务于性能。这意味着“写时”预聚合或加入数据。

因此,NoSQL数据建模的目标是确定将检索数据的所有方式,相应地设计存储结构,并评估不同的假设情景。

更麻烦的是,NoSQL并没有遵循通用标准,每个数据库供应商都有自己的术语,存储方法,定义主键的方式,数据类型,甚至是自己的查询语言。

方法论

基于应用程序的全局视野和策略以及早期阶段的功能要求,域驱动设计(DDD)方法达到的目标与更传统的概念模型相似,但DDD在解决问题上的重点有所不同,而非解。它也对行为感兴趣。输出是一个有限的上下文,包括业务用户,开发人员以及基础应用程序和数据库的所有级别的通用语言。

即使没有完全详细介绍,仍会开发流程图来定义应用程序工作流程,并绘制模型来描述应用程序屏幕和报告。流程图和模型的形式化带来了问题和挑战。它迫使团队成员考虑用户体验,功能和业务规则。随着团队讨论的进行,对领域和语言进行了微调,流程图和模型也进行了微调。

物理数据模型是从为应用程序逻辑,用户界面和报告提供服务所必需的查询中得出的。根据识别出的需求和约束条件,使用完整的非规范化技术和NoSQL设计模式。在测试驱动开发(TDD)方法中,即使在开发应用程序代码以通过测试之前,也要编写约束条件和业务规则的测试,并且数据建模工具可以生成大量符合模型的测试数据。

从那时起,以下工件将不断得到更新和同步:域模型,流程图,模型,体系结构设计,数据模型以及理想的测试计划。这些工件是团队成员之间定期讨论和协作的催化剂。理想情况下,这些讨论,讨论和对工件的微调会在每个周期的早期进行-在编写任何代码行之前。

尽管敏捷开发允许在项目的后期阶段定义细节,但定义好的基础越早,在将来进行的返工就越少。所有这些都是为了确保高质量的交付物,上市时间和总拥有成本。很快,就已经弄清了足够的基础,可以看到出现了一些模式,从而可以根据数据模型和应用程序代码的第一个版本创建原型。

所有应用程序涉众都进行协作以确保所构建应用程序的相关性。物理数据模型和应用程序代码将考虑整个技术堆栈的特定方面,包括NoSQL数据库。随着应用程序功能的成熟,需要考虑对操作,可伸缩性和性能的关注,这通常会导致对数据模型和代码的调整。

数据模型已根据特定的NoSQL数据库供应商的功能进行了验证,并进行了优化以利用这些功能。这包括存储方法,缓存,索引,查询功能和分片问题。

数据模型文档已成为生产中的活物,对业务用户,数据库管理员,数据治理和隐私保护人员有帮助。在设想应用程序增强时,在开发代码之前,需要与上述其他项目工件一起研究和考虑对数据模型的影响。

结论

尽管起点(业务需求)和终点(物理数据模型)与传统的概念-逻辑-物理方法中的相似,但两者之间的一切执行方式却有所不同。由于NoSQL的灵活性允许快速更改,因此需要重新考虑整个数据建模方法,以适应新技术和开发方法。需要下一代数据建模工具来支持新技术和方法。

最后,产品开发已更改为更MVP / fail-fast方法,软件开发已更改为敏捷/连续集成/ DevOps方法。数据建模成为一项越来越频繁的工作,需要更多的人以更少的块,更长的时间(包括在应用程序投入生产后)进行。

分享

信息管理的更多内容