原文地址：https://geekflare.com/open-source-database/
注意：尽管本文囊括了最受欢迎的开源数据库，但它不包括mysql，因为MySQL无处不在-这是每个人首先学到的东西，几乎所有的CMS或框架都支持MySQL，并且对于大多数场景来说，它非常非常好。换句话说，不需要“寻找” MySQL。
另外，本文介绍的数据库不一定要替代MySQL。某些情况下，它们是针对不同需求的不同解决方案。不用担心，我也将讨论它们的适用性。
特别提醒：请注意数据库的兼容性，如果您的项目出于某种目的仅仅支持特定数据库引擎，那么您就不用考虑太多了。例如，如果您正在运行WordPress，那么本文对您毫无用处。同样，那些运行在JAMStack的静态站点也不用寻找替代方案。
PostgreSQL
如果您经常使用php程序（WordPress, Magento, Drupal等），那么PostgreSQL对您来说可能是陌生的。但是，这种关系型数据库解决方案自1997年以来一直存在，并且是Ruby，Python，Go等社区的首选。
实际上，许多开发人员最终选择了PostgreSQL，是由于它所提供的功能，或仅仅是出于稳定性的考虑。很难在这样一篇短小文章内推荐某人使用它，但是PostgreSQL作为经过深思熟虑设计的产品，绝不会让您失望。
有许多不错的SQL客户端，可用于连接到PostgreSQL数据库，进行管理和开发。
独特的功能
与其他关系型数据库（特别是MySQL）相比，PostgreSQL具有一些令人赞叹的功能，例如：
- 数组，Range，UUID（通用唯一识别码），地理位置等内置数据类型。
- 对文档存储（JSON格式），XML和key-value存储（Hstore）的本地支持
- 同步和异步复制
- 可在PL，Perl，Python等语言中编写脚本
- 全文搜索
我个人最喜欢的是地理位置引擎（它消除了开发基于位置的APP时的痛苦——手动查找所有附近的点，您会明白我的意思的）和对数组的支持（许多MySQL项目不支持数组，而是选择臭名昭著的逗号分隔的字符串来替代）。
何时使用PostgreSQL
PostgreSQL总是一个比其他任何关系型数据库更好的选项。也就是说，如果您正在开始一个新项目，并且之前被MySQL折磨过，那么现在是考虑PostgreSQL的好时机。我有一些朋友放弃了与MySQL事务锁定失败作斗争，迁移到了PostgreSQL。
如果您需要部分NoSQL功能，如混合数据模型，那么PostgreSQL也具有明显的优势。由于本地支持文档和键值存储，因此您无需去寻找，安装，学习和维护另一个数据库解决方案。
何时不使用PostgreSQL
当您的数据模型不是关系型的和/或您有非常特定的体系结构要求时，PostgreSQL没有意义。例如，在Analytics型数据库中，不断根据现有数据创建新报告。此类系统读取繁重，并且对它们施加严格的架构时会很痛苦。当然，PostgreSQL有一个文档存储引擎，但是当您处理大型数据集时，事情就开始崩坏了。
换句话说，请始终使用PostgreSQL，除非您100％知道自己在做什么！
如果有兴趣了解更多信息，请查看此SQL＆PostgreSQL初学者课程。
MariaDB
MariaDB和MySQL是同一人开发的。在2010年MySQL被甲骨文接管之后（通过收购Sun Microsystems，顺带一提，这也是甲骨文控制Java的方式），MySQL的创建者开发了一个新的开源项目MariaDB，用以替代MySQL。
您问为什么要介绍这些无聊的细节？这是因为MariaDB是使用与MySQL相同的代码库创建的（在开源世界中，这被称为“forking”现有项目）。因此，MariaDB被视为为MySQL的替代品。
也就是说，如果您正在使用MySQL并想迁移到MariaDB，则该过程是如此简单，以至于您根本不相信它。
但是很遗憾，这样的迁移是单向的。从MariaDB迁移到MySQL是不可能的，如果强行这样做，最后的结果就是数据库永久损坏！
独特的功能
虽然MariaDB本质上是MySQL的克隆，但自从该数据库出现以来，两者之间的差异越来越大。在撰写本文时，采用MariaDB必须是您经过深思熟虑的决定。就是说，MariaDB中有很多（可能在MySQL中没有的）新特性：
- 真正的自由和开放：由于没有哪个公司控制MariaDB，因此您无需担心突然失去许可和其他麻烦。
- 一些可选的满足特定需求的存储引擎：例如，用于分布式事务的Spider引擎；用于海量数据、并行、分布式存储的ColumnStore引擎；等等
- 与MySQL相比，速度有所提高，特别是Aria存储引擎可处理复杂查询。
- 表中不同行的动态列。
- 更好的复制功能（例如，多源复制）
- 一些JSON函数
- 虚拟列（Virtual columns）
。。。还有很多很多。了解MariaDB的所有功能是不容易的。
何时使用MariaDB
如果您想真正地替代MySQL，希望保持创新趋势并且不打算再次返回MySQL，则应该使用MariaDB。一个很好的案例是在MariaDB中使用新的存储引擎来补充项目现有的关系数据模型。
什么时候不使用MariaDB
与MySQL的兼容性是这里唯一需要考虑的问题。随着WordPress，Joomla，Magento等项目开始支持MariaDB，它的问题变得越来越少。我的建议是不要在不支持它的CMS中使用MariaDB，这样很容易使系统崩溃。
CockroachDB
CockroachDB背后的团队似乎由受虐狂组成。有了这样的产品名称，他们肯定想要扭转不利的局面，然后仍然获胜吗?
好吧，不完全是。
之所以使用“蟑螂”这个名字，是因为它们是生存能力最强的昆虫，不管发生什么事——掠食者，洪水，永夜，腐烂的食物，轰炸，蟑螂都能生存并繁衍下去。
这个想法起源于，CockroachDB背后的团队(由前谷歌工程师组成)对传统SQL解决方案在大规模应用时的局限性感到失望。这是因为从历史上看，SQL解决方案应该托管在一台计算机上（数据不是那么大）。长期以来，一直没有办法构建运行SQL的数据库集群，这就是MongoDB吸引了如此多关注的原因。
即使在MySQL，PostgreSQL和MariaDB中出现复制和聚类（clustering）功能时，分布式sql也是令人痛苦的。CoackroachDB希望改变这一点，为SQL世界带来轻松的切片，clustering和高可用性。
何时使用CockroachDB
CockroachDB使系统架构师的梦想成真。如果您对SQL深信不疑，并且一直对MongoDB的扩展能力耿耿于心，那么您一定会喜欢CockroachDB。现在，您可以快速地设置一个集群，向它提交查询，并在晚上安心地睡觉。
何时不使用CockroachDB
你认识的魔鬼比你不认识的要好。我的意思是，如果您现有的RDBMS对您而言运行良好，并且您认为可以解决其带来的扩展难题，请坚持使用。另一个主要原因是SQL兼容性——如果你在做一些奇怪的SQL事务，并依赖它做一些重要的事情，那么CockroachDB给你你提供很多你喜欢的边缘情况（超出预想的情况）。
从现在开始，我们将考虑满足高度专业化需求的non-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这种完全不提供任何结构的数据库可能会成为他们的绊脚石。数据不匹配，无效数据，不应为空的空字段-所有这些都是有可能的。MongoDB本质上是一个“dumb”数据存储，如果您选择它，则应用程序代码必须承担很多维护数据完整性的责任。
如果您是开发人员，那么您会发现这很有用。
RethinkDB
顾名思义，当涉及到实时应用程序时，RethinkDB 会“重新考虑”数据库的思想和功能。
更新数据库后，应用程序将无法知道。通用的方法更新时立刻给应用程序发送通知，该更新通过复杂的桥接推送到前端（PHP-> Redis-> Node-> Socket.io是一个示例）。
但是，可以直接将更新从数据库推送到前端吗？
是的，这就是RethinkDB的承诺。因此，如果您打算制作一个真正的实时应用程序（游戏，市场，分析等），那么Rethink DB值得一看。
Redis
当讨论数据库时，很容易忽略Redis的存在。这是因为Redis是一个内存数据库，主要用于缓存等支持功能。
学习此数据库只需十分钟，它是一个简单的键值存储，用于存储带有到期时间的字符串（当然，可以将其设置为无穷大）。Redis在实用性和性能上弥补了它在特性上的损失。由于它完全存在于RAM中，读写速度快得惊人(每秒几十万次操作并非夸张)。
Redis还具有完善的pub-sub系统，这使该“数据库”的吸引力提高了两倍。
换句话说，如果您的项目需要大量缓存，或具有一些分布式组件，则Redis是首选。
SQLite
是的，我说过关系数据库已经结束了，但是SQLite太可爱了，无法忽略。
SQLite是提供关系数据库存储引擎的轻量级C库。该数据库中的所有内容都保存在一个文件中（扩展名为.sqlite），您可以将其放在文件系统中的任何位置。这就是您需要使用它的全部理由！是的，不需要复杂的环境配置，也没有要连接的服务。
有用的功能
即使SQLite是MySQL之类的数据库的轻量级替代品，它也带来了很大的冲击。其令人震惊的功能包括：
- 通过COMMIT，ROLLBACK和BEGIN等完全支持事务。
- 每张表格最大32,000列
- 支持JSON
- 支持64-way 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是所谓的“时间序列”数据库的一种。它与传统数据库的区别在于，它关注的是主轴，而海量数据集的分析和可视化是重中之重。时间序列数据库很少会看到现有数据的变化；一个例子是温室中的传感器发送的温度——每秒钟都有新的数据不断积累，这对分析和报告很有意义。
为什么不只使用带有时间戳字段的传统数据库呢？嗯，这主要有两个原因：
- 传统数据库未针对使用基于时间的数据进行优化。对于相同数量的数据，传统数据库将慢得多。
- 数据库需要处理大量的数据，因为新的数据不断流入、删除数据或改变模式；传统数据库不能成为一种选择。
独特的功能
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以获得一些出色的在线课程。
版权属于：作者名称
本文链接：https://www.sitstars.com/archives/73/
转载时须注明出处及本声明