ZMonster's Blog 巧者劳而智者忧,无能者无所求,饱食而遨游,泛若不系之舟

2020-11-19: Neo4j 多 DB, 笔记的目的

尝试在本周每天写一个当日摘要发到博客上,对于当日摘要要写些什么东西,暂定会有「笔记」和「时间」两块,不过我的想法随时可能会变,也许会在之后的几天产生新的想法,这一周时间一来是想确认一下我每天可以输出什么东西,然后也看一下自己是否能坚持这种写作方式吧。

今天加了一节「想法」,改了一下标题。

想法

写当日摘要第四天了,老实说感觉挺困难的,因为不是每天都能学到新的有价值的知识分享出来,像今天展示的笔记内容,其实没有一条是今天才创建的,十点多的时候我就在发愁今天写些什么好,想不出来,干脆去整理自己的笔记(因为存在不少笔记的层次混乱或者没有填充具体内容),在这个过程中想到今天得知的 Neo4j 新版变化,然后才整理了点东西出来。

我开始这个博客写作的短期计划,其主要目的之一是想尝试用输出的行为去倒逼我完善自己的知识管理系统,因为我发现我最近一段时间陷入了一个机械式学习东西然后往笔记库里填充材料的不良状态,除了看到笔记越来越多,得到的其他反馈很少。那么这个写作的计划有没有效果呢?确实是有的,现在我每天在扫资料的时候,开始会自发地询问自己看的这些东西是否有分享出去的价值、是否能和我已有的知识关联起来。

不过一天一篇还是感到有点累了,好在今天是周四了,周五熬过去,周末会有更多的时间用来做学习和写作的事情。

笔记

20201119-daily-notes.png

  • 术语: 知识图谱

    知识图谱并没有一个非常清晰的定义,大致可以用来泛指以图的结构存储实体以及实体之间关系,并以此来表示人类知识的一种知识库。其实通过结构化数据来表示并应用人类的知识,这是人工智能这一领域最早的时候符号主义学派的主张,自动定理证明、棋类 AI、游戏 AI 都和这个思想有关,这一条路子的发展在上世纪 80 年代左右的时候随着专家系统的商用达到顶峰。

    我做过一段时间知识图谱相关的工作,这一方向的主要问题是,构建图谱很困难 —— 先不说应用阶段是否有足够强的推理算法能力,因为如果真的要在知识图谱上建立起丰富强大的应用,一个大前提是要有一个足够大的、细节足够完善的知识图谱,而构建知识图谱是一个系统性工程,不是一个不可分割的原子问题,这就决定了没有一个单独的工具或流程能解决它,但目前也并没有成套的、成熟的、易用的解决方案。

  • 术语: 图数据库

    所谓图数据库是一种 NoSQL 数据库,相比于 MySQL 之类的关系数据库(RDBMS),能更灵活地表示数据,这种灵活性体现在多方面:

    1. 像所有 NoSQL 数据库一样可以灵活地设计、扩展 schema
    2. 更适合表示实体之间的关系,特别是当实体之间存在大量的、复杂的关系的时候

    图数据库强调实体和关系两个基本概念,虽然说在关系数据库中也可以表示实体和关系,但如果关系的种类繁多且实体之间通过关系构成复杂的结构的时候,用图数据库可能会更合适一些。此外,图数据库会对一些常见的图操作进行支持,典型的比如查询最短路径,如果用关系数据库来做就会比较麻烦。

    知识图谱数据是比较典型的图数据。

  • 软件: Neo4j

    Neo4j 是一个流行的、Java 编写的图数据库,有比较易用的查询语句和可视化操作界面,我在之前写过一篇相关的介绍文章

    今年二月份 Neo4j 发布了 4.0 版,终于支持多 database 了 —— 多 database 这种在关系数据库中非常基本的功能,Neo4j 4.0 之前的版本是不支持的,这就导致当我们想要隔离数据时不得不部署多个 Neo4j 应用,管理起来非常的麻烦。

    为什么二月份发布的我现在才知道呢?因为很久没碰知识图谱这块了,但这周我司升级狂魔 SA 在迁移集群资源的时候发现了这个更新并告知了我。有多 database 功能的话,我构想中的基于 org-mode 和 Neo4j 的知识管理工具就更有吸引力了啊(然而挖坑半年了)。

  • 插件: ob-cypher

    主页: https://github.com/zweifisch/ob-cypher

    一个让 Emacs 用户能在 org-mode 的代码块中写 Neo4j 的查询语言并执行得到结果的插件,如下图所示:

    ob-cypher.png

时间

20201119-time-usage.png