原文地址: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/
转载时须注明出处及本声明