在选择数据库的路上,我们遇到过哪些坑?(1)

【编者按】你会怎么选择数据库,是关系数据库、XML 数据库、资源描述框架(RDF),还是图形数据库?这篇演讲深入而生动地探讨了各种选择。本文系国内 ITOM 管理平台 OneAPM 编译呈现。

备注:在去年十月于旧金山举办的 GraphConnect 大会上,FactGem 公司首席技术官 Clark Richey发表了这篇演讲,解释了他决定选择 Neo4j 数据的原因。

我是 FactGem 的首席技术官 Clark Richey。FactGem 是一家小公司。

在这里我想说一说我们是怎么开始接触数据库技术的,然后我们做出了哪些改变,我们还需要做出哪些决定,哪些东西影响了我们的决策流程。我还会介绍我们调查研究过的各种数据库和技术,以及我们在使用 Neo4j 过程中发现的一些最佳做法和最差做法。

2014 年夏天之后,很多事情都发生了变化,我也会对我们在这段时期测试的各种数据库做出一个仔细的评估。

选择数据库

关系数据库

最初,我们的创始人准备把数千份不同的文件放在一起,用来执行有效搜索、制定业务决策、进行数据分析和创建数据可视化。

在选择数据库的路上,我们遇到过哪些坑?(1)

我们在研究过程中发现,关系数据库 (RDBMS) 并不适合我们。当然,我们的本能反应就是使用这种数据库,毕竟我们已经用了这么长时间。但关系数据库需要固定的架构,并且创建数据库时就要设置好这一固定架构。用户必须创建各种表,确定关系,然后创建 JOIN 连接:

在选择数据库的路上,我们遇到过哪些坑?(1)

而我们需要的是比关系模型更为灵活的数据库。

XML 数据库

我曾经接触过 NoSQL 数据库。那时我在 MarkLogic 公司工作。MarkLogic 是一家企业级模式自由型 XML 数据库公司,该公司还存储文档并提供 JSON 格式。这种数据库无论在上传信息还是执行搜索时,速度都较快,并且模式自由。

在选择数据库的路上,我们遇到过哪些坑?(1)

我们确实从这一初始概念点(POC)学到了一些东西,但顾名思义,概念点本身就是一种不够全面的看法。我们依次对这一看法的各个子集进行测试,然后选取部分样本集,发现能够进行快速搜索和导航。

我们认识到,文档之间的隐含信息比存储在每个文档内的信息要有意思得多。于是我们试着弄清楚能不能创建一个数据库好让我们利用这些关系。

我们再次将信息建模,形成文档,后者非常适合我们的数据集。但使用文档数据库时,用户真正关心的当然是文档了。因此,尽管我们可以进行 JOIN 连接,但仍然不适用于大型数据集。

我们可以在文档内进行快速搜索,但不能对文档之间的关系进行快速搜索。对于这项操作而言,这一数据库并不合适。

资源描述框架 (RDF) / 三元组存储

为了解决问题,MarkLogic 把我们的所有文档从 XML 迁移到资源描述框架 (RDF),这一框架又被称为三元组存储。这无疑是个大手笔,也是非常与众不同的对待数据的方式,我们决定,就是它了。

这不算太难,因为我们很小心地从架构的剩余部分解耦了持久层。最后花了大约两个月时间,然后我们终于能在不影响应用程序剩余部分的情况下进行迁移。

我们为什么选择资源描述框架?因为它是专为连接带有统一资源标识符的信息而设计的,还拥有一种叫做 SPARQL 的标准化查询语言。

简而言之,资源描述框架是有关主/谓/宾关系的,从下面看得出来,其模型非常简单:

在选择数据库的路上,我们遇到过哪些坑?(1)

下面是资源描述框架概念的简单象形图:

在选择数据库的路上,我们遇到过哪些坑?(1)

如果我想说 Clark 认识 John Forrest,那么 Clark 就是资源。资源具有名字、姓氏和类型等属性,也具有关系。下面这些资源描述框架的三元组可以体现这一示意图:

在选择数据库的路上,我们遇到过哪些坑?(1)

我们的数据库确实很给力,总体来说我们也相当满意。利用资源描述框架,我们不仅重建了整个概念点,还实现了对数据库的更多操作 —— 包括探索各种关系。虽然在各个机构和行业之间进行大范围的数据分享时非常方便,但这并不是我们使用数据库的主要目的。

资源描述框架非常冗长,它是一种基于非属性的图形。由于所有内容都表现为节点,要想进行复杂的关系查询,必须先到达目的地然后再一同返回,这给我们带来了一些性能问题。虽然资源描述框架没有成为我们的最终选择,但它确实帮我们看清了专注于数据关系的希望。

作为一家小型初创公司,在这么短的时间里经历了这么多种数据库,我们有些担心。即使这样,我们仍然明白,从一开始就要选择合适的数据库是多么的重要,于是我们顶着重重压力,在没有做好充分的数据库工作的情况下,我们决定尝试图形数据库。

改变从这里开始:图形数据库

最初我们认为图形数据库和资源描述框架一个样。但我们知道,要描述两个人之间的关系,用资源描述框架太复杂了。我们希望能有一个非常非常简单的工具,让我们能够给节点分配属性,然后我们在一个属性图形模型里找到了以下内容:

在选择数据库的路上,我们遇到过哪些坑?(1)

于是我们又明白了,我们不能使用关系数据库,因为它们在关系上的表现不够出色。JOIN 连接、外键和索引既不真实,也不具体;它们只是我们画在纸上用来方便理解的图案。反过来说,在图形数据库中,关系被表达成具体实体。

TitanDB 数据库

我们先研究了 TitanDB,它各项强大的功能和极佳的可扩展性一开始让我们非常振奋。可惜的是,TitanDB 的启动和维护都非常复杂,必须得从 Cassandra 或 HBase 后台运行。

我们关心的另一个功能是最终一致存储,它并不符合 ACID 原理。这表示,如果我们要长时间运行大型图形数据库,最后可能会出现不一致现象。

TitanDB 确实提供了一个基本可长期运行的流程,能够始终如一地穿行整个图形,以期探测和修复不一致问题。除了这些不一致之外,TitanDB 还可以作为不基于图形的本地存储之上的层。

OrientDB 数据库

接下来我们又了解了 OrientDB。OrientDB 启动起来似乎简单得多,还具备大量针对文档的功能。但从社区的评论来看,性能和可扩展性是个问题。另外,OrientDB 把自己宣传成多模式数据库 ——图形和 SQL。这种宣传缺乏对纯图形操作的针对性,让我很是忧心,我们不仅想要做图形,还要做好图形。

发现 Neo4j

然后我们发现了 Neo4j。Neo4j 可高度扩展,对节点、关系或索引的数量没有限制。同时 Neo4j 入门也相当简单,这对我们是很大的诱惑;在使用第三个数据库时,必须得迅速投入运行。

性能表现极佳,扩增也非常广泛,并且只专注于图形用例。Titan 确实提供映射(作为本地节点类型)支持,但我们知道,即使没有这一支持我们也可以继续下去。

总的来说,我们之所以选择 Neo4j,有以下原因:

在选择数据库的路上,我们遇到过哪些坑?(1)

我们使用 Neo4j 企业版已有大约 16 个月,体验一直非常美好。Neo4j 易于使用,设置和维护也很简单,实现甚至超出了我们的预期。它让我们超越了我们的概念点,非常非常迅速地投入运行和构建新事物。

在本文的第二部分,将详细介绍使用 Neo4j 之后,作者学习到的经验教训,敬请期待。

本文系 OneAPM 工程师整理呈现。OneAPM 能为您提供端到端的应用性能解决方案,我们支持所有常见的框架及应用服务器,助您快速发现系统瓶颈,定位异常根本原因。分钟级部署,即刻体验,性能监控从来没有如此简单。想阅读更多技术文章,请访问 OneAPM 官方技术博客

本文转自 OneAPM 官方博客

原文地址:https://dzone.com/articles/from-good-to-graph-choosing-the-right-database

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,188评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,464评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,562评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,893评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,917评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,708评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,430评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,342评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,801评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,976评论 3 337
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,115评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,804评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,458评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,008评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,135评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,365评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,055评论 2 355

推荐阅读更多精彩内容