分布式数据库 订阅
分布式数据库系统通常使用较小的计算机系统,每台计算机可单独放在一个地方,每台计算机中都可能有DBMS的一份完整拷贝副本,或者部分拷贝副本,并具有自己局部的数据库,位于不同地点的许多计算机通过网络互相连接,共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。 展开全文
分布式数据库系统通常使用较小的计算机系统,每台计算机可单独放在一个地方,每台计算机中都可能有DBMS的一份完整拷贝副本,或者部分拷贝副本,并具有自己局部的数据库,位于不同地点的许多计算机通过网络互相连接,共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
信息
特    点
就地完成
系统可靠性
支持技术
分布式处理
中文名
分布式数据库
外文名
distributed data base
简    称
DDB
伪代码应用领域
结构模式 根据我国制定的《分布式数据库系统标准》,分布式数据库系统抽象为4层的结构模式。这种结构模式得到了国内外的支持和认同。4层模式划分为全局外层、全局概念层、局部概念层和局部内层,在各层间还有相应的层间映射。这种4层模式适用于同构型分布式数据库系统,也适用于异构型分布式数据库系统。
收起全文
精华内容
下载资源
问答
  • 分布式数据库技术系列简报-金融级需求与分布式数据库应用契合.pdf
  • 分布式数据库

    2018-07-09 15:17:21
    分布式的架构中,小型的系统也还好解决,如果出现像国美这种大型复杂的零售系统、订单系统、SAP系统如何解决?这种全流程的架构如何解决?
  • 分布式系统数据库系统原理(第三版)中的描述:“我们把分布式数据库定义为一群分布在计算机网络上、逻辑上相互关联的数据库。分布式数据库管理系统(分布式DBMS)则是支持管理分布式数据库的软件系统,它使得分布对于...
  • 东北大学分布式数据库历年真题以及答案
  • 东北大学分布式数据库2018年考试题
  • 癸巳即将过去,总得点礼物吧,思来想去,觉得写写GOOGLE分布式数据库技术发展情况,以此作为礼物献给自己,聊以自慰,由于时间有限,加之对于GOOGLE的分布式数据库理解也只能盲人摸象,难免有错误之处,敬请谅解。...
  • 分布式数据库技术金融应用规范》的技术架构及分布式事务核心功能的解读揭秘内容项描述: 1、教科书定义的分布式事务数据库的技术架构及功能特性 2、国内三种主流金融行业的分布式事务数据库的技术架构揭秘 3、...
  • 近年来,人民银行推动信息化...历经2年时间,于2020年11月26日,中国人民银行正式发布《分布式数据库技术金融应用规范 技术架构》(JR/T 0203-2020)、《分布式数据库技术金融应用规范安全技术要求》(JR/T0204-2020)
  • 本文档使用YCSB测试Hbase和MySql性能 包括运行时间,吞吐量,时延等, ycsb是yahoo开源的一个多功能压测软件,支持mysql mongodb redis hbase等多种软件
  • clearpool是一个开源的高性能的分布式数据库池,它可以高效地管理多个数据库源,并支持分布式事务。clearpool有着良好的性能,因为它最大程度地复用了数据库连接池的连接。 clearpool的功能: 有效地...
  • 分布式数据库系统的复习提纲,帮助在校学生期末复习,内容比较详细。内容广适性比较强,对于不同版本教材均比较实用。
  • 跟打印店的考题形式不太一样,记录下来,希望能够帮到学弟学妹们 2019年的,也提醒一下学弟学妹们:PPT的内容很有用,你们要好好学哦,
  • 一、Hbase数据库概述; 二、Hbase体系结构; 三、Hbase数据库模型; 四、总结Hbase整体特点; 五、案例:搭建Hbase分布式数据库系统
  • 数据库大作业,内容有文档包括需求分析,概要设计,测试报告,总体实验设计报告已经代码。 下面就是凑字数了,下了这个文档后,你的作业基本就没有问题了,随便水水过去了,这些课程真的太无聊了,看的人头痛,屁用...
  • 全书总计 8 章,首先简单介绍了分布式系统和分布式数据库的需求,然后讲解了分布式数据库的实现原理,并对市场上存在的各种分布式数据库中间件进行了对比,再围绕着如何利用 Mycat 实现分布式数据库而展开。...
  • 分布式数据库系统及其应用(第2版)》在第一版的基础上做了较大的修改,增加了与分布式数据库技术密切相关的、新的网络与数据库的接口技术,基于组件的新的软件开发方法,WWW数据库,移动数据库,数据仓库和数据挖掘...
  • 机密 GoldenDB 分布式数据库 例行维护手册 中兴通讯股份有限公司 <以上所有信息均为中兴通讯股份有限公司所有不得外传> i 机密 GoldenDB分布式数据库 例行维护手册 资料版本 20180930-R1.0 产品版本 策 划 编 著 审 ...
  • postgresql分布式数据库架构文档。Postgres-XC提供同步多主复制、任意数据节点可写等等多种功能。
  • 该文档内容如下: HBase安装配置与实践: 1. HBase安装 1.2 将解压的文件名hbase-1.0.1.1改为hbase,以方便使用 ...2.1伪分布式模式配置 接下来测试运行HBase。 1.3.2编程实践 附:设置Linux环境变量的方法和区别
  • 全书总计 8 章,首先简单介绍了分布式系统和分布式数据库的需求,然后讲解了分布式数据库的实现原理,并对市场上存在的各种分布式数据库中间件进行了对比,再围绕着如何利用 Mycat 实现分布式数据库而展开。《分布式...
  • 此文档为个人学习总结的 分布式数据库TIDB 技术 及原理讲解,适合初学者及想学习原理的同学学习,也可以作为讲学课件。
  • 1.分布式数据库是多个数据库,而rac只是一个库多个实例; 2.rac事务上没有协调的问题,而分布式数据库由于是多个库需要事务上的协调; 3.分布式数据库数据是分散存储在各个节点,但是设备一般都是廉价的设备,经常...
  • 分布式数据库课件

    2017-11-13 19:05:30
    可供教学PPt使用,学习等。 !
  • #资源达人分享计划#
  • 目录分布式数据库架构分布式数据库发展梗概关于数据库文件系统了解一下LSM-TreeB+Tree VS LSM-Tree第一代分布式数据库——分库分表及分布式中间件普通分布式中间件阿里OceanBase数据库第二代分布式数据库——NoSQL第...

    分布式数据库架构

    这个系列文章是笔者自己学习分布式数据库的记录,共有两篇,分别是:
    (一)分布式数据库架构
    (二)分布式数据库事务

    本篇是该系列的第一篇,将从分布式的概念出发,阐述笔者理解的分布式数据库三个发展阶段,并分别介绍每个阶段的代表性的数据库及其架构,这些数据库也会在后面对分布式事务的介绍中作为样例分析。

    笔者水平有限,如有错误恳请指正。文中的部分图片获取自网络,侵删。

    分布式数据库发展梗概

    分布式是面向业务扩展而出现的一个概念,而分布式数据库,就是为了解决存储可扩展性的一类数据库。笔者认为除了最初的分库分表方案,分布式数据库经历了三个主要发展阶段。第一代是分布式中间件的形式,大多数是基于MySQL数据库做Data Sharding和水平扩展;第二代是以Cassandra、MongoDB为代表的NoSQL;第三代是以AWS Aurora和Google Spanner为代表的云数据库,或者称作NewSQL。

    这三个阶段在分布式这个概念上没有本质上的区别,但是在具体的实现上有不同的侧重点,比如NoSQL就不支持跨分片的ACID事务。大家要注意并不是越新的概念的就越先进,实际上,现在市面上主流的分布式数据库,大多是分布式中间件的形式。

    关于数据库文件系统

    在具体介绍各类分布式数据库之前,我们先来了解一下在数据库中实际存储数据的数据库文件系统。
    目前主流的数据库文件系统有两类,一类是关系型数据库(如MySQL)使用的B+Tree,另一类是多用于键值存储数据库(如NoSQL)的LSM-Tree数据结构。分布式数据库建立在分布式文件系统之上,在底层实现上也是依赖于这两类数据结构的。

    了解一下LSM-Tree

    相信大家对B+Tree都有一定程度的了解,但对LSM-Tree可能就没那么熟悉了,这里我们简单介绍一下LSM-Tree。
    LSM-Tree,全称Log Structured Merge Tree,是一种写入操作不做原地更新,而是以追加的方式写入内存,每次写到一定程度,即冻结为一层,然后写入持久化存储的数据结构。
    我们可以简单描述一下一条数据在LSM-Tree中的写入过程:写入Log -> 写入memtable -> flush入持久化存储 -> 经compaction操作进入持久化存储的更新层 -> 同一key的新数据到来时丢弃。
    下面是一张LSM-Tree的结构图。
    LSM-Tree架构

    B+Tree VS LSM-Tree

    我们来比较一下这两类数据结构,明确它们的特性和适用场景。
    B+Tree将数据拆分为固定大小的Block或Page,Page是读写的最小单位。B+Tree可以做到原地更新和删除,因此对数据库事务的支持更加友好,因为一个key只会出现一个Page页里面。
    而LSM-Tree的设计思路是将数据拆分为几百M大小的Segment,并顺序写入。LSM-Tree只能追加写,并且在L0层key的range会重叠,所以对事务支持较弱,只能在Segment Compaction的时候真正地更新和删除。

    B+Tree的优点是支持高效的读(稳定的O(logN)的复杂度),但对大规模的写请求的效率就比较低(O(logN)复杂度),这是因为在大规模写的情况下,为了维护B+Tree的结构,B+Tree的节点就会不断分裂,操作磁盘的随机读写概率会变大,从而导致写性能降低。
    LSM-Tree则相反,支持高吞吐量的写(O(1)),但普通LSM-Tree读取的复杂度是O(n),在使用索引或者缓存优化后可以达到O(logN)。

    我们可以粗略的认为未优化的LSM-Tree的写比B+Tree快一个数量级,未优化的LSM-Tree的读比B+Tree慢一个数量级。

    第一代分布式数据库——分库分表及分布式中间件

    最初面对存储扩展问题,一个比较直接的思路就是分库分表——一个库装不下,我就用多个库装。

    假设一开始我们有一个单点的MySQL数据库,随着业务增长,达到了单库的存储性能瓶颈,准备使用三到五个MySQL来重新安排存储。在最理想的情况下,我们可以在拥有原来三到五倍存储空间的情况下,也能有三到五倍的并发来提升存储性能。

    但这有两个很明显的问题:第一个是我要对业务进行大量的改造,找到一个合适的维度打散业务进入多个库(而且这种完美的方案还不一定存在),而且跨库的业务也要重新写业务逻辑。第二个是一旦库又满了,我想再做一次扩容的工作,我就又要把这部分的工作再做一次——包括重写业务。

    上面两个问题的代价显然是不可承受的,这时候就有分布式数据库厂家来说了:我们来做整合并管理多个库的工作,你们应用只要把多个数据库当作原来的一个库使用即可。

    这就诞生了分布式中间件的概念,或者称作分布式关系型数据库。分布式中间件,是从关系型数据库出发,加入分布式技术,实现分布式的高可用性和高扩展性等特性。本文把此类数据库称为分布式中间件,不代表它们就没有对底层数据库(通常是MySQL)做任何改动。实际上,目前市面上的分布式关系型数据库几乎都对底层数据库有自己的修改,甚至有阿里的OceanBase那样自己实现一个关系型底层的情况。

    但是,分布式中间件 有根本解决上面的两个问题吗?显然并没有。分布式中间件没有把数据自动分片的能力,应用也不能真真正正的把分布式数据库当作一个单库来使用——除非你完全不在乎跨片的性能损耗。

    但分布式中间件也确确实实有很大的作用,它极大的减少了业务的改造量,也保证了了分布式事务的ACID特性。在各类分布式中间件迭代发展的过程中,这一技术路线也在逐渐进步:厂家开始探索对底层数据库的改造,以使其更适应分布式特性;中间件层也吸收了后面NewSQL的一些技术思路,在全局事务管理、数据增量写入等方面做了很多优化。

    普通分布式中间件

    大部分分布式中间件的架构一般有以下三个部分:

    客户端:通常为MySQL5.7或8.0版本的客户端,支持JDBC访问。
    存储层:由多个MySQL实例组成,引擎为InnoDB。
    计算层(中间件层):组织并管理存储层的MySQL实例,接受并解析客户端传来的SQL请求。计算层通常用片的概念把存储层的MySQL分割,然后以片为单位进行多副本来实现高可用。计算层显式或隐式的有一个事务管理组件,负责给事务赋一个全局唯一的ID,这个组件是实现分布式事务一致性的一种重要的解决方案。计算层对客户端屏蔽多副本和事务ID,会对客户端发来的普通SQL进行拆分和改造,并生成分布式的执行计划,然后下发到存储层的MySQL实例执行。

    阿里OceanBase数据库

    OceanBase的总体架构如下图。
    在这里插入图片描述
    可以看到OceanBase主要由五部分组成:
    客户端:用户使用OceanBase的方式和MySQL数据库完全相同,支持JDBC、C客户端访问等。
    RootServer:管理集群中的所有服务器,子表(tablet)数据分布以及副本管理。RootServer一般为一主一备,主备之间由数据强同步。
    UpdateServer:存储OceanBase系统的增量更新数据。UpdateServer一般为一主一备,主备之间可以配置不同的同步模式。部署时,UpdateServer进程和RootServer进程往往共用物理服务器。
    ChunkServer:存储OceanBase系统的基线数据。基线数据一般存储两份或者三份,可配置。
    MergeServer:接收并解析用户的SQL请求,经过词法分析、语法分析、查询优化等一系列操作后转发给响应的ChunkServer或者UpdateServer。如果请求的数据分布在多台ChunkServer上,MergeServer还需要对多台ChunkServer返回的结果进行合并。
    OceanBase借鉴了BigTable的做法,相比于普通的分布式中间件引入了UpdateServer这种增量更新机制,在不需要使用两阶段提交的情况下实现了分布式事务,这点下一篇分布式事务部分会详细展开。

    第二代分布式数据库——NoSQL

    在早期分库分表方案发展过程中,好多公司都面临了因扩容而无限次改造业务的痛苦。他们再次观察业务,发现业务并不复杂——至少没复杂到需要使用高级SQL的地步。这样NoSQL干脆就抛弃了高级SQL(分布式ACID特性),从而换来对业务透明的特性和强水平扩展的能力。

    这样做的好处显而易见——只要你能忍受不用高级SQL这一点,那么你只要进行一次到NoSQL的改造,后面就可以近乎无限的扩容,无需任何业务的适配。

    各种NoSQL,如HBase,Cassandra,Leveldb,RocksDB底层的数据结构,都是LSM-Tree。

    因为NoSQL不支持分布式ACID特性,和其他分布式数据库差别较大,所以不列入后面对事务的讨论。

    第三代分布式数据库——NewSQL

    上面的分库分表、分布式中间件和NoSQL都不可避免的由一个业务侵入性的问题,有些前沿厂家就产生了把二者结合起来,设计一个兼具分布式事务一致性和强可扩展性的数据库的想法——这就是NewSQL的诞生。

    在NewSQL领域,有两个流派,分别是Amazon的Aurora和Google的Spanner。这两者之前的区别实际上是非常大的,所以我们在后文中也把他们看作两种完全不同的数据库。

    Aurora流派

    Aurora流派也被称作Shared Everything,目前这个流派,多是被部署到虚拟计算环境中的云数据库,本文涉及的云数据库有阿里的PolarDB,Amazon的Aurora以及华为云数据库Taurus。

    知乎上有个很有意思的问题:为什么AWS云计算服务是亚马逊先做出来,而不是Google?

    这个问题的回答也都很专业,这里简单总结一下。Amazon的核心业务电子商务有太强的季节性,可以理解成,Amazon要维持的服务器数量是根据每年黑五的需求决定的,而一年的其他时间完全不需要这么多服务器。于是就诞生了AWS的想法,也成为后来“云”这一概念的雏形。
    另外还有一点就是两者商业哲学的不同。Amazon更倾向于提供近似于水电的基础设置服务,成本应该越低越好,价格也应该越低越好;而Google零几年的时候主营的业务广告利润非常之高,并且Google一向只喜欢提供终端的服务,既没有压力也没有动力去做云。

    Aurora流派最重要的一个概念就是Log is Database。这个概念是把log写到存储层,由存储层负责重放log、回写page并尽量减少写放大。

    下面一个表格列出了Aurora一系列数据库的特性对比.

    数据库计存分离解决方案架构特点架构缺点
    PolarDB将InnoDB的log和page存放带类POSIX接口的分布式文件系统CPU负载小;采用基于RDMA实现的ParallelRaft技术来复制数据;对于InnoDB的侵入非常小,便于跟进MySQL社区的新版本Page刷脏网络压力大;
    AuroraLog is Database将db的数据(也就是所有的page)分成若干个10GB大小的shard,相应的log也随data一起保存在shard中;持久化、page读取都只需要一跳网络传输。存储节点需要大量的CPU做redo log到innodb page的转换
    SocratesLog is Database相比于Aurora单独了一个log层用于持久化log,避免受到重放log、回写page的影响;PageServer层从log层拉取log进行重放、回写page,并向计算节点提供读取page服务。存储节点需要大量的CPU做redo log到innodb page的转换
    CynosDBLog is Database相比于Aurora存储层为计算节点提供了Log IO接口与Page IO接口,前者负责持久化log,后者负责page的读取存储节点需要大量的CPU做redo log到innodb page的转换
    TaurusLog is Database有独特的Log Store设计;使用了raft复制协议存储节点需要大量的CPU做redo log到innodb page的转换

    需要专门说明的一点是Aurora和PolarDB理念上的区分。Aurora认为网络会成为云数据库的瓶颈;PolarDB则认为网络传输速度会快速发展,后续软件代码(CPU)才是性能的瓶颈。

    这两种思路的区别导向了两种架构。Aurora的设计是日志即数据,在保证日志落盘的前提下,尽量减少磁盘IO,所以整个Aurora只写一份Redo log到底层存储,由底层存储来实现把rodo log‘恢复’成数据页的行为;PolarDB则把数据页和rodo log都写入底层存储,PolarDB的底层存储PolarStore更像一个通用的高可用存储,不需要进行类似Aurora一样把Redo日志恢复出数据文件的操作。

    从同行的表现来看,后面一系列的云原生数据库基本都跟进了Aurora的架构,看起来还是Log is Database架构更合理。不过,也有一种说法是PolarDB在早期没有过分考虑技术的长远性,而是直接选择一种易实现的架构来抢占市场。从这种角度看,PolarDB是成功的。

    华为云Taurus数据库

    我们这里以2020年六月份华为云Taurus在Sigmod上发表的论文来看一下Aurora流派的结构。下图是Taurus的结构图。
    在这里插入图片描述
    可以看到Taurus主要由四部分组成:

    客户端:目前是一个改版的MySQL8.0;
    SAL:全称Storage Abstraciton Layer,可以理解为存储层的前端和存储数据分布式管理组件,负责DB引擎与存储的Log Store/Page Store交互,同时也负责创建、管理、删除Page Store的Slices以及管理page在Slices上的映射关系;
    Log Store:负责持久化log以及为只读实例提供log内容;
    Page Store:存储真正的数据并为SQL前端提供page读取服务,向SAL提供4个API:WriteLogs,ReadPage,SetRecycleLSN,GetPersistentLSN。

    阿里双十一存储引擎X-Engine

    X-Engine是阿里专为双十一设计的存储引擎,因为其特殊性,我们这里也简单介绍以下它的架构。我们可以从2019年阿里发布的论文《X-Engine:An Optimized Storage Engine for Large-scale E_commerce Transaction Processing》中看到其具体的设计。

    X-Engine主要是为了解决双十一面临的三个问题而研发的,这三个问题是:

    海啸问题,活动开始时每秒交易量(TPS)激增;
    泄洪问题,缓存很快被大量数据填满;
    访问热点急速变化问题,随着促销活动的改变,数据的冷热会发生迅速的切换。

    这种特殊的场景使X-Engine相比于其他的分布式数据库更加重视insert和update性能,从而使用了具有杰出写入性能的LSM-Tree这种数据结构。

    X-Engine的架构见下图。(大家可以对照上文普通LSM-Tree的结构图)
    在这里插入图片描述

    基于LSM-Tree分层存储能够做到写的高吞吐,带来的副作用是整个系统必须频繁的进行compaction,写入量越大,Compaction操作越频繁。而Compaction操作非常消耗CPU和IO,在高吞吐的情况下,大量的Compaction操作占用大量系统资源,必然带来整个系统性能断崖式下跌,对应用系统产生巨大影响。

    X-Engine为了优化这个问题,引入了异构硬件设备FPGA来代替CPU完成compaction操作,使系统整体性能维持在高水位并避免抖动,是存储引擎得以服务业务苛刻要求的关键。

    Spanner流派

    Spanner流派也称作Shared Nothing。与分布式中间件不同的是,它是从分布式系统出发,再来做存储,做查询,利用天然的扩展能力和列存的性能优势,实现基于KV存储的支持关系型查询的数据库。如TiDB,就是一个NewSQL的商业化的实现。

    我们对Spanner的所有了解都来自Google于2012年发表的论文《Spanner: Google’s Globally-Distributed Database》。

    Spanner论文中有两个点需要十分重视:一个是TrueTime API的实现,给Spanner提供了全局的时钟接口,在此基础上Spanner才能实现强的全局一致性保证;另一个是论文中对Spanner的分布式事务实现细节进行了详细的描述。第一点在本文中会有详细的阐述,第二点详见下一篇分布式事务部分。
    Spanner的总体(全球)架构见下图。
    在这里插入图片描述
    universe是Spanner的全球部署实例,并被分成多个zone,zone是Spanner管理部署和物理隔离的单元。
    一个zone包含一个zonemaster,若干个location proxy,和一百至几千个spanserver。zonemaster把数据分配给spanserver,spanserver把数据提供给客户端。客户端使用每个zone上面的location proxy来定位可以为自己提供数据的spanserver。

    spanserver的架构见下图。
    在这里插入图片描述
    每个spanserver负载管理了100到1000个tablet(BigTable提出的一种数据结构),tablet实现了下面的映射:

    (key:string,timestamp:int64) -> string

    为了支持复制,每个spanserver会在每个tablet上面实现一个单个的Paxos状态机。Paxos协议会选举出一个领导者(上图中中间的那个replica),写操作必须在领导者上初始化Paxos协议,读操作可以直接从底层任何副本的tablet中访问状态信息,只要这个副本足够新。副本的集合称为一个Paxos group。

    此外,Spanner实现分布式事务一致性是靠两阶段提交,所以一个分布式事务还会选举出一个participant leader。transaction manager就是用来实现participant leader的。

    lock table则用来实现并发控制,这个锁表包含了两阶段锁机制的状态:它把键的值域映射到锁状态上面。

    下图是Spanner TrueTime的三个API。
    在这里插入图片描述
    TrueTime会显式地把时间表达成TTinterval,这是一个时间区间,具有有界限的时间不确定性。

    TT.now()返回的结果是当前时间的一个闭区间[earliest,latest]。用函数tabs(e)表示一个事件e的绝对事件,那么对于一个调用tt=TT.now(),TrueTime可以保证tt.earliest <= tabs(e) <= tt.latest。

    底层上,TrueTime使用GPS和原子钟两种方式来获取时间,增加可靠性。在Google的线上应用环境中,TrueTime的误差边界是一个关于时间的锯齿形函数,在1到7ms之间变化,其中1ms来自网络通讯延迟。

    总结

    本文从分布式的概念出发,阐述笔者理解的分布式数据库三个发展阶段,并分别介绍每个阶段的代表性的数据库及其架构,主要包括普通分布式中间件、OceanBase、华为云Taurus、X-Engine引擎和Spanner。下一篇,我会详解这些分布式数据库分布式事务的的实现。

    展开全文
  • 分布式数据库技术系列简报:云计算场景驱动分布式数据库技术演进.pdf
  • Sharding-JDBC是一个开源的分布式数据库中间件解决方案。它在Java的JDBC层以对业务应用零侵入的方式额外提供数据分片,读写分离,柔性事务和分布式治理能力。
  • 分布式数据库 Mycat . 分布式数据库架构及企业实践 基于Mycat中间件.pdf
  • 随着传统的数据库、计算机网络和数字通信技术的飞速发展,以数据分布存储和分布处理为主要特征的分布式数据库系统的研究和开发越来越受到人们的关注。但由于其开发较为复杂,在一定程度上制约了它的发展。基于此,...
  • 完整的东北大学申德荣教授的 分布式数据库原理与应用课件 ppt,共计10章。 《分布式数据库系统原理与应用》主要介绍分布式数据库系统的理论与实现机制方面的有关原理和方法。全书共分十章,第1章和第2章介绍分布式...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 583,088
精华内容 233,235
关键字:

分布式数据库