NOSQL系统一般都会宣传一个特性,那就是性能好,然后为什么呢?关系型数据库发展了这么多年,各种优化工作已经做得很深了,NOSQL系统一般都是吸收关系型数据库的技术,然后,到底是什么因素束缚了关系型数据库的性能呢?我们从系统设计的角度看这个问题。
1, 索引支持。关系型数据库创立之初没有想到今天的互联网应用对可扩展性提出如此高的要求,因此,设计时主要考虑的是简化用户的工作,SQL语言的产生促成数据库接口的标准化,从而形成了Oracle这样的数据库公司并带动了上下游产业链的发展。关系型数据库在单机存储引擎支持索引,比如Mysql的Innodb存储引擎需要支持索引,而NOSQL系统的单机存储引擎是纯粹的,只需要支持基于主键的随机读取和范围查询。NOSQL系统在系统层面提供对索引的支持,比如有一个用户表,主键为user_id,每个用户有很多属性,包括用户名,照片ID(photo_id),照片URL,在NOSQL系统中如果需要对photo_id建立索引,可以维护一张分布式表,表的主键为<photo_id, user_id>形成的二元组。关系型数据库由于需要在单机存储引擎层面支持索引,大大降低了系统的可扩展性,使得单机存储引擎的设计变得很复杂。
2, 事务并发处理。关系型数据库有一整套的关于事务并发处理的理论,比如锁的粒度是表级,页级还是行级,多版本并发控制机制MVCC,事务的隔离级别,死锁检测,回滚,等等。然而,互联网应用大多数的特点都是多读少些,比如读和写的比例是10 : 1,并且很少有复杂事务需求,因此,一般可以采用更为简单的copy-on-write技术:单线程写,多线程读,写的时候执行copy-on-write,写不影响读服务。NOSQL系统这样的假设简化了系统的设计,减少了很多操作的overhead,提高了性能。
3, 动态还是静态的数据结构。关系型数据库的存储引擎总是一颗磁盘B+树,为了提高性能,可能需要有insert buffer聚合写,query cache缓存读,经常需要实现类似Linux page cache的缓存管理机制。数据库中的读和写是互相影响的,写操作也因为时不时需要将数据flush到磁盘而性能不高。简而言之,关系型数据库存储引擎的数据结构是通用的动态更新的B+树,然而,在NOSQL系统中,比如Bigtable中采用SSTable + MemTable的数据结构,数据先写入到内存的MemTable,达到一定大小或者超过一定时间才会dump到磁盘生成SSTable文件,SSTable是只读的。如果说关系型数据库存储引擎的数据结构是一颗动态的B+树,那么SSTable就是一个排好序的有序数组。很明显,实现一个有序数据比实现一个动态B+树且包含复杂的并发控制机制要简单高效地多。
4, Join操作。关系型数据库需要在存储引擎层面支持Join,而NOSQL系统一般根据应用来决定Join实现的方式。举个例子,有两张表:用户表和商品表,每个用户下可能有若干个商品,用户表的主键为<user_id, item_id>,用户和商品的关联属性存放在用户表中,商品表的主键为item_id,商品属性包括商品名,商品URL,等等。假设应用需要查询一个用户的所有商品并显示商品的详细信息,普通的做法是先从用户表查找指定用户的所有item_id,然后对每个item_id去商品表查询详细信息,即执行一次数据库Join操作,这必然带来了很多的磁盘随机读,并且由于Join带来的随机读的局部性不好,缓存的效果往往也是有限的。在NOSQL系统中,我们往往可以将用户表和商品表集成到一张宽表中,这样虽然冗余存储了商品的详细信息,却换来了查询的高效。
关系型数据库的性能瓶颈往往不在SQL语句解析上,而是在于需要支持完备的SQL特性。互联网公司面临的问题是应用对性能和可扩展性要求很高,并且DBA和开发工程师水平比较高,可以通过牺牲一些接口友好性来换取更好的性能。NOSQL系统的一些设计,比如通过宽表实现Join操作,互联网公司的DBA和开发工程师也做过,NOSQL系统只是加强了这种约束。从长远来看,可以总结一套约束集合,并且定义一个SQL子集,只需要支持这个SQL子集就可以在不牺牲可扩展性的前提下支持比如90%以上的互联网应用。我想,NOSQL技术发展到这一步的时候就算是比较成熟了,这也是我们最终想做的事情。我们在设计和使用NOSQL系统的时候也可以适当转化一下思维,如下:
1, 更大的数据量。很多人在使用Mysql的过程遇到记录条数超过一定值,比如2000W的时候,数据库性能开始下降,这个值的得出往往需要经过大量的测试。然而,大多数的NOSQL系统可扩展性都比较好,能够支持更大的数据量,因此也可以采用一些空间换时间的做法,比如通过宽表的方式实现Join。
2, 性能预估更加容易。关系型数据库由于复杂的并发控制,insert buffer及类似page cache的读写优化机制,性能估算相对较难,很多时候需要凭借经验或者经过测试才能得出系统的性能。然后,NOSQL系统由于存储引擎实现,并发控制机制等相对简单,可以通过硬件的性能指标在系统设计之处大致预估系统的性能,性能预估可操作性相对更强。
分享到:
相关推荐
- 从早期的桌面软件到云端服务的转变。 - **互联网开源社区和技术** - **GitHub**:最大的开源代码托管平台。 - **Apache**:流行的Web服务器软件。 - **Linux**:广泛使用的开源操作系统。 - **OpenSSL**:...
《奔跑吧程序员:从小白到CEO》这本书是为那些对编程和软件开发充满热情的新手设计的,旨在帮助他们从零开始,逐步建立起全面的IT技术基础,同时培养团队管理和领导力,最终实现从程序员到CEO的角色转变。...
教师的角色也将转变为引导者和辅导者,鼓励学生自主探索和团队合作,培养他们的创新思维和问题解决能力。 总结来说,大数据时代的数据库课程教学改革应围绕技术更新、专业差异和学生能力差异这三个关键点展开。通过...
数据服务提供SQL和NoSQL服务,支持分钟级配置,实现跨源Join和业务单元化部署,确保了数据的高可用性。数据管理则关注数据的协同、研发质量、安全性和追踪,确保数据的准确性和一致性。 在场景篇中,移动数据运营被...
除了基础的SQL语言、关系数据库理论外,还应引入NoSQL数据库、数据仓库、数据挖掘等前沿内容,使学生能够全面了解数据库领域的最新动态。 1.2 教学大纲与方法 教学大纲应突出实践性和应用性,明确理论与实践的比例...
这一转变不仅仅是技术上的升级,也涉及到思维方式的改变。企业需要从传统的批处理模式转向实时或近实时的数据处理,以实现更快的洞察。此外,数据治理和安全性也需要得到加强,以保护隐私和合规性。建议在实践中...
大数据技术体系包括Hadoop、流处理、MPP(大规模并行处理)、NoSQL数据库等,能够处理和分析大量结构化和非结构化数据。 其次,从思维方式上看,BI倾向于提供宏观的、基于群体共性的分析,帮助决策者了解整体趋势,...
此外,教师的角色也需要转变,从知识的传授者转变为引导者和辅导者,鼓励学生主动学习,培养他们的自主学习能力和团队协作精神。同时,加强与企业的合作,引入企业的真实项目,使课程内容与行业需求紧密相连。 总结...
1. **思维模式转变:**从传统的关系型数据库思维转向MongoDB需要一定的学习曲线。 2. **索引设计:**不当的索引设计可能导致性能问题。 3. **数据模型设计:**尽管MongoDB提供了灵活性,但在设计阶段仍需谨慎考虑...
总结来说,大数据不仅是技术的革新,也是思维方式的转变。它改变了我们对信息的理解和利用,推动了社会的信息化、智能化进程。随着技术的不断发展,大数据将继续在各行各业发挥关键作用,驱动创新和进步。
他们多数来自经济条件较好的家庭,可能缺乏明确的学习动力,但思维活跃,敢于表达,有一定的社会实践经验和较强的沟通能力。同时,部分学生可能存在学习自觉性和主动性不足的问题,以及心理承受能力较弱的情况。因此...
教师的角色应转变为引导者,鼓励学生自主学习,利用各种在线资源,并通过参与竞赛如“互联网+”创新创业大赛、软件设计大赛等,提升学生的综合素质和创新能力。竞赛的准备和反思环节有助于深化课堂学习,同时培养...
大数据的崛起标志着一个时代的转变,它不仅改变了我们获取信息的方式,还影响了我们的生活、工作和思维方式。 大数据技术基础主要涉及数据采集、存储、处理和分析。数据采集涵盖各种来源,如社交网络、传感器、文本...
2. **数据存取**:使用关系数据库(如MySQL)、NoSQL数据库(如MongoDB)和SQL查询语言,以支持不同类型的存储需求。 3. **基础架构**:采用分布式存储系统,如Hadoop的HDFS,以支持大规模数据的存储和处理。 4. *...
9. **大数据带来的思维方式转变**: - **全样而非抽样**:利用全部数据而非样本进行分析。 - **效率而非精确**:在追求效率的同时允许一定程度的误差。 - **相关而非因果**:寻找变量间的相关性而不是因果关系。 ...