Hello gophers,

We plan to issue Go 1.13.2 and Go 1.12.11 on Wednesday, October 16.
These are minor releases to fix security issues.

Following our policy at https://golang.org/security,
this is the pre-announcement of those releases.

Cheers,
Katie on behalf of the Go team

摘要

本文翻译自 CMSWire 网站的《Open Source vs. Open Core: What's the Difference?》，主要介绍 Open Source 和 Open Core 的区别。Open Source 已广为人知，那么 Open Core 又是什么，在开源软件盛行的今天，二者会怎样影响这个市场呢？

开篇之前，我们先回到一个 2013 年 CMSWire 向行业内专家提出一个问题：专有软件（ proprietary software ）和开源软件 ( open source），哪个更好？当时就这个问题业内人士没有达成共识，而现在这个问题似乎已经失去其存在价值。

开源无处不在

Constellation Research 副总裁兼首席分析师 Holger Mueller 曾表示——“开源无处不在“，而专有软件供应商过去的经历也证实了这一点。开源代码促进了专有软件的发展，反观专有软件也是开源项目的重要贡献者。许多大厂，如：思科，谷歌，IBM，微软，Pivotal，SAP，SUSE 也都是 Cloud Foundry Foundation 的成员，此外， Red Hat 也被归类到开源公司行列， 拥有 4,550 名员工为开源项目贡献代码的微软也不例外。无独有偶，除微软外，亚马逊，IBM 和 SAP 也位列开源代码贡献榜单的前十名。

尽管 Open Source 盛行，大多数软件供应商并不会给自己贴上“Open Source”的标签。这是为什么呢？此外，还有些公司自称“Open Core” 或附加额外许可证以限制其开源代码的使用，比如，Confluent 使用 Confluent Community 许可证而 MongoDB 使用 SSPL 许可证，背后的原因又是什么呢？

Open Source 和“免费开源软件”（FOSS）的开发者和爱好者对开源以及非开源的讨论充满热情，他们讨论关于“free”的不同含义，比如“免费软件”（free, as in beer）和“开源软件”（free as in libre）。但对于大多数开发者而言，尤其是面向 GitHub 编程的这类人，他们从 Github 上获取需要的代码为他们所用，却不会关注对应软件的许可证。正如 Mueller 所说，“PM 只在意代码运行结果和开销并不在意开发是如何实现的，因此造成开发者对许可证的不敏感”。

但开发者、PM，或正在阅读本文的你，真的应该去关注许可证吗？来，我们研究下企业在听到“开源”时，他们在想什么。

管理者如何看待 Open Source

作为 Host Analytics、Marklogic 的前首席执行官和 Nuxeo 的董事，软件主管戴夫·凯洛格（Dave Kellogg）说过，人们在面对开源时会混淆两件事：源代码和商业模式。在涉及到源代码时，凯洛格指出需要考虑以下方面：

1. 代码访问：代码是否可见，可获取，可更改等？
2. 代码作者：它是由谁编写的？是开源社区中的成千上万贡献者共同编写，还是来自软件供应商的工程师编写？

比如 Drupal 有来自社区的 114,702 个贡献者，而 MongoDB 99％ 的代码是由其员工编写。

说到商业模式，大多数情况下开源软件是“免费的”，假设不是直接从 Apache Software Foundation 或 Eclipse Foundation 这样机构获取所使用的代码，Kellogg 建议我们直接研究开源项目的供应商是如何赚钱的。

开源软件有如下商业模式：

1. 纯服务模式，比如，之前的 Hortonworks （现在的 HDP—— Hortonworks 发行版），用户只需为技术支持及咨询服务买单。
2. Open Core 模式，比如，大家熟悉的 Elastic，部分产品是免费，而高级版本或附加组件则使用商业许可证（参考：社区版和企业版）。正如凯洛格指出的那般，"开源软件供应商最大的竞争对手往往是他们自己的免费社区版"。
3. SaaS 模式，比如，Databricks，供应商将其开源软件作为服务托管在云上，通过收取每月/每年的托管和服务费获利。

Gartner 分析师 Nick Heudecker 是这样区分 Open Core 与 Open Source 的："Open Core 是以 Open Source 为基础的商业产品。Open Source 既是一种开发形式，也是一种源代码的许可方式"。

Heudecker 在博客中提出：

Open Source 供应商的核心价值在于不再受供应商的约束。毕竟，产品核心部分是开源的，且由全球社区开发。产品核心部分并不属于某个公司，多数情况是由 Apache Software Foundation（ASF）拥有。在最坏情况下，即使公司倒闭这种最坏的情况发生，核心代码依然安全存在(于) ASF，被 ASF 所支持。

 

这听起来不错。坦白来讲，这不是事实。这是迈出了第一步并在头一年迅速扩张的好方法。

 

在 24 或 48 个月的限期后期阶段，供应商需要增加收入，有时他们甚至会大幅提高软件价格。这会导致我和我的同事要接很多客户打来的咨询电话。他们会询问他们实际所使用及有价值的功能，如果不用开源组件外的其他功能，他们能正常使用产品吗？有些时候，这个问题的答案是肯定的 。此外，客户们还会这些疑问：市面上还有谁家是支持开源组件的？它们更便宜吗？他们和我之前合作过的软件供应商用的同一策略吗？

 

其他软件供应商见机，会咨询我们是否该提供对这些开源组件外的其他组件的简单支持。因为他们的客户也会与他们谈论其他的内部供应商的策略。

凯洛格对这种销售策略有其他的看法，他表示，“从供应商的角度来看，免费/社区版本既是潜在客户的主要来源，也是最大的竞争对手——如果企业版没有提供相较于社区版更棒的功能，那么人们就不会为之买单或再次购买。”

企业级购买者更倾向于 Open Source 还是 Open Core?

关于企业级购买者更倾向 Open Source 而不是 Open Core，还是 仅仅根据他们业务选择软件/服务这个问题，Ovum 分析师 Tony Baer 表示，这是一个复杂的问题。他说：“这是一个难题，答案是‘视情况而定’”。理论上，所有软件决策取决于商业利益，而商业利益又由一系列选项构成，包括：增加收入，提高盈利，员工保留策略（留用希望在简历上体现开源项目经历的开发者），现有 IT 环境的兼容性和并购中的机构。

我们咨询的大多数分析师一致认为，公司应该关注它们正在使用的开源技术，然而，这说起来容易做起来难。首先，开发者从 GitHub 或其他站点获取资源时通常不会征求许可。其次，正如凯洛格提及的那样，在开放源代码计划（OSI）批准的清单上有 82 种不同的许可证类型，公司需要了解哪些组件受哪些许可证约束以及使用这些许可证的后果。

OSI总经理兼董事 Patrick Masson 表示，这正是一些大厂，甚至是那些拥护开源的公司针对许可证采取行动的原因。比如，Google 已彻底禁止了至少七种类型的开源许可证。

有人会说因为产品背后的软件供应商会处理许可证兼容性之类的问题，并且内置了企业所需的管理和安全功能，因此 Open Core 软件可能是一种更安全，更轻松的方法。但是亚马逊，谷歌和微软等大型云提供商可能正在改变游戏规则。

附录

Nebula Graph GitHub 地址：https://github.com/vesoft-inc/nebula ，加入 Nebula Graph 交流群，请联系 Nebula Graph 官方小助手微信号：NebulaGraphbot

Nebula Graph：一个开源的分布式图数据库。

 

GitHub：

https://github.com/vesoft-inc/nebula 

知乎：https://www.zhihu.com/org/nebulagraph/posts

 

微博：https://weibo.com/nebulagraph

简单的来讲，敏捷的意思就是反应迅速，为什么要反应迅速？看看腾讯、阿里就知道了，市场变化越来越快，客户要求越来越高，为了满足用户的需求， 人家一个星期发一个版本，我们仨月才能憋出一个来 ， 那还不被打的满地找牙？

问题是如何才能反应迅速？  我们先来看一个场景：

一、残酷的现实

软件开发有一大难题就是客户脑子中的需求难于描述出来， 我们通常的应对方法是这样：

先花上几个月整理需求， 天天和客户座谈， 画出几百页的流程图， 写出上千页的文档， 最后把客户都快搞晕了。

项目经理：这是您要的软件需求吗？

客户：（看到这么多的文档） ： 嗯， 应该是。

项目经理：那就请您在需求确认书上签字吧

客户：（心里犯嘀咕， 但是一想，反正是我先给你个首期款，怕啥？ ） ： 签就签！

项目经理：（非常高兴的宣布）需求分析阶段结束了， 项目成功进入下一个阶段： 概要设计！

然后是详细设计， 开发， 测试，  我们强悍的技术团队开始发动， 一切都严格按照计划进行， 一切看起来都很完美， 看来项目马上成功结束了！

但是客户的验收测试给了我们当头一棒： 这个界面怎么少了一个选项 ？    那个界面怎么不能跳转 ， 那个功能需要给领导一个后门， 还有， 我的业务规则怎么不能改？  什么？ 在代码中写死了？  唉，你们做的系统啊， 根本就不能用 ！

每个人都很郁闷， 几个月的辛苦开发看来要付诸东流了。

从这个场景中能看出的是，  我们从客户那里得到的需求描述和需求文档， 其实离客户真正想要的软件还差的很远。 

在瀑布式的开发模式下，验收测试发现的问题，要想改正代价是非常高昂的。

二、改进

一个想法自然而然就浮现出来： 为了避免到最后习惯性崩盘，能不能让客户经常性的做验收测试？ 

让他们经常性的去使用一个可以工作的软件， 从而告诉我们那些地方还有欠缺 ？ 那些地方做错了？  这样我们可以迅速的修改， 这样我们就会轻松多了 ！

我们可以把软件开发划分成一个个小的开发周期， 例如每个周期就两三周时间， 在这两周之内我们完成一个或几个功能， 然后就让用户去试用， 有问题立刻反馈，在下一个开发周期马上改掉。 这样就可以逐步逼近客户的最终目标。

这还带来了一个额外的好处， 不用花费巨长的时间来分析，整理冗长的需求文档了。

听起来很美是不是？  但是仔细想想这里边的问题很多。那么该如何实施敏捷开发呢？我们可以借用CORNERSTONE敏捷开发工具，来帮助我们高效规划任务,灵活调整计划,高质交付产品,快速迭代,响应需求。

1.  抛弃了冗长的需求文档， 但还是得描述需求啊

CORNERSTONE为需求生命周期搭建流程，可以自定义更改按收集、评审、排期、设计、开发、发布设立多个阶段，在不同阶段把任务分发给产品、设计或者开发人员，让需求完成无缝衔接。

2.  怎么决定每个小开发周期（我们称之为迭代）要开发的东西？

用户故事得有估算， 得有大小， 太大了一个迭代开发不完 ， 还得拆分一下。

我们需要对需求按照优先级进行排序， 按照优先级从高到低的原则来开发。

CORNERSTONE透过增量迭代⽅法进⾏敏捷式开发，根据不同版本制定⽬标与评审计划，同步统计⾄天/周 /⽉视图、燃尽图以及完成度。迭代进度 清晰可追溯，助⼒企业敏捷迭代，⼩步快跑。

3. 不要架构设计了吗？

一上来就按优先级选择需求， 直接进入迭代开发， 把架构师撂在一边，合适吗？

架构工作肯定还是需要的，在正式的迭代周期开始之前需要架构设计， 但是和设计出面面俱到的架构设计不同， 我们更需要演进式的架构， 随着迭代的推进而进化。

4. 那详细设计怎么办？

在每个迭代开始的时候，团队在一起把这些用户故事给拆分成一个个小的任务， 这个拆分的过程就相当于详细设计了。  对于一些特别复杂的，例如算法， 当然可以写文档，帮助大家理解。

在CORNERSTONE里，可以同时并行管理多个项目。每个项目清晰明确可见责任⼈、任务状态、优先级、类别、时间等多维度信息，帮助企业快速⾼效的对项⽬进⾏全周期管理。

5. 由于是迭代式开发， 这个迭代周期修改上一个迭代周期的代码在所难免， 怎么保证不破坏原有的功能？ 总不能每次都手工重测一遍吧？

对于敏捷开发来说，开发人员需要尽可能做到提早集成，频繁集成，一般每添加进一些新的代码时，最好都做一次集成，不要临到软件发布或者交付的当天才开始集成，也不要很久才集成一次，如此可尽早发现代码中的问题，保持软件的状态一直是可用的。

CORNERSTONE⽀持将持续集成等结果部署到对应的测试环境，所有部署版本在测试 环境中可随时访问，⽀持灰度发布到⽣产环境中。

6.  这么短的开发周期， 测试人员怎么测试啊？

开发和测试需要同步进行， 当开发在澄清需求的时候， 测试需要参与， 当开发在编码的时候，测试人员在编写测试用例，等到一个用户故事开发完，马上就可以投入测试。

CORNERSTONE执行测试计划，也是非常有亮点的哦！

亮点一：用例的执行情况一目了然,随着执行的进度即时更新测试结果

亮点二：执行用例不通过，有BUG，可以直接关联缺陷，新增缺陷指派责任人，完全不用退出页面，再去缺陷列表新增

亮点三：执行用例过程中，执行后，自动切换到下一条用例，减去很多点点的操作。

亮点四：测试用例批量执行的功能肯定少不了，你需要的它都有哦。

亮点五：用例执行页面执行操作简单明了，还可以记录下了执行过程中发现的缺陷，执行人员的操作记录，一目了然。

7. 看来开发、测试之间需要紧密的协作， 它们之间怎么沟通？

肯定是面对面的沟通， 有问题就跑到对方的座位那里去问，大家的座位最好在一起， 扭头就可以讨论，尽可能减少效率不高的电话、QQ/微信等工具的使用。

CORNERSTONE讨论功能也可供团队成员互相交流,共享信息,解决自己在工作中遇到的各种问题。

开发团队也可每天开一个15分钟左右的站会，展示自己的进展和计划，让进度保持透明，及时暴露问题，解决问题。

8. 客户什么时候可以做验收测试？

随时欢迎， 但是我们更倾向于迭代结束以后， 这时候功能会稳定下来， 我们会给客户做一个演示， 告诉他这个迭代完成的工作， 邀请他也测试一下软件， 给我们反馈。

当然客户可能会发现问题， 甚至提出新的需求， 我们表示欢迎， 我们要和客户合作，而不是对抗。

除了给客户演示之外，我们自己还会反思一下，看看有那些地方做的好，要继续保持；  那些地方做的不好， 要持续改进。

当我们完成了项目目标或可交付成果的时候，就可以对项目进行归档了，当然归档之前可以对项目行进中的一些问题进行复盘，给团队和个人提供一个反省和提高的机会。

总结：

CORNERSTONE作为新一代智能项目管理平台，专注于产品研发项目管理，致力于帮助企业全方位解决团队协作与研发痛点，内嵌精益/敏捷/DevOps方法论，让企业能快速响应市场变化和客户需求，同时还具备成熟的立体化智能数据分析系统，可自动生成报表，帮助企业科学量化团队表现，实时把控项目进展。CORNERSTONE适用于各行各业，产品体验链接（https://www.cornerstone365.cn/）。

Excelize 是 Go 语言编写的用于操作 Office Excel 文档类库，基于 ECMA-376 Office Open XML 标准。可以使用它来读取、写入由 Microsoft Excel™ 2007 及以上版本创建的 XLSX 文档。相比较其他的开源类库，Excelize 支持写入原本带有图片(表)、透视表和切片器等复杂样式的文档，还支持向 Excel 文档中插入图片与图表，并且在保存后不会丢失文档原有样式，可以应用于各类报表系统中。入选 2018 开源中国码云 Gitee 最有价值开源项目 GVP，目前已成为 Go 语言最受欢迎的 Excel 文档基础库。

开源代码

GitHub: github.com/xuri/excelize
Gitee: gitee.com/xurime/excelize
中文文档: xuri.me/excelize/zh-hans

Excelize 知名用户

2019年10月9日，社区正式发布了 2.0.2 版本，该版本包含了多项新增功能、错误修复和兼容性提升优化。下面是有关该版本更新内容的摘要，完整的更改列表可查看 change log。

有关更改的摘要，请参阅 Release Notes。完整的更改列表可查看 change log。

Release Notes

此版本中最显著的变化包括：

兼容性提示

升级至该版本需要您的 Go 语言版本高于 1.10。

新增功能

• 支持创建数据透视表。新增 AddPivotTable() 函数
• 支持创建迷你图 (Sparkine)。 新增 AddSparkline() 函数
• 新增 GroupSheets() 和 UngroupSheets() 方法，支持设置工作表分组和取消工作表分组
• 新增 AddVBAProject() 方法，支持向 Excel 文档中嵌入包含函数和宏的 VBA 工程
• 函数 SetPageLayout() 增加适应页面宽高属性支持，相关 issue #432
• 函数 SetSheetViewOptions() 现在支持 “值为零的单元格是否显示零值” 属性的设置
• 函数 SetCellFormula() 增加了对公式类型和引用属性的设置支持
• 增加带有删除线字体样式的创建支持，相关 issue #482

问题修复

• 修复部分情况下读取批注内容文本不完整的问题，解决 issue #434
• 修复由于内部合并单元格偏移量计算错误导致的部分情况下使用 RemoveRow() 删除行出现下标越界问题，解决 issue #437
• 修复部分情况下数据验证下拉菜单中的公式失效问题
• 修复在循环迭代中调用 Save() 方法保存导致的文档损坏问题，解决 issue #443
• 提升文档内部 workbook.xml.rels 中相对路径格式解析的兼容性，解决 issue #442
• 修复部分情况下，删除带有合并单元格的文档所导致的文件损坏问题
• 修复部分情况下设置保护工作表属性失效的情况，解决 issue #454
• 修复部分情况下 GetSheetName 获取工作表名称为空的问题, 解决 issue #457
• 增加单元格内多行文本解析的支持, 相关 issue #464
• 修复 32 位操作系统环境下数字溢出问题，相关 issue #386
• 修复 go module 依赖版本不匹配问题, 相关 issue #466 和 issue #480
• 修复部分情况下调用 SetSheetPrOptions() 所致的文档损坏问题，解决 issue #483

性能表现

• 性能优化，减少读取文档时的内存开销和耗时，相关 issue #439

其他

• 完善 SetSheetRow() 函数中的异常处理
• 代码精简优化, 合并了下列内部函数:

将函数 workBookRelsWriter, drawingRelsWriter 合并为 relsWriter;
将函数 drawingRelsReader, workbookRelsReader, workSheetRelsReader 合并为 relsReader;
将函数 addDrawingRelationships, addSheetRelationships 合并为 addRels

引子

Nebula Graph 的技术总监在 09.24 - 09.30 期间同开源中国·高手问答的小伙伴们以「图数据库的设计和实践」为切入点展开讨论，包括：「图数据库的存储设计」、「图数据库的计算设计」、「图数据库的架构设计」等方面内容，本文整理于他和开源中国小伙伴对图数据库的讨论内容~

嘉宾·陈恒介绍

陈恒，开源的分布式图数据库 Nebula Graph 技术总监，图数据库领域专家 & HBase Committer。北京邮电大学硕士，曾就职于蚂蚁金服、猿题库、网易等公司，一直从事基础设施相关研发工作。

本文目录

• 图数据库怎么和深度学习框架进行结合？
• 图数据库它可以被认为是 MySQL 中的一种数据库引擎，具备特殊的查询功能，以及特殊的数据结构？
• Nebula 和 Neo4j 的图数据库的优势和劣势？为何要新开发使用 Nebula ？
• 图数据库目前主要用于哪些应用场景?
• 图数据库和一般数据库结构相比，优势在哪里？
• Nebula 的实践问题
• 存储计算分离
• Nebula 高度可扩展具体指的是什么？存储层是否还支持其他类型的数据库？
• 「图数据库」是基于已有数据库衍生出来的产品吗？如何设计图数据库？
• 图数据库为何没有通用的图查询语言？
• 图数据库适合存储什么类型数据，比如树形目录？
• Nebula 的部署安装配置要求是什么？

图数据库怎么和深度学习框架进行结合？

Stiofan：
图数据库打破了关系数据库的这种古老数据存储模式，将图形化特性属性数据存入，但是关于这些特性化属性的数据使用图数据库和将其转换为类型数据放入深度学习框架，两个之间的关系或者说使用场景应如何来规划。

我们见过一些机器学习使用图数据库的 case，最主要的是 feature extraction 阶段，使用图数据库来拿到当前点相关联的点的一些属性作为 feature，或者产生一些随机游走的路径，使用图数据库可以大大加速整个过程。

图数据库它可以被认为是 MySQL 中的一种数据库引擎，具备特殊的查询功能，以及特殊的数据结构？

钛元素：
恒大你好，我对图数据库不是很明白，是否可以这样理解：它可以被认为是 MySQL 中的一种数据库引擎，具备特殊的查询功能，以及特殊的数据结构？谢谢。

不是特别准确， 图数据库是为了网络结构的数据（比如社交网络，资金网络等）而专门设计的一类数据库。 这类的数据库有着自己独特的数据组织形式， 以及自己独特的查询语句。 它并不是 MySQL 中的一种存储引擎， 而是一个独立的产品，就像 HBase 与 MySQL 的关系一样。

开源中国·sixliu 小伙伴补充：你可以这样理解，原先这些数据都是用关系数据库存的，分别为主体表和关系表，但是在应用使用时查询性能，比如查 n 度关系。所以为了提升查询使用图数据库天然符合，节点(主体)和边(关系)，比如说要查 A 的 2 度关系，那么通过 id 直接 key 匹配到 A，然后再获取到路径 <=2 的节点就可以获得结果。

Nebula 和 Neo4j 的图数据库的优势和劣势？为何要新开发使用 Nebula ？

5G加ios：
Nebula 和 Neo4j 的图数据库的优势和劣势？ 为何要新开发使用 Nebula ？？

Neo4j 是目前市面上知名度最高的图数据库， 是一款非常优秀的产品。 但是开源的 Neo4j 最大的问题在于它是一款单机数据库， 扩展能力存在比较大的问题。 Nebula 是在互联网公司的长期实践中诞生的一款产品， 相比于Neo4j， Nebula 最大的特色便是分布式的架构，扩展性要好很多。

图数据库目前主要用于哪些应用场景?

crf1111：
你好，最近在开发分布式任务处理系统，使用到了有向无环图（DAG）的概念。请问，图数据库目前主要用于哪些应用场景。
对于Nebula，目前提供了几种 client 库，是否能兼容 python-networkx 中的 Graph 对象？

图数据库主要应用于网络结构数据的存储与查询， 比如在社交关系中， 查找一个人的 N 度好友（可以带一些过滤条件），用传统的关系数据库来搞，不仅性能不能满足要求， 还会使用很复杂的 SQL 描述， 对于用户十分不友好。 而在图数据库中，这样的查询就是一条语句而已。
当前 Nebula 提供了 Go / Java / C++ / Python 的 client，对于其他语言可以直接使用 thrift 生成相应的接口。而我们的 Python client 能链接 Nebula Graph，执行相应的 nGQL 语句，暂时不支持 python-networkx 中的 Graph 对象。

图数据库和一般数据库结构相比，优势在哪里？

KelvinQ ：
请问图数据库和一般数据库结构相比，优势在哪里？

Everything is connected. 图数据库天生适合表达 connection，或者说多对多的关系。 图数据库可以很高效的查询几度关系，而传统关系型数据库不擅长，一般都需要做表连接，表连接是一个很昂贵的操作，涉及到大量的 IO 操作及内存消耗。当然，文档、关系型数据库和图数据库相互可借鉴点还是非常多的。

Nebula 的实践问题

Li_Peng ：
您好，最近刚开始注意到 Nebula，有 3 个问题想请教一下：
1、Neo4j 社区版的单节点限制问题，目前看 Nebula 应该不存在类似问题，不知道这样理解是否正确？
2、Nebula 支持类 SQL 查询，是否有相关 JDBC 驱动可以使用？目前看 GitHub上貌似没有，后期是否会支持？
3、官方文档 https://docs.nebula-graph.io/manual-index/ 地址打开有点慢，目前是否有微信或者钉钉群可以交流？

1. 是的， Nebula 相比于 Neo4j 最大的优势便在于分布式的设计。
2. 目前我们使用的是 thrift rpc 进行 client 与 server 的通信。对于JDBC 的支持，如果客户的需求比较强烈，会考虑提供支持。
3. 可以关注我们的微信公众号 NebulaGraphCommunity， 里面有微信交流群，可以添加我们的小助手进群：NebulaGraphbot

存储计算分离

长眉欧巴：
想问个跨界的问题，貌似目前的数据库走存算分离的路线，而硬件方面却走存算一体的路线，比如类脑芯片，参考人类大脑神经系统的功能。神经元是存算一体的（虽然还没定论，但这更可能）。而图数据库的结构天生跟神经系统有异曲同工之妙，到最后是不是更应该也存算一体？

所谓的存储计算分离，也没有说完全分割，比如说在 Nebula 里面，很多的计算其实是在存储层完成的，也就是所谓的计算下推。
之所以采用存储计算分离的架构，主要是为了扩展性和上云的考虑。

开源中国·sixliu 小伙伴补充：可以把它理解成之前 存储过程完成复杂逻辑->应用层完成逻辑。主要就是为了满足高容错和可扩展。存储层只要提供高度抽象的谓词下推即可。

Nebula 高度可扩展具体指的是什么？存储层是否还支持其他类型的数据库？

myw31415926：
陈大，您好。Nebula 的高度可扩展包含哪些，能说明一下吗？存储层是否还支持其他类型的数据库，如 Oracle 和 PostgreSQL？多谢

Nebula 采用了存储计算分离的架构，对于计算层，因为是无状态服务，可以随意扩容。对于存储层， 我们提供了扩容相关的运维语句，可以比较简单的扩容。存储层支持 storage plugin， 目前已经有 HBase 的 plugin，其他的 plugin 也可以根据需求来支持。但是我们并不推荐在关系型数据库上使用图数据库，因为这样的效率会非常低，扩展起来也会很麻烦。

「图数据库」是基于已有数据库衍生出来的产品吗？如何设计图数据库？

海参拉面：
老师，图数据库是基于现在已有的数据库产品衍生出来的吗？怎么设计呢？

图这种关联关系和相应的需求其实很早很早就有了，只是各种技术上的原因。
以前大家只能用关系型数据库来存储，但是这样需要使用者把关联关系适配成表结构，并不直观，所以图数据库也是这样发展出来的。
关于怎么设计，其实参考了很多 SQL，NoSQL 和各种分布式系统的工程实现，欢迎阅读 Nebula 的系列技术文章。

图数据库为何没有通用的图查询语言？

JIANGGuo：
你好，请问图数据库作为 NoSQL 中的一类，底层都是图数据结构来存储的，为什么没有通用的图查询语言呢，Nebula Graph 用 nGQL，Neo4j 用 Cypher ？谢谢。

很好的问题。
我觉得最大的原因是图数据库比较新，各家的产品应对的场景也不尽相同，所以到现在也没有产生统一的图查询语言。

图数据库适合存储什么类型数据，比如树形目录？

荒野刀客：
图数据库是否适合存储树形的数据，比如树形目录？  Nebula 和 Neo4j 相比，语法是否兼容，是否容易切换？

数据结构上来说，树是图的子集。只是单纯树的业务场景不多，我碰到过的树的场景主要是数据仓库里面的数据血缘。
Nebula 语法上和 Neo4j 接近，但并不兼容。我们设计时语法更接近 SQL，你可以下个Docker 试试，我觉得花个 15 分钟，应该能熟悉语法了。

Nebula 的部署安装配置要求是什么？

图数据库猫：
数据库 Nebula Graph 可以安装在 Win7 64 上吗？CentOS 的版本有要求吗？

建议安装在 Linux 服务器上。如果是 Windows 环境，可以下载一个 Docker 试用，https://hub.docker.com/r/vesoft/nebula-graph. CentOS 建议版本是 7.5+

附录

最后是 Nebula 的 GitHub 地址，欢迎大家试用，有什么问题可以向我们提 issue。

GitHub 地址：https://github.com/vesoft-inc/nebula ，加入 Nebula Graph 交流群，请联系 Nebula Graph 官方小助手微信号：NebulaGraphbot

Nebula Graph：一个开源的分布式图数据库。

GitHub：https://github.com/vesoft-inc/nebula

知乎：https://www.zhihu.com/org/nebulagraph/posts

微博：https://weibo.com/nebulagraph