① 国内做分布式数据库开发的现状如何
应该说,现在是国产分布式数据库发展的利好时期。在讨论发展前景前,首先要先看看分布式数据库的发展方向。
大家把传统关系型数据库称作oldsql,给人感觉要被淘汰似的。但其实数据量不是很大或者事务处理的场景夏,关系型数据库的还是占优的。
关系型数据库的主要问题在于:
性能瓶颈,
单一模型(关系模型),只适合OLTP
应对业务的灵活性不够,
弹性扩充能力不够,
两地三中心和双活等问题上不足。
随着互联网和手机的飞速发展,无论从用户规模、使用频率、还是场景多样性都使得这些问题浮出水面。其实Oracle在92年就开始尝试转向分布式,还当时引起了业界的巨大争论,最后失败。更何况过去CPU、内存、存储、带宽的高成本导致分布式数据库的性价比并不高,只能停留在学术阶段,限制了分布式的发展。
新分布式数据库首先是要避免和传统关系型数据库的竞争,这是明智的选择,能够轻装上阵。因此从几个方面入手,应对海量数据处理、分析、缓存、流式处理、开发模式等等。相对应列式,KV,Document等多种存储数据结构。
所有这些都被称为NoSQL数据库,放弃ACID和事务能力还换取性能。然而,NoSQL又收到了大量的批评反对意见,主要是说把数据库应该处理的问题交还给了开发是种发展的倒退。这些问题包括,索引、版本、SQL支持、事务支持等等。市场上超过90%的开发员都需要SQL,而且SQL也是非常有效和成熟。于是大家无论底层是什么存储结构又开始支持SQL,形成了NewSQL。
这里插一句题外话,在硅谷已经不再用SQL、NoSQL、NewSQL来划分数据库了。理由很简单,SQL是一种语言,从来没有SQL数据库的说法,自然也不应该有NoSQL数据库的说法。NewSQL数据库就更不合理,用的SQL并非什么“New“的新东西。所以专业上用关系型和非关系型数据库来划分,分布式数据库主要都是非关系型数据库。
回过头来看国内分布式数据库市场需求,中小企业不满足Mysql的性能,分库分表又很难搞,也不彻底;大型企业被Oracle等垄断支付高额成本,而且又不解决实际碰到的瓶颈问题。因此,用户都在寻找新的解决方案。小型用户、云计算的用户、大型企业都需要对应的分布式数据库产品。
再加上国产自主和去IOE浪潮,更加推动了国产分布式数据库的发展利好。值得注意的是,数据库研发是个严肃的事情,没法短平快。
② 现在国产数据库有哪些品牌
据我网上找的资料,目前国产数据库主要有3个1、南京大学通用newsql数据库——gbase2、达梦新1代云数据库——dm73、人大金仓分析型数据库kingbasees但个人观点,在国外多个知名商业化数据库oracle,sqlserver,db2等和开源的数据库如mysql,postgresql等眼前,这些基本没有甚么市场
③ 如何评价SequoiaDB巨杉数据库
equoiaDB巨杉数据库 是国内领先的新一代分布式数据库厂商。
主要产品SequoiaDB是国内唯一一款企业级的新一代分布式、标准化NewSQL数据库。作为商业化的数据库产品,现已开源。同时也提供了包括企业数据融合和再加工、非结构化数据管理平台、大数据管理平台在内的多个企业级大数据解决方案。
SequoiaDB巨杉数据库也于近期发布了SequoiaDB 2.0企业版,新版本加入了SQL2003支持、双引擎核心存储、双活机制等,在企业级功能上超越硅谷同类产品。作为Spark全球的发行商之一,巨杉在2.0时代将提供高并发实时计算、高吞吐量批处理分析、以及在线流处理计算等一系列企业级解决方案,SequoiaDB巨杉数据库平台可以帮助企业快速地进行跨系统的数据融和、提炼和再加工。
近期,在当前的资本寒冬之下,巨杉于近期获得了DCM领投的近亿元B轮融资。这体现了投资界对于这家务实的大数据基础软件公司发展的一致看好,而此次融资也成为国内新一代分布式数据库领域最大的一笔投融资。
④ 分库分表 VS newsql数据库
最近与同行 科技 交流,经常被问到分库分表与分布式数据库如何选择,网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章,但有些观点与判断是我觉得是偏激的,脱离环境去评价方案好坏其实有失公允。
本文通过对两种模式关键特性实现原理对比,希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。
首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题,国外有篇论文pavlo-newsql-sigmodrec,如果根据该文中的分类,Spanner、TiDB、OB算是第一种新架构型,Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种(文中还有第三种云数据库,本文暂不详细介绍)。
基于中间件(包括SDK和Proxy两种形式)+传统关系数据库(分库分表)模式是不是分布式架构?我觉得是的,因为存储确实也分布式了,也能实现横向扩展。但是不是"伪"分布式数据库?从架构先进性来看,这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等,这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战,本文中NewSQL数据库特指这种新架构NewSQL数据库。
NewSQL数据库相比中间件+分库分表的先进在哪儿?画一个简单的架构对比图:
这些大多也是NewSQL数据库产品主要宣传的点,不过这些看起来很美好的功能是否真的如此?接下来针对以上几点分别阐述下的我的理解。
这是把双刃剑。
CAP限制
想想更早些出现的NoSQL数据库为何不支持分布式事务(最新版的mongoDB等也开始支持了),是缺乏理论与实践支撑吗?并不是,原因是CAP定理依然是分布式数据库头上的颈箍咒,在保证强一致的同时必然会牺牲可用性A或分区容忍性P。为什么大部分NoSQL不提供分布式事务?
那么NewSQL数据库突破CAP定理限制了吗?并没有。NewSQL数据库的鼻主Google Spanner(目前绝大部分分布式数据库都是按照Spanner架构设计的)提供了一致性和大于5个9的可用性,宣称是一个“实际上是CA”的,其真正的含义是 系统处于 CA 状态的概率非常高,由于网络分区导致的服务停用的概率非常小 ,究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区,另外就是其高效的运维队伍,这也是cloud spanner的卖点。详细可见CAP提出者Eric Brewer写的《Spanner, TrueTime 和CAP理论》。
完备性 :
两阶段提交协议是否严格支持ACID,各种异常场景是不是都可以覆盖?
2PC在commit阶段发送异常,其实跟最大努力一阶段提交类似也会有部分可见问题,严格讲一段时间内并不能保证A原子性和C一致性(待故障恢复后recovery机制可以保证最终的A和C)。完备的分布式事务支持并不是一件简单的事情,需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常,通过严格的测试。之前跟某友商交流,他们甚至说目前已知的NewSQL在分布式事务支持上都是不完整的,他们都有案例跑不过,圈内人士这么笃定,也说明了 分布式事务的支持完整程度其实是层次不齐的。
但分布式事务又是这些NewSQL数据库的一个非常重要的底层机制,跨资源的DML、DDL等都依赖其实现,如果这块的性能、完备性打折扣,上层跨分片SQL执行的正确性会受到很大影响。
性能
传统关系数据库也支持分布式事务XA,但为何很少有高并发场景下用呢? 因为XA的基础两阶段提交协议存在网络开销大,阻塞时间长、死锁等问题,这也导致了其实际上很少大规模用在基于传统关系数据库的OLTP系统中。
NewSQL数据库的分布式事务实现也仍然多基于两阶段提交协议,例如google percolator分布式事务模型,
采用原子钟+MVCC+ Snapshot Isolation(SI),这种方式通过TSO(Timestamp Oracle)保证了全局一致性,通过MVCC避免了锁,另外通过primary lock和secondary lock将提交的一部分转为异步,相比XA确实提高了分布式事务的性能。
但不管如何优化,相比于1PC,2PC多出来的GID获取、网络开销、prepare日志持久化还是会带来很大的性能损失,尤其是跨节点的数量比较多时会更加显着,例如在银行场景做个批量扣款,一个文件可能上W个账户,这样的场景无论怎么做还是吞吐都不会很高。
虽然NewSQL分布式数据库产品都宣传完备支持分布式事务,但这并不是说应用可以完全不用关心数据拆分,这些数据库的最佳实践中仍然会写到,应用的大部分场景尽可能避免分布式事务。
既然强一致事务付出的性能代价太大,我们可以反思下是否真的需要这种强一致的分布式事务?尤其是在做微服务拆分后,很多系统也不太可能放在一个统一的数据库中。尝试将一致性要求弱化,便是柔性事务,放弃ACID(Atomicity,Consistency, Isolation, Durability),转投BASE(Basically Available,Soft state,Eventually consistent),例如Saga、TCC、可靠消息保证最终一致等模型,对于大规模高并发OLTP场景,我个人更建议使用柔性事务而非强一致的分布式事务。关于柔性事务,笔者之前也写过一个技术组件,最近几年也涌现出了一些新的模型与框架(例如阿里刚开源的Fescar),限于篇幅不再赘述,有空再单独写篇文章。
HA与异地多活
主从模式并不是最优的方式,就算是半同步复制,在极端情况下(半同步转异步)也存在丢数问题,目前业界公认更好的方案是基于paxos分布式一致性协议或者其它类paxos如raft方式,Google Spanner、TiDB、cockcoachDB、OB都采用了这种方式,基于Paxos协议的多副本存储,遵循过半写原则,支持自动选主,解决了数据的高可靠,缩短了failover时间,提高了可用性,特别是减少了运维的工作量,这种方案技术上已经很成熟,也是NewSQL数据库底层的标配。
当然这种方式其实也可以用在传统关系数据库,阿里、微信团队等也有将MySQL存储改造支持paxos多副本的,MySQL也推出了官方版MySQL Group Cluster,预计不远的未来主从模式可能就成为 历史 了。
需要注意的是很多NewSQL数据库厂商宣传基于paxos或raft协议可以实现【异地多活】,这个实际上是有前提的,那就是异地之间网络延迟不能太高 。以银行“两地三中心”为例,异地之间多相隔数千里,延时达到数十毫秒,如果要多活,那便需异地副本也参与数据库日志过半确认,这样高的延时几乎没有OLTP系统可以接受的。
数据库层面做异地多活是个美好的愿景,但距离导致的延时目前并没有好的方案。 之前跟蚂蚁团队交流,蚂蚁异地多活的方案是在应用层通过MQ同步双写交易信息,异地DC将交易信息保存在分布式缓存中,一旦发生异地切换,数据库同步中间件会告之数据延迟时间,应用从缓存中读取交易信息,将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理,等数据同步追上之后再将这些业务对象从黑名单中剔除。由于双写的不是所有数据库操作日志而只是交易信息,数据延迟只影响一段时间内数据,这是目前我觉得比较靠谱的异地度多活方案。
另外有些系统进行了单元化改造,这在paxos选主时也要结合考虑进去,这也是目前很多NewSQL数据库欠缺的功能。
Scale横向扩展与分片机制
paxos算法解决了高可用、高可靠问题,并没有解决Scale横向扩展的问题,所以分片是必须支持的。NewSQL数据库都是天生内置分片机制的,而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点,然后进行分片的分裂、数据迁移、合并,这些过程应用是无感知的,这省去了DBA的很多运维工作量。以TiDB为例,它将数据切成region,如果region到64M时,数据自动进行迁移。
分库分表模式下需要应用设计之初就要明确各表的拆分键、拆分方式(range、取模、一致性哈希或者自定义路由表)、路由规则、拆分库表数量、扩容方式等。相比NewSQL数据库,这种模式给应用带来了很大侵入和复杂度,这对大多数系统来说也是一大挑战。
这里有个问题是NewSQL数据库统一的内置分片策略(例如tidb基于range)可能并不是最高效的,因为与领域模型中的划分要素并不一致,这导致的后果是很多交易会产生分布式事务。 举个例子,银行核心业务系统是以客户为维度,也就是说客户表、该客户的账户表、流水表在绝大部分场景下是一起写的,但如果按照各表主键range进行分片,这个交易并不能在一个分片上完成,这在高频OLTP系统中会带来性能问题。
分布式SQL支持
常见的单分片SQL,这两者都能很好支持。NewSQL数据库由于定位与目标是一个通用的数据库,所以支持的SQL会更完整,包括跨分片的join、聚合等复杂SQL。中间件模式多面向应用需求设计,不过大部分也支持带拆分键SQL、库表遍历、单库join、聚合、排序、分页等。但对跨库的join以及聚合支持就不够了。
NewSQL数据库一般并不支持存储过程、视图、外键等功能,而中间件模式底层就是传统关系数据库,这些功能如果只是涉及单库是比较容易支持的。
NewSQL数据库往往选择兼容MySQL或者PostgreSQL协议,所以SQL支持仅局限于这两种,中间件例如驱动模式往往只需做简单的SQL解析、计算路由、SQL重写,所以可以支持更多种类的数据库SQL。
SQL支持的差异主要在于分布式SQL执行计划生成器,由于NewSQL数据库具有底层数据的分布、统计信息,因此可以做CBO,生成的执行计划效率更高,而中间件模式下没有这些信息,往往只能基于规则RBO(Rule-Based-Opimization),这也是为什么中间件模式一般并不支持跨库join,因为实现了效率也往往并不高,还不如交给应用去做。
存储引擎
传统关系数据库的存储引擎设计都是面向磁盘的,大多都基于B+树。B+树通过降低树的高度减少随机读、进而减少磁盘寻道次数,提高读的性能,但大量的随机写会导致树的分裂,从而带来随机写,导致写性能下降。NewSQL的底层存储引擎则多采用LSM,相比B+树LSM将对磁盘的随机写变成顺序写,大大提高了写的性能。不过LSM的的读由于需要合并数据性能比B+树差,一般来说LSM更适合应在写大于读的场景。当然这只是单纯数据结构角度的对比,在数据库实际实现时还会通过SSD、缓冲、bloom filter等方式优化读写性能,所以读性能基本不会下降太多。NewSQL数据由于多副本、分布式事务等开销,相比单机关系数据库SQL的响应时间并不占优,但由于集群的弹性扩展,整体QPS提升还是很明显的,这也是NewSQL数据库厂商说分布式数据库更看重的是吞吐,而不是单笔SQL响应时间的原因。
成熟度与生态
分布式数据库是个新型通用底层软件,准确的衡量与评价需要一个多维度的测试模型,需包括发展现状、使用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA人才、SQL兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别、在线DDL等等,虽然NewSQL数据库发展经过了一定时间检验,但多集中在互联网以及传统企业非核心交易系统中,目前还处于快速迭代、规模使用不断优化完善的阶段。
相比而言,传统关系数据库则经过了多年的发展,通过完整的评测,在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势,同时对已建系统的兼容性也更好。
对于互联网公司,数据量的增长压力以及追求新技术的基因会更倾向于尝试NewSQL数据库,不用再考虑库表拆分、应用改造、扩容、事务一致性等问题怎么看都是非常吸引人的方案。
对于传统企业例如银行这种风险意识较高的行业来说,NewSQL数据库则可能在未来一段时间内仍处于 探索 、审慎试点的阶段。基于中间件+分库分表模式架构简单,技术门槛更低,虽然没有NewSQL数据库功能全面,但大部分场景最核心的诉求也就是拆分后SQL的正确路由,而此功能中间件模式应对还是绰绰有余的,可以说在大多数OLTP场景是够用的。
限于篇幅,其它特性例如在线DDL、数据迁移、运维工具等特性就不在本文展开对比。
总结
如果看完以上内容,您还不知道选哪种模式,那么结合以下几个问题,先思考下NewSQL数据库解决的点对于自身是不是真正的痛点:
如果以上有2到3个是肯定的,那么你可以考虑用NewSQL数据库了,虽然前期可能需要一定的学习成本,但它是数据库的发展方向,未来收益也会更高,尤其是互联网行业,随着数据量的突飞猛进,分库分表带来的痛苦会与日俱增。当然选择NewSQL数据库你也要做好承担一定风险的准备。
如果你还未做出抉择,不妨再想想下面几个问题:
如果这些问题有多数是肯定的,那还是分库分表吧。在软件领域很少有完美的解决方案,NewSQL数据库也不是数据分布式架构的银弹。相比而言分库分表是一个代价更低、风险更小的方案,它最大程度复用传统关系数据库生态,通过中间件也可以满足分库分表后的绝大多数功能,定制化能力更强。 在当前NewSQL数据库还未完全成熟的阶段,分库分表可以说是一个上限低但下限高的方案,尤其传统行业的核心系统,如果你仍然打算把数据库当做一个黑盒产品来用,踏踏实实用好分库分表会被认为是个稳妥的选择。
很多时候软件选型取决于领域特征以及架构师风格,限于笔者知识与所属行业特点所限,以上仅为个人粗浅的一些观点,欢迎讨论。
⑤ newsql和nosql的区别和联系
TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库,结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL,支持无限的水平扩展,具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。
TiDB 具备如下特性:
高度兼容 MySQL
大多数情况下,无需修改代码即可从 MySQL 轻松迁移至 TiDB,分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
水平弹性扩展
通过简单地增加新节点即可实现 TiDB 的水平扩展,按需扩展吞吐或存储,轻松应对高并发、海量数据场景。
分布式事务
TiDB 100% 支持标准的 ACID 事务。
真正金融级高可用
相比于传统主从 (M-S) 复制方案,基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证,且在不丢失大多数副本的前提下,可以实现故障的自动恢复 (auto-failover),无需人工介入。
一站式 HTAP 解决方案
TiDB 作为典型的 OLTP 行存数据库,同时兼具强大的 OLAP 性能,配合 TiSpark,可提供一站式 HTAP 解决方案,一份存储同时处理 OLTP & OLAP,无需传统繁琐的 ETL 过程。
云原生 SQL 数据库
TiDB 是为云而设计的数据库,支持公有云、私有云和混合云,配合TiDB Operator 项目可实现自动化运维,使部署、配置和维护变得十分简单。
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景,更复杂的 OLAP 分析可以通过TiSpark 项目来完成。
TiDB 对业务没有任何侵入性,能优雅地替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题,专注于业务开发,极大地提升研发的生产力。
⑥ 如何评价SequoiaDB巨杉数据库
equoiaDB巨杉数据库 是国内领先的新一代分布式数据库厂商。
主要产品SequoiaDB是国内唯一一款企业级的新一代分布式、标准化NewSQL数据库。作为商业化的数据库产品,现已开源。同时也提供了包括企业数据融合和再加工、非结构化数据管理平台、大数据管理平台在内的多个企业级大数据解决方案。
SequoiaDB巨杉数据库也于近期发布了SequoiaDB 2.0企业版,新版本加入了SQL2003支持、双引擎核心存储、双活机制等,在企业级功能上超越硅谷同类产品。作为Spark全球的发行商之一,巨杉在2.0时代将提供高并发实时计算、高吞吐量批处理分析、以及在线流处理计算等一系列企业级解决方案,SequoiaDB巨杉数据库平台可以帮助企业快速地进行跨系统的数据融和、提炼和再加工。
近期,在当前的资本寒冬之下,巨杉于近期获得了DCM领投的近亿元B轮融资。这体现了投资界对于这家务实的大数据基础软件公司发展的一致看好,而此次融资也成为国内新一代分布式数据库领域最大的一笔投融资。
⑦ NewSQL为何使传统关系数据库黯然失色
传统数据库仍旧会有一席之地,至于NewSQL的优势又是什么,简单和大家说说:
首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题,国外有篇论文pavlo-newsql-sigmodrec,如果根据该文中的分类,Spanner、TiDB、OB算是第一种新架构型,Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种(文中还有第三种云数据库,本文暂不详细介绍)。
基于中间件(包括SDK和Proxy两种形式)+传统关系数据库(分库分表)模式是不是分布式架构?我觉得是的,因为存储确实也分布式了,也能实现横向扩展。但是不是“伪”分布式数据库?从架构先进性来看,这么说也有一定道理。
“伪”主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等,这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战,本文中NewSQL数据库特指这种新架构NewSQL数据库。
NewSQL数据库相比中间件+分库分表的先进在哪儿?画一个简单的架构对比图:
- 传统数据库面向磁盘设计,基于内存的存储管理及并发控制,不如NewSQL数据库那般高效利用;
- 中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作,效率相比较低;
- NewSQL数据库的分布式事务相比于XA进行了优化,性能更高;
- 新架构NewSQL数据库存储设计即为基于paxos(或Raft)协议的多副本,相比于传统数据库主从模式(半同步转异步后也存在丢数问题),在实现了真正的高可用、高可靠(RTO<30s,RPO=0);
- NewSQL数据库天生支持数据分片,数据的迁移、扩容都是自动化的,大大减轻了DBA的工作,同时对应用透明,无需在SQL指定分库分表键。
⑧ 数据库为什么要分库分表
1 基本思想之什么是分库分表?
从字面上简单理解,就是把原本存储于一个库的数据分块存储到多个库上,把原本存储于一个表的数据分块存储到多个表上。
2 基本思想之为什么要分库分表?
数
据库中的数据量不一定是可控的,在未进行分库分表的情况下,随着时间和业务的发展,库中的表会越来越多,表中的数据量也会越来越大,相应地,数据操作,增
删改查的开销也会越来越大;另外,由于无法进行分布式式部署,而一台服务器的资源(CPU、磁盘、内存、IO等)是有限的,最终数据库所能承载的数据量、
数据处理能力都将遭遇瓶颈。
3 分库分表的实施策略。
分库分表有垂直切分和水平切分两种。
3.1
何谓垂直切分,即将表按照功能模块、关系密切程度划分出来,部署到不同的库上。例如,我们会建立定义数据库workDB、商品数据库payDB、用户数据
库userDB、日志数据库logDB等,分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
3.2
何谓水平切分,当一个表中的数据量过大时,我们可以把该表的数据按照某种规则,例如userID散列,进行划分,然后存储到多个结构相同的表,和不同的库
上。例如,我们的userDB中的用户数据表中,每一个表的数据量都很大,就可以把userDB切分为结构相同的多个userDB:part0DB、
part1DB等,再将userDB上的用户数据表userTable,切分为很多userTable:userTable0、userTable1等,
然后将这些表按照一定的规则存储到多个userDB上。
3.3 应该使用哪一种方式来实施数据库分库分表,这要看数据库中数据量的瓶颈所在,并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据,并且项目的各项业务逻辑划分清晰、低耦合,那么规则简单明了、容易实施的垂直切分必是首选。
而
如果数据库中的表并不多,但单表的数据量很大、或数据热度很高,这种情况之下就应该选择水平切分,水平切分比垂直切分要复杂一些,它将原本逻辑上属于一体
的数据进行了物理分割,除了在分割时要对分割的粒度做好评估,考虑数据平均和负载平均,后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中,往往是这两种情况兼而有之,这就需要做出权衡,甚至既需要垂直切分,又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分,我们首先对数据库进行垂直切分,然后,再针对一部分表,通常是用户数据表,进行水平切分。
4 分库分表存在的问题。
4.1 事务问题。
在执行分库分表之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。
4.2 跨库跨表的join问题。
在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上,这时,表的关联操作将受到限制,我们无法join位于不同分库的表,也无法join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完成。
4.3 额外的数据管理负担和数据运算压力。
额
外的数据管理负担,最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算,例如,对于
一个记录用户成绩的用户数据表userTable,业务要求查出成绩最好的100位,在进行分表之前,只需一个order
by语句就可以搞定,但是在进行分表之后,将需要n个order
by语句,分别查出每一个分表的前100名用户数据,然后再对这些数据进行合并计算,才能得出结果。
⑨ 什么是数据库啊
数据库是一种存储技术。最简单和通俗地理解就是,我们把需要存储的内容做成一张张二维表格,数据库负责把这些表存放到计算机的磁盘上,并提供增、删、改、查询等各种手段来维护和管理这它们。最传统的关系型数据库就是这样的。数据量小的一台计算机就可以搞定,当数据量越来越大,就需要专用的存储介质(比如存储阵列)来放,到后来要读和写的人越来越多,就需要多台计算机搭配存储阵列一起来工作,其中一台负责写,多台读。数据量再大就需要分布式架构,多台读、多台写。现在在关系型数据库之外,还有NoSQL、NewSQL等数据库出来,它们提供更自由的保存数据的方式,能储存更多数据。
⑩ 关于NewSQL数据库对于CAP的再解释
作者 石默研
关于CAP的讨论已经很多,包括作者的另一篇文章“对CAP的初步解释”,基本已经即定思维的理解就是:分布式系统必须遵循CAP,一个分布式系统的设计只能同时满足其中两个,不可能同时满足;传统关系数据库选择A与C,代表了互联网新兴技术的NoSQL数据库则选择A与P(或者C与P,虽然这种情况其实需要详细讨论)。
但是,近年来,新兴的NewSQL数据库(TiDB或者OceanBase),则是一种在分布式环境下,保证的ACID强事务特征的强一致性数据库,并且很显然,它同时也满足了高可用性与优秀的分区可容忍性(很好的可扩展特性便是其一个层面的证明),似乎看起来,C、A、P都同时保证了,这不是违反了已经经过严格证明的CAP理论吗?
这个问题初看起来,似乎是比较神奇,但仔细分析,其实答案是很明显的。
首先,需要读者区分“分布式”与CAP中所提到的分区可容忍性Paritition Tolerance并不是一回事。分区可容忍性P是指以下两种分布式的情况:
. 同一份数据的多个副本的可分布性
. 有相互关联的数据的可分布性(操作中表现为保证ACID的强分布式事务)
即使是分库分表,如果不存在以上两种情况,只是独立数据在同一个节点上的情况,虽然也是分布式,但跟CAP中的P没有半毛钱关系。
那么,还是回到上面的问题,NewSQL数据库,确实也是在保证了同一份数据多副本的强读写一致性、以及强分布式事务特性这样的C的情况下,同时保证了A与P呀!事实确实如此,但这还是要仔细分析:
无论是TiDB,还是OceanBase,其在保证数据多副本的强一致性时,都采用了Paxos协议或者Raft,它们简单来讲就是多数选举的原则,即写不需要全部副本都完成,就能保证读的强一致性,反过来也是一样。因此,其在分布式情况下,保证数据读写强一致性的效率还是很高的,就是说,在同一个数据中心的网络环境下,虽然这种分布可容忍性的满足理论上讲也会比单节点多一点点效率损失,但实际上是可以忽略不计的。但需要指出的是,在跨数据中心、跨城市的分布式情况下,如果要保证数据多副本的强一致性,即保证分区可容忍性,对效率(实际上是可用性A)的影响那还是不可忽略的。因此,在这种情况下,CAP理论依然成立。
再来看相互关联数据的可分布性,这就涉及到了分布式事务。现有的NewSQL数据库,即使在同一数据中心,为了保证强的分布式事务,对效率的折衷都是不可忽略的,所谓的乐观事务,只是因为客观问题本身冲突就少,并不改变冲突很多时效率明显受影响的现实。因此,NewSQL数据库虽然提供强分布式事务的能力,但在现实应用中,都是提倡尽量避免大量的分布式事务出现。如果你所遇到的应用场景是确实需要大量的分布式事务执行,又不做应用优化全交给数据库执行,那么,现有的NewSQL分布式数据库,依然会遇到明显的性能问题,其实就是可用性A降低了。同学仔细去研究应用中的实际情况就会发现,很多互联网应用,当其所需要的QPS很高很高,而对读写一致性与强分布式事务的要求又不那很高时候,其实,NewSQL数据库还是不能满足他们的需求的,他们仍然需要根据自己的情况改造或者选用NoSQL数据库,这也是CAP理论并没有被NewSQL打破的现实证明。
因此,总结来讲,NewSQL数据库,也是遵循CAP理论的,只不过,在同中心数据多副本情况下,保证P的同时对A的影响微乎其微;而在分布式事务的情况下,又采用了与应用特性相关的策略(其实乐观、悲观事务本质上就有根本应用特性区分的意思)来保证性能而已。当然,随着网络与计算机性能的提高,CAP三个特征中,保证其中两个,折衷另外一个,所带来的影响也会逐渐变小,但其理论依然是正确的。