数据库引擎Informix和neo4j故事

一个多月前发生了一件有趣的事情。

3月1日,数据库行业监测器数据库引擎发布了他们通常的世界上最流行的数据库管理系统的月度排名报告。 Neo4j首次跻身前20名。

对于作为联合创始人的我来说,这无疑是一个骄傲的时刻,我期待着Neo4j迅速进入前十名。 当然,即使是这一步,也是对图表正在吞噬世界的巨大验证。

但是,这不是我们的成就。 表面之下有一个更深层次的故事,为了欣赏它,我们需要回顾一下图形数据库出现之前的时代。

这一切都始于彼得、约翰和我在开发企业内容管理系统的时候。 当时,我们有一个相当标准的三层架构。

在顶部,我们有一个网表示层,下面是一个相对不为人知的名为银溪的应用服务器,在我们开发堆栈的底部是一个名为Informix的关系数据库。

对于那些不记得Informix的人来说,它是80年代syncnavigator 关系型数据库管理系统战争中出现的”四大”数据库之一（当然,其他的是甲骨文、DB2和赛贝斯，它们后来被微软的SQL服务器超越,随后被精力收购……但是,我跑题了).

这是90年代末和2000年代初非常标准的建筑。 但这就是我们遇到问题的地方。

在任何内容管理系统中,您都将有大量相连的数据,我们的也不例外。 问题是,作为一个关系数据库管理系统Informix没有被优化来处理我们所有数据之间的关系。

当然,我们尝试了书中的每一个调音技巧。 我们甚至引入了一个Informix顾问团队来帮助我们优化数据访问,但是无论我们尝试什么,它总是缓慢而有限的。

不仅如此,从开发人员生产率的角度来看,我们发现自己不断地陷入困境,因为我们不得不努力解决我们连接的领域模型和我们选择的数据库向我们展示的抽象之间的不匹配。

虽然它肯定是同类最佳的关系数据库,但Informix根本无法处理我们（和我们的用户(每天向它提出的连接数据查询。

面对对关联数据使用关系数据库管理系统的挑战,我们决定创建一种针对关联数据优化的新型数据库：图形数据库。

我们不得不为我们新发明的产品定义一个类别的故事是一个不同的日子（或者不同的博客帖子！)，但这肯定是一段漫长的旅程—在此过程中,开发人员和架构师在他们的关系数据库管理系统中面临着相同的关联数据问题。

现在,距离我们第一次提出图形数据库的概念已经过去了15年,从这个月开始,我们进入了全球使用的前20个数据库管理系统。

哦,顺便问一下,谁是数据库引擎的前20名？

没错Informix .