V2EX - 技术

最近总是被 google 阻断连接
数据库表设计是否需要在字段前标注字段的所属对象，比如用户表的名字是 user_name,学校表的名字字段是 school_name
近期 1.2.4.8 DNS 出现大规模的 DNS 无响应
有人 idea 升级到 2021.1 遇到无法 import 的 bug 吗
唉，有点可怕，这开发者好像还在论坛的。还是官网下载的.....FinalShell.....
Hangouts 环聊不能用了吗？发不出消息
一起来从 0 到 1 开发可视化搭建项目吧！
RESTful API 设计最佳实践
Sony 新机 Xperia 1 III 能否在 Android 阵营站起来？
JetBrainsIDE 升级到 2021.1 大家有遇到 git 提交面板偶尔无法输入中文的情况吗？
最近个人抽空写的一个网页版的 SSH & SFTP 服务器连接工具，欢迎大家提建议（目前内测中）
移动端的未来是什么
有数据库建模和实际数据库同步的数据库建模工具吗
golang plugin mac 平台下交叉编译生成 .so 文件报错
mongodb 查询返回 value 而不是返回 key:value
Java 要不要转 .net 换个方向？大佬进来讨论下
Android 有没有可以升降 key、加减速播放的音乐播放器？
go 如何动态连接多个数据库
不懂就问：如何正确设计一个订单号？
如果有个 CRUD 工具会不会有兴趣用？
stackoverflow 上看到一个问题，不是很理解。
QQ 令 cpu 温度升高
对应届生来说客户端开发真的是劝退吗
图查询语言的历史回顾短文
谷歌的人机身份验证
公司 app 又被腾讯报毒了，有没人见过这情况，
jboss， JavaEE 这套东西还有人用吗，值得投入太多精力下去吗
IDEA 可以设置对某个单词高亮嘛
[flag 回收][密码学]分组密码的工作模式
间隙锁的危害场景
Foxmail 邮箱拖拽保存附件、右键另存附件的 MD5 不一致
在非 main 分支上使用 continuous deployment，真的好吗？
当有一个 PR 被 merged 到 A git repo 后，如何触发 B git repo 的 build，等等？
amd mxgpu 云主机安装了 win10 系统，安装 amd 官网驱动后，虚拟 GPU 没有成功驱动
为什么 leetCode 不能用 BigDecimal ？
系统二次验证大佬们有什么解决方案吗?
求大佬们推荐一个钉钉个人号的 API
如何使用 k8s 对外暴露 pods 的任意端口？
有什么方法可以取消在 Windows 里面 ctrl+鼠标滚轮缩放的功能？
Google 搜索这是发生甚么事了?
麻了， gdb 远程调试连不上

Posted: 15 Apr 2021 04:33 AM PDT

Our systems have detected unusual traffic from your computer network. Please try your request again later. Why did this happen?  This page appears when Google automatically detects requests coming from your computer network which appear to be in violation of the Terms of Service. The block will expire shortly after those requests stop.  This traffic may have been sent by malicious software, a browser plug-in, or a script that sends automated requests. If you share your network connection, ask your administrator for help — a different computer using the same IP address may be responsible. Learn more  Sometimes you may see this page if you are using advanced terms that robots are known to use, or sending requests very quickly.

包括但可能不限于 google 搜索、youtube，有时是其中一个阻断，有时是两个。直接 sorry，没有人机验证。同时被全球最大的搜索引擎和视频网站拒绝，这就很难受。

小心巨头。

数据库表设计是否需要在字段前标注字段的所属对象，比如用户表的名字是 user_name,学校表的名字字段是 school_name

Posted: 15 Apr 2021 04:32 AM PDT

这样写法会不会过于冗余。

近期 1.2.4.8 DNS 出现大规模的 DNS 无响应

Posted: 15 Apr 2021 04:31 AM PDT

前情提要 /t/770575

不知道为啥，其他国内 DNS 比如阿里腾讯都能解析的域名，该 DNS 无法解析

排查了一遍各种设备都没有问题，后来发现每次都是第一次响应解析失败、之后的响应几乎都能成功，第三次响应失败。想起 dnsmasq 一共配置了三个上游 DNS，第一个是 1.2.4.8，于是去 dig 了一下。

发现果然是 1.2.4.8 的问题。很多域名都无法解析了。更换上游 DNS 解决了这个问题。

顺便吐槽一下，为啥我前情提要的主题发在 Q&A 被移动到 Chrome 节点了，看的人都没有。

有人 idea 升级到 2021.1 遇到无法 import 的 bug 吗

Posted: 15 Apr 2021 04:31 AM PDT

如题，springboot 项目 idea 不能自动 import，即使我手动 import 了 idea 也爆红，但是项目是可以正常启动的。

唉，有点可怕，这开发者好像还在论坛的。还是官网下载的.....FinalShell.....

Posted: 15 Apr 2021 04:29 AM PDT

直接看图吧。。

官网下载。未登录账号。

打开工具后，首先访问官网:www.hostbuf.com/:443 （ ip: 101.32.72.254 ）

然后跟着访问备份的域名： backup.www.hostbuf.com:443 (域名用了 cdn) 80 端口为『免费内网穿透工具，无需公网 IP,无需设置路由器,100%穿透内网』

跟着访问内网穿刺网站： main.d1sm.net/:443 （ ip: 101.32.72.254 ）
www.youtusoft.com/:443 （ ip: 101.32.72.254 ） pwlt.wn1998.com/:443(域名用了 cdn) 80 端口为『免费内网穿透工具，无需公网 IP,无需设置路由器,100%穿透内网』

如果依然无网络，会访问 https://www.fcg51.com:443 其网站证书为：hostbuf.com

最后会访问 bing.com:80 ......

那么问题来了，一个 Shell 管理工具，我刚打开，你就访问这么多东西.最后还访问 bing 。。

官网无备案，服务器在 HK，官网是三无产品。你是做啥的呢？

Hangouts 环聊不能用了吗？发不出消息

Posted: 15 Apr 2021 04:25 AM PDT

Hangouts 环聊不能用了吗？发不出消息会是下面这个样子

一起来从 0 到 1 开发可视化搭建项目吧！

Posted: 15 Apr 2021 04:23 AM PDT

前言

笔者最近写了本关于可视化搭建方向的掘进小册，直接放链接： https://juejin.cn/book/6930553086918262798 同时为大家准备了 50 个 5 折优惠码，数量有限，先到先

小册介绍

在当下业务需求迭代飞快的互联网环境下，如何助力业务，为业务快速试错、迭代提供基础支持是不可规避的挑战之一。这其中最重要的一环就是"快"。有的时候为了满足业务诉求，我们不得不重复去开发一些活动页。所以你可能和我一样，非常想通过一款可以由运营自主组装页面的工具来自动生成页面，规避掉重复、无技术含量的劳动。

相比业界现状，不管在阿里还是腾讯等大厂都有适配自己内部业务诉求场景的一套可视化搭建体系。实现细节虽然有着出入但是核心思想都是希望把原本由开发人肉堆代码的活，通过可视化的方式表达给运营同学使用。或者通过 lowcode 的形式减少开发者的重复劳动。因为与业务相关，所以基本上都不会开源。而现在大多数开源的可视化搭建项目，也只是实现了部分可视化搭建的能力，并不能完全结合业务场景使用。

笔者希望借这本小册，一方面为没有接触过可视化搭建的同学提供一个解决问题的思路和方法。另一方面本小册将会从背景到架构设计再到技术实现细节来一步步介绍如何落地一个围绕业务场景的可视化搭建需求。

作者介绍

muwoo，前端攻城狮。之前在 51 信用卡搞过一年的可视化搭建平台鲁班，半年内发布了 1000+ 活动页。后面辗转反侧去了蚂蚁集团，接触到内部的云凤蝶项目，对自己的可视化搭建理念产生了一定的影响。现在团队内也落地了一套可视化搭建体系，也是踩过了颇多的坑。

你可以在这里找到我

Github: https://github.com/muwoo

知乎： https://www.zhihu.com/people/monkey-wang-

小册目录

<input checked="" disabled="" type="checkbox"> 1. 前言：可视化搭建诞生背景
<input checked="" disabled="" type="checkbox"> 2. 架构设计
<input checked="" disabled="" type="checkbox"> 3. 前置基础知识准备
<input checked="" disabled="" type="checkbox"> 4. 模板设计
<input checked="" disabled="" type="checkbox"> 5. 模板通信设计
<input checked="" disabled="" type="checkbox"> 6. 模板动态化设计
<input checked="" disabled="" type="checkbox"> 7. 稳定性-模板更新策略
<input checked="" disabled="" type="checkbox"> 8. 全局组件设计
<input checked="" disabled="" type="checkbox"> 9. 全局组件注册
<input checked="" disabled="" type="checkbox"> 10. 稳定性-组件更新策略
<input checked="" disabled="" type="checkbox"> 11. 设计实现 CLI 为开发助力
<input checked="" disabled="" type="checkbox"> 12. 可视化编辑区实现
<input checked="" disabled="" type="checkbox"> 13. 可视化编辑区 mock&预览
<input checked="" disabled="" type="checkbox"> 14. vue3 Form render 实现
<input checked="" disabled="" type="checkbox"> 15. Server 端编译实现
<input checked="" disabled="" type="checkbox"> 16. 发布流程设计
<input checked="" disabled="" type="checkbox"> 17. 写在最后
<input checked="" disabled="" type="checkbox"> 18. 加餐：当前可视化搭建未解决的问题
<input checked="" disabled="" type="checkbox"> 19. 加餐：H5 可视化搭建项目如何在本地跑起来

你会学到什么？

可视化搭建的历史背景和方向选择
了解可视化搭建的技术设计思想
可视化搭建的编辑区设计
可视化搭建动态表单设计
可视化搭建模板的设计
可视化搭建组件设计
可视化搭建 CLI 设计
可视化搭建发布流
可视化搭建页面更新策略和版本设计
可视化搭建页面的未来发展方向

适宜人群

熟悉常用的 js 框架 Vue 或者 React
对 h5 可视化搭建有兴趣的前端开发者

RESTful API 设计最佳实践

Posted: 15 Apr 2021 04:21 AM PDT

本文首发于刘星的个人网站 www.liuxing.io

简介

RESTful API 是目前最流行的 API 设计规范，它用于 Web 数据接口的设计。它允许包括浏览器在内的各种客户端与服务器进行通信。因此正确是设计我们的 RESTful 是相当重要的！我们的 API 必须安全、高性能、同时易于使用。

在本文我们将探讨如何设计出易于使用并且安全快速的的 RESTful API 。

RESTful API 即是基于 Rest 构建的 API 。那么在开始之前，我们先来看看 REST 是什么？

REST 与技术无关，它代表的是一种软件架构风格，REST 它是 Representational State Transfer 的简称，中文的含义是: 表现层状态转移(转移：通过 HTTP 动词实现)。即 URL 定位资源，HTTP 动词操作（ GET，POST，PUT，DELETE ）描述操作。

确保接受并响应 JSON 数据格式

RESTful API 应该接受 JSON 格式的请求，并返回的响应体也应该是 JSON 格式的。JSON 是一种数据传输标准，主流编程语言几乎都能很好的支持它。同时在浏览器中我们的 JavaScript 也能很轻松方便的操作这些数据。所以，以 JSON 格式编写的 RESTful API 具有简单、易读、易用的特点。

为了确保当我们的 RESTful API 服务使用 JSON 格式响应，我们应该将其响应头的Content-Type设置为application/json。

让我们来看一个接收 JSON 数据并返回 JSON 数据的 API 示例。本示例使用 Node.js 的 Express 框架。我们使用了 body-parser 中间件来解析 JSON 请求体，然后使用 res.json 返回传入的 JSON 对象。

const express = require('express'); const bodyParser = require('body-parser');  const app = express();  app.use(bodyParser.json());  app.post('/', (req, res) => {   res.json(req.body); });  app.listen(3000, () => console.log('server started'));

在本示例中 bodyParser.json() 将 JSON 请求体的字符解析为 JavaScript 对象，然后将其分配给该req.body对象。

在 API 路径中使用名词代替动词

RESTful API 是面向资源的 API，HTTP 动词操作（ GET，POST，PUT，DELETE ）描述操作。

我们不应该在 URL 路径中使用动词。我们应该使用要操作的实体的名词作为路径名。因为我们的 HTTP 请求方法本身就是动词，就能描述要进行的操作，如常见的方法包括 GET，POST，PUT 和 DELETE，这些请求方法即可完成 CRUD。

GET 检索资源。
POST 将新数据提交到服务器。
PUT 更新现有数据。
DELETE 删除数据。

例如，我们有个文章(/articles/)资源。我们对其进行 CRUD 的 RESTful API 如下：

使用 GET /articles/来获取文章列表
使用 POST /articles/ 添加新文章
使用 PUT /articles/:id 更新给定 ID 的文章
使用 DELETE/articles/:id 删除具有给定 ID 的文章

我们通过 Express 来实现上面这个增删改查的例子，如下所示：

const express = require('express'); const bodyParser = require('body-parser');  const app = express();  app.use(bodyParser.json());  app.get('/articles', (req, res) => {   const articles = [];   // code to retrieve an article...   res.json(articles); });  app.post('/articles', (req, res) => {   // code to add a new article...   res.json(req.body); });  app.put('/articles/:id', (req, res) => {   const { id } = req.params;   // code to update an article...   res.json(req.body); });  app.delete('/articles/:id', (req, res) => {   const { id } = req.params;   // code to delete an article...   res.json({ deleted: id }); });  app.listen(3000, () => console.log('server started'));

在上面的示例代码中，我们定义了 API 来操作文章(articles)资源。如我们所见，API URL 路径中使用的都是名词，作为动词的请求方法说明了 API 的操作意图。

使用名词复数

我们应该使用复数名词来命名集合。

通常，我们想要取得的数据都是一个集合，而不是单个项目。同时数据库中的表也是具有多个条目的。所以我们的 API 也应该使用复数名词，这样更合乎情理。

嵌套分层的资源对象

在处理嵌套资源的 API 时，应该将嵌套资源附加到父资源的路径之后。

例如一个文章有评论列表，获取某个文章的评论列表的 API 则为:

GET /articles/:articleId/comments

我们可以使用 express 来做个示范：

const express = require('express'); const bodyParser = require('body-parser');  const app = express();  app.use(bodyParser.json());  app.get('/articles/:articleId/comments', (req, res) => {   const { articleId } = req.params;   const comments = [];   // code to get comments by articleId   res.json(comments); });   app.listen(3000, () => console.log('server started'));

使用标准的 http 状态码

为了消除 API server 发生错误时用户的困惑，我们应该优雅地处理错误，并返回指示发生了具体错误的 HTTP 响应代码以及明确的错误信息。这可以很好的为 API 使用者提供了足够的信息来了解所发生的问题。

常见的错误 HTTP 状态代码包括：

400 错误的请求 – 这意味着客户端输入验证失败。
401 未经授权 - 这意味着用户无权访问资源。通常在用户未通过身份验证时返回。
403 禁止访问 - 表示用户已通过身份验证，但不允许其访问资源。
404 Not Found – 表示找不到资源。
500 内部服务器错误 – 这是一般服务器错误。它可能不应该明确地抛出。
502 错误的网关 - 这表明来自上游服务器的无效响应。
503 服务不可用 – 这表示服务器端发生了意外情况（可能是服务器过载，系统某些部分发生故障等）。

我们应该抛出服务错误相对应的错误码。例如，如果我们要拒绝客服端发起的请求，则应在 Express API 中返回如下所示的 400 响应：

const express = require('express'); const bodyParser = require('body-parser');  const app = express();  // existing users const users = [   { email: 'abc@foo.com' } ]  app.use(bodyParser.json());  app.post('/users', (req, res) => {   const { email } = req.body;   const userExists = users.find(u => u.email === email);   if (userExists) {     return res.status(400).json({ error: 'User already exists' })   }   res.json(req.body); });   app.listen(3000, () => console.log('server started'));

在上面的示例中，用户尝试创建一个已经存在的 user，将获得 400 响应状态代码，并带有一条'User already exists' 的错误消息，让用户知道该用户已经存在。利用这些信息，用户可以通过使用其他 email 来创建新用户。

通常错误代码需要附带明确错误消息，以便用户有足够的信息来了解自己遇到了什么问题。

每当我们的 API 未成功调用时，都应通过发送明确的错误信息来帮助用户采取纠正措施来完成操作。

添加过滤，排序和分页功能

通常我们的数据都会非常庞大。我们不可能一次全部返回，这会非常慢也可能导致系统崩溃。因此，我们需要有过滤，分页数据的方式。过滤和分页都可以通过减少消耗服务器资源来提高性能。这些功能相当基础且重要。

分页、过滤、排序查询都功能都应该使用查询参数来实现。如：

/employees?page=1&pageSize=10&firstName=Xing

下面这就是一个带有过滤查询的示例：

const express = require('express'); const bodyParser = require('body-parser');  const app = express();  // employees data in a database const employees = [   { firstName: 'Jane', lastName: 'Smith', age: 20 },   //...   { firstName: 'John', lastName: 'Smith', age: 30 },   { firstName: 'Mary', lastName: 'Green', age: 50 }, ]  app.use(bodyParser.json());  app.get('/employees', (req, res) => {   const { firstName, lastName, age } = req.query;   let results = [...employees];   if (firstName) {     results = results.filter(r => r.firstName === firstName);   }    if (lastName) {     results = results.filter(r => r.lastName === lastName);   }    if (age) {     results = results.filter(r => +r.age === +age);   }   res.json(results); });  app.listen(3000, () => console.log('server started'));

保持良好的安全意识

客户端和服务器之间的大多数通信应该是私有的。因此，必须使用 SSL/TLS 进行安全保护。现在加载 SSL 成本是相当低的。我们没有理由不使用它。

同时，不同的用户具有不同的数据访问权限。例如，普通用户不应该能够访问其他用户的信息。他们也不应该能够访问管理员的数据。

适当缓存数据以提高性能

可以适当添加缓存服务，从缓存中返回常用数据，而不是每次都从数据库去读取。缓存的好处是可以更快地获取数据，但是也让我们获取最新的数据变得复杂。缓存方式有很多如：Redis 、内存缓存( in-memory cache)等等，我们应该根据自己的应用具体情况来选择是不是该用缓存，使用哪种缓存机制。

这儿我们来使用 Express 的apicache中间件来实现一个简单的内存缓存:

const express = require('express'); const bodyParser = require('body-parser'); const apicache = require('apicache'); const app = express(); let cache = apicache.middleware; app.use(cache('5 minutes'));  // employees data in a database const employees = [   { firstName: 'Jane', lastName: 'Smith', age: 20 },   //...   { firstName: 'John', lastName: 'Smith', age: 30 },   { firstName: 'Mary', lastName: 'Green', age: 50 }, ]  app.use(bodyParser.json());  app.get('/employees', (req, res) => {   res.json(employees); });  app.listen(3000, () => console.log('server started'));

版本化我们的 API

原则上我们应该尽量让 API 避免破坏性变更，保持向后兼容。但是经常有些时候破坏性的变更是不可避免的，这时版本化的 API 就派上用场了。当我们发布了不兼容或重大更改变，则可以将其发布在新版本中的 API 。

我们通常通过 URL 来实现版本化，及添加版本号在我们 API 路径的开头，例如：api.liuxing.io/v1 api.liuxing.io/v2

我们可以在 express 很简单的实现版本化的 RESTful API:

const express = require('express'); const bodyParser = require('body-parser'); const app = express();  app.use(bodyParser.json());  app.get('/v1/employees', (req, res) => {   const employees = [];   // code to get employees   res.json(employees); });  app.get('/v2/employees', (req, res) => {   const employees = [];   // different code to get employees   res.json(employees); });  app.listen(3000, () => console.log('server started'));

总结

设计高质量 RESTful API 的最重要的一点是遵循 Web 标准和约定以保持一致性。JSON 、SSL/TLS 和 HTTP 状态代码都是现代 Web 的标准。性能也是重要的考虑因素。我们可以使用分页、缓存等手段来提升性能。可维护性可扩展性也是我们需要考虑的。

前言

最近在对图查询语言 GQL 和国际标准草案做个梳理，调研过程中找到下面这篇 mark 了没细看的旧文（毕竟收藏就是看过）。做个简单的记录。

摘要

本短文会涉及到的图查询语言有 Cypher 、Gremlin 、PGQL 和 G-CORE 。

背景

本文主要摘录翻译自 [Tobias2018] （见参考文献），并未涉及到 SPARQL 和 RDF，只讨论了属性图。

文章撰写的时间是 2018 年，可以看做 GQL （ Graph Query Language ）的一些前期准备。GQL 有多个相关的起源，参见下面这张图。

graph-query-language-review

因为 Cypher 的历史和 Neo4j 紧密相关，本文会提一些 Neo4j 早期的历史。[Angles2008]（见参考文献）和 [Wood2012]（见参考文献）是两个不错的关于图模型和图查询语言的总结。

年表简述

2000 年，Neo4j 的创始人产生将数据建模成网络（ network ）的想法。
2001 年，Neo4j 开发了最早的核心部分代码。
2007 年，Neo4j 以一个公司的方式运作。
2009 年，Neo4j 团队借鉴 XPath 作为图查询语言，Gremlin 最初也是基于这个想法。
2010 年，Neo4j 和 Marko Rodriguez 采用术语属性图（ Property Graph ）来描述 Neo4j 和 Tinkerpop / Gremlin 的数据模型。[PG2010]（见参考文献）
2011 年，第一个公开发行版本 Neo4j 1.4 发布了第一个版本的 Cypher 。
2012 年，Neo4j 1.8 为 Cypher 增加写入图的能力。
2012 年，Neo4j 2.0 增加了标签和索引，Cypher 成为声明式的语言。
2015 年，Oracle 为 PGX 发明查询语言 PGQL 。
2015 年，Neo4j 将 Cypher 开源为 openCypher 。
2015 年，LDBC 成立图查询语言工作组。
2016 年，LDBC 工作组开始设计 G-CORE 。
2017 年，WG3 工作组开始讨论如何将属性图查询能力引入 SQL 。
2017 年，LDBC 工作组完成了 G-CORE 的初始设计 [GCORE2018]（见参考文献）。
2018 年，Cypher 形式化语义的论文发表 [Cypher2018] （见参考文献）。

Gremlin 、Cypher 、PGQL 和 G-CORE 的演进

Neo4j 的早期历史

Neo4j 和属性图这种数据模型，最早构想于 2000 年。Neo4j 的创始人们当时在开发一个媒体管理系统，所使用的数据库的 schema 经常会发生重大变化。为了支持这种灵活性，Neo4j 的联合创始人 Peter Neubauer，受 Informix Cocoon 的启发，希望将系统建模为一些概念相互连接的网络。印度理工学院孟买分校的一群研究生们实现了最早的原型。Neo4j 的联合创始人 Emil Eifrém 和这些学生们花了一周的时间，将 Peter 最初的想法扩展成为这样一个模型：节点通过关系连接，key-value 作为节点和关系的属性。这群人开发了一个 Java API 来和这种数据模型交互，并在关系型数据库之上实现了一个抽象层。

虽然这种网络模型极大的提高了生产力，但是性能一直很差。所以 Neo4j 联合创始人 Johan Svensson 花精力，为这种网络模型实现了一个原生的数据管理系统。这个就成为了 Neo4j 。在最初的几年，Neo4j 作为一个内部产品很成功。在 2007 年，Neo4j 的知识产权转移给了一家独立的数据库公司。

Neo4j 的第一个公开发行版中，数据模型由节点和有类型的边构成，节点和边都有 key-value 组成的属性。Neo4j 的早期版本没有任何的索引，应用程序只能从根节点开始自己构造查询结构（ search structure ）。因为这样对于应用程序非常笨重，Neo4j 2.0 （ 2013 年 12 月发布）引入了一个新概念——点上的标签（ label ）。基于点标签，Neo4j 可以为一些预定义的节点属性建立索引。

节点、关系、属性、关系只能有一个标签、节点可以有零个或者多个标签，以上这些构成了 Neo4j 属性图的数据模型定义。后来增加的索引功能，让 Cypher 成为了与 Neo4j 交互的主要方式。因为这样应用开发者只需要关注于数据本身，而不是上段提到的那个开发者自己构建的查询结构（ search structure ）。

图或者说网络类型的数据模型（多对多的关系）和其数据库的历史，可以追溯到 80 年代。见 Kleppmann 2017 第二章（见参考文献部分）。

Gremlin 的创造

最初与 Neo4j 的查询方式是通过 Java API 。应用程序可以将查询引擎作为库嵌入到应用程序中，然后使用 API 查询图。如果是自定义查询引擎，然后应用程序远程访问服务器，这样就比较困难。

就在这段时间，NOSQL 这个概念开始出现。NOSQL 型的数据库引擎一般用 REST 和 HTTP 来交互和查询。Neo4j 的早期员工 Tobias Lindaaker （和 Ivarsson ）考虑用 HTTP 的方式访问 Neo4j 会是一种更好的办法。他们观察到很多的查询语句可以表达为：图到树的投影映射（ projection ）。典型的，从根节点开始遍历一个扩张树（ spanning tree ），然后返回叶子节点。基于这样的观察，并参考一些树结构的查询语句，比如 XPath，也许可以作为一种图的查询方式。而且，XPath 的语法和一般 URI 的语法很像。这样 XPath 查询可以很自然的作为 HTTP GET 中 URI 的一部分。Neo4j 的联合创始人 Peter Neubauer 喜欢这个想法，找了一个朋友 Marko Rodriguez 来干。两天后，Marko 做了一个原型，用 XPath 作为图查询，Groovy 提供循环结构，分支，和计算。这个就是 Gremlin 最初的原型。2009 年 11 月发布了第一个版本。

后来，Marko 发现同时用两种不同的解析器（ XPath 和 Groovy ）有很多问题，就将 Gremlin 改为基于 Groovy 的一种内置的领域特定语言（ DSL ）。

Cypher 的创造

Gremlin 和 Neo4j 的 Java API 一样，最初用于表达如何查询数据库的一种过程（ Procedural ）。它允许更短的语法来表达查询，也允许通过网络远程访问数据库。Gremlin 这种过程式的特性，需要用户知道如何采用最好的办法查询结果，这样对于应用程序开发人员来说仍旧有负担。基于声明式语言 SQL 的成功：SQL 可以将获取数据的声明方式和引擎如何获取数据分开，Neo4j 的工程师们希望开发一种声明式的图查询语言。

2010 年，Andrés Taylor 作为工程师加入 Neo4j，在此之前他是 SQL DBA 。他开始了一个项目，受 SQL 启发，其目标是开发图查询语言，而这种新语言 Cypher 于 2011 年 Neo4j 1.4 发布。

Cypher 的语法基础，是用 "ascii 艺术(ascii art)" 来描述图模式。这种方式最初来源于 Neo4j 工程师团队在源代码中评注如何描述图模式。可以看下图的例子：

graph-query-language-review

ascii art 简单说，就是如何用可打印文本来描述点和边。Cypher 文本用（）表示点，-[]->表示边。(query)--[modeled as]->(drawing) 来表示起点 query，终点 drawing，边 modeled as 。

对于程序员来说，当然可以设计一个 API 表示操作点，一个 API 表示操作边. 但这样就不是 SQL 这种声明式语言的目的，对于非程序员使用也太困难。

Cypher 第一个版本实现了对图的读取，但是需要用户说明从哪些节点开始查询。只有从这些节点开始，才可以支持图的模式匹配。

略微学术一点的说，graph patterns （或者 motifs finding ）和 navigational expression 是两种不同的图查询操作[Renzo2017][databricks2020]（见参考文献部分）。不同语言这两种操作的语义是有一定差别的。

在后面的版本，2012 年 10 月发布的 Neo4j 1.8 中，Cypher 增加了修改图的能力。但查询还是需要指明从哪些节点开始。

2013 年 12 月，Neo4j 2.0 引入了 label 的概念，label 本质上是个索引。这样，查询引擎就可以利用索引，来选择模式所匹配到的节点，而不需要用户指定开始查询的节点。

有没有熟悉的感觉？

随着 Neo4j 的普及，Cypher 有着广泛的开发者群体，和各行各业的使用。

图查询语言也有声明式（ Decalarative ）和命令式（ Imperative ）的区别，前者（ Cypher ）相比后者（ Gremlin ）更强调目的和手段分离，更依赖于执行优化。但在工程上，两者思想并没有那么大的区别，后者也会有延迟计算和优化，前者也可以部分命令式的思想。好的优化在工程上并不是那么容易，专业的用户比查询引擎更清楚如何求取、访问、加工数据[Renzo2017][Deutsh2020]。

openCypher - 一种推进和标准化 Cypher 的开源过程

2015 年 9 月，Neo4j 开放了 Cypher 查询语言，通过开源的方式来治理。这个新主体的治理主体是 openCypher Implementors Group （ oCIG ）。

2016 年，openCypher 项目发布 EBNF 和 ANTLR4，Neo4j 也贡献了很多基于 Apache 2.0 的语言功能测试集（ openCypher Technology Compatibility Kit, TCK ）。将这些作为语言标准定义，任何人都可以为该语言提交新的提议。2016 年，SAP HANA Graph 发布了基于 Cypher 的查询部分的实现，Agens Graph 和 Redis Graph 在 2017 年支持了 Cypher 。2017 年 oCIG 也进行了一系列线上线下的会议，讨论语言功能扩展等。

这个治理和讨论方式可以通过如下方式：https://github.com/opencypher/openCypher/blob/master/CIP-PROCESS.adoc

oCIG 发布 openCypher，采用英语语言作为规范，对应了 Neo4j 3.3.0 版本中的 Cypher 。

PGQL 的创建

2015 年，Oracle 为 PGX 引擎开发了图查询语言 PGQL 。PGQL 受 Cypher 的启发，也和 Cypher 很接近。

G-CORE 的创建

Linked Data Benchmarking Council （ LDBC ）定义了一种厂商无关的基准测试。在开发这个基准测试的过程中，他们发现市面上没有标准的查询语言来表达图查询。为了处理这个问题，成立了一个特别工作组，调研市面上已经存在的图查询语言和框架，定义图查询必须的功能，然后为现有语言提供修改建议。

2016 年，他们想设计一种新语言，而不是对于现有语言的修改。主要原因是不想受现有语言的模型的限制。

G-CORE 是由 LDBC 工作组设计的，但主要受 Cypher 的启发，采用一样的语义。

结论

Cypher 是 PGQL 和 G-CORE 的共同祖先。这几个语言的语法和语义都非常的接近。PGQL 更接近一些早期的 Cypher，而 G-CORE 更期望语法和语义上都与 Cypher 兼容。

一些个人看法

除去学术上的探索和一些零散的工程尝试，以 Cypher 作为主流属性图查询语言工程实践的历史基准，也就 10 年的时间。在前面的几年 2010-2013，Cypher 自身在基础图功能上还有不少缺失，比如索引、图模式，迭代到 2014 年才产生当前使用的一个主流版本，并且还在持续演化 [Nadime2018]（见参考文献部分）。

重头全新设计一种图语言其实很难，很可能会把前人走过的路（坑）再走（掉）一遍（ G-CORE 和 nGQL ）。这是 GQL 第一个不容易的地方。

一个标准化组织中，有学术和商业机构，各自诉求也很不相同，商业机构已经各自有庞大的商业使用群体，这是第二个不容易的地方。

制定完的标准，最后是否会被市场所接受和采纳（ vendor 、custormer 、developer 、goverment ），又需要多少的布道。这是 GQL 第三个不容易的地方。

除了核心基础的图操作以外的特性，比如 SQL 、pregel [Grzegorz2010]（见参考文献部分）、GNN，每个语言 PGQL 、GSQL 甚至 Neo4j 自己都各自采用了完全不同的方式来支持这些特性，要不要考虑这些新出现的特性。这是 GQL 第四个不容易的地方。

再想想 GQL 和 Apache Tinkerpop/Gremlin 这两条完全不同的路，这是一个变化很快的时代，计算机又是一个更强调 de facto 标准的行业，GQL 并不容易。(打脸）

参考文献

[Angles2008] Renzo Angles and Claudio Gutierrez, "Survey of Graph Database Models", ACM Computing Surveys, Vol. 40, February 2008
[PG2010] Marko A. Rodriguez and Peter Neubauer, "The Graph Traversal Pattern", April 2010
[Wood2012] Peter Wood, "Query Languages for Graph Databases", SIGMOD Record 2012
[Cypher2018] Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor, "Cypher: An Evolving Query Language for Property Graphs", SIGMOD 2018
[GCORE2018] Renzo Angles, Marcelo Arenas, Pablo Barceló, Peter Boncz, George Fletcher, Claudio Gutierrez, Tobias Lindaaker, Marcus Paradies, Stefan Plantikow, Juan Sequeda, Oskar van Rest, and Hannes Voigt, "G-CORE A Core for Future Graph Query Languages", SIGMOD 2018
[Cypher9] openCypher, "Cypher Query Language Reference", Version 9, Nov. 2017
Renzo2017 Renzo Angles, Marcelo Arenas, Pablo Barceló, Aidan Hogan, Juan Reutter, and Domagoj Vrgoč. 2017. Foundations of Modern Query Languages for Graph Databases. ACM Comput. Surv. 50, 5, Article 68 (November 2017), 40 pages.
Kleppmann2017 Kleppmann, Martin: Designing Data-Intensive Applications. Beijing : O'Reilly, 2017. - ISBN 978-1-4493-7332-0
[Tobias2018] Title: An overview of the recent history of Graph Query Languages. Authors Tobias Lindaaker, U.S. National Expert.Date: 2018-05-14
Deutsh2020 Alin Deutsch, Yu Xu, Mingxi Wu, and Victor E. Lee. 2020. Aggregation Support for Modern Graph Analytics in TigerGraph. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (SIGMOD '20). Association for Computing Machinery, New York, NY, USA, 377–392.
Grzegorz2010 Grzegorz Malewicz, Matthew H. Austern, Aart J.C Bik, James C. Dehnert, Ilan Horn, Naty Leiser, and Grzegorz Czajkowski. 2010. Pregel: a system for large-scale graph processing. In Proceedings of the 2010 ACM SIGMOD International Conference on Management of data (SIGMOD '10). Association for Computing Machinery, New York, NY, USA, 135–146.
Nadime2018 Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor. 2018. Cypher: An Evolving Query Language for Property Graphs. In Proceedings of the 2018 International Conference on Management of Data (SIGMOD '18). Association for Computing Machinery, New York, NY, USA, 1433–1445.
databricks2020https://docs.databricks.com/spark/latest/graph-analysis/graphframes/user-guide-scala.html#motif-finding

交流图数据库技术？加入 Nebula 交流群请先填写下你的 Nebulae 名片，Nebula 小助手会拉你进群~~

查看大厂实践案例？Follow Nebula 公众号：NebulaGraphCommunity 回复「 PPT 」掌握 [美团的图数据库系统] 、 [微众银行的数据治理方案] 以及其他大厂的风控、知识图谱实践。

Thursday, April 15, 2021

V2EX - 技术

V2EX - 技术

前言

小册介绍

作者介绍

小册目录

你会学到什么？

适宜人群

简介

确保接受并响应 JSON 数据格式

在 API 路径中使用名词代替动词

使用名词复数

嵌套分层的资源对象

使用标准的 http 状态码

添加过滤，排序和分页功能

保持良好的安全意识

适当缓存数据以提高性能

版本化我们的 API

总结

更多推荐

项目背景：

需要实现的功能：

尝试与疑问：

备注：

前言

摘要

背景

年表简述

Gremlin 、Cypher 、PGQL 和 G-CORE 的演进

Neo4j 的早期历史

Gremlin 的创造

Cypher 的创造

openCypher - 一种推进和标准化 Cypher 的开源过程

PGQL 的创建

G-CORE 的创建

结论

一些个人看法

参考文献

推荐阅读

No comments:

Post a Comment