说明
上篇介绍了一下设计方面的想法,这篇主要考虑一下图系统构建工程化的思路。
内容
1 几部分组件
1.1 前端到mongo数据库
我希望这是可以直接辅助工作的,减少负担的系统。在使用上没有比网页来的更简单的了,这部分实践过,基本认为只是消耗时间。
1.2 python到mongo(几种模式)
python到mongo的操作就那些,但是我希望用不同的逻辑去构建。至少需要主表和日志表,日志表和主表之间根据操作号进行同步更新。
主要是可以确保回溯到某个时期的操作。
1.3 python到neo4j的方式
通过py2neo,以cypher操作为主,要完成df向图库的录入,更新和删除。主要采取的逻辑是按照neo4j import
约定的样式:
- 1 节点表和关系表分开
- 2 先建节点表再建关系表
- 3 每次的操作最多是一类关系表
- 4 节点表可以一次录入
比较重要的实现是子图操作。根据某个标签号或者cypher模式,批量的选择节点及关系(子图),重新映射为python对象,处理后再重新映射回图库的过程。
2 一些原则
功能极简
按照实现功能的最简单的考虑进行设计和实施,不需要考虑太复杂的内容。例如考虑project_id和schema_id是合理和必须的,而user_id,company_id就有点没必要。
两端到中间,中间到完成
最终如何实现一定是有n种办法的,因为太复杂,具体实现的办法无法事先确定。一种可行的方法是从确定的两端逼近:
- 1 需求端:我想要做成什么样的功能
- 2 工具端:目前我有哪些可用的工具
整个过程是一个折中的过程,需要尽量砍掉现阶段次要的功能;在工具端只需要构建能满足现阶段使用的部件即可,不要盲目扩大。
3 实践先行
等待是下策。
以知识管理为例,可以先基于子图进行表格的录入,直接写入图库进行测试。连接是第二步的事。
以建模过程为例:
- 1 子图名称: SubGraphModelProcess
- 2 节点:原始数据、描述元数据…
- 3 关系:缺失检查
其中特征工程可能又比较复杂,可以将其压缩为一个”节点“。这个节点更多是逻辑上的,事实上是一个子图:
- 1 子图名称:SubGraphFeatureEngineering
- 2 节点:原始数据,差分数据…
- 3 关系:时间特征提取…
连接可以有通用连接,以表达其构造方式,也可以有具体连接,以表达其特定技术。
通用连接有:
- 1 依赖 DependsOn
- 强依赖 Strong:没有就会无法执行
- 弱依赖 Weak: 没有可能会有报警,但不影响执行。
- 2 有关系 HasRelWith
- 等价关系:Same
- 互补关系:Mutex
- 相反关系:Opposite
- 构成部分:ComposeOf
- 递进关系:Upgraded
节点和节点之间如果有关系,那么一定有通用连接,反之未必
具体可以把一些工作内容按照图的方式梳理,然后和neo4j交互,特别是子图交互,看看效果。