设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客
LUPA开源社区 首页 业界资讯 开源资讯 查看内容

MySQL还是NoSQL:开源数据库该如何选择

2014-3-6 11:08| 发布者: joejoe0332| 查看: 3478| 评论: 0|原作者: 毛梦琪|来自: CSDN

摘要: MySQL,关系型数据库,有数量庞大的支持者。NoSQL,非关系型数据库,被视为数据库革命者。两者似乎注定要有一场厮杀,可同属开源大家庭的它们却又能携手并进、和睦相处,齐心协力为开发者提供更好的服务。 ...
  MySQL,关系型数据库,有数量庞大的支持者。NoSQL,非关系型数据库,被视为数据库革命者。两者似乎注定要有一场厮杀,可同属开源大家庭的它们却又能携手并进、和睦相处,齐心协力为开发者提供更好的服务。

  MySQL体积小、速度快、成本低、结构稳定、便于查询,可以保证数据的一致性,但缺乏灵活性。NoSQL高性能、高扩展、高可 用,不用局限于固定的结构,减少了时间和空间上的开销,却又很难保证数据一致性。两者都有大量的用户和支持者,寻求两者的结合无疑是个很好的解决方案。作 者John Engates是Rackspace主机托管部门CTO,也是个开放云支持者,他为我们带来了详细的分析。



  以下为译文:


  开源数据领域被分成了两派,NoSQL狂热支持者喜欢发表长篇大论批评关系型数据库的局限性,MySQL爱好者则固执地捍卫关系型数据库——坚持让数据整齐地存放在表中。




  你肯定会认为这两方决不可能和睦相处,但事实上,成千上万的公司一直都在努力将关系型和非关系型数据库结合起来,而且很多年前就有这样的尝试了。


  但新技术的发展往往和过去的技术对立。当NoSQL发展起来时,光这个名字听起来就像是要宣告关系数据库的终结,但这是不可能的,至少不会这么快。


  Craigslist的成功


  Craigslist公司无缝集成结构化和非结构化数据检索是个很好的例子。过去,该公司一直用MySQL处理频繁的任务和分类广告。


  尽管工作量很大,MySQL还是能轻松地完成这项任务。只有当存档数据达到超纪录的级别时,才会产生对NoSQL的需求。由于管理的要求,Craigslist必须将所有历史数据存档——即使是SXSW期间为奥斯汀那昏暗、高价的公寓所做的广告也得存档。


  如果一个关系型数据库依靠数据之间的逻辑,那前端架构的更改必然会影响到存档数据。这是一个高风险、高时耗的过程,而且它会造成停机时间损失。想象一下去更新带有10亿条记录的MySQL服务器集群


  Craigslist发现需要以离散方式处理两类数据——当前数据和历史数据。Craigslist或许已经转而使用MongoDB帮助应对数据的增长,但是与MySQL一起运行的NoSQL也从没有出现过问题,这说明MySQL和NoSQL可以很好的结合。




  开源同盟


  越来越多的应用开发商和托管服务提供商认识到NoSQL和MySQL一直是开源同盟,没有因数据库类型不同而成为不相往来的仇敌。归于一点,数据就是数据,它应该用来为应用程序和用户服务,不应该受到后端数据库的限制。


  越来越多的Rackspace客户发现自己面临和Craigslist同样的处境。当关系型数据库涵盖所有他们的数据领域时,他们构建了自己的数据结构,而现在他们已经进入应用时代了。


  达到100万客户原先需要数年时间,现在只需要几周就可以了,而且社会共享和实时查询对数据提出了新的要求——也需要支持这些数据的基础设施,这一系列变化使他们面临的数据量达到了每月10亿之巨。


  他们不一定要挖掘MySQL数据库,但他们需要增加数据引擎。为了增加数据库的速度和灵活性,MongoDB、Cassandra或者 Redis(这类数据库)会被纳入数据结构中。但这些开源数据库不太可能用于存储用户机密信息或者财务记录,因为这些内容必须始终保持一致性。


  目前,技术公司在聘请传统关系型数据库管理员同时,组建一个NoSQL应用开发团队也很常见。有时,基于关系型数据库和非关系型数据库的同一个应用甚至可以在Web层进行通信。


  过去的数据库管理员必须和新一代使用NoSQL编程的开发人员合作,进行有关部署和体系结构的决策(也许这些数据库管理员和开发人员也能成为朋友)。


  可能这类公司连数据库管理员也没有,它们将所有的应用和数据层外包给托管服务供应商,这样的话,它们就得充分利用深厚的专业知识和团队合作,才能跨越SQL与NoSQL之间的鸿沟。


  选择其中一个?还是两者都要?


  应用程序是否应该与关系型数据库或NoSQL(也许是两者)相一致,当然,这得基于被生成或被检索数据的性质。和大多数科技领域的事物一样,做决定时要折中考虑。


  如果规模和性能比24小时的数据一致性更重要,那NoSQL是一个理想的选择 (NoSQL依赖于BASE模型——基本可用、软状态、最终一致性)。


  但如果要保证到“始终一致”,尤其是对于机密信息和财务信息,那么MySQL很可能是最优的选择(MySQL依赖于ACID模型——原子性、一致性、独立性和耐久性)。


  作为开源数据库,无论是关系型数据库还是非关系型数据库都在不断成熟,我们可以期待还会有一大批基于ACID和BASE模型的新应用产生。


  暂且把它称为混合方案。有时这些应用程序的设计需要认真地权衡利弊,有时还能意外的得到发展,做出一系列调整以适应不断变化的数据需求,毕竟,谁能预测到今天社会共享数据的大规模增加(即使是在五年前)?


  像往常一样,开发人员处于这种创新的最前沿,他们促使托管服务提供商将这两个数据领域结合到一起。在必要时候,他们还会对开源数据技术进行修正。


  比如,在Oracle占有了MySQL后,MySQL有闭源的风险,基于MySQL的MariaDB很好的替代了MySQL。开发者社区要求其开源工具完全透明,包括开放对测试用例bug修复的权限。


  此混合方案在2014年将继续发展,托管公司也会提供更好的支持。在媒体上,我们就不会再说“要么关系型数据库,要么非关系型数据库”这样的话了。


  这和混合云领域所用方法是类似的。专用硬件有着优越的性能,而公共云有很好的可扩展性,结合两者优点可以带来更大的灵活性,产生最合适的解决方案,这才是解决问题的最优办法。


  毕竟,数据收集和解释的最终目标是捕获这个瞬息万变世界发生的每一条信息。数据,无论来自何处,都只是一个窗口,真正重要的是透过这个窗口看到的景象。


原文链接: Open source data grows up: Choosing MySQL, NoSQL, or both

酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部