Google Spanner

想必看到此篇的同学对于newSQL已经不是很陌生了，那么直接进入今天的主题： mysql的问题在哪？ 一、不能通过mysql的server把InnoDB变成一个分布式数据库。 因为mysql生成的执行计划是个单机的 二、一个分布式的plan执行起来很复杂且低效。 比如使用分布式方案Proxy，因为它不支持分布式的transaction，也不支持跨节点的join 三、异步或半同步复制 因为有时候数据出问题你不知道是否应该切换节点，因为异步的方式会导致一部分数据“还在路上”。尤其是对于多数据中心的复制和数据中心的容灾。 而NewSQL真正发展起来是在2014年末到2015年初的时候，Raft论文发表之后，真正的NewSQL理论基础就基本确立了。 那么从技术实现的角度分析，为什么这样的技术会诞生呢？它又能解决哪些过去的产品解决不了或者不是最优方案的场景呢？ 首先，举一个范围查询的例子，如果要查找一个班级里成绩在80-90之间的学生，那么通过KV的API的要很麻烦的，但是SQL的优化器就很容易解决此类问题，写一句SQL就可以搞定。 其次是高可用，未来的系统肯定是要设计成Auto-Failover的，即自动恢复，需要人工去干预的容灾系统不是好厨子。 然后针对业务还要说几点： 比如按照ID去分库分表，比如使用一致性哈希去指导节点均衡。如果问题上升到了一定的复杂度

https://dbaplus.cn/news-160-1297-1.html 本文转自【 Qunar技术沙龙】， 经平台同意授权转载。 近期大家都在讨论Paxos算法，我看了很多网上的文章，总觉得有些晦涩难懂，经过一段时间研究，对Paxos有了一些理解，在这里总结一下，希望能抛砖引玉。 1、为什么需要Paxos Paxos要解决的问题，是分布式系统中的一致性问题。那么，到底什么是“分布式系统中的一致性问题”呢？在分布式系统中，为了保证数据的高可用，通常我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。副本要保持一致，那么所有副本的更新序列就要保持一致。因为数据的增删改查操作一般都存在多个客户端并发操作，到底哪个客户端先做，哪个客户端后做，更新顺序要保证。如果不是分布式，那么可以通过加锁的方法，谁先申请到锁谁就先操作，但这就存在单点问题。 Paxos协议主要有两种用法：一种用法是用来实现全局的锁服务或者命名和配置服务，例如Google Chubby以及Apache ZooKeeper。另外一种用法是用它来将用户数据复制到多个数据中心，例如Google Megastore以及Google Spanner。 以一个分布式的KV数据库为例，假设数据库对外提供2种操作Put和Get，具体架构如下： 在这样一个架构下

最近与同行科技交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库（分库分表）与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。 本文通过对两种模式关键特性实现原理对比，希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。 NewSQL数据库先进在哪儿？ 首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是"伪"分布式数据库？从架构先进性来看，这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。 NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：

日志就是按照时间顺序追加的、完全有序的记录序列，其实就是一种特殊的文件格式，文件是一个字节数组，而这里日志是一个记录数据，只是相对于文件来说，这里每条记录都是按照时间的相对顺序排列的，可以说日志是最简单的一种存储模型，读取一般都是从左到右，例如消息队列，一般是线性写入log文件，消费者顺序从offset开始读取。 日志在数据库中的应用 由于日志本身固有的特性，记录从左向右开始顺序插入，也就意味着左边的记录相较于右边的记录“更老”, 也就是说我们可以不用依赖于系统时钟，这个特性对于分布式系统来说相当重要。 日志是什么时候出现已经无从得知，可能是概念上来讲太简单。在数据库领域中日志更多的是用于在系统crash的时候同步数据以及索引等，例如MySQL中的redo log，redo log是一种基于磁盘的数据结构，用于在系统挂掉的时候保证数据的正确性、完整性，也叫预写日志，例如在一个事物的执行过程中，首先会写redo log，然后才会应用实际的更改，这样当系统crash后恢复时就能够根据redo log进行重放从而恢复数据(在初始化的过程中，这个时候不会还没有客户端的连接)。日志也可以用于数据库主从之间的同步，因为本质上，数据库所有的操作记录都已经写入到了日志中，我们只要将日志同步到slave，并在slave重放就能够实现主从同步，这里也可以实现很多其他需要的组件，我们可以通过订阅redo