关系数据库管理系统( RDBMS ) 代表了最先进的技术，这在一定程度上要归功于其由周边技术、工具和广泛的专业技能组成的完善的生态系统。
在这个涵盖信息技术(IT) 和运营技术(OT) 的技术革命时代，人们普遍认识到性能方面出现了重大挑战，特别是在NoSQL 解决方案优于传统方法的特定用例中。事实上，市场提供了许多解释和利用各种不同数据模型的NoSQL DBMS解决方案：
- 键值存储（例如，最简单的存储，其中对持久数据的访问必须是即时的，并且通过像哈希映射或字典这样的键进行检索）；
- 面向文档（例如，在无服务器解决方案和 lambda 函数架构中广泛采用，其中客户端需要直接从数据库获取结构良好的 DTO）；
- 面向图的（例如，对于知识管理、语义网或社交网络有用）；
- 面向列（例如，在查询驱动的建模方法中提供高度优化的"即用型"数据投影）；
- 时间序列（例如，用于处理物联网场景中的传感器和样本数据）；
- 多模型存储（例如，组合不同类型的数据模型以实现混合功能目的）。
"与那些完全不使用数据的人相比，使用不充分的数据时出现错误要少得多。"
一个较少被研究的问题是依赖于关系解决方案的软件架构能够灵活地适应软件领域和功能需求快速而频繁的变化。类似敏捷的软件开发方法加剧了这一挑战，这些方法旨在满足客户处理由其业务市场主导的不断出现的需求。
特别是，RDBMS 就其本质而言，当软件需求随着时间的推移而变化时，可能会受到影响，通过引入新的关联表（也替换预先存在的外键）并在 SQL 查询中生成新的 JOIN 子句，对数据库表格模式产生快速影响，从而导致更复杂且更难维护的解决方案。
根据我们的企业经验，我们已经成功实施并试验了基于Neo4j 图形数据库的面向图形的 DBMS 解决方案，以便在具有不同用户和角色的数字社交社区的典型操作环境中减轻需求变更的架构后果。
在这篇文章中，我们：
- 举例说明面向图形的 DBMS 如何更能满足功能需求；
- 讨论在经典的N层（分层）架构中采用面向图的DBMS的可行性，提出一些克服主要困难的方法；
- 强调在各种环境和用例中采用它们的优点和缺点以及威胁。
Neo4j 图形数据库
面向图的数据模型背后的思想是采用原生方法来处理实体（即节点）及其背后的关系（即边），以便通过导航实体之间的关系来查询知识库（即知识 图）。
Neo4j 图形数据库适用 于面向属性图，其中节点和边都拥有不同类型的属性属性。
我们选择它作为 DBMS，主要是为了：
- 它的"本机"实现是通过数字图元模型具体建模的，其运行时实例由节点（包含具有域属性的实体）和边（表示互连概念之间的可导航关系）组成。这样，关系的遍历时间为O(1)；
- Cypher查询语言被采用为图形中持久知识的非常强大且直观的查询系统。
此外，Neo4j 图形数据库还提供用于对象图形映射(OGM) 的Java 库，可帮助开发人员实现映射、持久化和管理模型实体、节点和关系的自动化过程。实际上，OGM 对于面向图形的 DBMS 的解释与对象关系映射( ORM )模式对于关系持久层的作用相同。
与为 RDBMS 设计的 ORM 模式相比，OGM 模式用于简化数据访问对象( DAO )的实现。它的主要功能是在源代码中正确配置和注释的持久域模型实体中启用半自动细化。
相对于被广泛认为是领先的 ORM 技术的Java Persistence API ( JPA )/Hibernate，Neo4j的 OGM 库以独特的方式运行：
写操作
- OGM 在托管实体的所有关系中传播持久性更改（从托管对象开始分析整个对象关系树）；
- JPA从托管实体开始逐表执行更新，并基于级联配置处理关系。
读操作
- OGM通过查询检索一整棵具有固定深度的"关系树"，从指定节点开始，充当"树的根"；
- JPA允许配置EAGER和LAZY加载方法之间的关系。
示例性案例研究的解决方案优势
为了举例说明我们分析的意义，我们引入一个简单的操作场景：图 1.1 中的 UML 类图描述了一个与实体 Auth（授权的缩写）具有 1 对 N 关系的 User 实体，该实体定义了应用程序内的权限和授权。这种领域模型可以通过类似于表 1.1 和表 1.2 的架构在关系型数据库管理系统（RDBMS）中支持，或者在面向图形的数据库管理系统中，如图 1.2 中的知识图所示。
图 1.1：领域模型的 UML 类图。
| USERS TABLE | ||
|---|---|---|
| id | firstName | lastName |
| ... | ... | ... |
表 1.1：在 RDBMS 架构中为 User 实体映射的表格。
| AUTHS TABLE | |||
|---|---|---|---|
| id | name | level | user_fk |
| ... | ... | ... | ... |
表 1.2：在 RDBMS 架构中为 Auth 实体映射的表格。
图1.2：与图1.1 的领域模型相关的知识图 。
现在，想象一下，在应用程序的生产生命周期期间出现了一个新的需求：出于管理原因，客户需要将授权限定在特定时间段内（即有效期的开始和结束日期），如图 2.1 所示，将 User 和 Auth 之间的关系转变为 N 对 N。这种领域模型可以通过类似于表 2.1 的架构在关系型数据库管理系统（RDBMS）中支持，或者在面向图形的数据库管理系统中，如图 2.2 中的知识图所示。
图 2.1：在定义新要求后的领域模型 UML 类图。
| USERS TABLE | ||
|---|---|---|
| id | firstName | lastName |
| ... | ... | ... |
表 2.1：在 RDBMS 架构中为 User 实体映射的表格。
| USERS_AUTHS TABLE | |||
|---|---|---|---|
| user_fk | auth_fk | from | until |
| ... | ... | ... | ... |
表 2.2：在 RDBMS 架构中用于存储 User 和 Auth 实体之间关联的表格。
| AUTHS TABLE | ||
|---|---|---|
| id | name | level |
| ... | ... | ... |
表 2.3：在 RDBMS 架构中为 Auth 实体映射的表格。
图 2.2：与图 2.1 领域模型相关的知识图。
在架构层面上的优势已经很明显：实际上，面向图形的方法没有改变架构，只是在边缘（建模关系）上定义了两个新属性，而 RDBMS 方法则创建了新的关联表 users_auths，替代了 auths 表中引用用户表的外键。
进一步深入分析，我们可以尝试分析 SQL 查询和用 Cypher 查询语言语法编写的查询在这两种方法下的区别：我们想要识别名为"Paul"的用户，他们拥有名为"admin"的 Auth，并且级别大于或等于 3。
一方面，在 SQL 中，所需的查询（分别是第一个查询用于从表 1.1 和表 1.2 检索数据，第二个查询用于表 2.1、表 2.2 和表 2.3）是：
sql
SELECT users.*
FROM users
INNER JOIN auths ON users.id = auths.user_fk
WHERE users.firstName = 'Paul' AND auths.name = 'admin' AND auths.level >= 3
sql
SELECT users.*
FROM users
INNER JOIN users_auths ON users.id = users_auths.user_fk
INNER JOIN auths ON auths.id = users_auths.auth_fk
WHERE users.firstName = 'Paul' AND auths.name = 'admin' AND auths.level >= 3另一方面，在Cypher 查询语言中，所需的查询（对于这两种情况） 是：
sql
MATCH (u:User)-[:HAS_AUTH]->(auth:Auth)
WHERE u.firstName = 'Paul' AND auth.name = 'admin' AND auth.level >= 3
RETURN u虽然 SQL 查询需要多一个 JOIN 子句，但值得注意的是，在这种特定情况下，不仅用 Cypher 查询语言编写的查询没有额外的子句或 MATCH 路径的变化，而且它也保持不变。后端的"查询系统"上没有必要进行任何更改！
结论
楔形工程作为国际项目中的技术合作伙伴，设计了一个协作社交平台，作为一个解耦的 Web 应用程序，在 3 层架构中由以下部分组成：
- 后端模块，一个分层的 RESTful 架构，利用 JakartaEE 框架；
- 知识图，由 Neo4j 图形数据库提供的 NoSQL；
- 前端模块，一个基于 HTML、CSS 和 JavaScript 的单页应用程序，利用 Angular 框架。
我们面临的最具挑战性的设计选择是使用原生利用 Cypher 查询语言的驱动程序还是利用 OGM 库简化 DAO 实现：我们发现使用 Cypher 查询语言编写的自定义查询构建整个应用程序既不可行也不可扩展，而 OGM 在处理涉及大量涉及引用外部实体的关系的大型数据层次结构时可能不够高效。
我们最终选择了一种自定义方法，利用 OGM 作为映射节点和边缘的参考解决方案，以 ORM 类型的视角，并支持特定 DAO 的实现，因此通过无法表现良好的自定义查询方法优化了时间上的优化。
总之，我们可以说采用的软件架构很好地响应了知识图模式的变化，并完全满足了客户需求，同时减轻了楔形工程开发团队的努力。
然而，在采用这种架构之前，必须考虑一些威胁：
- SQL 比 Cypher 查询语言更为常见 → 因此，更容易找到（并因此纳入开发团队）能够维护 RDBMS 而不是 Neo4j 图形数据库的代码的专家；
- Neo4j 的本地生产系统要求很高（即对于基于服务器的环境，至少推荐 8 GB）→ 这种解决方案可能不适合资源有限的场景和低成本实施；
- 在我们的最大努力下，我们没有找到任何"随时可以使用且易于使用"的开源编辑器来浏览 Neo4j 图形数据库的数据结构（Neo4j 的官方数据浏览器不允许通过 GUI 进行数据修改，除非自定义 MERGE/CREATE 查询），就像 RDBMS 有很多一样 → 这可能是由于特定的数据模型本身导致的，使得实现数据的表格视图变得困难。
作者：Cosimo Giani
更多技术干货请关注公号【云原生数据库】
squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。