为您的下一个项目选择的前13个开源数据库软件

数据就是一切。而数据库也是如此。下面是一些开源选项,适用于您的下一个出色项目。

长期以来,像Oracle和SQL Server这样的数据库套件主导着这个世界,现在似乎出现了无休止的解决方案。原因之一是由开源驱动的创新-非常有才华的开发人员想解决一个问题,并创造出他们可以沉浸其中的东西。

另一个原因是新商业模式的出现,其中企业维护其产品的社区版本,以获取市场份额和推动,同时提供商业附加功能。

结果呢?

数据库多得无法跟上。没有关于这个的官方统计数据,但是如果将来自特定堆栈的对象数据库与来自大学的不太受欢迎的项目结合起来,我相信我们今天可以提供超过一百种选择。

我知道,这也吓到了我。选择太多-要阅读太多文档-而生命又是如此短暂。 🙂

这就是为什么我决定写这篇文章,介绍十个最好的数据库,无论是为自己还是为他人构建解决方案。

没有MySQL

请注意:即使MySQL可以说是最受欢迎的开源数据库解决方案,但此列表不会包含MySQL。

为什么呢?

因为MySQL无处不在-每个人都首先学习的就是它,几乎每个CMS或框架都支持它,对于大多数用例来说,它非常好。换句话说,MySQL不需要“被发现”。 🙂

也就是说,以下内容不一定是MySQL的替代品。在某些情况下,它们可能是替代品,而在其他情况下,它们是完全不同的解决方案,用于完全不同的需求。不要担心,我也会讨论它们的用途。

特别说明:兼容性

在开始之前,我还必须提到兼容性是您需要考虑的一些事情。如果由于某种原因,您的项目仅支持特定的数据库引擎,那么您的选择就很有限。

例如,如果您正在运行WordPress,那么这篇文章对您没有用处。同样,那些在JAMStack上运行静态网站的人也不必认真寻找替代方案。

由您来计算兼容性等式。然而,如果您有一个空白的基础并且架构由您确定,这里有一些建议。

PostgreSQL

如果您来自PHP领域(WordPress,Magento,Drupal等),那么PostgreSQL对您来说可能是陌生的。然而,这款关系型数据库软件自1997年以来一直存在,并且是像Ruby,Python,Go等社区的首选。

事实上,许多开发人员最终会转移到PostgreSQL,因为它提供的功能或者仅仅是因为其稳定性。在这篇简短的文章中很难说服某人,但把PostgreSQL看作是一个深思熟虑的工程产品,永远不会让您失望。

有许多好用的工具可用于连接到PostgreSQL数据库进行管理和开发。

独特功能

与其他关系型数据库(特别是MySQL)相比,PostgreSQL具有几个有趣的特性,例如:

  • 内置的数据类型,如数组,范围,UUID,地理位置等
  • 对文档存储(类似JSON),XML和键值存储(Hstore)的原生支持
  • 同步和异步复制
  • 可通过PL,Perl,Python等进行脚本编写
  • 全文搜索

我个人最喜欢的是地理位置引擎(在使用基于位置的应用程序时,能够减轻痛苦——试着手动找到附近的所有点,你就会知道我在说什么了)和数组支持(许多 MySQL 项目由于没有数组而未完成,而选择了臭名昭著的逗号分隔字符串)。

何时使用 PostgreSQL

PostgreSQL始终是比其他关系数据库引擎更好的选择。也就是说,如果你要开始一个新项目,并且之前遇到过 MySQL 的问题,那么现在是考虑使用 PostgreSQL 的好时机。我有朋友放弃了与 MySQL 神秘的事务锁故障作斗争,并永久地转向了 PostgreSQL。如果你做出相同的决定,你不会过度反应。

如果您需要部分 NoSQL 功能来进行混合数据模型,PostgreSQL也具有明显的优势。由于文档和键值存储的本地支持,您无需去寻找、安装、学习和维护另一个数据库解决方案。

不使用 PostgreSQL 的情况

当您的数据模型不是关系型的和/或当您有非常特定的架构要求时,PostgreSQL就没有意义了。例如,考虑一下分析,其中不断从现有数据创建新报告。这种系统以读取为主,并且在其被强制执行严格的架构时会受到影响。当然,PostgreSQL有一个文档存储引擎,但是在处理大型数据集时,事情开始变得混乱。

换句话说,除非您百分之百确定自己在做什么,否则始终使用 PostgreSQL!🙂

如果有兴趣了解更多,请查看此 SQL & PostgreSQL for Beginners course

MariaDB

与MySQL由同一人开发的人创建了 MariaDB 来替代MySQL。

困惑吗?

实际上,MySQL在2010年被Oracle收购后(通过收购Sun Microsystems,顺便说一句,这也是Oracle掌控Java的方式),MySQL的创始人启动了一个名为MariaDB的新的开源项目。

你为什么问这些无聊的细节有关系呢?这是因为MariaDB是从与MySQL相同的代码库创建的(在开源世界中,这被称为“分叉”现有项目)。结果,MariaDB被称为MySQL的“插曲”替代品。

也就是说,如果你正在使用MySQL并想迁移到MariaDB,这个过程是 so easy 的,你简直不敢相信。

不幸的是,这种迁移是单向的。无法从MariaDB回到MySQL,如果你试图使用强制手段,将会导致永久性数据库损坏!

独特功能

虽然MariaDB基本上是MySQL的克隆,但事实并非如此。自从引入数据库以来,两者之间的差异一直在增长。就目前而言,采用MariaDB需要您经过深思熟虑的决策。也就是说,MariaDB中有许多新的功能可以帮助您进行过渡:

  • 真正自由和开放:由于没有单一的公司实体控制MariaDB,您可以摆脱突然的授权许可和其他担忧。
  • 为特殊需求提供了几种更多的存储引擎选项:例如,用于分布式事务的Spider引擎;用于大规模数据仓库的ColumnStore;用于并行分布式存储的ColumnStore引擎,以及许多其他引擎。
  • 相对于MySQL的速度改进,特别是由于复杂查询的Aria存储引擎。
  • 表中不同行的动态列。
  • 更好的复制能力(例如,多源复制)
  • 几个JSON函数
  • 虚拟列

. . . 还有很多很多。跟上所有MariaDB的功能是令人精疲力尽的。🙂

何时使用MariaDB

如果你想要一个真正取代MySQL的解决方案,你应该使用MariaDB,因为他们希望保持在创新的曲线上,并且不打算再回到MySQL上。一个很好的应用场景是在MariaDB中使用新的存储引擎来补充你项目中现有的关系数据模型。

不适合使用MariaDB的情况

这里唯一的考虑是与MySQL的兼容性。话虽如此,随着WordPress、Joomla、Magento等项目开始支持MariaDB,这已经不再是个问题。我的建议是不要使用MariaDB来欺骗不支持它的CMS,因为许多特定于数据库的技巧很容易导致系统崩溃。

看看MariaDB vs MySQLMariaDB installation guide之间的区别。

CockroachDB

CockroachDB团队似乎都是受虐狂。以这样的产品名,他们肯定想要扭转一切的不利因素并仍然获胜,对吗?

嗯,并不完全是这样。

“Cockroach”背后的理念是,它是一种为生存而生的昆虫。无论发生什么事情 – 捕食者、洪水、永恒的黑暗、腐烂的食物、轰炸,蟑螂总能找到生存和繁殖的方法。

这个想法是,CockroachDB的团队(由前谷歌工程师组成)对传统SQL解决方案在大规模应用中的局限感到失望。这是因为历史上,SQL解决方案应该在单台机器上托管(数据不是那么大)。很长时间以来,没有办法构建运行SQL的数据库集群,这就是为什么MongoDB引起了如此多的关注。

即使MySQL、PostgreSQL和MariaDB推出了复制和集群功能,但最多也只能说是痛苦的。CoackroachDB希望改变这一点,为SQL世界带来轻松的分片、集群和高可用性。

何时使用CockroachDB

CockroachDB是系统架构师梦寐以求的产品。如果你坚信SQL,并一直对MongoDB的扩展能力感到兴奋,那么你会喜欢CockroachDB的。现在,你可以快速设置一个集群,对其进行查询,并在夜晚安心入眠。🙂

不适合使用CockroachDB的情况

舍近求远未必划算。我的意思是,如果你现有的关系型数据库管理系统对你很好,并且你认为自己可以应对它带来的扩展困难,那就坚持使用它吧。CockroachDB对于所有涉及的天才来说都是一个新产品,你不希望以后与之奋斗。另一个主要原因是SQL兼容性 – 如果你在做一些奇特的SQL操作并且依赖它进行重要的事情,CockroachDB将给你带来太多的边界情况。

从现在开始,我们将考虑非SQL(或称为NoSQL)数据库解决方案,以满足高度特殊化的需求。

ClickHouse

正在寻找一个快速的、开源的OLAP数据库系统吗?

选择ClickHouse吧。

它充分利用每一台硬件的潜力,以更快的速度处理每个查询。处理查询的性能峰值通常每秒超过两个太字节。为了避免增加的延迟,读操作会自动在健康的副本之间进行平衡。

它支持多主异步复制,并且可以部署在不同的数据中心。由于节点保持平等,你可以避免出现单点故障。无论是单个节点还是整个数据中心的停机都不会影响系统的可用性,无论是写入还是读取。

ClickHouse非常易于使用和简单。它可以使数据处理更加高效,将你的所有数据以有组织的方式存储在一个系统中,并且可以立即用于构建报告。此外,SQL方言可以帮助你在不使用任何非标准API的情况下表达结果,而这是在其他系统上很难实现的。

您可以依赖此数据库管理系统将其配置为位于分离节点上且没有故障点的分布式系统。此外,它的安全功能强大,包括企业级安全和防错机制,以应对人为错误。

与具有相同CPU容量和I/O吞吐量的行导向系统相比,ClickHouse可以更快地处理查询。其列式数据存储格式有助于将更多数据存储在RAM中,从而缩短响应时间。

通过使用旋转磁盘驱动器而不是使用NVMe / SSD,可以降低商品硬件的总拥有成本,而不会牺牲查询的延迟。它致力于CPU效率,优化对磁盘驱动器的访问,并尽量减少数据传输。

此外,由于其功能丰富的SQL数据库,您可以在短时间内高效处理查询,连接共同定位和分布式数据,高效管理非规范化信息等。ClickHouse可以水平和垂直扩展,并轻松适应在单个服务器或具有数千个节点的集群上运行。

在网络和应用程序分析、电信、广告网络、在线游戏、物联网、金融、电子商务、监控等领域使用ClickHouse。

它与link_10链接,Postgres和MySQL进行集成。

如果您还没有准备好安装和设置服务器,可以尝试使用link_11进行点击即可获取ClickHouse。

Neo4j

最近十年中最重要的发展之一就是连接数据。我们周围的世界并非分割成表格、行和盒子 – 它是一个巨大的混乱,几乎每个事物都与其他事物相连。

社交网络就是一个典型的例子,使用SQL甚至基于文档的数据库构建类似的数据模型是一场噩梦。

这是因为这些解决方案的理想数据结构是图形,而图形是完全不同的东西。为此,您需要像link_12这样的图形数据库。

上面的示例直接来自Neo4j网站,展示了大学生如何与他们的院系和课程相连。这样的数据模型在SQL中是不可能的,因为很难避免无限循环和内存溢出。

独特功能

link_13是独特的,而Neo4j几乎是使用图形处理的唯一选择。因此,它拥有的任何功能都是独特的。🙂

  • 支持事务性应用程序和图形分析。
  • 将大规模表格数据转化为图形的数据转换能力。
  • 专门的查询语言(Cypher)用于查询图形数据库
  • 可视化和发现功能

讨论何时使用Neo4j何时不使用是无意义的。如果您需要基于图形的数据之间的关系,则需要Neo4j。🙂

MongoDB

link_14是在技术行业引起轰动的第一个非关系数据库,并继续占据相当大的关注度。

与关系数据库不同,MongoDB是一种“文档数据库”,它将数据存储在块中,将相关数据组合在同一个块中。可以通过想象这样的JSON结构集合来更好地理解:

在这里,与基于表格的结构不同,用户的联系方式和访问级别存储在同一个对象中。获取用户对象将自动获取关联的数据,并且没有连接的概念。link_15提供有关MongoDB的更详细介绍。

独特功能

MongoDB具有一些严重的(我几乎想写“牛逼”来传达影响,但在公共网站上可能不合适)功能,这些功能使得一些经验丰富的架构师永远放弃了关系型数据库:

  • 一个用于专用/不可预测用例的灵活模式。
  • 非常简单的链接和集群化。您只需要为集群设置配置并忘记它。
  • 从集群中添加或删除节点是非常简单的。
  • 分布式事务锁。此功能在早期版本中缺失,但最终被引入。
  • 它针对非常快速的写入进行了优化,使其非常适合作为缓存系统的分析数据。

如果我听起来像是MongoDB的代言人,我道歉,但是很难过分宣传MongoDB的优势。当然,NoSQL数据建模一开始可能会感觉很奇怪,有些人永远无法掌握它,但对于许多架构师来说,它几乎总是优于基于表的模式。

何时使用MongoDB

MongoDB是从结构化、严格的SQL世界过渡到非结构化、几乎令人困惑的NoSQL世界的一个很好的桥梁。它擅长开发原型,因为您根本不需要担心模式,当您真正需要扩展时。是的,您可以使用云SQL服务来摆脱数据库扩展问题,但天哪,它太贵了!

最后,还有一些情况下,基于SQL的解决方案无法胜任。例如,如果您正在创建类似Canva的产品,用户可以创建任意复杂的设计并能够以后对其进行编辑,那么使用关系型数据库就祝您好运!

何时不使用MongoDB

MongoDB提供的完全缺乏模式对于那些不知道自己在做什么的人来说可能会成为一个陷阱。数据不匹配,无效数据,空字段等等都是可能的。MongoDB本质上是一个“愚蠢”的数据存储,如果选择它,应用程序代码必须在维护数据完整性方面承担很大的责任。

如果您是开发人员,那么您会发现this useful

RethinkDB

顾名思义,RethinkDB重新思考了数据库在实时应用中的概念和能力。

当数据库更新时,应用程序无法得知。接受的方法是,只要有更新,应用程序就会触发通知,通过复杂的桥接将通知推送到前端(PHP -> Redis -> Node -> Socket.io是一个示例)。

但是,如果更新可以直接从数据库推送到前端呢?!

是的,这就是RethinkDB的承诺。所以,如果您正在开发一个真正实时的应用程序(游戏、市场、分析等),那么RethinkDB值得一看。

Redis

在谈到数据库时,很容易忽略Redis的存在。这是因为Redis是一种内存数据库,主要用于缓存等支持功能。

Learning this database只需要十分钟(真的!),它是一个简单的键值存储,用于存储带有过期时间的字符串(当然可以设置为无限)。Redis在功能上可能有所不足,但在实用性和性能方面却有所提升。由于它完全以RAM为生存环境,读写速度非常快(每秒几十万次操作并不罕见)。

Redis还拥有先进的pub-sub system,使这个“数据库”变得更具吸引力。

换句话说,如果您有一个可以从缓存中受益或具有一些分布式组件的项目,Redis是首选。

SQLite

是的,我承诺我们已经结束了关系型数据库,但是SQLite太可爱了,不能忽视。

SQLite是一个轻量级的C库,提供了一个关系型数据库存储引擎。这个数据库中的所有内容都存储在一个单独的文件中(具有.sqlite扩展名),您可以将其放在文件系统的任何位置。这就是您使用它所需要的一切!是的,没有需要安装的“服务器”软件,也没有需要连接的服务。

有用的功能

尽管SQLite是MySQL等数据库的轻量级替代品,但它具有相当强大的功能。它的一些令人震惊的特点包括:

  • 完全支持事务,包括COMMIT、ROLLBACK和BEGIN。
  • 每个表支持32,000个列
  • 支持JSON
  • 支持64路连接
  • 子查询、全文搜索等
  • 最大数据库大小为140TB!
  • 最大行大小为1GB!
  • 比文件I/O快35%

何时使用SQLite

SQLite是一个非常专业的数据库,专注于简单直接的操作。如果您的应用程序相对简单,不想使用完整的数据库,SQLite是一个很好的选择。对于中小型CMS和演示应用程序来说,它特别合适。

何时不使用SQLite

尽管令人印象深刻,但SQLite并不能涵盖标准SQL或您喜欢的数据库引擎的所有功能。缺少集群、存储过程和脚本扩展。而且,没有客户端可以连接、查询和浏览数据库。最后,随着应用程序大小的增长,性能将下降。

Cassandra

尽管许多人宣称Java的末日已近,但是社区偶尔会放出重磅炸弹来让批评者无言以对。Cassandra就是其中之一。

Cassandra属于所谓的“列式”数据库系列。Cassandra的存储抽象是列而不是行。其思想是将所有数据在磁盘上物理上相邻地存储在一列中,从而最小化寻道时间。

独特特点

Cassandra专为特定的用例而设计——处理写入负载量大且对停机时间无法容忍。这些成为它的独特卖点。

  • 极快的写入性能。当处理大量写入负载时,Cassandra可以说是最快的数据库。
  • 线性可扩展性。也就是说,您可以向集群中添加任意多个节点,而集群的复杂度和脆弱性都不会增加。
  • 无与伦比的分区容错性。也就是说,即使Cassandra集群中的多个节点发生故障,数据库也能继续正常运行而不会损失数据完整性。
  • 静态类型

何时使用Cassandra

日志记录和分析是Cassandra的两个最佳用例。但这还不是全部——当您需要处理非常大量的数据时(例如,Apple的Cassandra部署处理400多PB的数据,Netflix每天处理1万亿个请求),并且几乎没有停机时间时,Cassandra是最好的选择。高可用性是Cassandra的重要特点之一。

何时不使用Cassandra

Cassandra的列式存储方案也有其缺点。数据模型相对扁平,如果需要聚合,则Cassandra的功能有限。此外,它通过牺牲一致性来实现高可用性(请记住分布式系统的CAP定理),这使得它不太适合需要高读取准确性的系统。

Timescale

新的发展需要新型数据库,物联网(IoT)就是其中之一。其中最好的开源数据库之一就是Timescale。

Timescale属于所谓的“时间序列”数据库类型。它与传统数据库不同之处在于时间是主要关注的轴,对于大规模数据集的分析和可视化是重中之重。时间序列数据库很少对现有数据进行更改;一个例子是传感器发送的温度读数,新数据每秒钟都在累积,这对于分析和报告非常有意义。

为什么不仅使用具有时间戳字段的传统数据库呢?有两个主要原因:

  • 通用数据库未经过优化以处理基于时间的数据。对于相同的数据量,通用数据库速度会慢得多。
  • 数据库需要处理大量的数据,因为新数据不断涌入,而删除数据或稍后更改模式不是一个选择。

独特特点

Timescale DB具有一些令人兴奋的特点,使其与同类数据库相区别:

  • 它是基于PostgreSQL构建的,可以说是最好的开源关系数据库。如果你的项目已经在运行PostgreSQL,Timescale将轻松适应。
  • 查询使用熟悉的SQL语法,降低了学习曲线。
  • 写入速度非常快,每秒可以插入数百万条记录。
  • 对于Timescale来说,拥有数十亿行或拥有PB级数据并不是什么大问题。
  • 真正灵活的模式,根据需要选择关系型或无模式。

讨论何时使用或不使用Timescale DB并没有太多意义。如果物联网是你的领域,或者你追求类似的数据库特性,Timescale值得一试。

CouchDB

CouchDB是一个简洁的数据库解决方案,安静地坐在一个角落里,并拥有一小部分忠实的追随者。它的创建是为了解决数据的网络丢失和最终解决,这是一个如此混乱的问题,以至于开发人员宁愿换工作也不愿处理它。

基本上,你可以将CouchDB集群视为一个分布式的节点集合,有大有小,其中一些节点预计处于离线状态。一旦节点上线,它就会将数据发送回集群,集群会慢慢而谨慎地消化这些数据,最终对整个集群可用。

独特特点

CouchDB在数据库领域有一些独特的特点。

  • 离线优先的数据同步功能
  • 专门为移动设备和Web浏览器提供的特殊版本(PouchDB,CouchDB Lite等)
  • 经过抗崩溃测试的可靠性
  • 容易进行冗余数据存储的集群化

何时使用CouchDB

CouchDB是为离线容错而构建的,在这方面仍然无人能敌。一个典型的用例是移动应用程序,其中部分数据驻留在用户手机上的CouchDB实例上(因为这是数据生成的位置)。有趣的是,你不能指望用户的设备始终保持连接,这意味着数据库必须机会主义,并准备好以后解决冲突的更新。这是通过令人印象深刻的 Couch Replication Protocol 实现的。

何时不使用CouchDB

试图在其预期用例之外使用CouchDB将导致灾难。它使用的存储空间比其他任何东西都多得多,仅仅是因为它需要维护数据的冗余副本和冲突解决结果。因此,写入速度也非常慢。最后,CouchDB不适合作为通用模式引擎,因为它与模式更改不兼容。

FerretDB

FerretDB是一个开源创新平台,以MongoDB为基础构建的Postgres替代品。MongoDB是最易于使用、得到良好支持的数据库,使开发人员能够比关系数据库更快地构建应用程序。

然而,MongoDB放弃了其开源根基,改变了服务器端公共许可证,并使其对许多开源和商业项目无法使用;这就是FerretDB的用武之地。使用FerretDB,用户可以运行相同的MongoDB协议查询,而无需学习新的语言或命令。

FerretDB是一个开源文档数据库,具有内置的MongoDB兼容性,同时可以运行MongoDB工作负载的PostgreSQL和其他数据库后端;这允许您在PostgreSQL中使用现有的MongoDB语法和命令来使用数据库。

FerretDB是一个文档数据库,使用类似MongoDB的命令、驱动程序和工具来存储数据。

与使用表、行和列指定数据库结构的关系型数据库不同,FerretDB将信息保存为JSON文档,可以与现代在线和移动应用程序无缝集成。

FerretDB快速高效地搜索大型数据库的能力是其最突出的特点之一。此外,该平台非常适应性强,可以根据您的组织需求进行调整。

对于专业人士和初学者来说,这是一个令人惊叹的数据库解决方案。它是一个完全去中心化的应用搜索引擎。

FerretDB是一个强大的数据库管理工具,允许开发人员和数据库管理员搜索、测试和部署代码。

结论

我不得不省略很多有趣的候选项,比如Riak,所以这个列表应该被看作是一个指南,而不是一条戒律。我希望通过这篇文章能够实现我的目标——不仅提供一系列数据库软件推荐,还简要讨论它们需要在哪里以及如何使用(和避免使用)。

如果你对学习数据库感兴趣,请查看一些优秀的在线课程。

类似文章