数据库架构应用是需要大多数后端编程开发程序员掌握的一个核心编程技能,而今天我们就通过案例分析来了解一下,数据库服务在web应用开发中的作用。
数据库服务为上层Web应用提供关系式或结构化的数据存储与查询支持。取决于具体用例,Web应用可以使用数据库连接器之类的插件机制来提供对不同数据库服务的访问支持。在这种架构下,用户可以灵活地选择或变更适合企业现阶段情况的不同数据库产品。例如:用户可以在原型阶段使用SQLite之类的嵌入式引擎完成快速部署和功能验证;而在应用的初期阶段切换到廉价的MySql数据库解决方案;等到业务需求不断上升,数据库负载不断加重时再向Clustrix、MongoDB、Cassandra、MySqlCluster、ORACLE等更昂贵和复杂的解决方案进行迁移。
Memcached服务作为一个完全基于内存和分布式数据对象缓冲服务,拥有令人难以置信的查询效率以及一个优雅的,无需服务器间通信的大型分布式架构。对于高负载Web应用来说,Memcached常被用作一种重要的数据库访问加速服务,因此它不是一个必选组件。用户完全可以等到现实环境下的数据库服务出现了性能瓶颈时在部署它。
当然,我们也应该注意到:以memcached为代表的分布式缓存系统,其本质上是一种以牺牲一致性为代价来提升平均访问效率的妥协方案——缓存服务为数据库中的部分记录增加了分布式副本。对于同一数据的多个分布式副本来说,除非使用Paxos、Raft等一致性算法,不然无法实现强一致性保证。
矛盾的是,memorycache本身就是用来提升效率的,这使得为了它使用上述开销高昂的分布式强一致性算法变得非常不切实际:目前的分布式强一致性算法均要求每次访问请求(无论读写)都需要同时访问包括后台数据库主从节点在内的多数派副本——显然,这还不如干脆不使用缓存来的有效率。
另外,即使是Paxos、Raft之类的分布式一致性算法也只能在单个记录的级别上保证强一致。意即:即使应用了此类算法,也无法凭此提供事务级的强一致性保证。
除此之外,分布式缓存也增加了程序设计的复杂度(需要在访问数据库的同时尝试命中或更新缓存),并且还增加了较差情形下的访问延迟(如:未命中时的RTT等待延迟,以及节点下线、网络通信故障时的延迟等)。
与此同时,可以看到:从二十年前开始,各主流数据库产品其实均早已实现了成熟、高命中率的多层(磁盘块、数据页、结果集等)缓存机制。既然分布式缓存有如此多的缺陷,而数据库产品又自带了优秀的缓存机制,它为何又能够成为现代高负载WebApp中的重要基石呢
其根本原因在于:对于十年前的技术环境来说,当时十分缺乏横向扩展能力的RDBMS(SQL)系统已成为了严重制约WebApp等网络应用扩大规模的瓶颈。为此,以GoogleBigTable、FacebookCassandra、MongoDB为代表的NoSQL数据库产品,以及以memcached、redis为代表的分布式缓存产品纷纷粉墨登场,并各自扮演了重要作用。
与MySQL、ORACLE、DB2、MSSQLServer、PostgreSQL等当时的"传统"SQL数据库产品相比,无论NoSQL数据库还是分布式缓存产品,其本质上都是以牺牲前者的强一致性为代价,来换取更优的横向扩展能力。
应当看到,这种取舍是在当时技术条件下做出的无奈、痛苦的抉择,系统因此而变得复杂——在需要事务和强一致性保障,并且数据量较少的地方,使用无缓存层的传统RDBMS;在一致性方面有一定妥协余地,并且读多写少的地方尽量使用分布式缓存来加速;在对一致性要求更低的大数据上使用NoSQL;如果数据量较大,同时对一致性要求也较高,就只能尝试通过对RDMBS分库分表等方法来尽量解决,为此还要开发各种中间件来实现数据访问的请求分发和结果集聚合等复杂操作……各种情形不一而足,而它们的相互组合和交织则再次加剧了复杂性。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!