在2005、2006年期间，谷歌内部大规模使用了 MySQL 数据库。其中Google Adwords （谷歌广告部门）使用了 90 多个 MySQL Shards（分片）集群方案存储数据，是谷歌内部使用 MySQL 数据库的最大的部门之一。由于系统维护的原因，谷歌广告部门重新规划了 MySQL 集群，整个过程花了 2 年时间。因为谷歌知道它们的数据增长的非常快，再使用 MySQL 这类数据库到未来的某个时刻会非常痛苦。这就是 Spanner 的诞生原因。
Cloud Spanner是Google Megastore系统的继承者，Spanner表现出远超前辈的能力。Spanner首次是在Google内部数据中心中出现，而在2017年才对外发布测试版并加入了SQL能力。如今已经在Google云平台上架并拥有大量各个行业的用户。Cloud Spanner数据库是全球范围分布式的关系型/事务数据库，并且Google承诺Cloud Spanner拥有高吞吐量、低延迟和99.999%的高可用性。 接触Cloud Spanner 第一次接触到Google Cloud Sp
Spanner 之前是一个键值数据库，与现在谈论的 Spanner 是完全不同的东西。在设计之初，Spanner 就支持事务、外部一致性和透明的故障转移。到后面，Spanner 开始支持带类型的数据库表结构和其它的一些关系型数据库功能，以及支持了 SQL 功能。而现在我们正在努力改进 SQL 语法的兼容性和关系型数据库功能。
Google Spanner简介 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，
Spanner是一个全球分布式的数据库，从数据模型来看Spanner很像BigTable，都是类似于key对应着一行数据，但是却并不一样，Spanner中衍生出了“目录”的概念（把两张表合并存储）。这并不是重点，Spanner的重是它是第一个在全球范围内传递数据且保证外部一致的分布式事务的系统，且支持几种特定的事务，这显然是一个很困难的问题，我们会在文章中加以描述，这篇文章主要对Spanner的事务以及实现事务所使用的 TrueTime API 进行分析，这些也是论文中描述最为详尽，也是比较不好懂的地方。还有之所以不分析Spanner的架构是因为我觉得论文（第二节）中此方面的描述实在是有些简略，所以直接看论文就可以。
The Google File System (2003) MapReduce: Simplified Data Processing on Large Clusters (2004) Bigtable: A Distributed Storage System for Structured Data (2006)
作为一个在虐狗节还奋笔疾书的公众号写手来说，最重要的是各位汪们不是汪的读者们的打赏。这篇文章就看大家怎么想啦。 今天不但是虐狗节还是世界癫痫日，还有，更大的新闻是Google宣布Spanner作为一个公有云的服务正式开始提供了。所谓几家欢喜几家愁，这永远都是真理。 我想Spanner大名鼎鼎，大家都知道，但是作为服务了狗狗家10余年的MegaStore，因为其出身不够正统，听说过的人就很有限了吧。很多时候我一直在想，到底是个人成就了公司还是公司成就了个人。每次看到Jeff Dean我就会觉得我和他比智商不
点击上方蓝字每天学习数据库 作者简介：李海翔，网名“那海蓝蓝”，腾讯金融云数据库技术专家。中国人民大学信息学院工程硕士企业导师。著有《数据库事务处理的艺术：事务管理和并发访问控制》、《数据库查询优化器的艺术：原理解析与SQL性能优化》、《大数据管理》，广受好评。 ---- Spanner支持事务的四个特性ACID，2012年的《Spanner: Google’s Globally-Distributed Database》论文，并没有明确描述ACID分别是怎么实现的，只是描述了C特性实现的一些内容，而D
有2年没有摸数据库了，重新学习下。数据库是IT系统的基石，小到一个个人站点，大到类似Google，阿里，腾讯这种大公司，里面都运行着各种各样的数据库，成千上万的人才还在继续开发和维护数据库。 数据库大牛stone breaker前两年还拿到了图领奖，了不起的成就。数据库理论这些年没啥大的突破，还是70年代提出来的关系模型，ACID等等。不过不表示数据库的发展停下来了，尤其是随着需要处理的数据和业务越来越大，数据库规模，性能越来越强。数据库的发展主要体现在工程能力，新硬件的使用上。 我个人理解就当前而言，技术
之前看过 《大规模分布式存储系统：原理解析与架构实战》 ，这个系统设计还是挺有意思的，里面提及了Google的一整套系统都有论文，而且现在已经进化到下一代支持分布式跨行事务的关系型数据库系统了。所以一直很想抽时间看看Google的那套去中心化并且可以平行扩容的分布式系统和数据库的论文。之前一些计划中的我自己的项目的优化项都差不多完成了，这段时间就陆陆续续的看完了这三篇Paper，可怜我的渣渣英语，所以看得比较慢。
本文视频地址（点击下方原文链接）：https://www.zhihu.com/zvideo/1543712850048430081
Spanner是Bigtable的魔改版，下面这张谷歌云的PPT几乎和intro一一对应。
关于昨天 Spanner 的文字，有人问 NewSQL 为什么会起名为 New，Spanner 的应用场景又是怎样的？那么这篇就顺着大数据的历史继续聊。
在分布式数据库领域中，高性能＋强一致性事务是代表数据库水平高低的重要象征，这个领域的代表数据库是Google Cloud Spanner和Azure Cosmos DB以及Apple开源的FoundationDB，YugaByte DB是这个领域的另外一个开源数据库。以下为 YugaByte DB关于开发分布式SQL数据库技术挑战的分享。
Tedis（https://github.com/eleme/tedis）是基于开源 TiKV 的兼容 Redis 协议的强一致性的 NoSQL 数据库开源项目。 本文介绍一下 Tedis 开源项目的架构设计和特性，以及架构背后的一些思考（包括为何选择 TiKV 和 Redis 协议）。
Tedis（https://github.com/eleme/tedis） 是基于开源 TiKV 的兼容 Redis 协议的强一致性的 NoSQL 数据库开源项目。 本文介绍一下 Tedis 开源项目的架构设计和特性，以及架构背后的一些思考（包括为何选择 TiKV 和 Redis 协议）。
最近因为工作需要对VLDB的一些论文进行了阅读。其中包括谷歌新发表的F1数据库的分析。解读谷歌论文一直都是不太容易的。因为谷歌向来都是说一半藏一半。这篇论文相对来说还是写的比较开放的，还是不能免俗。
ORACLE数据库既能跑OLTP业务，也能跑OLAP业务，能力是商业数据库中数一数二的。支持IBM小机和x86 PC服务器，支持多种OS。同时有多种数据库架构方案供选择，成本收益风险也各不相同。
第一次知道数据库，是在大学时的数据库课程，那个时候的数据库特指关系型数据库。到后面工作后，才知道除了MySQL，Oralce这类关系数据库之外，还有NoSQL。 印象中，当时NoSQL由于优秀的性能和扩展性，发展迅速。但技术并非一成不变，二者可以相互借鉴。 待NoSQL潮水褪去，NewSQL出现，就像是是NoSQL和SQL在易用性和可扩展性上的平衡。
python3 内置的enum 模块可以支持枚举类型，此模块定义了四个枚举类，用来定义名称与值的唯一组合: Enum、IntEnum、Flag 和 IntFlag。此外，还定义了一个装饰器unique()， 和一个辅助类auto。 枚举是由 class 句法创建的，这种方式易读、易写。
1 什么是时间？ 2 物理时间：墙上时钟 3 逻辑时钟：为事件定序 4 Turetime：物理时钟回归 5 区块链：重新定义时间 6 其他影响 6.1 NTP的时间同步 6.2 有限时间内的不可能性 6.3 延迟 6.4 租约 7 总结 8 参考文献
8.1 Collaboration and conflict resolution
分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。余军讲师为你讲解分布式数据库在金融行业的创新实践。 余军 PingCAP 高级技术总监，金融行业首席架构师；开源软件的忠实爱好者，负责金融行业基于 TiDB 产品的解决方案、产品架构咨询和建设规划。主要工作经历：富麦信息科技有限公司 CTO ，中
响应式编程已经在 Java 编程领域出现很长一段时间了。具有高性能，事件驱动，充分利用计算资源，更加优雅的异步编程体验，同时它也提供了背压机制来防止系统过载。很长一段时间 Java 的响应式只能同 MongoDB、Redis 等这些非关系型数据库进行交互。而目前我们大部分的数据还是存放在关系型数据库中，大部分情况下 Java 使用 JDBC 来操作关系型数据库，而 JDBC 是阻塞的、同步的。所以迫切需要一种支持响应式的数据库驱动协议。目前市面上有两种响应式数据库驱动协议，我们来了解一下它们。
这篇文章着重点不在于科普，毕竟关于CAP、BASE的理论的文章，网上很多。所以本文科普篇幅尽量小（只包含概念描述）。主要从几个侧面的问题来描述CAP，进而描述ACID、BASE理念。然后加入一点点调料，如何动态的切换一致性强度。
数字化时代下，企业的发展与数据库的建设息息相关。如果搭建云下数据库，不仅要通过大量的运维投入保证数据库稳定运行，随着企业规模与数据量的发展，还要应对数据库扩容、弹性、运维、备份等各种各样的问题，云下数据库对企业提出的要求日益增长。此时有两种应对之法，一是凭借扩充技术团队解决问题，但这无疑将会带来不菲的运维与人员成本，二则是把一切交给云服务。
作者：李海翔，腾讯TDSQL专家工程师 “在分布式背景下，怎么实现双一致性（事务一致性、分布式一致性），并提高分布式事务型集群的处理效率？”腾讯TDSQL数据库长期致力于基础研究创新，并持续获得关键技术突破。 2020年12月21日，第11届DTCC（中国数据库技术大会）大会上，腾讯TDSQL数据库专家工程师李海翔分享了数据库领域的核心技术——分布式事务处理技术的核心——多级一致性技术。该技术在遵循了ACID特性的同时，使得事务处理技术符合CAP原理，并在理论层面相较“严格可串行化”技术做了扩展，进一
目前主流的数据库或者NoSQL要么在CAP里面选择AP，比较典型的例子是Cassandra，要么选择CP比如HBase，这两个是目前用得非常多的NoSQL的实现。我们的价值观一定认为未来是分布式的，一定是尽量倾向于全部都拥有，大部分情况下取舍都是HA，主流的比较顶级的数据库都会选择C，分布式系统一定逃不过P，所以A就只能选择HA。现在主要领域是数据库的开发，完全分布式，主要方向和谷歌的F1方向非常类似。 目前看NewSQL代表未来(Google Spanner、F1、FoundationDB)，HBase在
从这张图可以看出，随着集群的增加，延迟增长到一定程度后趋稳，带宽速度在缓慢下载，容量在理所应当的增加。
“Now.” 从我写这个单词到你读到它，时间已经过去了至少几个星期，这种延迟我们认为是理所当然的，甚至在我们读到任何文章的时候都不会想到这个问题。 “Now.” 如果我们在同一个房间内，我大声这么说，你可能会有更强的直观性。你可能会直觉的觉得，就像我在说这个词的同时你就听到了一样。这种直觉是错误的，如果你不相信你的直觉，而是思考声音的物理原理，你就会知道从我说话到你的听觉之间一定经过了一段时间。空气的传播，带着我的话，会花费时间从我的嘴传递到你的耳朵。 “Now.” 即使我举起一个写着哪个字的牌子，我们都看着它，我们对哪个形象的感觉也不会同时发生，因为携带着这个牌子信息的光传到我们每个不同的人需要不同的时间。 虽然计算机的某些特性是虚拟的，但是他们仍然碧玺在现实世界中运行，不能忽视现实世界的挑战。海军少将Grace Hopper （我们这一领域最重要的先驱之一，他的成就包括创造了第一个编译器）用给每个学生一根11.8英寸长的电线来说明这一点，则是电在1 ns内可以传输的最大距离。这种信息，时间和距离之间的关系的物理表征可以作为一种工具来解释为什么信号（就像我们上面的比喻符号）必须总是而且不可避免地要花费时间才能到达目的地。考虑到这些延迟，很难解释“now”在计算机系统中的确切含义。 不过，如果我们提前详细计划，理论上没有什么能组织我们对“now”达成共识。（相对论在这里不是问题，尽管它很容易让人分心。人类目前所有的计算系统都有一个足够严谨的参照系，使得人们对于时间的感知存在着非物质的相对论性差异。）NTP协议用于在互联网上同步系统之间的时钟，部分工作原理是计算信息在主机之间传输的时间。一旦知道了这个传输时间，主机就可以根据这个时间来调整时钟，以匹配更权威的消息来源。通过在网络中提供一些非常精确的源，基于连续测量原子辐射的时钟。我们能够使用NTP将计算机的时钟同步到一个很小的误差范围内。在GPS中每个卫星都包含多个原子钟，这样一个时钟失败不会使卫星不可用。GPS协议允许任何人使用，只需要他们能够收到足够多的卫星信号就能解出所有的变量。不仅可以确定接收装置自己的位置，而且可以非常精确的确定时间。 我们已经理解这些协议几十年了，因此，我们很容易相信我们已经克服了这类问题，我们们应该能够建立一个假设我们的时钟是同步的系统。原子钟，NTP和GPS卫星提供了信息传播所需的时间的知识和设备。因此我，任何地方的系统都应该能够就“now”达成一致，并共享对时间进程的共同、单一的看法。然后，网络和计算中的所有困难问题都将变得容易得多。如果你所关系的所有系统对时间的感知都是完全相同的，那么即使再一些涉及主机出现故障时，许多这些问题也可以解决，但是在构建实际的分布式系统中，这些问题任然存在，并且处理它们不仅是一个持续活跃的研究领域，而且也是一个主要的关注点。 你可能会看到用于理解时间的成熟机制，并相信研究人员和系统构建者正在做大量不必要的工作。既然我们制定如何同步，为什么还要试图解决时钟可能不同的问题呢？为什么不适用时钟源和协议的正确组合来让时钟一致，继续前进，客服这些问题？有一件事情让这种说法难以置信，也让这些问题不仅重要，而且必须直面:一切都会崩溃。 真正的问题不是信息需要时间从一个地方转移到另外一个地方的理论概念。真正的问题是在计算系统所有的物理世界中，组件经常会失败。在构建系统，尤其是在商用机器和网络上的分布式计算系统时，最常见的错误之一就是假定脱离了基本的物理现实。光速就是这样一种现实，但是另外一种更有害但是同样普遍的现实也是这样，我们无法制造出永远有不坏的完美机器，正是这些现实，异步性和部分失败的结合，使得构建分布式系统变得困难。如果我们不计划考虑单个组件的故障，我们可以保证组合系统的故障。 分布式系统理论中最重要的结果之一不是可能的结果，它显示了在可能发生故障的世界中构建系统的能力的局限性。这通常被称为FLP结果，以其作者Fischer, Lynch, 和 Paterson命名。它们的工作以分布式计算领域最具影响力的论文获得了2001年的Dijkstra奖。最终证明了一些计算问题在同步模型中是可能实现的，在同步模型中，主机拥有相同或者共享的时钟，这样的不可能结果非常重要，因为它们可以引导你在涉及自己的系统的时候避免走入死胡同。它们还可以提供一个snake-oil探测器。所以你有理由怀疑哪些声称产品做了你认为不可能的事情的人。 一个相关的结果是CAP定理，用于一致性、可用性和分区耐受性。现在的开放人员相对FLP更加熟悉它。首先由Eric Brewer非正式的提出，后来由Seth Gilbert 和 Nancy Lynch证明了它。从分布式理论系统角度来看，CAP定理没有FLP有趣，一个反例击败了CAP的正式版本，它假设了一个比FLP更弱，更具有对抗性的世界模型，并要求在该模型中实现更多。虽然一个问题并不是另一
原文：Why SQL is beating NoSQL, and what this means for the future of data 作者：Ajay Kulkarni 翻译：Vincent
参考：https://www.twblogs.net/a/5c74cddcbd9eee339917b7b2https://towardsdatascience.com/exploring-the-gt-grammar-of-tables-package-in-r-7fff9d0b40cd
前段时间接触到腾讯云的一个新数据库产品 CynosDB 是基于 Amazon Aurora 数据库的Paper实现的。我比较感兴趣就来看看它和之前看过的 Spanner 之类有什么不同，也许部分设计也能用在我们游戏业务的服务器中。它的主要的创新点在于重新设计了binlog和存储的部分，所以我也主要就看了两篇Paper： 《Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases》 是一个整体性质的介绍和概述； 《Amazon Aurora: On Avoiding Distributed Consensus for I/Os,Commits, and Membership Changes》 是对其重点部分的存储服务的。
本作者是一位安卓初学者，之前学过JAVA，安卓只学过三天。《BLE Tool》也是我一个安卓项目，因为作者学习安卓加开发只用了10天时间，目前只是把所有接口打通了，只提供如何怎么实现。有不对的地方，大家多指点。开发之前，最好了解一下BLE的通信原理。最终实现的界面：
蚂蚁集团自研数据库OceanBase已经开源，这对国产分布式数据库来说，是一个重磅消息。一直以来OceanBase作为商业数据库，披露的技术细节并不多,以后又多了一个可以拿来研究的优秀分布式数据库。参考1[1]
OLAP和OLTP通过ETL衔接。为提升OLAP性能，需在ETL过程进行大量预计算，包括：
【导读】推荐系统和数据库技术，一个是偏机器学习数据挖掘相关的应用，一个是偏系统存储相关的技术，这两者在实际中有很大的应用。上一次专知推出漫谈推荐系统及数据库技术（一），大家反响热烈，特别是很多工业界的
Google最近发表了一篇有关大数据系统的论文，讨论了一个名为Mesa的数据仓库系统，它能处理近实时数据，即使在整个数据中心断线后还能正常工作。 Mesa是一个高度可扩展的分析数据仓库系统，能存储与Google广告业务有关的关键测量数据。Mesa能满足复杂和具有挑战性的用户与系统需求，包括近实时数据提取和查询，同时在海量数据和查询量中保持高可用性、可靠性、容错率和扩展性。Mesa每秒能处理数百万行更新，每天进行数十亿查询抓取数万亿行数据。Mesa能进行跨数据中心复制，即使在整个数据中心故障时，也能以低延迟返
Windows Azure Storage(WAS)是微软云服务的基础,提供了文件/结构化数据/消息等多种类型的存储。
翻了一下TiDB的文档，对TiDB有了个大概的了解。简单说，TiDB的实现架构是：底层是分布式KV引擎TiKV，上层是SQL引擎TiDB Servers。一般传统数据库也是这么分层实现的，只不过TiKV实现了一个分布式、强一致、支持事务的K/V，不像数据库是单机版K/V。在TiKV之上实现SQL引擎就简化了很多，因此TiDB Servers是无状态的。
预计 Gemini 在 Google Cloud 数据库产品中的可用性将帮助开发者比去年集成的 Duet AI 更快地编写代码和迁移。
关系型数据库指的是使用关系模型（二维表格模型）来组织数据的数据库，由二维表及其之间的联系所组成的一个数据组织。
在分布式系统中，实现一致性是一个至关重要的挑战。Paxos算法作为一种经典的分布式一致性算法，被广泛应用于各种分布式系统中，如分布式数据库、分布式文件系统和协调服务。本文将详细介绍Paxos算法的基本原理、实现方法及其在实际应用中的重要性。
而随着互联网在线业务的蓬勃发展，数据库面临着数据量大、高并发和超高峰值等诸多挑战。分布式数据库已成为业界普遍采用的有效解决方案。
在数据库领域，回顾2017这一年，精彩纷呈，热点不断，而且不乏标志性的事件发生。 如Oracle提出的自治数据库这样的概念，把数据库技术带入一个新世界。其实AI技术应用于数据库由来已久，如AI技术调优数据库的性能、AI技术优化SQL、AI技术自动创建数据库索引（Learned Index）等。但是能把AI和数据库结合使之进入大众视野的，还非“自治数据库”莫属。 再如NDBC（中国计算机学会数据库学术年会）庆祝四十华诞、阿里入股MariaDB、国内类Aurora架构的产品争相发布、数据库事务处理等核心技术
0 作为世界上最为知名的IT咨询和研究公司的Gartner，它的魔力象限可谓既简洁明了，又非常的知名。无数公司以自己被Gartner的魔力象限给评价为领导者而大张旗鼓的宣传。连微软之类的世界知名大公司
所以，当你通过网络发送一个数据包的时候，程序必须考虑到这个数据包可能丢失、也可能延迟。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
