推荐下一个项目的前11个开源数据库

本文概述

• PostgreSQL
• MariaDB
• CockroachDB
• Neo4j
• MongoDB
• RethinkDB
• Redis
• SQLite
• Cassandra
• Timescale
• CouchDB

数据就是一切。而且, 数据库也是如此。对于你的下一个踢球项目, 这里有一些很棒的开源选项。

对于一个由甲骨文和SQL Server这样的数据库诉讼统治了很长时间的世界, 现在似乎出现了无休止的解决方案。原因之一是开放源代码推动了创新-真正有才华的开发人员希望挠痒痒, 并创造自己可以吸收的东西。

另一部分是新业务模型的出现, 其中, 企业维护其产品的社区版本以获取思想份额和吸引力, 同时还提供商业附加产品。

结果？

数据库远远超过了一个。尚无官方统计, 但我敢肯定, 如果你将从特定于堆栈的对象数据库到大学不那么受欢迎的项目的所有内容组合在一起, 那么我们今天有一百多种选择。

我知道, 这也吓到我了。太多的选择–需要处理的文档太多–寿命很短。 ????

这就是为什么我决定写这篇文章的原因, 提出了十个最好的数据库, 你可以使用它们来改进自己的解决方案, 无论是为自己还是他人构建。

没有MySQL

请注意：尽管该列表可以说是最受欢迎的开源数据库解决方案, 但它不会包含MySQL。

为什么？仅仅是因为MySQL无处不在-这是每个人都首先学到的东西, 几乎所有的CMS或框架都支持MySQL, 并且对于大多数用例来说, 它非常非常好。换句话说, 不需要”发现” MySQL。 ????

也就是说, 请注意, 以下不一定是MySQL的替代品。在某些情况下, 可能是这样, 而在另一些情况下, 它们是完全不同的解决方案, 可以满足完全不同的需求。不用担心, 我也将讨论它们的用途。

特别说明：兼容性

在开始之前, 我还必须提到兼容性是你需要牢记的。如果你有一个出于某种原因而仅支持特定数据库引擎的项目, 那么你的选择就可以轻松解决。

例如, 如果你运行的是WordPress, 那么本文对你毫无用处。 ????同样, 那些在JAMStack上运行静态站点的人也不会因为过于认真地寻找替代方案而一无所获。

由你决定兼容性方程式。但是, 如果你确实空白, 并且架构由你自己决定, 则可以提出一些整洁的建议。

开源数据库

• PostgreSQL
• MariaDB
• CockroachDB
• Neo4j
• MongoDB
• RethinkDB
• Redis
• SQLite
• Cassandra
• Timescale
• CouchDB

PostgreSQL

如果你来自PHP(WordPress, Magento, Drupal等), 那么PostgreSQL对你来说听起来很陌生。但是, 这种关系数据库解决方案自1997年以来一直存在, 并且是Ruby, Python, Go等社区中的首选。

实际上, 许多开发人员最终”毕业”于PostgreSQL以获得其所提供的功能, 或仅仅是出于稳定性的考虑。很难说服某人像这样的简短文章, 但可以认为PostgreSQL是经过深思熟虑设计的产品, 永远不会让你失望。

有许多不错的SQL客户端可用于连接到PostgreSQL数据库进行管理和开发。

独特的功能

与其他关系数据库(特别是MySQL)相比, PostgreSQL具有一些引人入胜的功能, 例如：

• 数组, 范围, UUID, 地理位置等的内置数据类型。
• 对文档存储(JSON样式), XML和键值存储(Hstore)的本机支持
• 同步和异步复制
• 可在PL, Perl, Python等中编写脚本
• 全文搜索

我个人最喜欢的是地理位置引擎(它消除了使用基于位置的应用程序时的痛苦-尝试手动查找所有附近的点, 你会明白我的意思的)和对数组的支持(许多MySQL项目因缺乏而被撤消)数组, 而是选择臭名昭著的逗号分隔的字符串)。

何时使用PostgreSQL

PostgreSQL总是比其他任何关系数据库引擎更好的选择。也就是说, 如果你正在开始一个新项目并且之前被MySQL咬过, 那么现在是考虑PostgreSQL好时机。我有一些朋友放弃了与MySQL神秘的事务锁定失败作斗争, 并永久前进。如果你决定相同, 则不会反应过度。

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

何时不使用PostgreSQL

当你的数据模型不是关系型的和/或你有非常特定的架构要求时, PostgreSQL没有意义。例如, 考虑Analytics(分析), 在该分析中, 不断根据现有数据创建新报告。这样的系统是读取繁重的, 并且在对其施加严格的模式时会受到影响。当然, PostgreSQL有一个文档存储引擎, 但是当你处理大型数据集时, 事情就开始崩溃了。

换句话说, 除非你100％知道自己在做什么, 否则请始终使用PostgreSQL！ ????

如果有兴趣了解更多信息, 请查看此SQL＆PostgreSQL初学者课程。

MariaDB

MariaDB是由开发MySQL的同一人创建的, 以替代MySQL。

困惑？

好吧, 实际上, 在2010年MySQL被甲骨文接管之后(通过收购Sun Microsystems, 顺带一提, 这也是甲骨文控制Java的方式), MySQL的创建者开始了一个新的开源项目MariaDB。

你问为什么所有这些无聊的细节都重要？这是因为MariaDB是使用与MySQL相同的代码库创建的(在开源世界中, 这被称为”分叉”现有项目)。结果, MariaDB被呈现为MySQL的”替代”替代品。

也就是说, 如果你正在使用MySQL并想迁移到MariaDB, 则该过程是如此简单, 以至于你根本不相信它。

不幸的是, 这样的迁移是一条单向的街道。从MariaDB返回MySQL是不可能的, 如果你尝试使用武力, 则可以确保永久性数据库损坏！

独特的功能

虽然MariaDB本质上是MySQL的克隆, 但严格来说并非如此。自从引入数据库以来, 两者之间的差异一直在增长。在撰写本文时, 采用MariaDB必须是你经过深思熟虑的决定。就是说, MariaDB中正在发生许多新事情, 这些新事物可以帮助你进行此过渡：

• 真正的自由和开放：由于没有单个公司实体控制MariaDB, 因此你无需担心突然的掠夺性许可和其他麻烦。
• 满足特定需求的存储引擎还有其他几种选择：例如, 用于分布式事务的Spider引擎； ColumnStore用于海量数据仓库； ColumnStore引擎, 用于并行, 分布式存储；还有很多很多
• 与MySQL相比, 速度有所提高, 尤其是由于Aria存储引擎可处理复杂的查询。
• 表中不同行的动态列。
• 更好的复制功能(例如, 多源复制)
• 几个JSON函数
• 虚拟列

。 。 。还有很多很多。跟上MariaDB的所有功能很费力。 ????

何时使用MariaDB

如果你想真正地替代MySQL, 希望保持创新趋势并且不打算再次返回MySQL, 则应该使用MariaDB。一个很好的用例是在MariaDB中使用新的存储引擎来补充项目中现有的关系数据模型。

什么时候不使用MariaDB

与MySQL的兼容性是这里唯一需要考虑的问题。就是说, 随着WordPress, Joomla, Magento等项目开始支持MariaDB, 这一问题变得越来越少。我的建议是不要使用MariaDB欺骗不支持它的CMS, 因为有许多特定于数据库的窍门很容易使系统崩溃。

CockroachDB

CockroachDB背后的团队似乎由受虐狂组成。有了这样的产品名称, 他们肯定会想尽一切办法仍赢吗？

好吧, 不完全是。

“蟑螂”背后的想法是, 它是为生存而建立的昆虫。无论发生什么事-捕食者, 洪水, 永恒的黑暗, 腐烂的食物, 轰炸, 蟑螂找到了生存和繁殖的方法。

这个想法是, CockroachDB背后的团队(由前Google工程师组成)在大规模使用传统SQL解决方案的局限时感到沮丧。这是因为从历史上看, SQL解决方案应该托管在一台计算机上(数据不是那么大)。长期以来, 一直没有办法构建运行SQL的数据库集群, 这就是MongoDB吸引了如此多关注的原因。

即使在MySQL, PostgreSQL和MariaDB中出现复制和集群功能时, 它充其量也是痛苦的。 CoackroachDB希望改变这一点, 为SQL世界带来轻松的分片, 集群和高可用性。

何时使用CockroachDB

CockroachDB是系统架构师的梦想成真。如果你发誓要使用SQL并且一直对MongoDB的扩展功能有所了解, 那么你会喜欢CockroachDB。现在, 你可以快速设置集群, 对其进行查询, 并在晚上安静地入睡。 ????

什么时候不使用CockroachDB

比你所不知道的魔鬼好。我的意思是, 如果你现有的RDBMS对你而言运行良好, 并且你认为可以解决它带来的扩展难题, 请坚持使用。对于所有涉及的天才, CockroachDB是一个新产品, 你以后不想再为此苦苦挣扎了。另一个主要原因是SQL兼容性-如果你正在做一些奇怪的SQL事情, 并依靠它来处理关键事情, 那么CockroachDB会为你提供过多的优势。

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

Neo4j

近十年来最重要的发展之一就是关联数据。我们周围的世界并没有分成桌子, 行和盒子, 而是一团糟, 几乎所有其他事物都与之相连。

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

这是因为这些解决方案的理想数据结构是图形, 这是完全不同的野兽。为此, 你需要一个像Neo4j这样的图形数据库。

上面的示例直接来自Neo4j网站, 显示了大学生如何与他们的系和课程建立联系。这样的数据模型对于SQL来说是根本不可能的, 因为要避免无限循环和内存溢出将非常困难。

独特的功能

图形数据库本身是独特的, Neo4j几乎是使用图形的唯一选择。结果, 它具有的任何功能都是独一无二的。 ????

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

讨论何时使用Neo4j以及何时不使用Neo4j都是有争议的。如果你需要数据之间基于图形的关系, 则需要Neo4j。 ????

MongoDB

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

与关系数据库不同, MongoDB是一个”文档数据库”, 这意味着它以大块形式存储数据, 而相关数据则聚集在同一块中。通过想象这样的JSON结构的聚合可以最好地理解这一点：

在此, 与基于表的结构不同, 用户的联系详细信息和访问级别位于同一对象内。提取用户对象会自动提取关联的数据, 并且没有联接的概念。这是MongoDB的更详细介绍。

独特的功能

MongoDB具有一些严重的功能(我几乎想写” kick-ass”来传达影响, 但在公共网站上可能不合适), 这些功能使几位经验丰富的建筑师永远放弃了关系领域：

• 适用于特殊/不可预测的用例的灵活模式。
• 简单的分片和聚类。你只需要为集群设置配置, 而不必理会它。
• 从集群中添加或删除节点非常简单。
• 分布式事务锁。早期版本中缺少此功能, 但最终引入。
• 它针对非常快的写入进行了优化, 使其非常适合作为缓存系统的分析数据。

如果我听起来像MongoDB的发言人, 我深表歉意, 但是很难夸大MongoDB的优势。当然, NoSQL数据建模起初很奇怪, 有些人从来没有掌握过, 但是对于许多架构师来说, 它几乎总是胜过基于表的架构。

何时使用MongoDB

MongoDB是从结构化, 严格的SQL世界到无序的, 几乎令人困惑的NoSQL的巨大跨越桥梁。它非常擅长开发原型, 因为根本没有什么可担心的架构, 以及你何时真正需要扩展。是的, 你可以使用云SQL服务来解决数据库扩展问题, 但是这很昂贵！

最后, 在某些情况下, 基于SQL的解决方案将无法使用。例如, 如果你要创建像Canva这样的产品, 那么用户可以在其中创建任意复杂的设计, 并可以在以后进行编辑, 那么请使用关系数据库来祝你好运！

什么时候不使用MongoDB

对于那些不知道自己在做什么的人, MongoDB提供的完全缺少的模式可能会成为一个tar pit。数据不匹配, 无效数据, 不应为空的空字段-所有这些以及更多可能。 MongoDB本质上是一个”哑”数据存储, 如果你选择它, 则应用程序代码必须承担很多维护数据完整性的责任。

如果你是开发人员, 那么你会发现这很有用。

RethinkDB

顾名思义, RethinkDB在实时应用程序方面”重新考虑”了数据库的思想和功能。

更新数据库后, 应用程序将无法得知。公认的方法是应用程序在有更新时立即发出通知, 该更新通过复杂的桥推送到前端(PHP-> Redis-> Node-> Socket.io是一个示例)。

但是, 如果可以将更新直接从数据库推送到前端怎么办？

是的, 这就是RethinkDB的承诺。因此, 如果你要制作一个真正的实时应用程序(游戏, 市场, 分析等), 那么Rethink DB值得一看。

Redis

对于数据库, 忽略Redis的存在几乎太容易了。这是因为Redis是一个内存数据库, 主要用于缓存等支持功能。

学习此数据库需要十分钟的时间(从字面上看！), 它是一个简单的键值存储, 用于存储带有有效期限的字符串(当然, 可以将其设置为无穷大)。 Redis在实用性和性能方面所弥补的功能丧失了什么。由于它完全位于RAM中, 因此读写速度非常快(每秒数十万次操作并非闻所未闻)。

Redis还具有完善的发布订阅系统, 该”数据库”的吸引力是其两倍。

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

SQLite

是的, 我向我们保证关系数据库已经完成, 但是SQLite太可爱了, 无法忽略。

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

有用的功能

即使SQLite是MySQL之类的数据库的轻量级替代品, 它也带来了很大的冲击。其令人震惊的功能包括：

• 通过COMMIT, ROLLBACK和BEGIN完全支持事务。
• 每张表格支持32, 000列
• JSON支持
• 64路JOIN支持
• 子查询, 全文搜索等
• 最大数据库大小为140 TB！
• 最大行大小为1 GB！
• 比文件I / O快35％

何时使用SQLite

SQLite是一个非常专业的数据库, 专注于一种毫不费吹灰之力的方法。如果你的应用程序相对简单, 并且你不希望拥有功能完善的数据库, 那么SQLite是一个不错的选择。对于中小型CMS和演示应用程序, 这特别有意义。

什么时候不使用SQLite

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

Cassandra

尽管许多人宣称Java的时代即将到来, 但社区偶尔会突然抛弃重磅炸弹, 并让批评家保持沉默。Cassandra就是这样一个例子。

Cassandra属于所谓的” columnar”数据库家族。 Cassandra中的存储抽象是一列而不是一行。这里的想法是将所有数据物理上存储在同一列中的磁盘上, 以最大程度地减少查找时间。

独特的功能

设计Cassandra时要考虑到特定的用例-处理大量写入负载和零宕机时间。这些成为其独特的卖点。

• 极快的写入性能。在处理繁重的写入负载时, Cassandra可以说是目前最快的数据库。
• 线性可伸缩性。也就是说, 你可以继续向群集中添加任意数量的节点, 并且群集的复杂性或脆弱性将零增加。
• 无与伦比的分区容限。也就是说, 即使Cassandra群集中的多个节点出现故障, 数据库也可以在不丧失完整性的情况下保持性能。
• 静态打字

何时使用Cassandra

日志记录和分析是Cassandra的两个最佳用例。但这还不是全部–最棒的是, 当你需要处理非常大的数据量(苹果公司有Cassandra部署, 可以处理400 PB以上的数据, 而在Netflix每天处理1万亿个请求)时, 停机时间几乎为零。高可用性是Cassandra的标志之一。

何时不使用Cassandra

Cassandra的列存储方案也有其缺点。数据模型相当平坦, 如果你需要聚合, 那么Cassandra就不够用了。此外, 它通过牺牲一致性(记住分布式系统的CAP定理)来实现高可用性, 这使其不适用于需要高读取精度的系统。

Timescale

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

时标是所谓的”时间序列”数据库的一种。它与传统数据库的区别在于, 它是关注的主要轴, 海量数据集的分析和可视化是当务之急。时间序列数据库很少会看到现有数据的变化；一个例子是温室中的传感器发送的温度读数-新数据保持每秒积累, 这对于分析和报告很重要。

为什么不仅使用带有时间戳字段的传统数据库呢？嗯, 这主要有两个原因：

• 通用数据库未针对使用基于时间的数据进行优化。对于相同数量的数据, 通用数据库将慢得多。
• 随着新数据不断流入并删除数据或更改模式, 数据库需要处理大量数据。后来, 这不是一个选择。

独特的功能

Timescale DB具有一些令人兴奋的功能, 使其与同类中的其他数据库区分开来：

• 它建立在PostgreSQL之上, 可以说是目前最好的开源关系数据库。如果你的项目已经在运行PostgreSQL, 则Timescale将向右滑动。
• 通过熟悉的SQL语法进行查询, 从而减少了学习难度。
• 快得惊人的写入速度-每秒数百万的插入次数并非闻所未闻。
• 数十亿行或PB的数据-对于Timescale来说并不重要。
• 模式具有真正的灵活性-根据需要从关系模式或无模式中进行选择。

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

CouchDB

CouchDB是一个精巧的小型数据库解决方案, 它安静地位于角落, 并拥有少量但专心的追随者。创建它是为了解决网络丢失和最终数据解析的问题, 而这恰好是一个麻烦的问题, 以至于开发人员会改换工作而不是处理它。

从本质上讲, 你可以将CouchDB集群视为大型和小型节点的分布式集合, 其中一些节点预计将脱机。节点联机后, 它将数据发送回群集, 群集将被缓慢而仔细地消化, 最终可用于整个群集。

独特的功能

当涉及数据库时, CouchDB是一个独特的品种。

• 离线优先数据同步功能
• 适用于移动和Web浏览器的特殊版本(PouchDB, CouchDB Lite等)
• 耐碰撞, 经战斗考验的可靠性
• 通过冗余数据存储轻松集群

何时使用CouchDB

CouchDB专为离线容忍而构建, 在这方面仍然无与伦比。一个典型的用例是移动应用程序, 其中部分数据驻留在用户电话的CouchDB实例上(因为这是生成数据的地方)。令人兴奋的是, 你不能一直依赖用户的设备进行连接, 这意味着数据库必须具有机会性, 并且可以在以后解决冲突的更新。这是通过令人印象深刻的Couch复制协议实现的。

何时不使用CouchDB

尝试在其预期用例之外使用CouchDB将导致灾难。它使用的存储方式远比其他任何方式都要多, 这仅仅是因为它需要维护数据的冗余副本和解决冲突的结果。结果, 写入速度也非常慢。最后, CouchDB不适合用作通用模式引擎, 因为它不能很好地适应模式更改。

总结

我不得不遗漏许多有趣的候选人, 例如Riak, 因此, 该清单应作为指导, 而不是诫命。我希望我能够通过本文实现我的目标-不仅提出数据库建议的集合, 而且简要讨论需要在何处以及如何使用它们(并避免使用它们)。

如果你想学习数据库, 请访问Udemy以获得一些出色的在线课程。