The Google File System (2003) MapReduce: Simplified Data Processing on Large Clusters (2004) Bigtable: A Distributed Storage System for Structured Data (2006)
本文视频地址（点击下方原文链接）：https://www.zhihu.com/zvideo/1543712850048430081
Spanner是Bigtable的魔改版，下面这张谷歌云的PPT几乎和intro一一对应。
单体数据库时代，随着系统交易量的不断上升，数据库读写性能出现了严重下降。我们可以借助分库分表中间件，比如mycat、shardingjdbc来实现分库分表，缓解单库的读写性能。但是分库分表中间件并不支持事务，如果要保证数据一致性，就需要借助于分布式事务中间件，比如阿里巴巴的seata。后来分布式数据库逐渐成为解决数据一致性的选择，目前分布式数据库产品已经比较成熟，支持ACID事务，本文就来聊一聊分布式数据库。
这篇文章着重点不在于科普，毕竟关于CAP、BASE的理论的文章，网上很多。所以本文科普篇幅尽量小（只包含概念描述）。主要从几个侧面的问题来描述CAP，进而描述ACID、BASE理念。然后加入一点点调料，如何动态的切换一致性强度。
在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 语法的兼容性和关系型数据库功能。
响应式编程已经在 Java 编程领域出现很长一段时间了。具有高性能，事件驱动，充分利用计算资源，更加优雅的异步编程体验，同时它也提供了背压机制来防止系统过载。很长一段时间 Java 的响应式只能同 MongoDB、Redis 等这些非关系型数据库进行交互。而目前我们大部分的数据还是存放在关系型数据库中，大部分情况下 Java 使用 JDBC 来操作关系型数据库，而 JDBC 是阻塞的、同步的。所以迫切需要一种支持响应式的数据库驱动协议。目前市面上有两种响应式数据库驱动协议，我们来了解一下它们。
Spanner是一个全球分布式的数据库，从数据模型来看Spanner很像BigTable，都是类似于key对应着一行数据，但是却并不一样，Spanner中衍生出了“目录”的概念（把两张表合并存储）。这并不是重点，Spanner的重是它是第一个在全球范围内传递数据且保证外部一致的分布式事务的系统，且支持几种特定的事务，这显然是一个很困难的问题，我们会在文章中加以描述，这篇文章主要对Spanner的事务以及实现事务所使用的 TrueTime API 进行分析，这些也是论文中描述最为详尽，也是比较不好懂的地方。还有之所以不分析Spanner的架构是因为我觉得论文（第二节）中此方面的描述实在是有些简略，所以直接看论文就可以。
数字化时代下，企业的发展与数据库的建设息息相关。如果搭建云下数据库，不仅要通过大量的运维投入保证数据库稳定运行，随着企业规模与数据量的发展，还要应对数据库扩容、弹性、运维、备份等各种各样的问题，云下数据库对企业提出的要求日益增长。此时有两种应对之法，一是凭借扩充技术团队解决问题，但这无疑将会带来不菲的运维与人员成本，二则是把一切交给云服务。
诸如此类的问题，还能提出很多，因此需要一个靠谱的时钟来保证分布式系统里事件的处理不会出错。
ORACLE数据库既能跑OLTP业务，也能跑OLAP业务，能力是商业数据库中数一数二的。支持IBM小机和x86 PC服务器，支持多种OS。同时有多种数据库架构方案供选择，成本收益风险也各不相同。
本作者是一位安卓初学者，之前学过JAVA，安卓只学过三天。《BLE Tool》也是我一个安卓项目，因为作者学习安卓加开发只用了10天时间，目前只是把所有接口打通了，只提供如何怎么实现。有不对的地方，大家多指点。开发之前，最好了解一下BLE的通信原理。最终实现的界面：
上节介绍了如何整合Security，这节就说下如何再Springboot下使用持久层框架mybatis和牛人封装的通用mapper与mybatis的整合，直接进入正题吧！
有2年没有摸数据库了，重新学习下。数据库是IT系统的基石，小到一个个人站点，大到类似Google，阿里，腾讯这种大公司，里面都运行着各种各样的数据库，成千上万的人才还在继续开发和维护数据库。 数据库大牛stone breaker前两年还拿到了图领奖，了不起的成就。数据库理论这些年没啥大的突破，还是70年代提出来的关系模型，ACID等等。不过不表示数据库的发展停下来了，尤其是随着需要处理的数据和业务越来越大，数据库规模，性能越来越强。数据库的发展主要体现在工程能力，新硬件的使用上。 我个人理解就当前而言，技术
点击上方蓝字每天学习数据库 作者简介：李海翔，网名“那海蓝蓝”，腾讯金融云数据库技术专家。中国人民大学信息学院工程硕士企业导师。著有《数据库事务处理的艺术：事务管理和并发访问控制》、《数据库查询优化器的艺术：原理解析与SQL性能优化》、《大数据管理》，广受好评。 ---- Spanner支持事务的四个特性ACID，2012年的《Spanner: Google’s Globally-Distributed Database》论文，并没有明确描述ACID分别是怎么实现的，只是描述了C特性实现的一些内容，而D
原文：Why SQL is beating NoSQL, and what this means for the future of data 作者：Ajay Kulkarni 翻译：Vincent
“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更弱，更具有对抗性的世界模型，并要求在该模型中实现更多。虽然一个问题并不是另一
之前看过 《大规模分布式存储系统：原理解析与架构实战》 ，这个系统设计还是挺有意思的，里面提及了Google的一整套系统都有论文，而且现在已经进化到下一代支持分布式跨行事务的关系型数据库系统了。所以一直很想抽时间看看Google的那套去中心化并且可以平行扩容的分布式系统和数据库的论文。之前一些计划中的我自己的项目的优化项都差不多完成了，这段时间就陆陆续续的看完了这三篇Paper，可怜我的渣渣英语，所以看得比较慢。
本文仅收录了一些常见的 Spring Boot面试题，如需查看其它java面试题可查看我另一篇博文：
多年来，随着新功能的增加，spring 变得越来越复杂。访问spring官网页面，我们就会看到可以在我们的应用程序中使用的所有 Spring 项目的不同功能。如果必须启动一个新的 Spring 项目，我们必须添加构建路径或添加 Maven 依赖关系，配置应用程序服务器，添加 spring 配置。因此，开始一个新的 spring 项目需要很多努力，因为我们现在必须从头开始做所有事情。
Google Spanner简介 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，
关于昨天 Spanner 的文字，有人问 NewSQL 为什么会起名为 New，Spanner 的应用场景又是怎样的？那么这篇就顺着大数据的历史继续聊。
在分布式数据库领域中，高性能＋强一致性事务是代表数据库水平高低的重要象征，这个领域的代表数据库是Google Cloud Spanner和Azure Cosmos DB以及Apple开源的FoundationDB，YugaByte DB是这个领域的另外一个开源数据库。以下为 YugaByte DB关于开发分布式SQL数据库技术挑战的分享。
原文链接：https://blog.csdn.net/Design407/article/details/103263416
随着数据存储需求的不断增长，越来越多的应用选择使用NoSQL数据库来应对非结构化数据的挑战。MongoDB作为一款面向文档的NoSQL数据库，以其灵活的数据模型和高度可扩展性而备受青睐。本文将探讨如何在SpringBoot项目中整合MongoDB，以构建高效的数据存储应用。
spring Boot 是为 spring 服务的，是用来简化新 spring 应用的初始搭建以及开发过程的。Spring Boot是Spring开源组织下的子项目，是Spring组件一站式解决方案，主要是简化了使用Spring的难度，简省了繁重的配置，提供了各种启动器，开发者能快速上手。
多年来，随着新功能的增加，spring变得越来越复杂。只需访问https://spring.io/projects页面，我们就会看到可以在我们的应用程序中使用的所有Spring项目的不同功能。
最近因为工作需要对VLDB的一些论文进行了阅读。其中包括谷歌新发表的F1数据库的分析。解读谷歌论文一直都是不太容易的。因为谷歌向来都是说一半藏一半。这篇论文相对来说还是写的比较开放的，还是不能免俗。
众所周知，在 SQL 方面处于顶级的有两个公司，一个是 Oracle，他们已经积累了大量的经验，另一个是谷歌，谷歌 F1 在2012年发布了一篇论文，个人认为它是全球最优秀的 SQL OLTP 数据库。
技术综合 《小黄鸭调试法，每个程序员都要知道的》 《开发一个这样的 APP 要多长时间？》 《一段代码让你觉得人类智慧可以璀璨无比》 《成人网站有多大？》 《输入Google网址回车之后发生了什么？》 《为什么有些大公司技术弱爆了？》 《高效 MacBook 工作环境配置》 《如何编写让别人能读懂的代码？》 《最牛逼的编码套路》 《有了这列表，程序员不愁没练手小项目了》 《相似图片搜索的原理》 《麻省理工（MIT）牛人解说数学体系》 《程序员必须知道的10大基础实用算法》 《用 3 个空格缩进代码是异端么？
原文地址：Building a Virtual World Worthy of Sci-Fi: Designing a global metaverse 原文作者：Reto Meier 译文出自：掘金翻译计划 本文永久链接：github.com/xitu/gold-m… 译者：LeeSniper 校对者：IllllllIIl、Wangalan30 在 Build Out 系列的第二集里面，Colt McAnlis 和 Reto Meier 接受了设计一个全球虚拟世界的挑战。 看一看下面的视频，看看他们想
最新SpringBoot面试题【附答案解析】SpringBoot面试题及答案，SpringBoot最新面试题及答案，SpringBoot面试题新答案已经全部更新完了，有些答案是自己总结的，也有些答案是在网上搜集整理的。这些答案难免会存在一些错误，仅供大家参考。如果发现错误还望大家多多包涵，不吝赐教，谢谢~
Tedis（https://github.com/eleme/tedis） 是基于开源 TiKV 的兼容 Redis 协议的强一致性的 NoSQL 数据库开源项目。 本文介绍一下 Tedis 开源项目的架构设计和特性，以及架构背后的一些思考（包括为何选择 TiKV 和 Redis 协议）。
Tedis（https://github.com/eleme/tedis）是基于开源 TiKV 的兼容 Redis 协议的强一致性的 NoSQL 数据库开源项目。 本文介绍一下 Tedis 开源项目的架构设计和特性，以及架构背后的一些思考（包括为何选择 TiKV 和 Redis 协议）。
8.1 Collaboration and conflict resolution
作为一个在虐狗节还奋笔疾书的公众号写手来说，最重要的是各位汪们不是汪的读者们的打赏。这篇文章就看大家怎么想啦。 今天不但是虐狗节还是世界癫痫日，还有，更大的新闻是Google宣布Spanner作为一个公有云的服务正式开始提供了。所谓几家欢喜几家愁，这永远都是真理。 我想Spanner大名鼎鼎，大家都知道，但是作为服务了狗狗家10余年的MegaStore，因为其出身不够正统，听说过的人就很有限了吧。很多时候我一直在想，到底是个人成就了公司还是公司成就了个人。每次看到Jeff Dean我就会觉得我和他比智商不
最近一直都在面试，整理了几家公司常问的三大框架面试题，现在把它带答案整理好在这里分享给大家，希望对大家有所帮助。
Spring Boot 是一套快速开发框架，随着微服务架构应用不断普及，Spring Boot 的研发技术的掌握已经成为研发人员必会技能。与此同时，Spring Boot 开源生态建设能力非常强大，提供了很多应用组件，让Spring Boot 有丰富的三方开源软件的使用。
最近与同行科技交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库（分库分表）与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。
1 什么是时间？ 2 物理时间：墙上时钟 3 逻辑时钟：为事件定序 4 Turetime：物理时钟回归 5 区块链：重新定义时间 6 其他影响 6.1 NTP的时间同步 6.2 有限时间内的不可能性 6.3 延迟 6.4 租约 7 总结 8 参考文献
第一次知道数据库，是在大学时的数据库课程，那个时候的数据库特指关系型数据库。到后面工作后，才知道除了MySQL，Oralce这类关系数据库之外，还有NoSQL。 印象中，当时NoSQL由于优秀的性能和扩展性，发展迅速。但技术并非一成不变，二者可以相互借鉴。 待NoSQL潮水褪去，NewSQL出现，就像是是NoSQL和SQL在易用性和可扩展性上的平衡。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
