写点什么

李飞飞:如何看待数据库的未来?

  • 2020-03-05
  • 本文字数:9192 字

    阅读完需:约 30 分钟

李飞飞:如何看待数据库的未来?

一、云原生分布式数据库系统的发展历程

数据库市场分析与预测


首先为大家将介绍整个数据库市场分析与预测。根据 Gartner 公司的分析报告,2018 年全球基础软件如虚拟化软件、操作系统、存储等的市场规模大约为 2000 亿美金,其中数据库占 20%,大约为 461 亿美金。而中国的数据库市场规模大概为 161 亿人民币,但这一数字实际上因为各种原因被远远低估了。2018 年数据库市场的增长率是 18%,其中云数据库占比达到了 22.75%,而 Gartner 预测在未来的 2 到 3 年内云数据库的占比可能会达到 75%。在世界范围内,云数据库的领袖毫无疑问当然是亚马逊。亚马逊是最早在云数据库市场发力的厂商,也是目前做的最好的一家云厂商。而在 AWS 做云数据库之前,这个市场处于“None-Player”的状态,传统数据库市场的巨头是 Microsoft、IBM、Oracle,而 AWS 未能跻身其中。但云数据库赛道为 AWS 带来了发展的机遇,其发展速度非常快,它的云原生数据库 Aurora 在 2018 年就达到了 3 亿美金的营收。


数据库系统演进


数据库已经发展了 40 年,可以说是一个传统又古老的领域。回顾数据库的发展历史,1980 年到 1990 年属于商业起步阶段,此时 Oracle、IBM DB2、Sybase 以及 SQL Server 和 Informix 等开始出现。


1990 年至 2000 年,开源数据库开始展露头角,出现了 PostgreSQL 和 MySQL 等。与此同时,出现了一些分析型数据库,因为之前出现的都是 OLTP,而现在随着大量数据的出现,需要对于这些数据进行分析,因此出现了 OLAP,而为了避免读写冲突,就需要建立分析型数据库系统,Teradata、Sybase IQ、Greenplum 等就快速成长起来。



2000 年到 2010 年期间,以谷歌为代表的互联网公司逐渐推出了 NoSQL 数据库。尤其是谷歌的 GFS(Google File System)、Google Bigtable、Google MapReduce 三大件。Google File System 解决了分布式文件系统问题,Google Bigtable 解决了分布式 KV(Key-Value)存储的问题,Google MapReduce 解决了在分布式文件系统和分布式 KV 存储上面如何做分布式计算和分析的问题。之所以产生了这三大件,是因为数据强一致性对系统的水平拓展以及海量数据爆发式增长的分析能力出现了断层。因此就需要解决这个问题,把这种数据的强一致性需求弱化,换来能够使用用分布式的集群做水平拓展处理。谷歌三大件在业界诞生以后,很快的衍生了一个新的领域叫 NoSQL(Not Only SQL),就是针对非结构化、半结构化的海量数据处理系统。现在也有很多很好的商业公司基于 NoSQL 发展,比如说文档数据(MongoDB)、缓存(Redis)等大家平常应用开发都会用到的 NoSQL 系统。


而在 2010 年以后,AWS Aurora、Redshift、Azure SQL Database、Google Spanner 以及阿里云的 POLARDB 和 AnalyticDB 等都发展起来了,它们的特点就是云原生、一体化分布式、多模和 HTAP 的能力。


总结而言,数据库的演进经历了从结构化数据在线处理到海量数据分析,从 SQL+OLAP 的 RDBMS 到 ETL+OLAP 的 Data Warehouse 和 Data Cube,再到今天异构多源的数据类型的发展历程。


数据库:云上应用的关键一环


如今,上云已经成为一种趋势。而在上云的过程中,数据库则被认为是云上非常重要的一环。因为云最开始提供的是 IaaS,而随着各种智能化应用的兴起,数据库就成为了从 IaaS 到智能化应用连接的重要一环。



数据库发展:业务视角


大家知道,数据库可以分为几类:


最经典的是传统关系型 OLTP 数据库,其主要用于事务处理的结构化数据库,典型例子是银行的转账记账、淘宝下单、订单以及商品库存管理等。其面临的核心挑战是高并发、高可用以及高性能下的数据正确性和一致性。


其次是 NoSQL 数据库及专用型数据库,其主要用于存储和处理非结构化或半结构化数据(如文档,图,时序、时空,K-V),不强制数据的一致性,以此换来系统的水平拓展、吞吐能力的提升。


再次是分析型数据库 (On-Line Analytic Processing, OLAP),其应用场景就是海量的数据、数据类型复杂以及分析条件复杂的情况,能够支持深度智能化分析。其面临的挑战主要是高性能、分析深度、与 TP 数据库的联动,以及与 NoSQL 数据库的联动。


除了数据的核心引擎之外,还有数据库外围的服务和管理类工具,比如数据传输、数据备份以及数据管理等。


最后就是数据库的管控平台,无论是私有云、专有云、混合云还是自己的 IDC 机房内进行部署,总要有一套数据库管控系统来管理数据库实例的产生和消亡、实例的资源消费等,能够以简单的形式提供给 DBA 以及数据库开发者。



数据库系统 DBMS 的价值


如下图所示的是文件形式的数据存储系统和 DBMS 的区别。数据库系统的核心位置在操作系统和 SQL 的接口之间,简单而言就是在存储系统与上层抽象之间架起了一个系统来管理对于业务有用的数据,如果不这样设计则需要使用一些高级程序语言开发应用程序来与操作系统交互并管理这些数据。而数据库将对于数据的管理、存储以及消费抽象出来,这样一来不用每次都在应用程序里写相关的逻辑了,而可以专注于业务逻辑,数据管理相关的逻辑全部交给数据库系统实现,并且用 Structured Query Language 结构化查询语言对于数据访问接口进行抽象。



数据库系统的核心模块


将数据库系统拆开来看,其核心模块包括应用接口、SQL 接口、查询执行引擎、数据访问模块和存储引擎。其中,查询执行引擎进一步可以拆分为计划生成器、计划优化器和计划执行器;数据访问模块则可以分为事务处理、内存处理、安全管理以及文件和索引管理等模块;并且事务处理是最核心的模块,其中包括了崩溃恢复和并发控制;最底层的存储引擎则包括数据文件、索引文件和系统及元数据文件。



查询分析处理过程


数据库查询分析处理过程是这样的:首先,通过 SQL 语句或者大数据系统的 Dataframe API 将查询任务提交上来,之后经过 Simba PraserSimba Parser 进行处理,此时会有各种各样的执行方式,并生成 Catalog 和逻辑执行计划;之后对于逻辑执行计划进行优化,并生成物理执行计划;之后在借助系统的统计信息,如索引管理、内存管理来生成一个优化后的物理执行计划,再执行并生成最后结果或者 RDD。



简单而言,数据库系统的架构就是持久化存储的数据按照 Data Page 的形式进行存储,这些数据块在查询访问的时候会被带到内存里面。系统中有内存池,每个内存池可以装载一个 Page,此时的问题就是内存池的大小是有限的,如果数据存储非常大,需要进行优化。此外,还涉及到优化数据访问的问题,一般通过索引解决,主要是 Hash 索引和树形索引。


数据库系统挑战


数据库系统最关键的挑战就是并行访问时的写写冲突和数据一致性问题。此外,还有读和写的冲突问题,比如在数据库里做批量写入的时候系统宕机,应该考虑如何让系统自动恢复。



为解决以上的问题,数据库系统提出了一个核心概念——事务。简单而言,事务就是一系列动作可以被看作一个整体,从用户视角来看事务是隔离运行的,一个用户的事务和另一个用户没有关系。如果系统出现异常,事务要么全部执行完毕,要么一个也没有被执行。这样引申出来事务的核心概念:原子性、一致性、隔离性、持久性。


数据库系统的挑战


数据库系统与大数据系统非常相关,而在分析型数据库系统里面也会面临非常多的挑战,比如预测用户的退货率需要进行非常复杂的查询分析并且需要非常复杂的机器学习模型。


二、数据库系统架构的对比及趋势

云原生数据:要解决什么问题?


传统架构依赖于高端硬件,每套数据库系统服务器少,架构相对简单,但无法支持新业务的扩展需求。而云计算机构的核心逻辑就是通过虚拟化技术带来池化资源。云原生数据库采用分布式数据库架构,实现大规模扩展,每套数据库系统横跨多台服务器和虚拟机,带来了全新的系统管理挑战。其中最核心的挑战就是如何实现弹性以及高可用,实现按需按量使用,使得资源高效利用。



云原生数据库管控平台:DBaaS 智能化简化管理维护


云原生数据希望管控平台能够实现多实例统一管理;全图形化,无需命令行;分钟级安装,集群部署;自动备份,时间点恢复;动态扩容和缩容;以及性能监控和优化调整。



阿里巴巴数据库发展历史


在 2005 到 2009 年,当时阿里巴巴拥有亚太最大规模的 Oracle RAC 集群;在 2010 年到 2015 年开始,使用开源数据库以及分库分表的技术来解决对于商业数据库的依赖;从 2016 年开始到现在,阿里巴巴都在自研数据库上发力,TP 方面包括 POLARDB 和 OceanBase,AP 方面则有分析型数据库 AnalyticDB。



灵活的部署形态


随着云计算的发展,数据库的部署形式也发生了很大的变化。传统的数据都是部署在客户机房里面,与客户的机器绑定。而在云环境下,希望数据库能够在多种形态下部署,比如公有云、专有/私有云、混合云以及软硬件一体化独立部署,以及纯软件输出。



Oracle 等数据库厂商也正在向着 AWS 的部署方式转型。



多模数据库系统


数据库系统另外的一个趋势就是多模。数据库系统的演进经历了从最早的关系型数据库 OLTP 到半结构化,再到分析型数据库 OLAP 等非结构化的数据库,再发展到如今的多模数据库。对于多模数据库而言,主要有两种维度,南向维度是数据库可以有多种存储港方式,北向维度是可以有多种查询接口和标准,而希望由同一套数据库引擎来支撑。



数据库智能化+自动化管控平台


借助于机器学习、人工智能技术,希望能够与数据库内核进行结合,使得数据库能够更加自动化和智能化,实现自感知、自决策、自恢复和自优化。



新硬件: 软硬件一体化设计


未来,下一代的企业级数据库一定要结合软硬件一体化的设计理念,而不能把软件和硬件隔开,只有将软硬件结合在一起,才能把系统的优势发挥出来。



行存储 VS.列存储


TP 和 AP 的关键区别就是行存储和列存储,前者按照行将数据存储起来,其优点是能够高效简易访问一整条记录来处理更新,缺点是需要访问和读取不需要的数据信息;后者的优点是只需要读取所需数据,缺点是更新一条记录不同属性时需要多次访问。



HTAP:事务处理与分析处理一体化


HTAP 希望能够将行存和列存结合起来,在一套系统里面实现行列混存,但是这样也会遇到很多挑战,最核心的就是数据一致性的挑战。



云原生架构: 弹性 x 高可用 x 企业实践 x 开放生态


传统数据库架构采用单节点架构,其有点是部署和开发简单,缺点就是非常难于做弹性缩扩容。云原生架构是基于 RDMA 等网路实现分布式共享存储,使得上层应用看起来存储是一份,在上层实现存储与计算分离,使得存储和计算可以实现独立的缩扩容,这就带来了极致的弹性,也为云原生带来了很好的管理方式,如阿里云的 POLARDB、AWS 的 Aurora 等都是基于这样架构。



还有另外一种就是分布式架构,其对于数据库进行分库分片,其特点是水平扩展能力特别强,当数据量变大、并发量变高的时候只需要增加节点即可,其缺点是如果要求不改动上层业务逻辑,就必须要有能力去处理分布式事务和分布式查询,典型的代表有蚂蚁的 OceanBase、阿里的 POLARDB-X、ADB、TDSQL 等。


下一代企业级数据库:云原生+分布式+HTAP


下一代的企业级数据库架构应该是将云原生架构和分布式架构以及 HTAP 完美结合起来。上层是分库分表 Shared-Nothing 的架构,下层是存储与计算分离的云原生架构,这种架构的好处在于既能够水平扩展,又能够实现高可用的能力。而且面对高并发的情况时,所需要的分片数量会大大减小,因此分布式事务的复杂性也会大大降低。



分布式系统 CAP 理论


为了便于大家理解,这里为大家介绍一些分布式系统的理论,其中最核心的是 CAP 理论,即一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。解决上述问题存在不同的架构,包括单机单节点数据库架构、对数据进行分区分片、中间件架构,此外最好的方式就是一体化分布式,系统内部进行协调和处理并将最终结果返还给用户。



分布式数据库系统:高可用


这里涉及到高可用的问题,那就是分库分表之后数据库出现问题该怎么办。分布式高可用数据库可以通过数据一致性协议来确保分区数据一致性,业界提供了两个比较优秀的分布式数据一致性协议,即 Paxos 和 Raft。协议的内容大致就是分区进程一定可以对一个数据的取值达成一致,对一个数据的取值一定可以有一个可取值被提议,一旦分区进程对一个数据的取值达成一致,那么所有的分区进程最终都可以得到这个取值。


三、云数据库技术高速发展的现状

数据库技术与产品是完整的生态系统


本部分结合阿里巴巴的数据库产品进行介绍。阿里云数据库不仅在云上提供服务,还会支撑整个阿里巴巴集团内部经济体的所有活动。2019 年双 11,在零点刚过的第一秒,阿里的数据库系统峰值增长了大概 135 倍,瞬间爆发,这就需要数据库具有较高的可扩展性、弹性以及高可用。数据库技术与产品必须是一个完整的生态系统,因此需要 POLARDB、ADB 等工具来支撑。



云原生数据库:POLARDB


POLARDB 底层是基于 RDMA 的分布式共享存储,通过 Parallel Raft 协议在分布式共享存储里实现高可用,上层实现了多个计算节点,实现一写多读,因为底层看到的是一份逻辑数据,因此事务处理表现非常好,并且能够根据需求实现分钟级别的弹性缩扩容。此外,这种架构不涉及到分库分表的兼容性改造,因此能够供 100%兼容 MySQL、100%兼容 PG 和 Oracle 的版本。



POLARDB Box:高性能一体机


为了支持多种模式的数据库部署,阿里云在 2019 年也推出了一体机的产品解决方案。



POLARDB-X:分布式版本支持水平扩展+HTAP


阿里巴巴将 XDB 和 POLARDB 的能力以及 DRDS 的能力进行了融合,实现了分布式数据库 POLARDB-X。其上层就是 DRDS,主要做分布式的事务处理和查询处理,下面一层就是 POLARDB 层能够实现水平扩展和弹性扩展。POLARDB-X 的存储引擎使用了 X-Engine。



三节点金融级可用集群


在一个 AZ 里面想要实现三节点的金融级高可用,则使用 Raft 协议保证三副本之间的数据尺度一致,保证高可用、高可用以及性能。



两地多中心


跨 AZ 的部署存在较大的挑战,一般而言是在同城的三副本之间跑 AZ 的 Raft 协议,而跨城或者跨域则使用日志的同步技术实现,比如通过 DTS 实现,基本上就是通过解析 Binlog 的方式将源端的日志解析出来同步到远端再 Replay。



Big Data + Fast Data:将海量数据转化在线实时可用


目前业界的趋势是将大数据和 FastData 结合起来,也就是在线分析和交互计算在线化和实时化。



基于分布式集群的大数据计算与分析系统:由数据库系统演而来


无论是 MapReduce 还是 Spark 等大数据系统,其模式都是由数据库系统演进而来的,只不过 Spark 的处理都是在内存中进行的,这样可以大大降低系统的开销。



Spark SQL:大数据和数据库技术在快速融合


Spark SQL 是目前非常流行的使用 SQL 处理数据和分析的结构化模块,Spark SQL 的模式和数据库内核的模式非常相似,只不过是将 SQL 的输入转化为 Spark 的 Job 去执行。



大数据系统的核心:并行处理方式


基于 BSP 模型的大数据系统面临的最核心挑战就是并行处理时任务执行进度不一致而导致的同步问题,而现在希望大数据系统能够和数据库系统一样能够实现并行的同步。



基于 DAG 的调度和计划器


无论是数据库系统还是大数据系统,其调度方式都是基于 DAG 的调度和计划器。也就是将执行计划看做一个有向无环图,进行分组执行,每一轮执行完成之后进行同步,再进行到下一轮。



技术趋势:Serverless Storage + Serverless Compute


大数据和数据库系统正在进行融合,向着在线实时化发展。而在线实时化中最为核心的挑战就是要处理多个数据源和要进行 Serverless Computing。


四、阿里云数据库总结

智能化 OLAP:AnalyticDB 实时交互式数据仓库


举例而言,阿里云实现了智能化的 OLAP,实时交互式数据仓库 AnalyticDB,其也基于 BSP 模型,因此能够进行在线计算和分析处理。



AnalyticDB 的另外一个优势就是将非结构化数据、半结构化数据有效地和结构化数据联合处理,这是因为其具有向量化计算引擎,能够对于非结构化数据实现向量化,进而实现联合处理。


Data Lake Analytics-数据湖:全域数据,全局开放分析


数据湖其与数据仓库的相同点是都是为了解决异构分析处理的本质问题,但是数据仓库里面有自己的源数据管理和存储引擎,而数据湖只做了源数据管理,而没有存储引擎。数据湖只是去连接不同的数据源,而不是将数据转化到自己的存储引擎,这是数据库服务与 ADB 的本质区别。在阿里云等主流的数据湖内核中一般都会结合 Presto 或者 Spark 的内核来做交互式计算,并将计算结果提供给 BI 工具。因为其没有自己的存储引擎,因此非常适合于做 Serverless Computing 的架构。



企业级 NoSQL:非结构化和半结构化数据库套件


NoSQL 要支持非结构化与半结构化数据的处理,阿里云基于 Redis 实现了支持 KV 缓存的 Tair,处理文档数据的 MongoDB,处理时序时空的 TSDB(Time Series Database),处理图的 GDB(Graph DataBase),处理宽表的 Cassandra 等。总而言之,NoSQL 放弃了传统关系型数据库对 ACID 数据一致性的要求,换取了对非结构化、半结构化数据这种复杂数据水平拓展的能力。



企业数据管理功能矩阵


阿里巴巴的企业数据管理功能矩阵提供了面向研发、DBA、内审、运营决策的数据操作统一入口和业务报表服务。对于企业级数据库而言,存在安全管控、变更稳定、数据分析的需求,这里面涉及 SQL 任务执行引擎、逻辑库执行引擎、安全规则引擎、数据脱敏引擎等。



数据安全保障


阿里云上的数据库管理产品叫做 DMS,它除了提供上述服务,还提供了数据安全保障。从“审计”到“主动拦截”再到数据脱敏的整个流程都由 DMS 完成。DMS 内置了安全规则库、规则执行器以及动作 Action(类似 Trigger),这样当业务主系统出现问题时,数据不会丢失。



数据库备份 DBS


将备份数据变废为宝,对备份数据进行分析和查询甚至是 BI 的决策,这是现在 CDM 的趋势。



企业级云原生管控平台


管控平台的一个趋势,希望在公有云中提供“专有云”的能力。公有云管控虽然提供了实例管理的能力,但很多应用的时候需要自己去直接管理的能力。例如在公有云上能够拿到自己机房 root、admin 的权限,因此阿里云就做了大客户的专享集群,利用了云原生的管控能力如 K8S 的方式,能够尽可能的把管控透明化,把权限开放给客户和应用。



AI for DB- DAS: 智能化数据库管控与内核


在业界,大量集成智能化和机器学习成为管控的趋势。下图是阿里云管控的整体架构,它做了一个 SDDP(Self-Driving Database Platform),对每一个实例去采集性能数据(在用户许可的前提下采集访问一些用户的性能数据,非业务数据,如 CPU 使用率、磁盘使用率),进行建模分析,实时的进行监控。在这样的优化下,阿里云慢 SQL 的数量大幅度减少,内存的使用率大幅度提高。


数据安全


标准的云上数据安全包括传输过程、存储过程等,例如引用 TDE(Transparent Data Encryption)、Data at Rest Encryption。阿里云对数据安全的几个维度进行了总结:如加密的数据访问和存储、减小内部攻击风险、日志数据一致性的可验证(例如结合区块链技术把数据和日志让用户做一致性的验证)等。



全程加密数据永不泄露


数据进入内核以后也是进行加密的,不需要解密,加密使用的是客户的密钥,其他人不可见。这样确保了即使在内部攻击的情况下,整个数据过程也是完全保密的。



Oracle 迁移-数据库及应用迁移改造 ADAM


把 Oracle 现有的数据迁移到云上,是一个从评估到决策、实施、优化的过程。使用自动化工具 ADAM,能够通过自动化生成报表来告诉用户从 Oracle 迁移到目标数据库哪些应用是兼容的,哪些应用是不兼容的,这使做应用迁移决定的时候有一个清晰明了的过程,知道迁移改造的成本。



ADAM - ORACLE 迁移全链路解决方案


有了如下流程体系:使用 ADAM 这种自动迁移评估工具去做应用兼容性、一致性的评估,之后做评估改造,再用 DTS 把数据库迁移到不同的目标库,这样就形成了一个标准化、流程化、产品化的 Oracle 迁移方案。



Oracle 迁移的科学方案选型


建议中小型业务系统要选择与 Oracle 高度兼容的目标库进行迁移,例如 PolarDB。大型核心系统将来的发展方式很有可能是类似分布式的架构,分析型可以选择 AnalyticDB,事务型可以选择 PolarDB-X 分布式。



阿里云数据库总结


目前,阿里云在亚太市场排名第一,全球市场排名第三。从营收来讲,在全球市场仅仅落后于亚马逊和微软,在云数据库的市场上已经超过了许多传统型数据库,如 Oracle、Google 这种非常强劲的竞争对手。


应用案例


最后介绍一些基于阿里云的产品和技术做的一些解决方案和应用案例。首先阿里巴巴的数据库产品支撑了阿里巴巴集团内部所有复杂的业务,外部业务支撑了从国家重点项目的云上商业系统的应用,例如从制造业到国际客户、零售、金融、互娱。


阿里巴巴数据库应用的具体案例包括,帮助某东部银行基于 PolarDB 分布式版本快速构建新型业务与小微业务的互联网架构;帮助中国的某第三方跨境支付平台基于 PolarDB 分布式版构建高并发、低延时的支付系统,同时使用 DTS、DLA 做异构多元数据处理以及实时数据同步;使用 AnalyticDB 替换传统的“Sysbase IQ + Hadoop”解决方案,帮助某核心券商实现金融加速分析平台。


阿里巴巴还帮助天弘基金基于 AnalyticDB 构建了承载了 500TB 数据量和 1 亿用户的实时查询计算平台;帮助南区最大的银行之一构建基于 DTS 的“异地容灾”;帮助中国邮政利用 AnalyticDB 实现全国 10 万多机构寄报表平台;利用云原生的数据库技术帮助银泰百货改造数据库系统,实现了弹性高可用,使其能够支撑大促 20 倍峰值,并将成本减少 60%以上;

总结

数据库的未来发展趋势可以总结为以下四点:


产品架构与技术创新:云原生 + 分布式 (弹性、高可用)。架构上分布式共享存储、存储计算分离,云原生架构+Shared Nothing 分布式架构,满足弹性、高可用、水平拓展的能力。


数据挑战:多模,结构化与非结构化数据 (多源异构数据)。结构化与非结构化数据如何融合异构处理,比如数据湖的概念、ADB 里面用向量处理引擎把非结构化数据变成结构化数据,高维向量、多源异构数据处理的技术。


数据处理与分析:海量数据分析在线化 (实时在线交互式分析)。如何对海量数据进行在线分析和计算,支持实时在线交互式分析,需要做并行处理(DSP 模型、MPP 模型等等),对并行调度计算进行优化。


系统能力提升:智能化 + 安全 (使用方便可靠、运维简易)。如在管控平台的层面如何做智能化的调度、监控以及自动修复,怎样去做数据的安全处理、隐私保护、加密处理等等,使得整个数据库的使用更加方便可靠、运维简易。



数据库上云/迁移是一个生态,而不是一个项目。回顾一下本文分享的所有技术,数据同步与传输技术来做数据库的同步迁移,需要分布式云原生的系统来做弹性高可用,也需要 NoSQL 做图、时序/时空等非结构化数据的处理,同时需要数据同步/分发到分析系统里面做实时计算分析,还要备份、混合云的管理,以及针对企业数据库研发的 DevOps 开发流程管理套件。总而言之,只有完整的生态体系才能支撑中国的数据库市场快速发展以及走向全球。


本文转载自公众号阿里技术(ID:ali_tech)。


原文链接


https://mp.weixin.qq.com/s/mmT7OaTucduD9B_m-yMZOQ


2020-03-05 10:205046

评论 1 条评论

发布
用户头像
原来是阿里李飞飞,我说怎么跑去做数据库了呢
2020-03-06 14:56
回复
没有更多了
发现更多内容

每周学习总结 - 架构师培训2期

Damon

架构师之路-UML 入门

闻人

学习 架构设计 极客大学架构师训练营 架构总结

ARTS 打卡(20.06.08-20.06.14)

小王同学

从车辆工程转行程序员两年,我是这么走过来的

WB

程序员 汽车电子

实践Java如何创建安全的线程池

tingye

多线程 线程池 「Java 25周年」

【荒于嬉】事务的特性及隔离级别

luojiahu

事务

ARTS打卡 第1周

Scotty

ARTS 打卡计划

【架构师训练营-周总结-2】

小动物

总结 极客大学架构师训练营

极客时间 - 架构师培训 -2 期作业

Damon

「架构师训练营」第2周作业

Amy

极客大学架构师训练营 作业

软件设计原则作业

Mr.Monkey

《微服务设计》读后感

w0807m

微服务

第二课作业

首次披露我和知识星球老吴的一段对话

池建强

产品思维 产品定位 知识星球

设计模式原则思考

张瑞浩

架构师训练营作业(第二周)

默默

极客大学架构师训练营

架构师训练营-第一周作业1-食堂就餐卡系统设计

清风徐徐

极客大学架构师训练营 UML

架构师训练营第二周学习总结

张明森

架构师训练营-第一周学习总结

清风徐徐

依赖倒置原则

elfkingw

架构师训练营-学习笔记-第二周

心在飞

极客大学架构师训练营

如何优雅的理解HBase和BigTable

Rayjun

Java HBase

数据科学的门槛将提高,架构设计UML,John 易筋 ARTS打卡Week 04

John(易筋)

架构设计 ARTS 打卡计划 ARTS活动 arts

学习总结

Mr.Monkey

架构学习总结 - 1 - 软件设计原则

Chasedreamer

架构师训练营第二章作业

张明森

ARTS_20200_week1

不在调上

ARTS 打卡计划

框架设计原则

gitlab-runner 安装

dudu

面向对象设计原则

elfkingw

极客大学架构师训练营

架构师训练营 - 第二周 - 学习总结

stardust20

李飞飞:如何看待数据库的未来?_云原生_李飞飞_InfoQ精选文章