开源数据库Sharding技术

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

从Shard到Sharding

"Shard" 这个词英文的意思是"碎片",而作为数据库相关的技术用语,似乎最早见于大型多人在线角色扮演游戏(MMORPG)中。"Sharding" 姑且称之为"分片"。

Sharding 不是一门新技术,而是一个相对简朴的软件理念。如您所知,MySQL 5之后才有了数据表分区功能,那么在此之前,很多MySQL的潜在用户都对 MySQL 的扩展性有所顾虑,而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题,MySQL 的推广者经常会被问到:如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理,是如何办到的呢? 答案是:Sharding。

Sharding不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点数据库服务器的I/O能力限制,解决数据库扩展性问题。

事关数据库扩展性

说起数据库扩展性,这是个非常大的话题。目前的商业数据都有自己的扩展性解决方案,在过去相对来说比较成熟,但是随着互联网的高速发展,不可避免的会带来一些计算模式上的演变,这样很多主流商业系统也难免暴露出一些不足之处。比如 Oracle的RAC是采用共享存储机制,对于I/O密集型的应用,瓶颈很容易落在存储上,这样的机制决定后续扩容只能是Scale Up(向上扩展) 类型,对于硬件成本、开发人员的要求、维护成本都相对比较高。

Sharding基本上是针对开源数据库的扩展性解决方案,很少有听说商业数据库进行Sharding 的。目前业界的趋势基本上是拥抱Scale Out,逐渐从Scale Up中解放出来。

Sharding的应用场景

任何技术都是在合适的场合下能发挥应有的作用。 Sharding也一样。联机游戏、IM、BSP都是比较适合 Sharding 的应用场景。其共性是抽象出来的数据对象之间的关联数据很小。比如IM ,每个用户如果抽象成一个数据对象,完全可以独立存储在任何一个地方,数据对象是 Share Nothing 的;再比如 Blog 服务提供商的站点内容,基本为用户生成内容(UGC),完全可以把不同的用户隔离到不同的存储集合,而对用户来说是透明的。

这个"Share Nothing"是从数据库集群中借用的概念,举例来说,有些类型的数据粒度之间就不是"Share Nothing" 的,比如类似交易记录的历史表信息,如果一条记录中既包含卖家信息与买家信息,如果随着时间推移,买、卖家会分别与其它用户继续进行交易,这样不可避免的两个买卖家的信息会分布到不同的Sharding DB上,而这时如果针对买卖家查询,就会跨越更多的 Sharding,开销就会比较大。

Sharding并不是数据库扩展方案的银弹,也有其不适合的场景,比如处理事务型的应用就会非常复杂。对于跨不同DB的事务,很难保证完整性,得不偿失。所以,采用什么样的 Sharding 形式,不是生搬硬套的。

Sharding与数据库分区(Partition)的区别

有的时候,Sharding也被近似等同于水平分区(Horizontal Partitioning),网上很多地方也用 水平分区来指代Sharding,但我个人认为二者之间实际上还是有区别的。的确,Sharding 的思想是从分区的思想而来,但数据库分区基本上是数据对象级别的处理,比如表和索引的分区,每个子数据集上能够有不同的物理存储属性,还是单个数据库范围内的操作,而Sharding是能够跨数据库,甚至跨越物理机器的。(见对比表格)

Sharding策略

数据 Sharding 的策略与分区表的方式有很多类似的地方,有基于表、ID范围、数据产生的时间或是SOA 下理念下的基于服务等众多方式可选择。而与传统的表分区方式不同的是,Sharding 策略和业务结合的更为紧密,成功的Sharding必须对自己的业务足够熟悉,进行众多可行性分析的基础上进行,"业务逻辑驱动"。

Sharding实现案例分析:Digg 网站

作为风头正劲的 Web 2.0网站之一的Digg.com,虽然用户群庞大,但网站数据库数据并非海量,去年同期主数据大约只有30GB的样子,现在应该更大一些,但应该不会出现数量级上增长,数据库软件采用 MySQL 5.x。Digg.com的IO压力非常大,而且是读集中的应用(98%的IO是读请求)。因为提供的是新闻类服务,这类数据有其自身特点,最近时间段的数据往往是读压力最大的部分。

根据业务特点,Digg.com根据时间范围对主要的业务数据做Sharding,把不到10%的"热"数据有效隔离开来,同时对这部分数据用以更好的硬件,提供更好的用户体验。而另外90%的数据因用户很少访问,所以尽管访问速度稍慢一点,对用户来说,影响也很小。通过Sharding,Digg 达到了预期效果。

现有的Sharding软件简介

现在Sharding相关的软件实现其实不少,基于数据库层、DAO层、不同语言下也都不乏案例。限于篇幅,作一下简要的介绍。

MySQL Proxy + HSCALE

一套比较有潜力的方案。其中MySQL Proxy (http://forge.mysql.com/wiki/MySQL_Proxy) 是用Lua脚本实现的,介于客户端与服务器端之间,扮演Proxy的角色,提供查询分析、失败接管、查询过滤、调整等功能。目前的0.6版本还做不到读、写分离。HSCALE则是针对MySQL Proxy 插件,也是用Lua实现的,对Sharding过程简化了许多。需要指出的是,MySQL Proxy与HSCALE 各自会带来一定的开销,但这个开销与集中式数据处理方式单条查询的开销还是要小的。

Hibernate Shards

这是Google技术团队贡献的项目(http://www.hibernate.org/414.html),该项目是在对 Google财务系统数据Sharding过程中诞生的。因为是在框架层实现的,所以有其独特的特性:标准的Hibernate编程模型,会用Hibernate就能搞定,技术成本较低;相对弹性的Sharding策略以及支持虚拟Shard等。

Spock Proxy

这也是在实际需求中产生的一个开源项目。Spock(http://www.spock.com/)是一个人员查找的Web 2.0网站。通过对自己的单一DB进行有效 Sharding化 而产生了Spock Proxy(http://spockproxy.sourceforge.net/ ) 项目,Spock Proxy算得上MySQL Proxy的一个分支,提供基于范围的 Sharding 机制。Spock是基于Rails的,所以Spock Proxy也是基于Rails构建,关注RoR的朋友不应错过这个项目。

HiveDB

上面介绍了RoR的实现,HiveDB (http://www.hivedb.org/)则是基于Java的实现,另外,稍有不同的是,这个项目背后有商业公司支持。

PL/Proxy

前面几个都是针对MySQL的 Sharding 方案,PL/Proxy则是针对PostgreSQL的,设计思想类似 Teradata的Hash机制,数据存储对客户端是透明的,客户请求发送到PL/Proxy后,由这里分布式存储过程调用,统一分发。PL/Proxy的设计初衷就是在这一层充当"数据总线"的职责,所以,当数据吞吐量支撑不住的时候,只需要增加更多的PL/Proxy服务器即可。大名鼎鼎的 Skype 用的就是PL/Proxy的解决方案。

Pyshards

http://code.google.com/p/pyshards/wiki/Pyshards 这是个基于Python的解决方案。该工具的设计目标还有个Re-balancing在里面,这倒是个比较激进的想法。目前只支持MySQL数据库。

本文转自    geekwolf   51CTO博客,原文链接:http://blog.51cto.com/linuxgeek/997897


相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1天前
|
存储 SQL 人工智能
数据库技术:原理、实践与未来展望
一、引言 数据库技术是现代信息系统中的关键组成部分,它为我们提供了高效、可靠的数据存储、查询和管理手段
|
1天前
|
存储 SQL 人工智能
数据库技术:原理、应用与未来趋势
一、引言 数据库技术作为现代信息科技的重要组成部分,不仅为数据的存储、检索和管理提供了强大的支撑,还在推动数字化转型、大数据分析和人工智能等领域的发展中发挥着关键作用
|
1天前
|
SQL 存储 NoSQL
数据库技术:基石、创新与发展趋势
一、引言 在当今数字化时代,数据已成为企业的核心资产
|
1天前
|
SQL 存储 数据处理
数据库技术:核心原理、应用场景与未来趋势
一、引言 数据库技术作为现代信息科技的重要支柱,为企业和组织提供了稳定、高效的数据管理手段
|
1天前
|
存储 SQL 多模数据库
数据库技术:核心要素、行业应用及未来展望
一、引言 数据库技术是现代信息技术的重要组成部分,它承载着数据存储、管理、检索和分析的核心功能
|
1天前
|
存储 SQL NoSQL
数据库的奥秘与力量:揭秘数据库技术的核心与前沿
一、引言 在当今信息爆炸的时代,数据库技术作为数据存储、管理与分析的基石,其重要性不言而喻
|
2天前
|
存储 人工智能 关系型数据库
数据库的深度探索:技术演进、应用领域与未来趋势
一、引言 数据库,作为信息技术领域中的关键组件,不仅为数据的存储、检索和管理提供了强有力的支持,而且随着技术的不断发展,其功能和应用领域也在不断扩展
|
1天前
|
SQL 关系型数据库 MySQL
mysqldiff - Golang 针对 MySQL 数据库表结构的差异 SQL 工具
Golang 针对 MySQL 数据库表结构的差异 SQL 工具。https://github.com/camry/mysqldiff
30 7
|
3天前
|
SQL 关系型数据库 MySQL
Python 操作 MySQL 数据库
Python 操作 MySQL 数据库
|
4天前
|
DataWorks API 调度
DataWorks产品使用合集之在调度配置配置了节点的上游节点输出,没办法自动生成这个flow的依赖,该怎么操作
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。