何时弃用 MongoDB?| 技术头条
即使位列数据库排行榜的 Top 5,MangoDB 的日子也并不好过。自去年 10 月,MangoDB 宣布将开源许可协议从 GNU AGPLv3 切换至 Server ...
即使位列数据库排行榜的 Top 5,MangoDB 的日子也并不好过。
自去年 10 月,MangoDB 宣布将开源许可协议从 GNU AGPLv3 切换至 Server Side Public License 之后,AWS、RedHat、Fedora、Debian、Lyft 等项目以及企业随即相继宣布将移除 MangoDB,一时之间,MangoDB 成为众矢之的。但扪心自问,MangoDB 真的如此糟糕吗?我们又该如何做出正确的选择?
作者 | Justin Etheredge
译者 | 弯月
责编 | 屠敏
出品 | CSDN(ID:CSDNnews)
以下为译文:
最近,我读到了一篇关于红帽公司的Satellite不再支持MongoDB的文章(有些人说这是因为许可条款方面的修改。)这不禁让我想起过去几年里,我经常看到有关文章说为何MongoDB如此可怕,以及为何大家都不应该再使用MongoDB。然而,与此同时,MongoDB已经发展成为一款更为成熟的产品。那么 ,情况究竟如何呢?难道所有的这些仇恨真的只是由于MongoDB在早期实现和营销中犯下的错误吗?还是说人们责怪MongoDB,只是因为他们没能正确地评价MongoDB是否适合自己?
趋势聚焦
多年来,我一直在从事软件行业,但即便如此,我也只是经历了一小部分对该行业带来了冲击性的趋势。我目睹了4GL、AOP、敏捷、SOA、Web 2.0、AJAX、区块链,以及等等诸多技术的崛起。每年软件工程领域都会出现新的趋势。其中一些很快就遭遇了失败,还有一些则从根本上改变了软件开发的方式。
随着创新技术开始引领潮流,人们的兴趣骤然而生,于是大家纷纷开始涌入,或者看到其他跃跃欲试的人群为其造势。高德纳公司为整个过程专门定义了“技术成熟度曲线”(The Hype Cycle),虽然存在争议,但该曲线确实正确地评估了一项有价值的技术的发展成熟过程。
但每隔一段时间,就会出现一种新的创新(或者是旧已有技术的再度复苏),而这种创新由其中的某一种特定的实现所驱动。以NoSQL为例,其就受到了MongoDB的出现以及迅速崛起的大幅推动。这场运动并非源自MongoDB,但是大型互联网公司的数据挑战确实推动了非关系型数据库的回归。Google的Bigtable和Facebook的Cassandra等项目相继涌现,然而,MongoDB才是大多数开发人员最易获取,也是最方便实现的NoSQL数据库。
注:现在,你可能在想,我这不是把列式数据库、键/值存储或众多其他数据存储类型都混杂到了NoSQL旗下吗?你说的没错,但是当时这种情况确实发生了。每个人都一股脑扎进NoSQL中,坚称他们离不开NoSQL,但实际上他们并没有真正理解其中所涉及的不同技术。对于很多人来说,MongoDB就是NoSQL。
开发人员对此表示反对。无模式数据库无限扩展的概念可以应对任何挑战,因此非常诱人。在2014年左右,几乎到处都有人在使用MongoDB,而放到一年前人们都还都在使用MySQL、Postgres或SQL Server这样的关系数据库。如果你问他们MongoDB,他们的回答各不相同:有人的说辞很老套“网络规模扩展的需要”,也有人经过了深思熟虑“我的数据结构非常松散,特别适合无模式数据库”。
重要的是不要忘记,MongoDB和一般的文档数据库可以解决传统关系数据库无法应对的如下难题:
严格的模式:在关系数据库中,如果你有动态的数据,则不得不创建一堆随机的“杂项”数据列,将数据按块保存起来,或者使用 EAVEAV设置……所有这些方法都存在严重的缺陷。
难以扩展:在关系数据库中,如果你的数据过于庞大,则无法保存到一太服务器中;而MongoDB拥有跨多台计算机扩展数据的机制。
难以修改模式:数据无法迁移!在关系数据库中,变更数据库的结构是一项巨大的挑战(特别是你的数据量十分庞大的情况下)。MongoDB可以大幅简化这一过程,而且很容易上手,你可以不断更新你的模式并快速移动。
写入性能:MongoDB的性能非常好,尤其是按照某种方式配置的情况下。MongoDB开箱即用的写入配置受到的抨击最多,但也确实带来了出色的性能。
注意事项
MongoDB提供的潜在优势非常大,尤其是对于面临某些特定类型的问题的人。如果不配合上下文,或对于没有经验的人来说,阅读了上述列表就会以为MongoDB确实给数据库系统带来了颠覆性的改变。然而,上述优势还存在一些注意事项,下面我会一一列出。
公平地说,10gen / MongoDB Inc.并不是没有考虑到这些问题,他们只是做出了权衡利弊。
没有事务 :事务可以说是许多关系数据库的核心特征(虽然不是全部,但确实是大多数)。事务意味着你能够以原子方式执行多项操作,并始终确保数据保持一致。当然,在NoSQL数据库中,你可以在一个文档中包含一个事务,或者也可以通过分两个阶段提交的策略实现事务机制。但关键在于,这项工作必须由你自己完成……而且要保证正确无误的话,这可能也是一项富有挑战性且需要付出大量精力的工作。除非你看到数据库中的数据出现非法的状态,否则你往往无法意识到数据丢失的问题,只因为你无法保证操作的原子性。注意:很多人可能会提醒我,MongoDB 4.0已经于去年引入了事务机制,但是仍然存在很多局限性。正如本文开头所说,请评估是否能够满足你的需求。
没有关系完整性(外键):如果你的数据之间存在关系,那么你就需要将这些关系保存下来。几乎所有数据中都包含某种关系,如果数据库强制体现这些关系,那么就必须由你的应用程序来负责。如果数据库强制执行这些关系,那么就可以大大减轻应用程序的负担,从而减轻工程师的工作量。
缺乏执行数据结构的能力:强模式有时候可能会带来痛苦,但它们也能成为确保数据结构良好的强大机制。如果合理利用,你就可以通过这种强大的机制,确保你的数据在结构上符合你的期望。MongoDB等文档数据库在模式方面提供了惊人的灵活性,然而,这种灵活性会将责任转嫁到维护者身上,由他们负责数据的清洁。如果你不付出这些努力,那么最终你不得不在应用程序中大量代码,处理那些结构上与预期不符的数据。我们常常说:应用迟早需要重写,但数据将永远存在。注意:MongoDB支持模式验证,该功能非常有用,但仍然无法提供可以与关系数据库相媲美的保障。主要在于添加或修改模式验证不会影响集合中现有的数据,你需要确保更新的数据匹配新模式。因此,到底是否满足需求还得由你自己来决定。
自定义查询语言/没有工具生态系统:SQL在刚刚出现时绝对掀起了一场革命,从那以后再也没有任何变化。SQL是一种非常强大的语言,但也富有挑战性。你必须使用由JSON片段组成的自定义查询语言查询数据库,对于经验丰富的SQL人员来说,这是一个巨大的退步。此外,我们有一整套可与SQL数据库互操作的工具,从IDE到报告工具,应有尽有。切换到不支持SQL的数据库意味着你就无法使用大多数的工具了,或者你也可以想办法将输入保存到SQL数据库中,那么你就可以继续使用这些工具了,只不过这个过程可能比你想象得还难。
许多使用MongoDB的开发人员没有深入理解他们为权衡付出的代价,而且他们常常将MongoDB作为应用程序的主要数据存储。而这样的决定通常意味着极为昂贵的成本。
我们应该怎么做?
当然,并不是每位开发人员都会不计后果地一头扎进去。但这样的情况也着实不少,未来几年会有不少项目在意识到不适合后放弃MongoDB。如果这些组织能够花点时间系统地考虑一下他们做出的技术选择,那么也许就不会有那么多人做出这样的选择了。
那么,我们怎样才能确定哪种技术适合实际情况呢?目前已经有不少人尝试为评估技术创建系统性的框架,例如“软件公司引入技术的框架”(http://www.wohlin.eu/spi96.pdf),“评估软件技术的框架”(https://pdfs.semanticscholar.org/4268/30dd5dd944d3b75ec56b2a3b151c18afbaf9.pdf)。但我认为不需要弄得如此复杂。
我们只需要通过以下两个主要问题,就合理地评估众多技术,但是难点在于找到能够负责任地回答这些问题的人,他们愿意花时间回答这些问题,同时确保答案中毫无偏见。
“如果你没有遇到某个特定问题,就不需要引入新的工具。”
问题一:我需要解决哪些问题?
如果你没有遇到某个特定问题,就不需要引入新的工具。你可以就此打住。不要拿着解决方案反过来找问题。如果你没有遇到问题,那么就不需要新技术来更好地解决问题,所以就不需要决策。如果你是看到别人在使用某种技术,才考虑自己也使用,那么你应该先想一想他们遇到的问题,然后再问问自己是否也面临同样的问题。当你看到别的公司使用某种技术时,自己也会情不自禁,难点在于判断你自己是否也面临相同的困难。
问题二:我放弃了什么?
很明显,这个问题更加难以回答,因为你必须深入剖析,并对新旧两种技术都有很好的理解。有时候,在使用新技术构建出产品之前,你很难真正掌握这项技术,你也可以咨询那些在这项技术上花费了大量时间的人。
如果你既没有实际的使用经验,也没有人可以咨询,那么就应该考虑如何通过最小的投资确认该技术是否有价值。此外,如果你进行了投资,那么撤销这项决策的难度有多大?
人类总是把事情搞砸
你必须时刻牢记,如果你想不偏不倚地回答这些问题,那么就必须与人类的天性作斗争。为了有效地评估技术,必须克服一系列的认知偏差,下面仅举几个例子:
从众心理:相信每个人都听说过,但要克服这一点却非常艰难。请确保只选择能够解决你的实际需求的技术,而不要盲目跟风。
喜新厌旧:许多软件开发人员都会低估他们长期使用的技术,同时高估新技术的优势。这不仅仅是软件工程师特有的问题,每个人都有这样的倾向。
正面特点效应:有时我们只能看到眼前的东西,而会忽略不存在的东西。如果这一点与“喜新厌旧”的心理交织起来,那么有可能造成严重的破坏。因为你不仅更加看重新技术,还会忽视新技术中存在的弊端。
客观地看待事物是一种挑战,但了解可能影响到你的偏见,有助于你做出更合理的决策。
总结
当一项新的创新出现(或复苏)时,我们需要非常谨慎地回答以下两个问题:
这个工具能为我们解决实际问题吗?
我们是否清楚其中的权衡利弊?
如果你无法自信地回答这两个问题,那么就需要后退一步,重新进行评估。
MongoDB到底是不是正确的选择?是,它当然是,但是与大多数软件工程中的问题一样,你需要视情况而定。对于那些在这两个问题上有明确答案的团队来说,他们很多人都发现了MongoDB的价值,而且他们还会不断挖掘更多的价值。对于那些没有具体答案的人,希望他们能够从中吸取宝贵的教训(而不用付出惨重代价),学习如何驾驭技术成熟度曲线。
免责声明
我想澄清一点,我既不喜爱MongoDB,也不讨厌它。我根本没遇到过真正适合MongoDB的问题。我了解10gen/MongoDB公司确实犯过一些错误,包括在项目早期采用不安全的默认设置,并在所有场合下(特别是在黑客马拉松活动中)推广MongoDB,将其描述成一切数据需求的终极解决方案。没错,这些可能都是错误的决定,但我认为这也证实了本文所阐述的观点——所有问题都可以通过技术评估快速发现。
原文:https://www.simplethread.com/was-mongodb-ever-the-right-choice/
本文为 CSDN 翻译,如需转载,请注明来源出处。作者独立观点,不代表 CSDN 立场。
热 文 推 荐
戳他↓↓↓
“入职 6 年,新人工资高我 2 千”:老板不加钱,不是嫌你老
特斯拉Q1销量大跌,马斯克吹出的“交付100万”如何破?| 极客头条
2019年技术盘点微服务篇(二):青云直上云霄 | 程序员硬核评测
System.out.println("点个在看吧!");
console.log("点个在看吧!");
print("点个在看吧!");
printf("点个在看吧!\n");
cout << "点个在看吧!" << endl;
Console.WriteLine("点个在看吧!");
Response.Write("点个在看吧!");
alert("点个在看吧!")
echo "点个在看吧!"
点击阅读原文,输入关键词,即可搜索您想要的 CSDN 文章。
你点的每个“在看”,我都认真当成了喜欢更多推荐
所有评论(0)