Sql

背景在咱们的日常开发中，咱们肯定会接触到的一种数据就是分层数据。哪些是分层数据呢？业务组织结构图，内容治理类别，RBAC权限治理，产品类别等等，这些都是分层数据，以下是一个电子商店的产品类别层次结构： 在本文中，咱们将钻研在 MySQL 中解决分层数据的两种模型，从传统的邻接表模型开始。 邻接表模型通常，下面显示的示例类别将存储在如下表中（我把 CREATE 和 INSERT 语句都写下来，你能够跟着运行）： CREATE TABLE category( category_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(20) NOT NULL, parent INT DEFAULT NULL);INSERT INTO category VALUES(1,'ELECTRONICS',NULL),(2,'TELEVISIONS',1),(3,'TUBE',2), (4,'LCD',2),(5,'PLASMA',2),(6,'PORTABLE ELECTRONICS',1),(7,'MP3 PLAYERS',6),(8,'FLASH',7), (9,'CD PLAYERS',6),(10,'2 WAY RADIOS',6);SELECT * FROM category ORDER BY category_id;+-------------+----------------------+--------+| category_id | name | parent |+-------------+----------------------+--------+| 1 | ELECTRONICS | NULL || 2 | TELEVISIONS | 1 || 3 | TUBE | 2 || 4 | LCD | 2 || 5 | PLASMA | 2 || 6 | PORTABLE ELECTRONICS | 1 || 7 | MP3 PLAYERS | 6 || 8 | FLASH | 7 || 9 | CD PLAYERS | 6 || 10 | 2 WAY RADIOS | 6 |+-------------+----------------------+--------+10 rows in set (0.00 sec)在邻接表模型中，表中的每一项都蕴含一个指向其父项的指针。最下面的元素，在本例中是 ELECTRONICS ，其父元素是 NULL 值。邻接表模型的长处是比较简单，很容易看出 FLASH 是 MP3 PLAYERS 的子级，PORTABLE ELECTRONICS 的子级，ELECTRONICS 的子级。毛病也很显著，咱们要查某个节点的所有下级或者是所有上级都是要递归的去查问的。如果某个业务场景下，分层的层数减少到很多并且叶子节点也在增多，那咱们的查问就会变的很慢。这种咱们也是能够优化的，就是将每个叶子节点之间的门路存储下来。然而这种办法会减少数据的存储量。那么有什么方法是能够的将咱们的整个数存储在关系型数据库中的呢。\ ...

根本语法 // 查问语句，select * from 表名称，示意选取所有列SELECT 列名称 FROM 表名称SELECT * from websites // 关键词 DISTINCT 用于返回惟一不同的值。SELECT DISTINCT 列名称 FROM 表名称// 有条件的选取数据SELECT 列名称 FROM 表名称 WHERE 列 运算符 值// AND 和 OR 运算符，能够在where子语句中把多个条件连接起来SELECT * FROM Test WHERE cond1='A' AND cond2='B'SELECT * FROM Test WHERE cond1='A' OR cond2='B'// 依据指定的列对后果集进行排序，ORDER BYSELECT Company, OrderNumber FROM Orders ORDER BY CompanySELECT Company, OrderNumber FROM Orders ORDER BY Company DESC // 降序SELECT Company, OrderNumber FROM Orders ORDER BY Company ASC // 升序// INSERT INTO，向表格中插入新的行INSERT INTO 表名称 VALUES (值1, 值2,....)INSERT INTO table_name (列1, 列2,...) VALUES (值1, 值2,....) // 指定插入数据的列// UPDATE，批改表中的数据,更新UPDATE 表名称 SET 列名称 = 新值 WHERE 列名称 = 某值// DELETE，删除表中的行DELETE FROM 表名称 WHERE 列名称 = 值DELETE * FROM table_name // 删除所有行重要指令SELECT - 从数据库中提取数据UPDATE - 更新数据库中的数据DELETE - 从数据库中删除数据INSERT INTO - 向数据库中插入新数据CREATE DATABASE - 创立新数据库ALTER DATABASE - 批改数据库CREATE TABLE - 创立新表ALTER TABLE - 变更（扭转）数据库表DROP TABLE - 删除表CREATE INDEX - 创立索引（搜寻键）DROP INDEX - 删除索引WHERE 子句用于提取那些满足指定条件的记录。 ...

装置过程装置PostgreSQL 装置PostgreSQL 9.6时，会报错An error occred executing the Microsoft VC++ runtime installer解决办法：进入CMD，找到安装文件的目录，运行postgresql-9.6.24-1-windows-x64 --install_runtimes 0

家喻户晓，执行器执行之前，须要打算的撑持。打算分为逻辑打算和物理打算。他们的关系就好比是咱们要进来游览，抉择什么交通工具就相当于逻辑打算，在这一步比方抉择了飞机后，抉择哪家航空公司就相当于物理打算。最初，当你真正出发去游览就相当于执行。上面给出SQL语句执行的根本构架图，从中能够分明地看到优化器和执行器在整个流程中的执行过程。 优化器 逻辑打算和物理打算负责生成执行打算和索引抉择等性能，能够把它看做优化器。比方执行这样的语句，执行两个表的join： Select * from t1 join t2 using(ID) where t1.c = 10 and t2.d = 20既能够先从t1里取出c=10记录的ID，再依据ID关联到t2,再判断t2外面d的值是否等于20，也能够先从t2里取出c=20记录的ID，再依据ID关联到t1，再判断t2外面d的值是否等于10。这两种执行办法的逻辑是一样的，但执行效率不同，优化器能够预估代价决定应用计划。在分布式数据库中，其中的物理打算还能够依据要用到的数据span所在的节点判断该算子在哪个节点上执行，从而实现分布式执行。与分布式相干的物理打算具体作用在分布式执行概述。 分布式执行 分布式执行的要害思维是如何从逻辑执行打算到物理执行打算，这里次要波及两方面的解决，一个是计算的分布式解决，一个是数据的分布式解决。 一旦生成了物理打算，零碎就须要将其拆分并散布到各个node之间进行运行。每个node负责本地调度processors 和 inputs。node还须要可能彼此通信以将输入output router连贯到input。特地是，须要一个streaming interface来连贯这些组件。为了防止额定的同步老本，须要足够灵便的执行环境以满足下面的所有这些操作，以便不同的node除了执行打算初始的调度之外，能够绝对独立的启动相应的数据处理工作，而不会受到gateway节点的其余编排影响。 数据库的集群中的Gateway node会创立一个调度器，它承受一组flow，设置输出和输入相干的信息，创立本地processor并开始执行。在node对输出和输入数据进行解决的时候，咱们须要对flow进行一些管制，通过这种管制，咱们能够回绝request中的某些申请。 每个Flow示意整个物理打算中跨节点执行的一个残缺片段，由processors和streams组成，能够实现该片段的数据拉取、数据计算解决和最终得数据输入。如下图所示： 对于跨节点得执行，Gateway node首先会序列化对应得FlowSpec为SetupFlowRequest，并通过GRPC发送到远端node，远端node接管后，会先还原Flow，并创立其蕴含得processor和交互应用得stream（TCP通道），实现执行框架得搭建，之后开始由网关节点发动驱动得多节点计算。Flow之间通过box缓存池进行异步调度，实现整个分布式框架得并行执行。 对于本地执行，就是并行执行，每个processor，synchronizer和router都能够作为goroutine运行，它们之间由channel互联。这些channel能够缓冲信道以使生产者和消费者同步。 为实现分布式并发执行，数据库在执行时引入了Router的概念，对于JOIN和AGGREGATOR等简单算子依据数据分布特色，实现了三种数据再散布形式，mirror_router、hash_router和range_router，通过数据再散布实现processor算子外部拆分为两阶段执行，第一阶段在数据所在节点做局部数据的解决，解决后后果，依据算子类型会进行再散布后，第二阶段会集解决，从而实现了单个算子多节点合作执行。

因为公司我的项目起因，在生产我的项目中用到了SQL语句，只管只是一些简略的查问语句，也算是本人前端生涯的技能拓展，所以专门对于SQL语句，作了一些根底练习。网上学习SQL语句教程十分的多，学习材料百度即可。作为一个SQL菜鸟，在这里分享，是为了坚固学习，心愿能够帮忙到大家。 SQL根底SQL 是用于拜访和解决数据库的规范的计算机语言。目前我接触的数据库有：MySQL、PostgreSQL、MongoDB，前两个是关系型数据库，后一个是非关系型数据库。它们给我的直观区别是：关系型反对SQL语句，非关系型不反对。MySQL、PostgreSQL都是反对SQL语句的，这里须要一点前提常识。 数据库: 数据库是一些关联表的汇合数据表: 表是数据的矩阵。在一个数据库中的表看起来像一个简略的电子表格列: 一列(数据元素) 蕴含了雷同类型的数据, 例如邮政编码的数据行：一行（=元组，或记录）是一组相干的数据，例如一条用户订阅的数据主键：主键是惟一的。一个数据表中只能蕴含一个主键。你能够应用主键来查问数据，例如idSQL查问1. 如何进行数据表的查问？// 获取数据表中具体那几列的数据select column_name1, column_name2 from PERSONS// 获取数据表全副的数据，*示意所有select * from PERSONS这个的PERSONS就是数据表，column_name1、column_name2列的名称。 2. 如何进行数据表的过滤查问？// 查问合乎 name为liuheng 的数据select * from PERSONS where name='liuheng';// 查问合乎 name为liuheng和liuheng1 的数据select * from PERSONS where name='liuheng' and name='liuheng1';// 查问合乎 age大于20 的数据select * from PERSONS where age > 20;// 查问合乎 age等于20，30 的数据select * from PERSONS where age in (20, 30);// 查问合乎 name首字母为'l' 的数据select * from PERSONS where name like 'l%';// 查问合乎 name尾字母为'1' 的数据select * from PERSONS where name like '%1';where 子句用于提取那些满足指定条件的记录。like 操作符用于在 WHERE 子句中搜寻列中的指定模式。in 操作符容许在 WHERE 子句中规定多个值。 ...

Checkpoint 定义 抛开官网定义从咱们对数据库系统了解来看，批改数据个别是在缓存进行批改，数据库会有专用后盾 Backend 过程负责定时将脏块刷入磁盘，进行一个长久化。PG 的 Checkpoint 也是相似，官网文档对 Checkpoint 的定义，首先 Checkpoint 是一个程序的事物记录点，同 Checkpoint 这个工夫之前所有的 heap，以及索引文件批改都被认为是无效的。 在 Checkpoint 执行时，所有脏数据会被刷到磁盘，并记录一个非凡的切换记录到 Wal 日志里，当然这个数据批改是在 WAL 日志之后，也就是说是日志后行，也叫预写式日志。Checkpoint 还有一个作用，在 Crash 后或者重启须要 REDO 时，会依据 Checkpoint 记录去复原到对应工夫点。 这是 Checkpoint 作用的一个体现。从其它信息能够看到在 Checkpoint 之后，这时会把所有的数据做长久化到磁盘上，同时还会清理一些数据库认为不再须要的 Wal 日志，而在运维过程中要特地留神这个点，因为某些异样会导致 wal 累积；wal 的清理是一个清理加回收的机制。 简略来说 Checkpoint 是事务程序记录点，次要进行刷脏页，redo 时会参考 Checkpoint 进行日志回放，此外还会清理不须要的 Wal 日志。 Checkpoint 触发条件 接下来看 Checkpoint 触发条件。在 PostgreSQL 中 Checkpoint 是由 Checkpointer 过程来执行的。Checkpoint 过程的主流程是无条件 for 循环，在未触发 Checkpoint 时，始终在 Waitlatch 中 Sleep，也就是在 Epoll_wait 中察看 List 链表，看是否有事件句柄曾经就绪。 ...

逻辑复制概念 逻辑复制是 PG 数据库基于数据对象的复制标记，也就是 Replica Identity 来复制数据对象及数据变动的办法。它最后是在 2014 年 12 月份的 PG9.4.0 引入，称为逻辑解码，起初在 2017 年 10 月 PG10.0 版本中又引入了基于公布订阅的逻辑复制概念。之所以称为逻辑复制是为了和更早引入的物理复制加以辨别。逻辑复制法则和物理复制这两种复制机制有比拟大的区别，物理复制是应用精确的块地质陈迹逐字节的复制形式，而逻辑复制则容许在数据层面复制，并在安全性上提供更细粒度的管制。 逻辑复制性能演进大抵分为两个比拟大的阶段，第一阶段是 2014 年 12 月份，随着 9.4.0 版本公布，PG 为 DML 带来数据批改流动到内部提供基础设施，用户能够基于它实现复制解决方案和审计等目标。数据批改以流的模式收回，通过逻辑复制槽 Replication Slot 来辨认，配合解码插件 Decoding Plugin，实现每一份数据批改在每一个流中输入。 同时 PG 基于 WAL 日志作为原始输入，Slot 保障数据流的唯一性，Decoder 插件赋予用户自定义输入能力，来做到将 PG 实例的数据变动流动到内部。第二阶段是 2017 年 10 月 4.0 版本的公布，PG 逻辑复制提供了公布和订阅模型，外部和订阅能够是多对多关系，例如容许有一个或多个订阅者来订阅同一个实例上多个公布。订阅者与发布者雷同程序，利用数据变更实现在同一个订阅中保障公布事务的一致性，这种数据复制形式有时候被称为事务性复制。 数据迁徙的利用场景及宏观的技术架构 上面介绍迁徙的利用场景跟宏观的技术架构。数据迁徙产品对云上的数据库，私有云数据库是一个避不开的话题，也是用户数据上云的一个入口。云上数据迁徙产品可能帮客户在利用不停服前提下轻松实现数据迁徙上云，利用实时同步通道轻松构建高可用数据库容灾架构，通过数据订阅来满足商业数据挖掘、利用异步解耦等场景需要。 多个起源数据库要通过迁徙产品将数据转移到云上，包含 IDC 自建、其余云厂商、腾讯云本人的数据库及 CVM 自建等。为了稳固牢靠不便地实现用户迁云同步订阅需要，咱们定下了一致性、高性能、高可用的架构设计指标，在数据库类型上有多款数据库，不仅要实现同构迁徙，还要实现异构数据库迁徙，这是一个整体的数据迁徙利用场景。 插入 PPT 图片 迁徙场景总的技术架构，首先产品要具备向用户提供 API 和管制页面能力，就像这张图的最上层，其次是通过插件式的热加载，实现不同链路迁徙利用疾速接入，比如刚刚说的既有同构，也有异构。同构有多种数据库类型，异构同样有多种数据库类型，而且是 N×N 的链路组合。 看一下两头局部，工作执行平台，它不仅可能提供任务调度能力，还将组件高可用、监控告警、工作编排、运维零碎等纳入其中，做到了对前台高可用高牢靠，对后盾好运维、好接入的指标。图正下方这个区域，Node Server 是具体执行迁徙节点，能够把它看成是干事，具体干迁徙这件事件的一个节点或过程，它不仅可能疾速扩容，还可能动静负载平衡，实现全量和增量、并列、同步等工作。这个技术架构反对了腾讯云所有数据库类型的迁徙利用。 接下来回到 PG 逻辑复制，重点介绍逻辑复制外部的概念和原理。首先是比拟根底但又比拟重要的概念，复制标识是一个感知属性，它是用来管制表中记录被更新或改删除时写入 WAL 的内容，这个属性它只用于逻辑复制，并只能够通过 ALTER LABLE 来进行批改。同时须要留神的是，表中记录至多有一个列值发生变化了才会产生批改记录。感知属性有四个可感知，别离是 DEFAUTL、USINGINDEX、FULL、NOTHING，其中 FULL 和 NOTHING 这两个值比拟好了解，FULL 是指当记录变更时写入 WAL 日志的内容将包含所有字段原始值和所有字段的旧值。 ...

TDSQL-A 倒退历程 TDSQL-A 是一款基于 PostgreSQL 自主研发的分布式在线关系型数据库。是一个面向海量数据实时在线剖析产品，采纳无共享 MPP 构架。面向剖析型场景的极致性能优化，咱们自研了列式存储，同时也反对行列混合存储模式。在数据转发层面上，针对大规模集群面临的连贯风暴问题对集群执行/转发框架做了更深刻优化，来保障能够反对超过千台规模的集群能力。同时为减速用户在数据挖掘或剖析场景上的时延，通过多种计算能力优化来达到给用户提供更好成果。 在多年的倒退过程中 TDSQL-A 依靠腾讯外部业务进行充沛打磨，在外部业务及内部企业级用户场景下都有良好体现，并在 2021 年 5 月 18 日上线腾讯云。 TDSQL-A 整体构架 首先整体介绍 TDSQL-A 架构。TDSQL-A 是一个多 CN 入口的 MPP 分布式集群设计，CN 节点作为业务拜访入口，每个节点是对等的，对外提供统一的用户元数据和视图拜访，同时也能够通过多入口分担用户高并发压力场景下的连贯解决。 因为是一个多 CN 入口，须要一个全局事务管理器 GTM 节点，进行全局事务管理以及 Sequence 等全局统一能力的解决节点。晚期 GTM 在高并发状况下获取全局事务快照会有性能瓶颈，TDSQL PG 版以及 TDSQL-A 都针对分布式提交协定做了基于 timestamp 的革新，解决了全局事务快照的单点瓶颈问题。TDSQL-A 整体不论是行存和列存事务提交，整体的提交协定都基于 timestamp（GTS）协定，提供业界当先的高并发能力反对。 数据存储和计算节点咱们称为 Datenode，Datenode 节点通过 TDSQL-A 构架优化，反对超过 1000 个节点以上的集群部署，反对 10PB 级别以上的用户数据量。同时在计算时，会尽可能把所有计算都通过智能的优化器布局推到 DN 节点上做计算。 TDSQL-A 整体构建演进。因为用户数据量继续增大，须要面临最大挑战是在大规模集群下大数据访问量和简单查问场景。例如 TPC-DS 这类简单的用户场景，它的 query 是带有简单的子查问场景及 with 语句的。在这种状况下多表关联会比拟多，在分布式系统下会有多层重散布。 依照之前晚期构架，在执行时碰到 RemoteSubplan 算子的时候才会往下发整体的下一步查问打算，如果查问中重散布的档次比拟多，每一层 DN 都会认为本人是一个发起者，会导致大量多层过程连贯和网络连接耗费。 ...

TDSQL-C PG 版产品简介 TDSQL-C PG 版是一款基于计算、存储拆散的云原生数据库产品。相比于传统的 PG，咱们将 PG 数据库集群分为计算节点和存储节点两局部来进行独立的治理和部署。其中在计算节点方面，一个集群内所有计算节点会共用同一份近程数据存储，主备之间日志只会用于更新缓存，从而解脱传统 PG 下主备日志同步时影响集群可用性的问题。 在存储方面，TDSQL-C PG 版独立部署的存储服务以 Segment Group 为根本单元来治理数据库对应的数据存储，一个集群下的数据会拆分到多个 Segment Group，Group 中的 Segment 又能够散布到多个不同存储服务上进行治理，从而实现通过扩大存储服务来实现数据库存储空间扩大，解脱传统 PG 数据库在存储数据容量上受限于单机磁盘空间大小的问题。 另外，在数据库备份回档性能上也是拆分到 Segment Group 维度上来实现，Segment Group 能够并发进行备份和数据回档，从而极大的缩短数据库备份回档耗时。 TDSQL-C PG 版高可用性能改良 基于上述架构在产品个性上，咱们的近程存储应用多正本机制解决了数据可靠性问题，同时计算节点互相不依赖日志同步，从而解决了可用性问题，最终达到可靠性和可用性兼顾成果。在应用老本上，一个集群下不论多少个实例，都是共用同一份存储，并且依照存储理论使用量免费。相比于惯例主备集群下每个实例都须要独自占用存储空间，咱们极大的升高了集群的应用老本。 在最大存储数据量上，存储服务能够实现独自程度扩大，从而使整个集群数据存储量失去大幅度晋升。另外，在数据库集群计算能力扩大上，新增备实例都无需同步数据，能够实现秒级疾速扩大。最初，在数据库的回档操作中，咱们是基于 Segment Group 并行回档，能够将回档速度能够晋升到 GB 每秒。 基于此产品架构，咱们在高可用方面又有哪些相应改良？ 咱们先看看在惯例主备模式下的常见高可用计划。在惯例主备模式下，主备都是通过数据流复制形式来实现数据同步，其中同步数据流复制模式下，主实例的每一次提交都要等到备实例实现日志落盘之后才可能返回，这样才可能强行保障主备数据一致性。但同样也带来了，备实例异样时，会影响主实例可用性的问题。而在异步数据流复制模式下，主实例是能够不放心备实例的日志落盘状况。这样尽管能够防止可用性问题，但也会造成主备实例数据的一致性问题。 基于此，咱们会应用额定的 Warm Standby，和主实例之间放弃同步数据流复制。同时咱们的 Warm Standby 不会对外提供服务，尽量减少 Warm Standby 实例影响主实例的状况产生，而其余提供对外服务的备实例则通过异步数据流复制形式来实现和主实例数据同步。当主实例出现异常时，能够应用和主实例保持数据强统一的 Warm Standby 实例来进行备提主，疾速复原主实例可用性。之后咱们会再异步进行 Warm Standby 实例重建，最终将整个集群复原成失常状态。这种解决流程尽管尽可能保障了可用性，但依然存在一些问题是没有方法解决的，例如 Warm Standby 实例尽管没有提供对外服务，但还是可能会存在比方机器、网络等硬件故障导致不可用的危险，从而影响主实例的可用性。 另外，Warm Standby 实例重建也须要工夫，当其没有实现重建时，如果新的主实例再次出现异常，就没方法疾速复原可用性。除此之外，一个不提供对外服务的 Warm Standby 实例也要占用资源，所以必不可少会带来多余的老本开销。 那么在 TDSQL-C PG 版计算存储拆散架构下，这个问题是否有更好解决形式？得益于咱们做了计算存储拆散，主备实例会应用同一份远端存储数据，它们之间不存在数据同步的前置依赖。而在数据可靠性方面，咱们交由独自存储服务来实现。当在主实例上进行数据写入时，咱们会把日志发给存储服务，存储服务实现日志落盘后，就能够返回响应给客户端，同时存储服务再本人以异步日志回放形式去更新磁盘数据，而备实例接管主实例日志只用于更新缓存，在异样时也能够间接应用远端存储服务数据。这样下来主备之间就没有数据同步依赖，从而也就不存在备实例异样影响主实例状况。 ...

在详解 PostgreSQL 执行打算之前，须要先晓得执行打算由来。咱们 PostgreSQL 数据库任何查问都会通过语法和语义解析，生成查问表达式树，也就是罕用查问数，解析器它会去解析咱们的语法，分析器会把语法对应对象进行开展，通过重写器对规定进行重写，最初生成查问数。 依据查问树执行器通过查问再进行预处理，找出最小代价门路，最终创立出打算树。再把查问打算交由执行器进行执行。最终执行实现它会把后果返回给前端利用。这些操作都是在每个连贯对应 Backend 过程去进行解决。执行器在执行时，会去拜访共享内存，内存没有数据，则从磁盘读取。最终将查问的后果缓存在数据库中，逐渐输入给用户过程。 过程会波及到例如 Work memory、temp buffer 等过程级内存，能够通过咱们的 Explain 命令来查看执行打算，对不合理的资源进行调整，进步 SQL 执行效率。在 SQL 后面加上 Explain，就能够间接看到执行打算。不论是在 pgadmin 还是其它工具都能够简略进行查看，也能够通过咱们的 psql 去查看。 咱们的执行打算有几个特点，首先查问布局是以布局为节点的树形构造，以查问的一些门路作为树形构造，树最底层节点是扫描节点，它是去扫描表中原始行数。不同表也有不同扫描类型，比方程序扫描或索引扫描、位图索引扫描。也有非表列源，比如说 Values 子句。还有查问，可能须要关联、聚合、排序以便操作，同时也会在扫描节点上减少节点进行操作提醒以及耗费。Expain 输入总是以每个树节点显示一行，内容是根本节点类型和执行节点的耗费评估。可能会呈现同级别节点，从汇总行节点缩进显示其它属性。第一行个别都是咱们汇总的耗费，这个值是越小越好。 在看一个执行打算，咱们创立一个测试表，插入 1 万条数据做剖析后，能够看到它的执行打算，这个执行打算很简略，全面扫描它只有一行。执行打算咱们从左到右去看，先是评估开始的耗费，这里因为没有别的步骤，所以这个步骤是从 0 开始，而后是一个总耗费评估。 Rows 是输入的行数，它是一个评估后果；而后是每一行的均匀字节数，这是一个评估后果，这个评估后果依赖于 pg_stats 和 pg_statistic 统计信息。 那么咱们怎么去看执行打算呢？就是下级节点的耗费，其中蕴含了其子节点的耗费，这个耗费值反映在布局器评估这个操作须要的代价。个别这个耗费不包含将数据传输到客户端，只是在数据库后盾的执行代价。评估的行数不是执行和扫描节点查问的节点数量，而是返回的数量。同时耗费它不是一个秒的，它是咱们布局器的一个参数。Cost 是形容一个执行打算代价是多少，而不是具体工夫。 代价评估的一些基准值个别会关注哪几个参数呢？seq_page_cost，即扫描一个块须要的耗费，咱们默认为是 1，而随机扫描 random_page 咱们默认为是 4，这个在优化的环节须要进行优化，比如说当初应用 SSD，随机页的拜访效率必定比其它的磁盘更快，而这里值就能够改为 1。另外就是 cpu_tuple_cost，咱们 CPU 去扫描一个块里具体行数，一行大略 0.01 的耗费。索引是 cpu_index_tuple_cost，0.005 的耗费。 举个例子，新建 Test 表有一万行，它调配了 94 个页。而依据刚刚执行打算能够大略估算耗费：磁盘页乘程序扫描的 Cost，加上扫描行数。这个值就是 94 个页乘以 1，加上 1 万行乘以 0.01 的耗费就是 194。 ...

TPC与TPC-H 介绍据TPC官网（http://tpc.org）介绍，TPC是一家非盈利公司，专一于开发以数据为核心的基准规范，并向行业流传主观、可验证的数据。TPC公布的被业界宽泛承受应用的测试基准有TPC-C 、TPC-H、TPC-DS等，TPC-C是针对OLTP的测试基准，TPC-H和TPC-DS则通常是针对OLAP的测试基准。 TPC-H是一个决策反对基准（Decision Support Benchmark），它由一套面向业务的特地查问和并发数据批改组成。查问和填充数据库的数据具备宽泛的行业相关性。这个基准测试演示了查看大量数据、执行高度简单的查问并答复要害业务问题的决策支持系统。TPC-H报告的性能指标称为TPC-H每小时复合查问性能指标(QphH@Size)，反映了零碎解决查问能力的多个方面。这些方面包含执行查问时所抉择的数据库大小，由单个流提交查问时的查询处理能力，以及由多个并发用户提交查问时的查问吞吐量。 在2021年2月18日，TPC-H 标准规范公布了V3版本，下载链接：http://tpc.org/tpc_documents_... TPC-H 表构造与关系TPC-H 测试规范模仿了一个零部件在线销售的零碎，共定义了8个表： REGION 区域表NATION 国家表SUPPLIER 供应商表PART 零部件表PARTSUPP 零部件供给表CUSTOMER 客户表ORDERS 订单表LINEITEM 订单明细表各表的构造、数据量和相互之间的关系如下图，其中表名前面的括号内是该表的列名前缀，箭头指向为表之间一对多关系的方向，表名下方的数字或者公式是表的基数（行数）。 LINEITEM表中的基数是近似值，基数中的sf是比例因子，用于生成不同数据规模的数据集，sf必须从下列固定值中抉择：1/10/30/100/1000/3000/10000，相当于1GB/10GB/30GB/100GB/1TB/3TB/1PB。 关注公众号大数据研学社：BigDataRLC，第一工夫看最新文章。 TPC-H 查问SQL语句Q1：定价汇总报表查问定价汇总报表查问是分组、排序、汇集操作并存的单表查问操作，报告已开票、发货和退回的业务量； 为给定日期发货的所有订单项提供汇总定价报告，按l_returnflag和l_linestatus分组并排序，列出了扩大价格、折扣扩大价格、折扣扩大价格加税、均匀数量、均匀扩大价格、均匀折扣、各个分组的总行数。 select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice*(1-l_discount)) as sum_disc_price, sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_orderfrom lineitemwhere l_shipdate <= date '1998-12-01' - interval '[DELTA]' day (3) //DELTA是60~120内的值group by l_returnflag, l_linestatus order by l_returnflag, l_linestatus;Q2：最低老本供应商查问最低老本供应商查问是带有排序、汇集操作、子查问并存的多表查问操作，查找应该抉择那个供应商来为给定地区的给定整机下订单；在给定的区域中，针对特定类型和尺寸的每个整机，找到可能以最低老本供给的供应商。如果该地区的多个供应商以雷同的（最低）老本供货。查问列出了供应商的账户余额、名称和国家，零部件编号、制造商，供应商的地址、电话号码和评论信息。 ...

TDSQL-C PG 版整体架构 在介绍整体架构前，先说一下为什么咱们要做 TDSQL-C 这款产品。在传统数据库上，数据库的应用是存在一些问题，次要分为以下四个： 第一是资源利用率低，计算和存储在一台机器上，CPU 和磁盘应用不平衡，例如 CPU 用满，但磁盘很闲暇或者 CPU 很闲暇但磁盘又满了，这样就会导致资源利用率低。 第二是扩大能力有余，在单排上可能不能满足一些用户要求，无奈扩大。 第三是资源布局难，例如用户应用数据库，一开始无奈预估这个数据库须要多少次磁盘空间。 第四是备份比拟艰难，因为每一个实例数据是公有的，所以每个实例都须要独自进行备份。 TDSQL-C 的解决思路： 第一个问题是计算存储拆散，计算资源能够弹性调度。例如说可能给用户调配一个 4 核 8G 存储资源，一段时间当前会发现这个无奈满足他要求，那能够给它调配一个更高规格实例。比如说 16 核 32G 这样一个实例，这个是做计算资源升配。第二个问题是日志下沉以及异步回放，TDSQL-C 的日志是通过网络，从计算层下放到存储层。第三个问题是共享分布式存储，咱们 TDSQL-C 地区的所有实例，在底下是共享一个分布式存储，能够动静向一个实例里增加资源。最初一个是后盾继续备份，咱们的后盾有定期备份工作，将日志和数据备份到地上存储下面。 PG 实例，包含主实例和读实例，主的负责读写，只读是负责数据读取。在 PG 下有一个叫 CynosStore Agent 组件，它次要负责存储层进行通信，包含主的写日志、读页面，从的是读页面。再向下是存储服务或叫 CynosStore，采纳的是 RAPS 构造，一主两层。左边是集群治理服务，是对 CynosStore 里存储节点进行治理服务。包含故障迁徙是一个节点产生故障而后迁到其它节点性能。 另外一个当须要扩大资源时，也是由这个集群治理服务来实现。上面是对象存储，咱们会定期在对象存储备份日志和数据。这里波及几个外围架构：一个是日志下沉，计算节点产生的日志是通过网络，下沉到存储层。存储层是通过异步形式来回访日志，导出页面下来。另外是咱们会提供一个多版本读的能力，PG 下层可能会有多个 Buffer 会话去读这个数据，每个开始工夫不一样，可能会读到不同的版本。 介绍一下日志下沉、异步回放这部分。这里边波及几个概念： 第一个是数据原子批改，咱们叫 MTR。当中有很多状况是一个数对应一个数据库要批改多个页面，例如想对数字索引决裂或是一条 UP Date 语句，它可能要给多条元组，散布在不同的页面上，这些都须要保障是原子操作。第二是 CPL 概念，咱们 MTR 里批改了多条数据页面批改，最初一个产生日志咱们叫它 CPL，另外一个是叫 VDL。这 CPL 是存储层所有间断 CPL 里最大值，我管它叫做 VDL。随着数据库在运行中，这个 VDL 是在一直地向前推动。同时咱们的 PG 读也是拿到一个读点，就是一个个的 VDL。 第二个是日志异步写入。日志异步写入是由咱们 PG 过程来生成日志，写到咱们的日志 Buffer，日志 Buffer 是 PG 过程和咱们 CynosStore Agent 过程之间共享的。写到这个 Buffer 当前，由 Agent 过程给它异步发送到存储节点。存储节点是通过挂到日志链上，再异步合并到数据页面下来，整个过程都是异步的。 ...

TDSQL PG 版产品介绍 TDSQL PG 版通过十余年打磨大略能够分为以下几个阶段，第一个是单机时代引入 PostgreSQL 做为腾讯大数据平台 TDW 的一个补充，补救了小数据量剖析能力有余。随着业务倒退，单机瓶颈逐渐凸显，促使团队推出了更具备扩展性的 SQL 和兼容 V1 版本，并在 2015 年上线微信领取零碎。 此外，TDSQL PG 版提前布局咱们 ToB 市场，在 V2 版本反对三权分立，加密通明等平安个性，并在 2018 年拿下数字广东和云南公安等多个标杆客户。TDSQLV3 次要定位 HTAP，在 2019 年上线 PICC 外围业务，直到去年公布 V5 版本，次要是为了去 O，内核具备去 O 和读写拆散能力，同时上线的运营商用户还有保险零碎。 本次次要分享 V5 这一块。TDSQL PG 版是基于腾讯及 PostgreSQL 开源的自主分布式 HTAP 国产数据库，其全面兼容 PostgreSQL，高度兼容 Oracle 语法，产品采纳无共享架构，在提供数据仓库解决的能力的同时，还能反对残缺的事物分布式 ACID 能力。 TDSQL PG 版整体能力，从反对上来说它的反对的接口比拟丰盛，比方 libpq 外面 C 、C++，Jdbc/odbc、Python、Ecpg，各种罕用语言接口都是反对的，同时它也反对用户自定义函数操作服务。很多企业用户关怀的数据安全方面，TDSQL PG 版是用三权分立平安体系，反对数据脱敏同时还有加密性能，并且反对多种国密算法。 作为一个 HTAB 数据库，咱们反对千万级 TPS 事务处理，全并行分布式计算框架，能够让业务高效实现 OLAP 计算。在数据治理方面，能够反对在线扩缩容，用户无感知数据 Rebalance，应用通明的冷热数据拆散来缩小用户业务老本。此外，咱们还反对多种窗口剖析常函数，并且高度兼容 Oracle 常见语法。 ...

谈到数据库，在整个 IT 行业中灵活性是绝对较单薄的，而数字化转型须要十分快的业务响应及准入新业务。但从整个倒退背景来看数据库产品和技术，这个产品在各个维度都有着很快的倒退。 90 年代，大家晓得有这个数据库概念，然而在信息处理上信息库是信息最集中的。起初商业数据库例如 Oracle 等，很快霸占了金融业和电信行业市场，然而随着互联网的倒退，商业数据库十分低廉，怎么把低成本产品利用到 IT 零碎搭建当中呢？国内很多互联网公司基于开源社区产品打造了本人的数据库产品，这是基于算法晋升、硬件算力的根底所实现。 从行业维度来看，最后是商业数据库一统天下，本来金融业在选型都会选商业数据库，商业数据库稳定性、反对、服务都是最好的，而在近些年则呈现了百花齐放的场面，涌现出很多老牌国产数据库，还有一些基于开源后转为商用，包含 MongoDB、Redis 等。腾讯云领有欠缺的数据库产品矩阵，包含关系型数据库、非关系型数据库、自研国产分布式数据库 TDSQL 和 SaaS 产品。这些产品已胜利使用在了各个行业中，也反对了很多用户进行数字化转型，尤其是国有银行等，例如建行、中行、农业银行，这些咱们都有着丰盛的利用实际案例。 谈到腾讯云数据库，咱们再说到最新数字，2021 年在哪些业务畛域和场景会用到呢？银行的清理核心、农行的信贷、中国银行、农发行、兴业银行等，这些业务不是外围的 IT 治理、网管、OE 零碎，而是曾经迁入到理论业务当中进行应用，同时这是金融业包含保险突飞猛进的一年。这个问题是基于在过来十多年间腾讯在本身业务包含在互联网业务，进入云后打磨造成的成熟产品，而任何产品都不是久而久之就能利用到各个领域，腾讯云有这样积攒也是多年在各方面的打磨无关。 除了业务打磨，腾讯云数据库也在建设本人的技术和服务体系，在过来服务于泛滥行业用户过程中咱们发现，除了本身积攒，也要把本身技术能力做为开源形式分享进去，大家基于这个产品联合本身业务做更深的打磨。从产品服务体系看，腾讯在北京、上海、广州、深圳、四个中央为了服务四周区域，都建设了数据库产品研发和反对核心。 在金融场景有 6 个方面十分重要，数据强统一、金融级高可用、高性能低成本、高安全性、良好扩大、便捷运维。交付形式能够在一体机、软件部署、公有云三种形式提供服务。同时在产品生态来讲，咱们建设了本人的产品、丰盛的培训、合作伙伴机制，可能把产品施行能力以及技术体系各渠道合作伙伴建设起来，在过来一年咱们建设了联结翻新实验室，为 60 多家企业 100 多款业务进行了深刻适配。包含保险、银行还有其它行业都有深度单干的 SV 来帮忙咱们打磨好产品业务。 自主翻新畛域来说，腾讯云无论从数据库内核还是外维操作系统、芯片、UOS、新创单干都有着丰盛的教训。基于开源产品，然而不受开源影响。即便在开源协定变动的状况下，腾讯齐全有能力在现有产品上持续保护独立的，平安可控持的社区运作。同时咱们取得了信创各方面信赖，可能确保在信息系统业务当中零碎是完全符合平安可控要求。同时腾讯也是信创委员会会员单位，并产品通过国家权威机构的品质评测。 从国产化信创畛域来讲，腾讯云在很多行业都有积攒，包含本身财产通、微众银行，都有切入到业务外围。这一系列的业务利用代表着腾讯云能够反对金融级简单业务场景。接下来从互联网政务金融四个畛域方面进行阐明。 新型互联网公司在本人畛域中有很多利用，这些利用有很多独特性，包含互联网本身海量并发、疾速迭代，这些有赖于数据库的技术组建也能提供麻利的程度伸缩、高可用治理，及便捷的数据库运维，许多基于私有云的互联网用户，都在大量应用这款产品。 2020 年第七次人口普查，这个我的项目工夫很短，然而须要把大量数据会集起来，做维度剖析，这些剖析从而影响国家级决策。在这个我的项目当中，对整个高并发、简单剖析上有十分好的反对，这个我的项目可能顺利完成达到目标和这个产品有着严密的关系。咱们在昆山农商行业务的案例是新外围。整个外围零碎具备十分麻利高效以及灵便的个性，在全局能够十分疾速的在两个核心做灵便切换，这个对未来业务飞速增长，业务翻新都可能有着十分好的反对。 国有大行积攒了几千套 IT 零碎，这外面业务非常复杂，这对国产数据库简单场景的反对是一个很大的挑战。腾讯云在过来一年给农行业务带来了十分大的反对。从 2020 年年底 PUC 测试开始到前面实现信创的适配，再到我的项目立项、开发测试，始终到 2021 年 6 月份陆续上线，整个过程腾讯云在数据库畛域，金融外围业务场景开展了深刻单干。目前所投入生产的零碎，业务问题每天在 1 亿以上，这个量十分大，这是在农行信泛滥外围当中的一部分，同时实现了国产化的翻新，整个架构完全符合人行、监管要求。 在保险畛域咱们也领有很多翻新案例，尤其是在数据库替换我的项目开展了深刻单干。太保的 IT 翻新上走在保险行业的前列，设定了三年的商业数据库替换指标，在这个我的项目当中腾讯通过多轮 PK 顺利中标并且成为首选数据库，过来几个月整个零碎的调研，适配和演练后，实现了整个团体全量的数据库排查，明确了替换的门路和危险标识和难。怎么做全量数据库替换、怎么通过产品测试从而实现整个业务安稳切换，是咱们在过来几月始终开展进行的。到目前为止第一阶段曾经告一段落，而在信创的试点咱们曾经有三套零碎上线，在月底会达到 6 套零碎，这些都是业务的外围，无论是寿险、财险，反对外围业务的拓展都能够进行反对。 数字化要进入到深水区，要做的是外围业务零碎，然而一个零碎波及到几十套数据库，上百个模块，怎么实现切换，怎么帮忙国产数据库平台应用好，这些都是咱们当初须要关注的。而在国产化的畛域，腾讯云还会一直的加大投入，将全力做好标准化产品的输入和技术支持，与各行业合作伙伴一起减速推动国产数据库市场良性倒退，为企业数字化智能化转型提供更为弱小的技术撑持。

前两天在学习 SQL。做了一个脑图。 https://simon-mindmaps.netlif...

1 月 11 日，腾讯云 TDSQL PG 开源版（开源代号 TBase）再降级：分布区表关联查问性能（join）晋升超 10 倍，同时晋升了产品在分布式场景下的易用性，减少灵便可用的性能组件。 该降级版本在第十一届 PostgreSQL 中国技术大会上正式颁布，同时更新文档已同步在 GitHub 上。依靠社区和外部业务零碎的实际测验，TDSQL PG 开源版根本放弃每月一次小降级、每半年一次重大降级的节奏，助力泛滥开发者利用前沿数据库技术。 本期将为大家深度解读 TDSQL PG 开源版降级个性，具体包含：分区表性能加强、异地多活易用性加强、分布式死锁自动检测并解锁性能、2PC 残留自动检测并清理性能等硬核干货。 TDSQL PG 版开源倒退历程 TDSQL PG 版（原名 TBase）是腾讯自主研发的新一代分布式国产数据库，其具备业界当先的 HTAP 能力，属于 MPP 无共享架构，在企业级平安方面采纳三权分立平安体系。 图片 2020 年，腾讯云正式发表数据库品牌 TDSQL 的全新策略降级打算。原有的 TDSQL、TBase、CynosDB 三大产品线对立降级为“腾讯云企业级分布式数据库 TDSQL”。全新降级后的腾讯云 TDSQL 涵盖分布式、剖析型、云原生等多引擎交融的残缺数据库产品体系。TDSQL PG 版则是 TDSQL 系列产品之一，次要针对 HTAP 场景。 下图是 TDSQL PG 版的总体框架。左上角为事务管理器 GTM，负责整个集群的事务管理和全局事务的协调。右上角为协调节点 CN，它是业务利用拜访的入口，每个节点对等，业务连贯任意节点，最终返回的数据都雷同。右下角为数据节点 DN，每个 DN 只存储局部用户数据，所有 DN 一起组成残缺的数据集。最右边和最下边的局部属于管控零碎，负责零碎的资源管理和告警监控。 图片 TDSQL PG 版最早可追溯到 2008 年，2012 年其公布第一个分布式版本，2015 年其公布第二个分布式版本。截至目前，TDSQL PG 版曾经在泛滥市场客户中失去利用，包含数字广东、云南公安、微信广告、微信领取等。值得一提的是，TDSQL PG 版在 2019 年中标 PICC，成为行业内第一个胜利落地保险外围零碎的分布式国产数据库。 ...

1 月 11 日，腾讯云 TDSQL PG 版（开源代号 TBase）再降级：分布区表关联查问性能（join）晋升超 10 倍，同时晋升了产品在分布式场景下的易用性，减少灵便可用的性能组件。 该降级版本在第十一届 PostgreSQL 中国技术大会上正式颁布，同时更新文档已同步在 GitHub 上。依靠社区和外部业务零碎的实际测验，TDSQL PG 版根本放弃每月一次小降级、每半年一次重大降级的节奏，助力泛滥开发者利用前沿数据库技术。 TDSQL PG 版是一款具备 HTAP（事务剖析解决）能力、通过腾讯多年继续投入研发的数据库产品，可能提供成熟的一站式解决方案，2019 年 11 月正式开源。在首次开源的 10 天内，Star 数就回升到超过 500 个。开源不久，就受到了地理、医疗衰弱、批发等各个行业用户的青眼。 本次降级的外围能力，都是基于此前的用户反馈和在开源社区的积攒。具体包含：分区表性能加强、异地多活易用性加强、分布式死锁自动检测并解锁性能上线、2PC 残留自动检测并清理性能等重点降级。 首先，简略了解分区表，就是把一张大表分成若干小表，能够用来节俭数据读写总量，缩小响应工夫，此前业界依然面临数据量大时读写性能慢等问题。本次 TDSQL PG 版降级，整体响应速度更快，能有效应对这一挑战。 具体来说，新版本通过分区表性能加强，包含减少 hash 分区类型、反对 default 分区子表创立、分区父表索引操作主动同步子表等，实现分区表便捷治理。同时，新版本实现了分区剪枝性能晋升 30%，分布区表关联查问性能（join）晋升超 10 倍，完满解决查问效率问题。 另一重要降级，是异地多活的易用性加强。原先单活时跨区接入延时大，一旦产生故障服务和数据库都须要切换，流程简单。而异地多核心接入时延小，业务在一个核心内能实现闭环，秒级即可实现切换。本次降级新增多活插件化性能，不便用户装置配置，晋升了产品易用性。 开源是腾讯保持的长期价值之一。腾讯 2010 年起就确立了拥抱凋谢的策略，并始终秉承重数量、更重品质的态度倒退开源。 腾讯云数据库也在推动数据库 SaaS 服务工具的开源，包含能够实现 90%日常主动调优、智能诊断的 AI 自动化运维工具，以及能够进行大规模异构数据迁徙、散发、聚合的数据库迁徙平台。 “面对企业客户、开发者，咱们心愿提供的是一个成熟残缺的产品，而不仅仅只是一份代码”，腾讯云副总裁李纲示意，即便是开源产品，腾讯云数据库也会提供欠缺的产品服务。 而在根底钻研畛域，腾讯还开源了根底钻研平台型框架，来帮忙升高研究者的钻研门槛。2020 年，腾讯和中国人民大学单干开源的 3TS—事务处理技术验证零碎，积淀了腾讯与人大在数据库核心技术方面的许多研究成果，能够提供对立的事务处理框架，帮忙研究者疾速构建新的并发控制算法，以及检测数据异样。 开源的实质是以技术凋谢促成技术创新。在下个版本中，TDSQL PG 版将增强存储能力、一直优化索引，同时晋升分布式状态可视化。 腾讯云对 TDSQL PG 版一直开发和投入，将继续给客户带来价值。版本通过大量业务验证，成熟稳固，开源版本和腾讯自用版本共基线，帮忙用户疾速构建外围业务。独特打造可继续的国产数据库开源生态。

日前，第 11 届 PostgreSQL 中国技术大会圆满闭幕，大会上腾讯云多位顶级技术达人携手亮相，别离对腾讯云 PostgreSQL 系列产品技术亮点和翻新实际案例进行了深刻解读，针对 TDSQL-C PostreSQL 高可用个性、TDSQL-A 倒退历程、技术架构等做出了具体介绍。 会上腾讯云数据库开源产品 TDSQL PostgreSQL 版（开源代号 Tbase）再次颁布降级：分区表能力加强，分区剪枝性能晋升 30%，分布区表关联查问性能（Join）晋升超十倍。此外，异地多活易用性加强、分布式死锁自动检测并解锁性能上线，2PC 残留自动检测并清理等多方面降级，全方位的展现了腾讯云在 PG 技术畛域的冲破和服务。 同时在本次大会，腾讯云 TDSQL 凭借成熟的一站式解决方案和行业利用实际，斩获“数据库最佳利用奖’’，这是既取得中国开源软件联盟 PostgreSQL 分会颁发的‘‘2021 PostgreSQL 中国最佳数据库产品’’奖之后，TDSQL 在 PostgreSQL 畛域的杰出体现再获认可。本次主论坛现场，腾讯云数据库专家工程师刘少蓉具体解读了腾讯云在 PostgreSQL 畛域的全线产品技术架构演进和利用场景，明天带大家一文纵览刘少蓉博士的演讲精髓。 （数据库最佳利用奖） 腾讯云 PostgreSQL 家族早在 2008 年开始，腾讯在 PG 方面就开始做相干数据库研发，通过十几年的研发和业务打磨，咱们腾讯也为业界奉献了比拟丰盛的产品线：RDS 云数据库（TencentDB for PG），TDSQL PG 版 （企业级分布式数据库 PG 版，为用户提供 TP、AP 整体解决方案），TDSQL- A（基于分布式 TDSQL 架构专门研发的一款剖析型产品）和 TDSQL-C PG 版(云原生数据库)。上面咱们会具体介绍每款产品的架构和利用场景。 TencentDB for PG 是腾讯云在 PG 方面的 RDS，用于给用户提供开箱即用的云端数据库服务。用户能够通过云控制台一键创立和治理数据库。腾讯云负责解决绝大部分简单而耗时的管理工作，如 PostgreSQL 软件装置、存储管理等，这样用户就能够更专一于业务程序开发。 咱们来看一下 TencentDB for PG 的架构，这也是比拟典型的单机云数据库的架构。一主一从的强同步保障服务的高可用。同时呢，在线的热数据也会定时的备份到 COS 下面，以便在数据库劫难时进行数据恢复，这也保障了高可靠性。TencentDB for PG 也跟多种腾讯云产品集成和联通，比方说云监控能够主动监控数据库，省去了人工 DBA，ES 集群提供了日志查问服务等。 ...

云数据库上半场，是线上市场（私有云）之争，目前大局已定，阿里云以绝对优势领跑。现在，云数据库之战逐渐进行到下半场，即线下市场（混合云、公有云）之争，而下半场将是影响整个中国数据库市场格局的要害之战。 为什么说下半场将是影响中国数据库市场格局的要害之战？ 其一、线下市场是传统商业数据库最初的阵地。国内数据库市场营收大客户皆来自线下市场，这点与国外不同。进入云计算前，美国企业的 IT 数字化水平就已十分高，所以，绝对中国市场，美国企业对拥抱私有云是瓜熟蒂落的事。但中国市场有本人的特点，传统政企对公共云的拥抱必定不会有美国市场高。所以，中国混合云、公有云市场在相当长一段时间里会是一个外围赛道。 其二、线下市场在数据库方面的收入会占到整个中国数据库市场的近 8 成。数据显示，国内数据库市场营收，奉献前 5 的行业别离是金融 22.3%，电信 18.9%，政务 16.4%，制作 13.3%，交通 9.6%。也就是说，仅这 5 大行业就奉献了数据库八成以上营收，而这 5 大行业中，绝大多数行业显然是不承受数据放在私有云上的。 2021 年 9 月 3 日，阿里云智能数据库事业部总负责人李飞飞，在一场媒体沟通会上对外发表阿里云曾经做好全面服务政企数据库市场的筹备。这意味着阿里云数据库正式吹响了进军线下市场的号角。 相比之下，领有 toB 基因的华为，线下市场无疑是劣势畛域，多个报告指出，华为在金融政企市场占据劣势，最典型的就是工商银行和招行银行的标杆案例。华为云数据库对线下市场的志在必得在其官网口号“金融政企外围数据上云信赖之选”中体现的淋淋尽致。 2021 年 10 月 18 日，华为云数据库首席架构师冯柯在 DTCC 大会上承受笔者采访时示意，面向金融政企市场，华为云 Stack+GaussDB，为客户提供合乎政策监管要求本地部署的云服务。目前，华为云 GaussDB 曾经在助力国有大行外围交易与数仓零碎分布式革新，并曾经在四家国有大行和多家股份制银行商用。 但真正让人意外的要数腾讯云数据库，既没有阿里云的先发劣势，也没有华为云企业级传统劣势，但下半场却打的更有侵略性，不仅早早的开始线下布局，并且曾经先一步进入到深水区。 2021 年 11 月 10 日，腾讯公布 Q3 财报，不仅首次提到数据库对企业服务的奉献，更秀了一把数据，财报显示，腾讯云数据库 TDSQL 已被 3000 多家来自金融、公共服务和电信垂直行业的客户采纳，中国十大银行中的六家都利用了该产品。 明天，咱们就来盘点一下行将过来的一年，腾讯云数据库都干了些什么？为什么市场浸透如此之快。 品牌 &市场 2020 年底到 2021 年初，腾讯云数据库进行了品牌降级，原有 TDSQL、TBase、CynosDB 三大产品线对立降级为“腾讯云企业级分布式数据库 TDSQL”， TDSQL 代表的是腾讯云自研数据库品牌。全新降级后的腾讯云 TDSQL 将涵盖分布式、剖析型、云原生、Oracle 兼容、敏态等多引擎交融的残缺数据库产品体系。 对立品牌，意味着资源整合，提高效率，解决了对外品牌不对立的问题，这是要筹备集中力量干小事！ 2021 年 11 月 4 日，腾讯数字生态大会 Techo Day 上，腾讯云副总裁李纲在演讲中谈到了一个观点，腾讯云认为云化与国产化代替是中国数据库市场的双重驱动，也是国产分布式云数据库的历史时机。 ...

在云计算倒退和国产化趋势的双重驱动下，国产数据库需要迎来爆发式增长。回首过来一年，TDSQL 凭借优良的产品性能、优质的技术服务和日渐壮大的单干生态，失去业界宽泛认可，金融外围零碎客户数国内当先。 2022 年，在更高的终点上，TDSQL 将再度登程，推动国产数据库倒退迈入新篇章。 系列技术继续翻新 布局前沿利用场景 当传统技术架构逐步难以满足产业互联网时代的需要时，转型降级是必然的趋势抉择。在金融政企技术系统对国产化、数字化革新降级需要愈发迫切的背景下，TDSQL 从不同利用场景匹配不同引擎，为客户提供交融对立的产品服务，以及从前端治理到底层对立的智能管控体系。 2021 年 5 月，腾讯首款分布式剖析型数据库 TDSQL-A 正式公布，适应海量 OLAP 关联剖析查问场景。其采纳全并行无共享架构、具备全自研列式存储引擎，反对行列混合存储，具备弱小的海量数据实时剖析能力，并全面兼容 PostgreSQL 语法、高度兼容 Oracle 语法，同时具备高平安、高可用、超大规模集群反对和残缺事务能力等产品个性，可为企业用户需要提供高效、低成本的数据分析解决方案。 2021 年 11 月，TDSQL 新敏态引擎重磅公布。该引擎 100%兼容 MySQL8.0 语法，采纳计算存储拆散的云原生架构，可依据业务压力独立弹性扩缩容，原生 Online DDL 操作毋庸依赖内部工具即可动静更改表构造，超高压缩比存储能力最高可反对 EB 级海量存储，可有效应对业务倒退过程中业务状态变动及访问量突增的不可预知性。 2021 年 11 月，TDSQL 金融级引擎（Oracle 兼容版）全新公布，满足金融外围疾速上线要求。其高度兼容 Oracle 语法，保险/运营商行业兼容度高达 98%以上，同时具备集中式、分布式多种部署模式，实现数据库平滑迁徙替换。 同时，TDSQL-C 公布 100%兼容 MySQL8.0 版本，性能和稳定性大幅晋升，新增满载 CPU 流水线优化、软件栈多路 Run2Completion、全链路 RDMA，极短 IO 提早，吞吐大幅晋升，并公布了 lnstant DDL 性能，秒级实现构造变更。其全新状态 Serverless 可能通过全局工作流预测以及动静扩缩资源，突破传统固定规格产品状态，依据负载主动伸缩，按理论应用计费，不应用不计费，进一步降低成本。 此外，TDSQL 开源版公布重大降级，上万张表拜访场景下，会话内存占用节俭 60%，查问性能晋升百倍，鼎力晋升原有数据库版本在分布式场景下的易用性；数据库自治 DBbrain 反对 TDSQL，运维开启混合云自治场景...... 洞察将来趋势，深耕技术创新，TDSQL 系列技术的继续冲破，在适配更多行业利用场景的同时，也为下一代翻新蓄积了更多强劲动能，为国产数据库产品生态的进一步欠缺提供了更多实际。 金融外围零碎客户数国内当先 发明国产数据库新里程碑 ...

1.sqlite 查出所有表名select name from sqlite_master where type='table' 2.sqlite 查出表的所有字段PRAGMA table_info([表名]) 原文链接https://wangdongjie.com/sqlite-query-all-tables

SQL概述SQL的全称是Structured Query Language（结构化查询语言），是最早于1970年代提出并广泛应用于拜访和治理关系型数据库（如Oracle/MySQL）的规范计算机语言。 基于SQL的全面弱小的性能及简略易用的个性，其历经50年风雨始终长盛不衰；很多近年来才疾速倒退起来的大数据处理系统如Presto/Flink/Spark/Hive等也实现了SQL或类SQL的语言。 基于具体的性能能够对SQL做进一步的细分，罕用的有： 数据定义语言（DDL，Data Definition Language）：创立新表或批改、删除表，关键字包含CREATE、ALTER和DROP等数据操作语言（DML，Data Manipulation Language）：用于增加、批改和删除数据，关键字包含INSERT、UPDATE和DELETE等数据查询语言（DQL，Data Query Language）：用于从表中取得数据，关键字是SELECT理论利用中，咱们通常是编写SQL语句，提交给数据库或大数据系统来执行，而后获取执行后果；有几个容易搞迷糊的概念如下： Statement：语句，通常指整个SQL文本Clause：子句，通常指SQL文本中的一部分，如From子句、Where子句、Group By子句Query：查问，通常指SQL文本在零碎中的一次执行实例Database：库，一个库能够有多个表；含意相似的有：模式（Schema）Table：表，一个表能够有很多行；含意相似的有：关系（Relation）Row：行，一行能够有很多列；含意相似的有：记录（Record）、条目（Item）Column，列，不再细分的具体值；含意相似的有：字段（Field）须要强调的是，不同的数据库或大数据系统中的SQL会有肯定的实现差别或特有的扩大性能，本文着重于介绍通识性的概念和用法，理论利用时请联合浏览相干零碎的官网文档。 SQL查问语句SQL查问语句用于从零个或多个表中检索数据行，其能够蕴含子查问语句，还能够用UNION等将多个SELECT语句组合起来获取后果，也能够用WITH子句定义在SELECT中可拜访的公共表表达式（CTE，Common Table Expressions）。 OLTP畛域谋求SQL查问语句简略高效，很多性能个性都会防止应用，甚至不惜拆分屡次执行以最大化数据库系统的并发能力；然而，在大数据、OLAP畛域尽管也很期待查问能很快执行实现，但查问语句中往往间接夹杂着数据分析型业务逻辑或者ETL需要，从而导致查问语句变得十分长且简单；因而咱们来具体整顿一下组成简单查问语句的各个子句，熟练掌握这些子句能力比拟容易看懂并写出满足需要的简单查问SQL。 SQL查问语句的根本语法结构如下： [ WITH with_query [, ...] ]SELECT [ ALL | DISTINCT ] select_expr [, ...][ FROM from_item [, ...] ][ WHERE condition ][ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ][ HAVING condition][ WINDOW window_name AS ( window_definition ) [, ...] ][ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ][ ORDER BY {column_name | expr | position} [ASC | DESC], ... [WITH ROLLUP]][ LIMIT {[offset,] row_count | row_count OFFSET offset}] SELECT子句SELECT子句是查问语句中必不可少的局部，由SELECT关键字及至多一个标识要检索列的表达式形成，多个表达式之间以英文逗号分隔；反对的表达式包含但不限于如下状况： ...

一、前言最近几天在开发公司业务时，遇到了须要往不数据库中多个表中插入大量数据的一个场景，于是有了这篇文章： 在应用Mybatis批量插入数据时的注意事项，以及应用函数式编程对分批次数据插入方法的简略封装。 对于蕴含我在内大部分Java后端开发的小伙伴们在平时的CURD开发工作中，肯定是免不了应用Mybatis这个工具来对数据库进行操作的。 在SpringBoot的工程中，引入Mybatis后，可应用mapper注入的形式来实现增删改查。 比方如果要新增一条数据，那么在mapper.xml文件中能够这么写： <insert id="testInsert"> insert into massive_data_insert_test (value1,value2) values (#{value1},#{value2}) </insert>而后在service层调用mapper.insertOneItem(insertItem);即可。 如果要新增多条数据，如果是刚学Java的同学可能会这么写： for(int i = 0; i < insertList.size(); i++){ mapper.insertOneItem(insertList.get(i));}就是简略的放在一个循环中，屡次调用mapper中的数据库新增办法。这种办法编写简略易于了解，在数据量比拟少的时候是不会有什么问题的。 然而一旦数据过多就会有问题了。 实际上每次的mapper办法调用都是一次连贯数据库、预处理（PreparedStatement）、execute（执行SQL）的过程。 由此发现，如果放在for循环中的话，上述过程则会屡次执行，而咱们又分明数据库的连接数是无限的（建设连贯的过程也是很消耗资源的），如果for循环的次数过多时，不仅性能会降落还会造成数据库的梗塞甚至程序解体。当然，咱们能够创立或配置数据库连接池（比方HikariCP、Durid等）来复用连贯，但这还是对资源的一种节约。 总而言之，如果能有一种办法来一次性把要实现的事件做完就不要分屡次去做。 大部分数据库的新增语句是反对一次插入多条数据的。 insert into table(value1, value2)values ('v1','v2'),('v3','v4'),('v1','v5')Mybatis也给出了一种批量操作数据的办法。应用动静SQL语句中的<foreach>标签，将帮忙咱们拼接出形似下面的SQL语句。 咱们在mapper.xml中编写上面的内容： <insert id="testMassiveInsert"> insert into massive_data_insert_test (value1,value2) values <foreach collection="list" item="item" separator=","> (#{item.value1},#{item.value2}) </foreach> </insert>这样咱们就只须要调用一次mapper中的办法就能达到下面for循环代码的成果。 并且实际上执行的时候也是执行一次SQL，这个动静SQL语句的作用就是将传入的参数的内容拼接到插入语句的SQL中（预处理技术）。 这种办法很显著要比一开始的for循环的实现要好一点了。 二、批量插入数据量达到上万后报错然而，当咱们用上述的拼接SQL的形式进行批量插入时，数据量过大也会呈现问题！ 咱们能够先来试验一下批量插入一个四万条数据会怎么。 先来新建一张表作为插入数据的指标表：massive_data_insert_test。 CREATE TABLE "supply"."massive_data_insert_test" ( "value1" varchar(255) COLLATE "pg_catalog"."default", "value2" varchar(255) COLLATE "pg_catalog"."default");轻易在一个SpringBoot的工程中连贯数据库并创立mapper，编写插入语句（创立工程和扫描mapper等操作就不在此赘述了）： 上面是mapper接口和mapper.xml文件（中的sql语句）。 TestMapper.java @Repositorypublic interface TestMapper.java { void testMassiveInsert(List<HashMap> list);}TestMapper.xml ...

2022年，腾讯云数据库将持续携手宽广用户及合作伙伴，独特推动国产数据库生态倒退，助力政企数字化转型，推动产业降级！!

日前，在中国电子信息行业联合会面向行业优良品牌教育培养《2020-2021年度优良翻新软件产品》的征集中，腾讯云分布式数据库TDSQL管理系统胜利入选，并荣获“年度优良软件产品”奖项。 本次评比邀请工业和信息化部领导进行多轮评审，从零碎的普适兼容性、可部署在国产硬件利用资质、零碎创新性等多方面综合评估，腾讯云TDSQL管理系统凭借卓越的产品性能、技术当先性和创新性，在泛滥产品中怀才不遇，胜利入选2020-2021年优良翻新软件产品。 随着信息时代的到来，海量数据曾爆发式增长，数字经济也已成为助推寰球经济增长的重要引擎，而软件则是数字经济高质量倒退的重要能源。腾讯云分布式数据库TDSQL管理系统是腾讯自研的分布式数据库软件，其兼容支流开源数据库，具备表主动程度拆分、不停机程度扩大、寰球部署架构、高平安能力等；产品兼容SQL2016规范，反对JSON、空间等数据类型；兼容罕用的数据库客户端、（含国产）中间件；可部署在国产硬件和操作系统，且TDSQL的分布式数据库集群可调配集中式数据库实例；反对残缺的DDL/DML/DCL数据库定义、操作、管制语言，反对视图、存储过程等数据库高级个性；反对（强统一）分布式事务，分布式联结查问，数据强统一能力，可用于党政机关、十二金工程、金融外围交易系统。 同时市面上大部分管理工具无奈为利用运维和利用开发团队提供规范、自助化服务，腾讯云分布式数据库TDSQL管理系统推出智能化剖析“扁鹊”零碎和自动化运维“赤兔”平台，能够为用户提供诸如SQL慢查问优化诊断、长事务诊断等能力，让数据库管理员日常90%以上的操作均可通过界面化实现，而基于“赤兔”和“扁鹊”，能够大幅升高问题收敛速度，进步问题复原速度，保障日常业务平安。 此外，腾讯云数据库作为国产化数据库厂商，始终在生态建设方面踊跃的在和上下游国产软硬件进行适配，目前TDSQL曾经与百余家行业头部合作伙伴实现了产品兼容互认证，其中囊括各行业头部ISV60余家，笼罩政务、财政、金融、运营商、制造业、医疗、通用、平台产品等数十个典型行业场景。 值得一提的是，在2021年腾讯云数据库TDSQL做为惟一头部厂商，事务型和剖析型双双入围了2021年央采我的项目，这不仅象征着宽广业内机构对TDSQL综合实力、产品及创新性的认可，也更加夯实了腾讯云TDSQL在政务金融外围交易系统方面的突出技术和实际能力。

| 导语 数据库在执行过程中常常会遇到有SQL执行工夫超长，相互阻塞的问题。如何疾速找出罪魁祸首，并且干掉此类语句让流程持续，本文将简略为大家讲明。当咱们遇到语句简略然而执行工夫超长的SQL语句时，不肯定是因为SQL写得不好，很大可能是因为遇到了数据库的期待事件了，如何判断语句是因为什么起因而阻塞的呢？ 咱们应用一个测试场景进行模仿演习一次，首先创立一个表，而后插入局部数据，再显示的创立事务，结构一个锁期待的场景。 create table t1(id int primary key); insert into t1 select generate_series(1,10000); begin;delete from t1; # 再另开一个session 执行同样的语句： begin;delete from t1; 此时就能够发现在执行第二个事务的时候，SQL显著无奈执行上来，因为第一个事务未提交。 当然咱们能够通过一些现成的语句来间接查看锁信息，如： SELECTblocking_activity.datname as "数据库",blocking_activity.application_name as "持锁会话程序名",blocking_activity.client_addr as "持锁会话地址",now()-blocking_activity.query_start as "阻塞时长(s)",blocked_locks.pid AS "阻塞会话ID",blocked_activity.usename AS "被阻塞用户",blocking_locks.pid AS "持锁会话ID",blocking_activity.usename AS "持锁用户",blocked_activity. QUERY AS "被锁SQL",blocking_activity. QUERY AS "持锁SQL"FROMpg_catalog.pg_locks blocked_locksJOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pidJOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktypeAND blocking_locks. DATABASE IS NOT DISTINCTFROMblocked_locks. DATABASEAND blocking_locks.relation IS NOT DISTINCTFROMblocked_locks.relationAND blocking_locks.page IS NOT DISTINCTFROMblocked_locks.pageAND blocking_locks.tuple IS NOT DISTINCTFROMblocked_locks.tupleAND blocking_locks.virtualxid IS NOT DISTINCTFROMblocked_locks.virtualxidAND blocking_locks.transactionid IS NOT DISTINCTFROMblocked_locks.transactionidAND blocking_locks.classid IS NOT DISTINCTFROMblocked_locks.classidAND blocking_locks.objid IS NOT DISTINCTFROMblocked_locks.objidAND blocking_locks.objsubid IS NOT DISTINCTFROMblocked_locks.objsubidAND blocking_locks.pid != blocked_locks.pidJOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pidWHERENOT blocked_locks.GRANTED; ...

LSM-Tree（Log Structured Merge Tree）是数据库畛域内较高效的key-value存储构造，被广泛应用于工业界数据库系统，如经典的单机kv数据库LevelDB、RocksDB，以及被诸多分布式NewSQL作为底层存储引擎。 本期将由腾讯云数据库高级工程师韩硕来为大家分享基于LSM-Tree存储的数据库性能改良，重点介绍近年来学术界对LSM-Tree的性能改良工作，并探讨这些改良措施在工业界数据库产品中的利用状况以及落地的可能性。以下是分享实录： 1. LSM-Tree根本构造LSM-Tree全称为“Log Structured Merge Tree”，是一种基于磁盘存储的数据结构。1996年Patrick O’Neil等人在信息系统期刊上发表了一篇题名为“Log Structured Merge Tree”的论文，首次提出LSM-Tree构造。相比于传统的B+树，LSM-Tree具备更好的写性能，能够将离散的随机写申请转换成批量的程序写操作，无论是在RAM、HDD还是在SSD中，LSM-Tree的写性能都更加优良。 作为高效的key-value存储构造，LSM-Tree已被广泛应用到工业界数据库系统中，如经典的单机kv数据库LevelDB、RocksDB，以及被诸多分布式NewSQL作为底层存储引擎，近日公布的TDSQL新敏态引擎存储模块也使用了LSM-Tree构造。LSM-Tree构造有较多长处：写性能弱小、空间利用率高、较高的可调参个性、并发管制简略、有齐备的修复计划等。 LSM-Tree的实质是基于out-place update即不在原地更新。下图展现了in-place update即原地更新与out-place update即不在原地更新的区别。 在in-place update中，数据更新操作是将数据的新值间接笼罩旧值，但会带来随机读写问题。在out-place update中，数据更新操作则是将新值按工夫程序追加到文件开端，通常会带有版本号用于标记新值或旧值，个别为程序写，因而写性能更好，但毛病是会产生冗余数据，在读性能和空间利用率上也无奈与in-place update相比。 以后支流的LSM-Tree根本构造如下图，分为内存和磁盘两局部。内存采纳MemTable数据结构，能够通过B+树或跳表实现。MemTable用于承受最新的数据更新操作，保护外部数据in-tree逻辑上的有序。磁盘中的局部数据存储物理有序。数据依照层进行堆放，档次越往下，数据写入的工夫就越早。每层外部按是否有序可划分为一个或多个sorted run。一个sorted run外部的数据必然有序（通常指物理上有序）。sorted run数据可进一步划分为不同的SSTable。当MemTable中的数据写满时，其会向L0进行落盘操作即Flush操作。如果LSM-Tree的某一层也达到容量阈值，就会向下合并，将同样的key的过期版本革除，即compaction操作。 RocksDB是基于LSM-Tree的存储引擎，其根本构造如下图。它与LSM-Tree根本构造在主体上保持一致，不同点在于RocksDB的内存中减少了Immutable MemTable局部，这是用于Flush操作的写缓存机制。当MemTable中的数据写满时，会先暂存到Immutable MemTable中，再通过后盾的异步线程将Immutable MemTable缓缓落盘到磁盘中的SST根本件。RocksDB中还减少了WAL日志，用于crash时的数据恢复。 LSM-Tree反对的查问可分为点查与范畴查问两大类，对应的执行形式如下：● 点查：先查MemTable，再从SST中的Level0、Level1…...一层层向下探查，找到数据就返回。因为下层数据必然比上层数据的版本新，因而返回的都是最新数据。● 范畴查问：每一层都会找到一个匹配数据项的范畴，再将该范畴进行多路归并，归并过程中同一key只会保留最新版本。 LSM-Tree性能的掂量次要思考三类因素：空间放大、读放大和写放大。 第一类因素是空间放大。在LSM-Tree中所有写操作都是程序追加写，数据的更新操作则是通过创立一个新的空间来存储新值，即out-place update。与此同时，因为旧值不会立刻被删除，因而会占用局部空间。实际上这部分冗余数据占用空间的大小要远大于无效数据自身，这种景象被称为“空间放大”。LSM-Tree会利用compaction操作来清理旧数据从而升高空间放大。 第二类因素是读放大。在LSM-Tree、B+树等外存索引构造中，进行读操作时须要按从上到下的程序一层层去读取存储节点，如果想读一条数据，就会触发屡次操作，即一次读操作所读到的数据量实际上要远大于读指标数据自身，从而影响读性能，这种景象被称为“读放大”。    第三类因素是写放大。在LSM-Tree中，compaction操作会将多个SST文件重复读取，合并为新的SSTable文件后再次写入磁盘，因而导致一条kv数据的屡次重复写入操作，由此带来的IO性能损失即写放大。 LSM-Tree的初衷是想通过空间放大和读放大来换取写放大的升高，从而达到极致的写性能，但也须要做好三方面因素的衡量。EDBT 2016的一篇论文首先提出RUM猜测（R为read，U为update，M为memory usage，RUM为三者缩写）。该论文认为，三者之间存在衡量关系，无奈使得三个方面的性能都达到最优，因而必须在三者之间进行无效衡量。 以compaction操作为例，其目标是保证数据的部分有序和清理数据旧值，即一个sorted run外部的多个SST文件中的数据是有序的，从而升高读放大。对一个查问而言，在一个sorted run中至少只须要读取一个SST中的一个数据块。 如果齐全不做compaction操作，即始终程序写，LSM-Tree就会进化为log文件，这时写性能达到最佳。因为只须要程序写log即可，不须要做任何操作。但读性能将会处于最差状态，因为在没有任何索引、无奈保障有序性的状况下，每次想读到固定的数据项，就须要扫描所有的SST件。 如果compaction操作做到极致，实现所有数据全局有序，此时读性能最优。查问时只须要通过索引和二分法即可迅速找到要读的键值的地位，一次IO操作即可实现，但代价是须要频繁进行compaction操作来维持全局有序状态，从而造成重大的写放大，即写性能变差。 这就延长出两种compaction策略： ● Tiering compaction：较少做compaction操作，有序性较弱，每一层容许有多个sorted run。 ● Leveling compaction：更频繁的compaction操作，尽可能加强有序性，限度每一层最多只有1个sorted run（L0层除外）。 2. Compaction优化策略与剖析Leveling compaction策略中，每层只有一个sorted run，sorted run外部的数据放弃物理有序。具体实现上咱们以RocksDB为例。一个sorted run能够由多个key不重叠且有序的SSTable files组成。当第L层满时，L层会选取局部数据即局部SSTable，与L+1层有重叠的SSTable进行合并，该合并操作即compaction操作。 Tiering compaction策略中，每层能够有至少T个sorted run，sorted run外部有序但每层不齐全有序。当第L层满时，L层的T个sorted run会合并为L+1层的1个sorted run。因为每层容许有多个sorted run，因而SST文件间可能会存在数据范畴的重叠，compaction操作的频率会更低，写性能也会更强。 ...

日前，腾讯云计算（北京）有限责任公司与北京国双科技有限公司签订了《国产数据库产品策略单干协定》，单方将在数据库技术方面开展深度单干，通过分布式交易型数据库的联结研发、产品服务体系建设、品牌和市场共建，进一步拥抱云原生，共建共赢生态，为千行百业提供大型企业级数据库解决方案，助力产业倒退、企业和政府组织的数字化智能化转型。 作为中国当先的大数据和人工智能平台级软件及解决方案提供商，国双始终致力于自主研发为企业级用户提供海量数据分布式存储、计算和剖析开掘的高牢靠、高性能的大数据平台产品，其平安可控的、新一代云原生并存并算数据仓库正在赋能大型地方企业，特地是传统包含能源、制造业行业在内的企业数智化转型的过程中施展着独特的作用。 国双科技创始人、董事长兼CEO祁国晟示意，“在十六年的倒退历程中，国双不忘初心，始终为实现技术的自主可控投入大量人力物力。国双自主研发的新一代云原生并存并算数据仓库产品在赋能企业和政府组织数智化转型的过程中施展着独特的作用。明天，咱们可能与腾讯云联袂出阵，优势互补互为生态，置信肯定可能通过国产数据库的建设，为大型企业和政府数字化转型做出奉献。” 作为国产数据库的代表和先行者，腾讯云TDSQL在国产数据库畛域的根底技术研发和产业化方面均获得了突破性停顿。TDSQL具备强统一高可用、寰球部署架构、高 SQL 兼容度、分布式程度扩大、高性能、残缺的分布式事务反对、企业级平安等个性，能够全方位满足政企在数字化转型方面的需要。 基于此次与国双签订策略单干协定，腾讯云将进一步凋谢本身资源和能力，同时施展国双在包含能源在内的传统行业数智化转型实操教训，独特深耕能源、制造业等传统行业的数字化转型瘠田，帮忙企业在数据库层面实现平安可控。 在云数据库的倒退与国产化趋势的双重驱动下，腾讯云始终秉持凋谢连贯的产业生态策略，与生态搭档共建共赢。目前，腾讯云数据库已有超过2000家合作伙伴，独特服务超过10000家企业客户，独特打造了笼罩超过20个行业累计超100个解决方案，次要合作伙伴均匀业务增长率超100%。 将来腾讯云数据库还将鼎力激励合作伙伴跟客户间接签约数据库我的项目，全面凋谢服务生态，腾讯云全力做好标准化产品的输入和技术支持，与各行业合作伙伴一起减速推动国产数据库市场良性倒退，为企业和政府组织数字化智能化转型提供更为弱小的算力撑持。

Azure Database for MySQL Flexible Server 在中国大陆地区正式上线了！即刻起，欢迎您登录由二十一世纪互联经营的 Microsoft Azure 开启体验。 什么是 Azure Database for MySQL Flexible ServerAzure Database for MySQL Flexible Server 是一种齐全托管的数据库服务，旨在针对数据库治理性能和配置设置提供更精密的管制和更大的灵活性。 通常，该服务提供更大的灵活性和基于用户要求的服务器配置自定义。Flexible Server体系结构容许用户抉择单个可用性区域内以及跨多个可用性区域的高可用性。Flexible Server还提供更好的老本优化管制，并且给用户提供自定义保护窗口的能力。该服务目前反对 MySQL 5.7 和 8.0 的社区版本。 Flexible Server 的外围劣势区域冗余高可用性抉择单区域或区域冗余高可用性，确保您的数据可用，跨可用区数据零损失。为您的数据库抉择可用区，改善数据库连贯。 为数据库服务器参数提供最大管制和灵活性从自定义托管保护中受害，管制补丁和降级工夫。以简洁开发者体验进步生产力，助力您放慢端到端的部署。 进行/启动服务器以优化老本灵便服务器服务容许你依据须要进行和启动服务器以优化老本。服务器进行后，计算层计费会立刻进行。这使你可在开发和测试期间以及针对有时限的可预测生产工作负载，节俭大量老本。 欲了解更多Azure Database for MySQL Flexible Server新性能，欢送点击浏览原文。

盘点数据库中的一些坑（一）前言此文是集体依据日常工作中遇到的坑以及通过各种材料总结的sql 的踩坑点，有些坑如果在编写sql的时候不留神的确是容易翻车，所以这里一并进行总结。 前置条件 在解说具体的踩坑点之前，咱们构建一个简略的表： CREATE TABLE `admin` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键，自增', `username` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT '用户名', `password` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT '明码', `gender` int DEFAULT NULL COMMENT '1为男，2为女', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb3;INSERT INTO `admin` (`id`, `username`, `password`, `gender`) VALUES (1, '小红', '111', 2);INSERT INTO `admin` (`id`, `username`, `password`, `gender`) VALUES (2, '小蓝', '222', NULL);INSERT INTO `admin` (`id`, `username`, `password`, `gender`) VALUES (0, '小黄', NULL, 1);为了进行后续的操作，咱们先往里面轻易造一些数据： ...

第一章 SQL的介绍1.1、什么是sqlSQL：Structure Query Language。（结构化查询语言）,通过sql操作数据库(操作数据库,操作表,操作数据)SQL被美国国家标准局（ANSI）确定为关系型数据库语言的美国规范，起初被国际化规范组织（ISO）驳回为关系数据库语言的国际标准各数据库厂商(MySql,oracle,sql server)都反对ISO的SQL规范。各数据库厂商在规范的根底上做了本人的扩大。 各个数据库本人特定的语法1.2、sql的分类Data Definition Language (DDL数据定义语言) 如：操作数据库，操作表Data Manipulation Language(DML数据操纵语言)，如：对表中的记录操作增删改Data Query Language(DQL 数据查询语言)，如：对表中数据的查问操作Data Control Language(DCL 数据管制语言)，如：对用户权限的设置1.3、MySQL的语法标准和要求（1）mysql的sql语法不辨别大小写 MySQL的关键字和函数名等不辨别大小写，然而对于数据值是否辨别大小写，和字符集与校对规定无关。 ci（大小写不敏感），cs（大小写敏感），_bin（二元，即比拟是基于字符编码的值而与language无关，辨别大小写） （2）命名时：尽量应用26个英文字母大小写，数字0-9，下划线，不要应用其余符号user_id （3）倡议不要应用mysql的关键字等来作为表名、字段名等，如果不小心应用，请在SQL语句中应用`（飘号）引起来 （4）数据库和表名、字段名等对象名两头不要蕴含空格 （5）同一个mysql软件中，数据库不能同名，同一个库中，表不能重名，同一个表中，字段不能重名 （6）标点符号： 必须成对必须英文状态下半角输出形式字符串和日期类型能够应用单引号’’列的别名能够应用双引号""，给表名取别名不要应用双引号。取别名时as能够省略如果列的别名没有蕴含空格，能够省略双引号，如果有空格双引号不能省略。（7）SQL脚本中如何加正文 单行正文：#正文内容单行正文：–空格正文内容 其中–前面的空格必须有多行正文：/ 正文内容 /#以下两句是一样的，不辨别大小写show databases;SHOW DATABASES;#创建表格#create table student info(...); #表名谬误，因为表名有空格create table student_info(...); #其中name应用``飘号，因为name和零碎关键字或零碎函数名等预约义标识符重名了。CREATE TABLE t_stu( id INT, `name` VARCHAR(20));select id as "编号", `name` as "姓名" from t_stu; #起别名时，as都能够省略select id as 编号, `name` as 姓名 from t_stu; #如果字段别名中没有空格，那么能够省略""select id as 编 号, `name` as 姓 名 from t_stu; #谬误，如果字段别名中有空格，那么不能省略""第二章-DDL操作数据库2.1、创立数据库(把握)语法create database 数据库名 [character set 字符集][collate 校对规定] 注: []意思是可选的意思字符集(charset)：是一套符号和编码。 ...

作者：烧鸡太子爷 起源：恒生LIGHT云社区 Flyway是什么随着我的项目CICD接入,一键启动,麻利开发曾经成为降本提效的不二法宝,其中波及SQL的变更还不够智能和自动化,因而亟需一款工具可能帮忙开发及运维人员高效简便地实现SQL变更,Flyway正是能够满足咱们需要的一款工具。 当咱们关上Flyway的官网，在首页能够看到对于Flyway的一段英文介绍： Flyway是数据库的版本控制，跨所有环境的持重架构演变。轻松、欢快和简略的SQL。 总的来说，Flyway是一款专为CI/CD打造的，能对数据库变更做版本控制的工具。 Flyway反对的数据库很多，支流的数据库都可能完满反对，官网摘抄如下： Supported databases are Oracle, SQL Server (including Amazon RDS and Azure SQL Database), Azure Synapse (Formerly Data Warehouse), DB2, MySQL (including Amazon RDS, Azure Database & Google Cloud SQL), Aurora MySQL, MariaDB, Percona XtraDB Cluster, TestContainers, PostgreSQL (including Amazon RDS, Azure Database, Google Cloud SQL, TimescaleDB, YugabyteDB & Heroku), Aurora PostgreSQL, Redshift, CockroachDB, SAP HANA, Sybase ASE, Informix, H2, HSQLDB, Derby, Snowflake, SQLite and Firebird. ...

之前在应用sql进行查问时，如果是须要关联多表，通常都是应用的join这个语法 1、join on 这语法的了解，用一个场景来表述更分明：（信息不再一个表当中，而是离开在两个表，须要用其中一个表为条件(如会员)，进行获取会员对应的信息） 有3张表：会员绑定表、会员信息表、会员解绑表 当初要查绑定表中，也就是以后是会员的会员信息，就是须要绑定表外面会员的信息 然而绑定表只有会员绑定信息，无会员根底信息，此时就须要用join这个语法，把绑定表外面的会员和会员信息表外面的会员关联起来，取他们的交加，也就是以后会员的信息。 select from 会员表 a join 会员信息表 b on a.member_id = b.id where 条件 (能够获取对应表的数据) 同理会员解绑的信息也能够进行等同形式进行解决 2、union 我对union的了解，也用方才那个场景来进行阐明， 如果我须要全副用户的信息，用户的定义包含会员和非会员，此时独自用会员或非会员都无奈满足这个条件 所以第一步就能够先把会员绑定表、会员解绑表这两个表通过union来组合成一个表 select member_id from 表1 union select member_id from 表2 组成表 a 再用表a和会员信息表进行绑定 心愿对大家有帮忙！

简介：本次课程次要分为三大部分，首先将介绍慢调用的危害以及常见的起因；其次介绍慢调用的分析方法以及最佳实际；最初将通过几个案例来去演示一下慢调用的剖析过程。作者：李煌东 大家好，我是阿里云的李煌东。明天我为大家分享 Kubernetes 监测公开课第四节，如何应用 Kubernetes 监测定位慢调用。明天的课程次要分为三大部分，首先我会介绍一下慢调用的危害以及常见的起因；其次我会介绍慢调用的分析方法以及最佳实际；最初通过几个案例来去演示一下慢调用的剖析过程。 慢调用危害及常见起因 在开发软件过程中，慢调用是十分常见的异样。慢调用可能带来的危害包含： 前端业务维度：首先慢调用可能会引起前端加载慢的问题，前端加载慢可能会进一步导致利用卸载率高，进而影响品牌的口碑。我的项目交付的维度：因为接口慢导致达不到 SLO，进而导致我的项目延期。业务架构稳定性：当接口调用慢时，非常容易引起超时，当其余业务服务都依赖这个接口，那么就会引发大量重试，进而导致资源耗尽，最终导致局部服务或者整个服务不可用的雪崩的景象。所以，看似一个无关痛痒的慢调用可能暗藏着微小危险，咱们应该引起警觉。对慢调用最好都不要去漠视它，应该尽可能去剖析其背地的起因，从而进行危险管制。 产生慢调用的起因有哪些？产生慢调用的起因是千千万万的，归纳起来有五个常见起因。 第一个是资源使用率过高问题，比如说 CPU 内存、磁盘、网卡等等。当这些使用率过高的时候，非常容易引起服务慢。第二个是代码设计的问题，通常来说如果 SQL 它关联了很多表，做了很多表，那么会十分影响 SQL 执行的性能。第三个是依赖问题，服务本身没有问题，但调用上游服务时上游返回慢，本身服务处于期待状态，也会导致服务慢调用的状况。第四个是设计问题，比如说海量数据的表十分大，亿级别数据查问没有分库分表，那么就会非常容易引起慢查问。相似的状况还有耗时的操作没有做缓存。第五个是网络方面问题，比如说跨洲调用，跨洲调用是物理间隔太大了，导致往返工夫比拟长，进而导致慢调用。或者两点之间的网络性能可能比拟差。比如说有丢包重传率，重传率高的问题。明天咱们的例子围绕这五个方面，咱们一起来看一下。 定位慢调用一般来说有什么样的步骤，或者说有什么样的最佳实际呢？我这里总结的为三个方面：黄金信号 + 资源指标 + 全局架构。  咱们先来看一下黄金信号。首先，黄金信号是出自谷歌 SRE 圣经外面的 Site Reliability Engineering 一书。用来表征零碎是否衰弱的最小指标的汇合，这其中包含： 延时--用来形容零碎执行申请破费的工夫。常见指标包含均匀响应工夫，P90/P95/P99 这些分位数，这些指标可能很好的表征这个零碎对外响应的快还是慢，是比拟直观的。流量--用来表征服务忙碌水平，典型的指标有 QPS、TPS。谬误--也就是咱们常见的相似于协定里 HTTP 协定外面的 500、400 这些，通常如果谬误很多的话，阐明可能曾经呈现问题了。饱和度--就是资源水位，通常来说靠近饱和的服务比拟容易呈现问题，比如说磁盘满了，导致日志没方法写入，进而导致服务响应。典型的那些资源有 CPU、 内存、磁盘、队列长度、连接数等等。除了黄金信号，咱们还须要关注一个资源指标。驰名的性能剖析大神 Brandan Gregg ，在他的性能剖析方法论文章中提到一个 USE 办法。USE 办法是从资源角度进行剖析，它是对于每一个资源去查看 utilization（使用率），saturation （饱和度），error（谬误） ，合起来就是 USE 了，查看这三项基本上可能解决 80% 的服务问题，而你只须要破费 5% 的工夫。  后面有了黄金信号、资源指标之后，咱们还须要关注什么？正如 Branda 在方法论外面提到的“咱们不能只见树木，不见森林”。诸葛亮也说过“不谋全局者，不足以谋一域”。咱们应该把零碎架构画进去，从全局去看性能问题，而不只是看某个资源、某个服务。把所有货色进行综合思考，辨认出瓶颈所在，通过设计办法系统性解决问题，这也是一种更优的办法。所以，咱们须要黄金信号、资源指标以及全局架构这种组合。  慢调用最佳实际接下来我会讲三个案例，第一个是节点 CPU 打满问题，这也是典型的资源问题导致的服务慢的问题，即服务本身的资源导致的问题。第二个是依赖的服务中间件慢调用的问题。第三个是网络性能差。第一个案例是判断服务本身有没有问题；第二个案例是判断上游服务的问题；第三个就是判断本身跟服务之间的网络性能问题。 咱们以一个电商利用举例。首先流量入口是阿里云 SLB，而后流量进入到微服务体系中，微服务外面咱们通过网关去接管所有流量，而后网关会把流量打到对应的外部服务外面，比如说 ProductService、CartService、 PaymentService 这些。上面咱们依赖了一些中间件，比如说 Redis 、MySQL 等等，这整个架构咱们会应用阿里云的 ARMS 的 Kubernetes 监测产品来去监测整个架构。故障注入方面，咱们会通过 chaosblade 去注入诸如 CPU 打满、网络异样等不同类型的异样。 ...

前 言2021到了最初一个月份，年后必定有蛮多小伙伴须要跳槽换工作，但对于年限稍短的软件测试工程师，难免会须要进行口试，而在口试中，根本都会碰到一道对于数据库的大题，明天这篇文章呢，就收录了下最近学员反馈上来的一些数据库口试真题，蕴含答案！ 1、根据以下学生表、班级表，按要求写 SQL 答案：1、select * from student aleft join class b on a.c_id = b.idwhere score = (select max(score) from student)2、select b.name,count(*),avg(score) as avgScore from student a,class bwhere a.c_id = b.idgroup by b.nameorder by avgScore; 2、Table A 保留客户的根本信息；Table B 保留客户的资产负债信息。按要求写 SQL 答案：（1）select ID from A where name = '李四';（2）select NO,NAME，ID from A,B where A.NO = B.NO AND DEPOSIT >= 1000;（3）select COUNTRY,count(*) FROM A GROUP BY COUNTRY;（4）SELECT '80 后' as 年龄段，sum(CREDIT) AS '信用卡余额' FROM A,B WHERE A.NO = B.NO AND BIRTH >= 19800101 AND BIRTH < 19900101UNIONSELECT '90 后' as 年龄段，sum(CREDIT) AS '信用卡余额' FROM A,B WHERE A.NO = B.NO AND BIRTH >= 19900101 AND BIRTH < 20000101; ...

简介：阿里云开发者学堂出品了近千门课程，在数据库畛域中哪几门课程最受开发者们的青眼呢？小助手来揭秘！阿里云开发者学堂为了不便开发者，推出了近千门的收费课程供开发者们学习，课程蕴含云计算、大数据、数据库、云原生等泛滥畛域。课程会集常识碎片，为开发者们解决技术难题。开发者学堂学习核心：https://developer.aliyun.com/course/explore 本期举荐开发者学堂数据库畛域TOP10课程，榜单来啦NO.1【MySQL高级利用 - 索引和锁】—14000+人学习课程地址：https://developer.aliyun.com/learning/course/598 MySQL 是目前最风行的关系型数据库管理系统，在 WEB 利用方面 MySQL 也是目前最好的 RDBMS 应用软件之一。 本教程次要讲授针对 Java 开发所需的 MySQL 高级常识，课程中会让大家疾速把握索引，如何防止索引生效，索引的优化策略，理解innodb和myisam存储引擎，相熟MySQL锁机制，能纯熟配置MySQL主从复制，熟练掌握explain、show profile、慢查问日志等日常SQL诊断和性能剖析策略。 NO.2【企业Web罕用架构LAMP-LNMP实战】— 12000+人学习课程地址：https://developer.aliyun.com/learning/course/385 本课程针对企业级罕用的web运维技术Linux+Apache+MySQL+PHP以及Linux+Apache+MySQL+PHP架构进行讲述，从架构平台的部署、调试、故障剖析、架构调优等方面别离开展介绍，可能帮忙开发者迅速把握Web运维技能。 NO.3【Linux MySQL服务器搭建与利用】—11000+人学习课程地址：https://developer.aliyun.com/learning/course/578 本课程向开发者们讲述了数据库的发展史，深度解说了数据库原理。同时也帮忙开发者更快学习关系型数据库标准、 MySQL装置和基本操作、MariaDB的二进制装置和实战、源代码编译装置MySQL和多实例常识。 NO.4【HBase入门教程】—10000+人学习课程地址：https://developer.aliyun.com/learning/course/397 HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了相似于Bigtable的能力。 HBase是Apache的Hadoop我的项目的子项目。HBase不同于个别的关系数据库，它是一个适宜于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。 NO.5【云数据库 Redis 版应用教程】 —9000+人学习课程地址：https://developer.aliyun.com/learning/course/434 云数据库Redis版是兼容Redis协定规范的、提供长久化的内存数据库服务，基于高牢靠双机热备架构及可无缝扩大的集群架构，满足高读写性能场景及容量需弹性变配的业务需要。 NO.6【疾速把握 MongoDB 数据库】—7500+人学习课程地址：https://developer.aliyun.com/learning/course/400 本课程次要解说MongoDB数据库的基本知识，包含MongoDB数据库的装置、配置、服务的启动、数据的CRUD操作函数应用、MongoDB索引的应用（惟一索引、天文索引、过期索引、全文索引等）、MapReduce操作实现、用户治理、Java对MongoDB的操作反对（基于2.x驱动与3.x驱动的齐全解说）。 通过学习此课程，读者将具备MongoDB数据库的开发能力，并且可能应用MongoDB进行我的项目开发。 NO.7【PostgreSQL云上开发实际】—6800+人学习课程地址：https://developer.aliyun.com/learning/course/528 PostgreSQL被业界誉为“最先进的开源数据库”，面向企业简单SQL的OLTP业务场景，反对NoSQL数据类型（JSON/XML/hstore）、提供阿里云自研Ganos多维多模时空信息引擎，及PostGIS地理信息引擎。 RDS PostgreSQL是先进的开源数据库，它的长处次要集中在对SQL标准的残缺实现以及丰盛多样的数据类型反对，包含JSON数据、IP数据和几何数据等。除了完满反对事务、子查问、多版本控制（MVCC）、数据完整性查看等个性外，RDS PostgreSQL还集成了高可用和备份复原等重要性能，加重您的运维压力。 NO.8【云数据库MongoDB版应用教程】—6000+人学习课程地址：https://developer.aliyun.com/learning/course/435 云数据库MongoDB版反对ReplicaSet和Sharding两种部署架构，具备平安审计，工夫点备份等多项企业能力。在互联网、物联网、游戏、金融等畛域被宽泛采纳。 云数据库MongoDB版（ApsaraDB for MongoDB）齐全兼容MongoDB协定，基于飞天分布式系统和高牢靠存储引擎，提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 NO.9【云数据库HBase版应用教程】—5600+人学习课程地址：https://developer.aliyun.com/learning/course/436 面向大数据畛域的一站式NoSQL服务，100%兼容开源HBase并深度扩大，反对海量数据下的实时存储、高并发吞吐、轻SQL剖析、全文检索、时序时空查问等能力，是风控、举荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库，是为淘宝、支付宝、菜鸟等泛滥阿里外围业务提供要害撑持的数据库。 NO.10【SQL Server on Linux入门教程】—4000+人学习课程地址：https://developer.aliyun.com/learning/course/386 SQL Server数据库始终只提供Windows下的版本。2016年微软发表推出可运行在Linux零碎下的SQL Server数据库，该版本目前还是晚期预览版本。 本课程次要介绍SQLServer On Linux的基本知识。 下期预报：云原生畛域top 5课程 举荐及解密 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

好将来（NYSE：TAL）是一家以智慧教育和开放平台为主体，以素质教育和课外辅导为载体，在寰球范畴内服务公办教育，助力民办教育，摸索将来教育新模式的科技教育公司。截至2020年11月底，好将来在102个城市建设起990个教学点，业务范围覆盖全国331个地级市以及海内20多个国家和地区。 随着业务的倒退，实时数据的剖析需要日益增多，尤其在营销举荐、归因剖析、业务辅助决策等场景下，实时数据分析所带来的效益晋升是离线数据所不能比较的。在这些业务场景的驱动下，好将来抉择了StarRocks来撑持实时数据的剖析利用。实现了数据秒级查问响应能力，构建了一个对立&疾速&高效&灵便的实时数仓。 “ 作者：王岳， 好将来数据迷信组负责人，专一于数仓建设、数据分析、算法等畛域钻研。 ”业务背景业务场景分类在教育场景下，依据数据时效性划分，数据分析解决可分为离线和实时两大部分： 离线 离线数据以8大数据域（日志、营销、交易、服务、教学、内容、学习、画像）建设为主，次要解决外围历史数据，解决“业务经营、分析师、算法”等海量数据多维度剖析和开掘等，采纳批处理的形式定时计算。 实时 实时数据分析解决，次要包含由埋点产生的各种日志数据，数据量大，以结构化或半结构化类型为主；另外还包含由业务交易产生的业务数据，通常应用数据库的Binlog获取。 实时数据分析的需要越来越多，特地是在营销签单业务和在读学员是否续报等场景，须要实时数据来助力业务营销付费和续费指标达成。当指标没实现时，业务经营须要对数据进行多维度剖析，找到起因，并疾速做出决策调整等治理动作。 业务痛点T+1的离线数据分析曾经无奈满足业务对时效性的需要，咱们心愿建设实时数仓来反对业务实时数据分析场景，解决如下痛点： 市场：想通过广告页投放策略，洞悉PV、UV等流量数据，如果出现异常，可疾速剖析和优化。但之前因为各种因素咱们无奈提供实时数据，对于业务来说T+1数据时效性滞后，参考价值无限。销售：通过剖析动向用户跟进和签单数据，依据当日销售指标，及时发现还有哪些治理动作须要优化。但目前是提供滞后数据，每日签多少单都通过人来统计，剖析也是通过历史数据，剖析成果很差。在读学员续报：实时观测哪些学员续报了，老师须要做哪些续报动作。课堂行为剖析：剖析课堂实时互动行为、答题行为等，阶段评测报告、课堂品质等。算法模型：实时更新模型须要的特色数据，更准时的预测模型成果。实时数仓指标数据团队要提供灵便&丰盛的分钟级的实时数据，并要保证数据的丰富性&准确性&及时性等。 丰富性 沿用离线数仓建模好的数据维度和指标，保障离线能用到的，实时也能用到。 准确性 实时指标的构建须要能够保障数据完整性和准确性。所有指标开发依照指标定义文档，线上应用DQC平台来监控数据准确性，实时发送异样数据等。 及时性 要保证数据的“陈腐”度，线上实时产生的业务数据和日志数据，要能及时地被用于数据分析，晋升一线人员或业务的反馈速度。 实时数仓技术架构演进实时数仓的摸索过程中，咱们先后经验了如下几个阶段： 2018年~2019年，基于Hive框架下的小时级任务计划；2019年，基于Flink+Kudu的实时计算计划；2020年至今，基于StarRocks的实时数仓技术架构。基于Hive在原有天级提早的离线数据处理工作根底上，开发小时级提早的数据处理链路，将外围数据按小时同步到Hive数仓中，每小时调度一次DAG工作，实现小时级任务计算。工作DAG示意图如下所示： 长处： 离线和小时级任务各自独立代码逻辑复用性高，缩小开发成本能够应用离线数据笼罩小时级数据，进行数据修复毛病： 小时级数据的提早性还是很高，已无奈满足业务对数据时效性的要求MapRecude不适宜分钟级频次的任务调度，次要是MapReduce工作启动慢，另外会过高的频次会产生很多小文件，影响HDFS的稳定性，以及SQL on Hadoop零碎的查问速度批量数据处理每次运行对资源要求高，尤其是当凌晨Hadoop资源缓和时，工作常常无奈失去调度，提早重大基于Flink+Kudu为了解决下面基于MapReduce小时级任务的问题，咱们采纳了流式解决零碎Flink和反对增量更新的存储系统Kudu。 如上图所示，实时的日志数据通过Flume采集到Kafka，实时的业务数据通过canal实时同步数据库的binlog再转发到Kafka中，Flink再实时生产Kafka中的数据写入Kudu中。 在应用Flink+Kudu的实际中，咱们遇到了如下几个问题： Flink 基于 stream 语义，做简单指标计算非常复杂，门槛高，开发效率不高，数据仓库更多应用批处理SQLKudu+Impala聚合查问效率不高，查问响应工夫不能满足业务多维分析要求应用Kudu须要依赖Impala、Hive等整个Hadoop组件，保护老本太高Kudu社区不沉闷，遇到问题很难找到相干解决方案，应用过程中遇到过宕机等各类疑难问题基于StarRocks基于下面计划的问题，咱们开始对实时数仓进行调研，包含 StarRocks、ClickHouse、Kylin等零碎，思考到查问性能、社区倒退、运维老本等多种因素，咱们最初抉择 StarRocks 作为咱们的实时数仓，各零碎的比照总结如下： 咱们也深刻思考过ClickHouse，对于教育场景，一个学员要关联的数据维度多，包含课堂、服务、订单、教研等。在每个主题咱们都会建设灵便且易用的星型数据模型。当业务想进行个性化自助剖析时，仅须要关联相干表即可。但如果间接构建明细大宽表，随着业务一直调整，常常须要重构开发。这种状况下，ClickHouse的 join 能力弱，无奈满足需要，而StarRocks强悍的Join能力，就成了咱们应答业务变动的利器。而且 StarRocks反对CBO（基于老本统计的优化器），具备简单查问的优化能力，从而能够疾速的进行简单实时微批处理工作，能够帮忙咱们更好的进行实时指标构建。 最终抉择StarRocks的起因： 应用StarRocks能够让咱们像开发离线Hive工作一样进行实时数仓的开发，防止了简单的Flink stream语义，同时也能在性能上对齐离线指标，保障指标丰富性的根底上实现指标定义口径的统一，并且能够保障分钟级的数据可见性。大宽表和星型模型的查问性能都很好，能够灵便高效的满足各类业务剖析要求。StarRocks 简略易用，运维治理成本低基于StarRocks的实时数仓架构零碎搭建 整个零碎，除了StarRocks集群之外，咱们还搭建了上面两个配套零碎 调度：应用Airflow，进行DAG任务调度监控：应用grafana+prometheus，采集StarRocks信息并进行实时监控实时数仓总体架构 基于StarRocks的实时数仓总体架构，次要包含上面三个局部： 数据源：业务数据（应用Flink实时同步mysql的binlog日志，写入到Kafka）、日志数据（包含H5小程序、APP、直播ipad客户端等埋点采集的各类日志数据，通过Flume写入到Kafka中） 数据存储： 采纳 StarRocks的Routine Load间接生产Kafka中的日志和业务数据应用StarRocks的Broker Load将Hadoop中的DWD、DWS、ADS等数据导入到StarRocks中对于Flink等流式解决下零碎，应用StarRocks的Stream Load形式实时将数据导入StarRocks数据利用： 应用DataX能够将StarRocks数据导出到MySQL中应用StarRocks的Export能够将StarRocks中的数据导出到HDFS中StarRocks齐全兼容Mysql协定，BI或业务零碎能够应用Mysql Connector间接连贯StarRocks进行应用实时数仓数据处理流程 在实时数仓外部，也是依照传统离线数仓的形式，对数据处理进行分层解决： ODS层，设置StarRocks的Routine Load距离30秒生产一次Kafka数，写入到ODS表中DWD层，按业务剖析的须要建模DWD表，通过Airflow距离5分钟，将ODS表中过来5分钟的增量数据写入到DWD表中DWS层，对DWD表中的维度进行轻度或中度汇总，能够放慢下层查问速度BI层，通过自研的一个指标定义工具，剖析人员能够疾速的基于DWS构建报表，也能够衍生出一些复合指标进行二次加工。分析师也能够将取数口径中的SQL做长期批改，生成一个简单跨主题查问SQL，来应答一些Adhoc需要场景。StarRocks实时数仓具体利用在好将来，为保障课堂上课数据、订单数据的实时剖析要求，应用StarRocks撑持了课堂、订单等剖析业务。上面以课堂、订单场景为例，从数据同步、数据加工等几个步骤拆解StarRocks在好将来利用场景的落地计划。 实时数据同步在好将来，采纳flink采集业务库的binlog数据，而后写入到kafka中，StarRocks只须要生产kafka对应的topic数据即可，整体流程如下图： 实时数仓数据处理StarRocks外部的实时数据加工解决次要有如下操作： 缩短计算链路的长度，实时局部最多计算2层。dwd或dws层增量计算，采纳StarRocks的UNIQUE KEY模型，相当于(insert + update)，因而只计算增量局部即可采纳工夫分区，多正本策略。既为了数据安全，又能防止锁表离线表构造与实时表构造，放弃一样，这样就能够用离线修复T + 1 数据 ...

逾越速运团体有限公司创立于2007年，目前服务网点超过3000家，笼罩城市500余个，是中国物流服务行业独角兽企业。逾越团体大数据中心负责全团体所有数据平台组件的建设和保护，撑持20余条外围业务线，面向团体5万多员工的应用。目前，大数据中心已建设数据查问接口1W+，每天调用次数超过1千万，TP99在1秒以下。咱们利用StarRocks作为通用查问引擎，无效解决了原架构大量查问返回工夫过长，性能达不到预期的问题。 “ 作者：张杰， 逾越团体大数据运维架构师，负责集团公司大数据平台的保护和建设 ”业务背景总体架构咱们原始离线数仓的总体架构如下图所示，数据从各个业务线的数据库，比方MySQL等，通过数据集成工具汇聚到ETL集群（即Hadoop集群），再应用Hive、Spark、Presto等批量解决引擎进行数据仓库的分层解决，而后将DW层和ADS层的数据推送到各种不同的查问引擎。 在这些查问引擎之上，有个对立的查问API网关，应用层的自助剖析工具或ERP零碎前端通过调用这个API网关，将数据内容出现给用户。 业务痛点该零碎最大的痛点是查问性能问题。公司对大数据查问接口的响应提早是有考核的，冀望99%的查问申请都能在1秒内返回，比方页面ERP零碎、手机端各类报表APP，用户会随时查看数据并进行生产环节调整，过慢的查问响应会影响用户体验，甚至影响业务生产。针对简单的SQL查问场景，之前采纳的Presto、Impala+Kudu、ClickHouse等零碎，是远远达不到预期的。另外，针对各种简单的数据分析业务场景，引入很多不同组件，导致了保护和应用老本十分高。 因而，咱们急需一个新的查问引擎，能对立查问引擎，解决性能查问问题，升高应用和保护老本。 OLAP引擎选型 第一阶段，在2019年，逾越团体大数据中心应用Presto作为通用的查问引擎。此阶段团体大数据中心数仓层根本用的是Hive，Presto能够直连Hive的个性让咱们无需做过多的革新，就能够间接生成查问的API。从性能角度思考，咱们也会将数仓中的局部数据拷贝至独立的Presto集群，和数仓ETL集群进行资源隔离。这套架构运行一年多之后，随着业务需要越来越简单，数据量越来越大，该基于Presto构建的集群性能急剧下降。 第二阶段，为解决Presto集群性能有余的缺点，咱们基于ClickHouse开始构建新的通用查问引擎。2020年咱们应用ClickHouse构建了大量大宽表，将此前须要多层关联的查问逐渐迁徙到ClickHouse集群。通过这种形式，咱们的确解决了此前面临的性能问题。但与此同时，咱们须要建设越来越多的大宽表，操作繁琐运维艰难。并且这种数据模型无奈随业务需要变动而疾速扭转，灵活性差。 第三阶段，咱们在2021年开始寻找其余能满足咱们需要的OLAP引擎，此时咱们发现了StarRocks这个产品。首先关注到StarRocks的单表、多表关联查问的性能都十分优良，可能满足咱们对查问延时的需要；StarRocks反对MySQL协定，让咱们开发共事在开发接口的时候学习和应用门槛非常低。另外，StarRocks还具备反对按主键更新、反对多种类型表面、部署运维简略以及反对丰盛的数据导入形式等个性。这些都是咱们所须要的。 因而，咱们开始逐渐将以往的剖析业务迁徙到StarRocks集群上，将StarRocks作为大数据中心的通用查问引擎。 StarRocks在逾越团体的利用在线场景利用以后咱们每天在线数据接口的查问申请量曾经超过千万。在引入StarRocks前，咱们用了8到9种查问引擎来撑持各种在线业务场景。大数据量的明细点查场景应用ElasticSearch作为撑持；对于查问维度固定、能够提前预计算的报表场景，会应用MySQL；对于SQL查问简单，如果多表Join、子查问嵌套的查问场景，会应用Presto；实时更新的场景，则会应用Impala+Kudu的组合来撑持。 引入StarRocks后，目前已替换掉Presto和Impala+Kudu撑持的场景。ElasticSearch、MySQL以及ClickHouse，后续也可能会依据业务场景理论状况逐渐替换为StarRocks。 上面具体介绍一个理论在线场景的典型案例。如上图，咱们在原Presto零碎上有一个蕴含200个字段的宽表聚合查问。因为业务需要比较复杂，SQL语句有600多行。咱们曾心愿从业务逻辑上进行优化，然而并不容易，不能因为零碎能力问题就一味要求业务方来迁就。当初咱们应用10个节点雷同配置的StarRocks替换原15台雷同配置服务器的Presto集群后，在没有做什么业务逻辑变动的状况下，应用StarRocks明细模型，凭借StarRocks自身的高性能将查问延时从5.7秒升高为1秒，性能是原Presto集群的近6倍。 OLAP场景利用逾越团体的OLAP多维分析平台是咱们自研的一套BI零碎。用户能够依据本人业务场景抉择字段以及关联条件等，以利落拽的形式生成数据的表格或图表。最早咱们撑持OLAP多维分析的后端引擎是Presto，在这类场景下的性能的确不尽如人意。因为性能问题，咱们也没方法将这个工具推广给更多的用户应用。咱们将后端查问引擎替换为StarRocks后，性能晋升非常明显。咱们将OLAP多维分析平台向整个团体推广，受到了越来越多的用户好评。 OLAP多维分析次要是离线剖析为主，以客户离线剖析场景为例，数据通过ETL解决后，生成对应的DW层或ADS层数据，再通过Broker Load将数据按天导入StarRocks中。咱们应用星型模型构建客户主题域，客户主表以明细模型在StarRocks中建表，同样以明细模型创立维表。这样用户就能够在前端对客户主题域的各种指标、各种维度进行利落拽，生成对应的表格和图表。 在客户离线剖析场景下，咱们StarRocks上线前后业务逻辑没有进行太多调整前提下，TP99从4.5秒降落到1.7秒，性能是原来的三倍（后续咱们将尝试开启CBO优化器，预计会有更大性能晋升）。绝大多数场景都能实现1s内返回，大大晋升了用户的体验。 利用StarRocks的实时剖析能力，咱们还构建了实时OLAP多维分析。以运单实时剖析场景为例，本来咱们是用Hive每两小时跑批的形式来实现的，将固定维度数据算好，后果写入Presto上提供查问，逻辑相似于离线数仓，并不能称为真正的实时。引入StarRocks后，咱们调整数据流转逻辑，通过监听Binlog将数据写入Kafka，再通过Rontine Load的形式生产Kafka，将数据实时写入StarRocks中。咱们应用更新模型建设实时运单主表，将运单ID设置成主键，这样每一笔运单更新后，都能实时更新到运单主表中。和离线剖析场景一样，应用星型模型构建运单主题域。 通过这样的调整，以往每两小时更新数据的运单主题域，当初能够实现秒级更新，成为货真价实的实时剖析。另外此前须要依赖预计算，维度都是固定的，很多剖析上性能受限。经革新后，除了大幅晋升“实时”体验外，在剖析灵活性上的晋升也非常明显。实时体验和灵便剖析也成为OLAP多维分析平台工具在理论服务中最大的亮点。 后续布局1、 为了防止局部慢查问影响整体的集群性能，后续会搭建多套StarRocks集群，按业务场景进行物理资源隔离。 2、 StarRocks查问Hive表面的性能，经内部测试比Presto查问Hive的性能要好，后续会将本来Presto查问Hive的场景无缝迁徙到StarRocks上。 3、 目前咱们在StarRocks上写入了很多实时数据，这些数据须要进行聚合等解决，咱们正在尝试应用调度工具，在StarRocks上进行5分钟级、10分钟级的轻量ETL解决。 4、 开启StarRocks的CBO优化器，进一步晋升查问性能。 最初，感激鼎石为咱们提供StarRocks这么好的产品，满足了咱们对性能强、性能全的查问引擎产品的要求；感激鼎石始终以来提供的技术支持，解决了咱们在应用中遇到的各类问题。

前言在理论工程项目中，有时工程不仅仅须要和实时数据库进行数据交换，有可能还须要和关系数据库进行数据交换，为此提供了多种与关系数据库通信的形式。如：自在报表，全局函数，绑定表等。当然也有免费的数据转储组件，本节不做探讨。本节次要介绍前两种形式：自在报表，全局函数。 自在报表自在报表形式与关系数据库进行通信，首先在数据库中创立“报表关系数据源点”。该点在运行时负责和关系数据库进行联结，并且把从报表发来的命令转交关系数据库执行，并最终将关系数据库返回的后果传递给报表。1、创立报表关系数据源点2、创立报表，并关联报表关系数据源点3、执行SQL语句 函数参考： SqlSelectCmd(String csCmd)阐明：设置报表查问的Select语句。报表尽管能够设置初始的Select语句，然而在这里能够更改它。比方Select * from db where UpdateTime > #2006-06-01 00:00:00# 参数:csCmd: 须要设置的Select语句。 示例：#Rep.SqlSelectCmd("须要设置的Select语句");//设置报表查问的Select语句。SqlExeCmdNoRet(String csCmd)阐明：向“报表关系数据源点”发送不须要返回记录集的SQL命令。参数:csCmd: 须要设置的Select语句。 示例：#Rep.SqlExeCmdNoRet("Insert Into db Values('2006-06-26 15:30:23','A1.PV',123)")。SqlGetError() As String阐明：返回执行关系数据命令时返回的谬误，经常用在报表的返回谬误后果触发脚本上。 返回值:字符型，产生的谬误。示例：MsgBox(#rep.SqlGetError());//返回执行关系数据命令时返回的谬误。全局函数全局函数查问形式包含两种办法，第一种是间接应用全局函数的办法；第二种是表模板和绑定表联合的办法。本节介绍第一种，间接应用函数操作关系库。 应用全局函数查问形式，首先要利用SQLConnect函数与指定的数据库建设连贯，如果指定的近程数据库不存在，该函数可能要期待几十秒。当在web（蕴含StartWin）模式下时，缺省是通过实时数据库拜访关系库，为了间接拜访关系库，须要在应用SQLConnect之前执行语句：“SQLSetHost("NONE");”SQLSetHost函数用来设置执行SQL语句的机器，以便SQL脚本在该近程机器上运行。当关系数据库连贯应用完后，应该应用SQLDisconnect函数来断开连接。 1、SQLConnect函数连贯数据库 2、执行SQL语句SQLConnect函数里的ODBC串的获取：1、通过鼠标脚本里的数据源抉择性能抉择2、通过报表关系数据源点取得 相干函数： SQLConnect(Int& ConnectID, String SourceDesc) As Bool阐明：与指定的数据库建设连贯。如果指定的近程数据库不存在，该函数可能要期待几十秒。在web（蕴含StartWin）模式下缺省是通过DB拜访关系库,为了间接拜访关系库,须要在应用SQLConnect()之前执行语句：“SQLSetHost("NONE");”。参数:ConnectID: 数据源标识，为返回值，该值将用于其它后续SQL函数。SourceDesc: 数据源形容。数据源形容能够通过脚本中工具条按钮“SQL连贯“按钮失去。返回值:0为失败，1为胜利。示例：SQLConnect(ConnectID,"DSN=abc;DBQ=D:\abc.mdb;DriverId=25;FIL=MS Access;MaxBufferSize=2048;PageTimeout=5;UID=admin;");//与Access数据库文件abc.mdb建设连贯留神：参数必须为变量，返回函数执行后的数据。数据源应用完后，应用SQLDisconnect来断开连接。SQLExecute(Int ConnectID, String SqlCommand)阐明：执行SQL命令。参数:ConnectID: 数据源标识，由SQLConnect调用返回。SqlCommand: 要执行的SQL命令。返回值:无。示例：SQLExecute(ConnectID,"Select * From Mytab");//应用Connect关联的数据库，执行指定的SQL语句留神：该语句不能与其余语句配合应用，如示例中抉择的后果不在其余语句操作的数据集中，因而不能显示。视频演示 紫金桥知识库-理解紫金桥组态软件更多技术

Azure SQL Managed Instance （SQL托管实例）, 简称SQL MI,。它是一种智能、可缩放的云数据库服务；它将被宽泛应用的 SQL Server 数据库引擎兼容性与齐全托管的云平台及其所有劣势相结合。SQL 托管实例具备与最新 SQL Server (企业版) 数据库引擎近 100% 的兼容性，提供解决常见平安问题的本机虚构网络 (VNet)反对，它提供现有 SQL Server 客户习用的业务模型。同时，SQL 托管实例保留了所有 PaaS 性能（主动修补和版本更新、主动备份、高可用性），可大幅升高治理开销和总领有老本。 特色翻新 PaaS 劣势无需洽购和治理硬件不产生底层根底构造的治理开销疾速预配和服务缩放主动修补和版本升级与其余 PaaS 数据服务集成业务连续性99.99% 的运行工夫 SLA内置高可用性应用主动备份爱护数据客户可配置的备份保留期用户发动的备份数据库工夫点还原性能安全性和合乎性隔离的环境（VNet 集成、单租户服务、专用的计算和存储资源）通明数据加密 (TDE)Azure Active Directory (AAD) 身份验证、繁多登录反对Azure AD 服务器主体（登录名）遵循与 Azure SQL 数据库雷同的合规性规范SQL 审计高级威逼防护 可管理性用于主动预配和缩放服务的 Azure 资源管理器 API用于手动预配和缩放服务的 Azure 门户性能数据迁徙服务平安性能Azure SQL 托管实例提供一组可用于爱护数据的高级平安性能。 SQL 托管实例审核- 可跟踪数据库事件，并将其写入 Azure 存储帐户中的审核日志文件。审核可帮忙你始终放弃听从法规、理解数据库流动，以及深刻理解能够指明业务考量因素或疑似平安违规的偏差和异样。动态数据加密 - SQL 托管实例提供动态数据加密，应用传输层安全性爱护数据。除传输层安全性以外，SQL 托管实例还应用 Always Encrypted 在动静、动态和查询处理期间提供敏感数据的爱护。Always Encrypted 可针对波及要害数据被盗的破绽提供数据安全性。例如，借助 Always Encrypted，信用卡号即便在查询处理期间也始终加密存储在数据库中，容许经受权员工或须要解决该数据的应用程序在应用时进行解密。高级威逼防护是对审核的补充，它在服务中提供一个内置的附加平安智能层，用于检测希图拜访或应用数据库的异样的潜在无害尝试。呈现可疑流动、潜在破绽、 SQL 注入攻打和异样数据库拜访模式时，它会收回警报。能够从 Microsoft Defender for Cloud 查看高级威逼防护警报。它们可提供可疑流动的详细信息，以及如何考察和缓解威逼的举荐操作。动态数据掩码性能通过对非特权用户模糊化敏感数据来限度此类数据的透露。动态数据掩码容许指定在对应用层产生最小影响的前提下能够走漏的敏感数据量，从而帮忙避免未经受权的用户拜访敏感数据。它是一种基于策略的平安性能，会在针对指定的数据库字段运行查问后返回的后果集中暗藏敏感数据，同时放弃数据库中的数据不变。应用行级别安全性 (RLS) 可依据执行查问的用户特色（例如按组成员身份或执行上下文），管制对数据库表中的行的拜访。RLS 简化了应用程序中的安全性设计和编程。应用 RLS 可针对数据行拜访施行限度。例如，确保工作人员只能拜访与其部门相干的数据行，或者将可拜访的数据限度为相干的数据。通明数据加密 (TDE) 能够加密 SQL 托管实例数据文件，称为静态数据加密。TDE 针对数据和日志文件执行实时 I/O 加密和解密。加密应用数据库加密密钥 (DEK)，它存储在数据库疏导记录中，可在复原时应用。可应用通明数据加密爱护托管实例中的所有数据库。TDE 是 SQL Server 中教训证的动态加密技术，许多合乎性规范都须要它来避免存储介质被盗。通过 Azure 数据库迁徙服务或本机还原来反对将加密数据库迁徙到 SQL 托管实例。如果打算应用本机还原迁徙加密数据库，则必须将现有 TDE 证书从 SQL Server 实例迁徙到 SQL 托管实例。 ...

 结构化查询语言(Structured Query Language)：是一种非凡目标的编程语言，是一种数据库查问和程序设计语言，用于存取数据以及查问、更新和治理关系数据库系统。 数据查询语言（DQL）：SELECT(查问) 数据操作语言（DML）：INSERT(插入)、UPDATE(批改)、DELETE(删除) 一、常见的MySql的数据类型： 文本：varchar、text、longtext 数字：int、tinyint、bigint、float、double 日期：date（2021-07-15）、datetime（2021-11-03 15:31:05） 二、SQL常见语法1、训练数据集，共四个表文件Course、Student、Score、Teacher 2、INSERT语法：在表文件中插入数据 INSERT INTO 表名称 VALUES(值1,值2,……); INSERT INTO 表名称(列1,列2,……) VALUES(值1,值2,……),(值1,值2,……),……; 注：关键字之间要有空格，如果不是多条语句同时执行，语句后的分号(;)能够省略 3、DELETE语法：删除表文件中局部数据 DELETE FROM 表名称 (WHERE 列名称 = 值) 4、UPDATE语法：批改表文件中数据 UPDATE 表名称 SET 列名称1 = 新值, 列名称2 = 新值, …… WHERE 列名称 = 某值 5、SELECT语法：查问语句 整体语法：SELECT 列名称1 AS 列1, 列名称2 AS 列2, …… FROM 表名称 (WHERE 列名称 = 某值 ORDER BY 列名称 ASC/DESC LIMIT 数字1,数字2 ) 示例： SELECT s_id AS '学号', s_name, s_birthday, s_sex FROM student WHERE s_id < 5 ...

博主(编码砖家)负责的我的项目次要采纳阿里云数据库MySQL，最近频繁呈现慢SQL告警，执行工夫最长的居然高达5分钟。导出日志后剖析，次要起因居然是没有命中索引和没有分页解决 。 其实这是十分低级的谬误，我不禁后背一凉，团队成员的技术水平亟待进步啊。革新这些SQL的过程中，总结了一些教训分享给大家，如果有谬误欢送批评指正。 MySQL性能最大数据量抛开数据量和并发数，谈性能都是耍流氓 。MySQL没有限度单表最大记录数，它取决于操作系统对文件大小的限度。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB，才举荐分库分表。性能由综合因素决定，抛开业务复杂度，影响水平顺次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考，并非铁律。博主已经操作过超过4亿行数据的单表，分页查问最新的20条记录耗时0.6秒，SQL语句大抵是 select field_1,field_2 from table where id < #{prePageMinId} order by id desc limit 20，prePageMinId是上一页数据记录的最小ID。尽管过后查问速度还对付，随着数据一直增长，有朝一日必然不堪重负。分库分表是个周期长而危险高的大活儿，应该尽可能在以后构造上优化，比方降级硬件、迁徙历史数据等等，切实没辙了再分。对分库分表感兴趣的同学能够浏览分库分表的根本思维。 最大并发数并发数是指同一时刻数据库能解决多少个申请，由maxconnections和maxuserconnections决定。**maxconnections是指MySQL实例的最大连接数，上限值是16384，maxuserconnections是指每个数据库用户的最大连接数。MySQL会为每个连贯提供缓冲区，意味着耗费更多的内存。如果连接数设置太高硬件吃不消，太低又不能充分利用硬件。个别要求两者比值超过10%，计算方法如下： 查看最大连接数与响应最大连接数： 在配置文件my.cnf中批改最大连接数 查问耗时0.5秒倡议将单次查问耗时管制在0.5秒以内，0.5秒是个经验值，源于用户体验的 3秒准则 。如果用户的操作3秒内没有响应，将会腻烦甚至退出。响应工夫=客户端UI渲染耗时+网络申请耗时+利用程序处理耗时+查询数据库耗时，0.5秒就是留给数据库1/6的解决工夫。 施行准则相比NoSQL数据库，MySQL是个娇气软弱的家伙。它就像体育课上的女同学，一点纠纷就和同学闹别扭(扩容难)，跑两步就气喘吁吁(容量小并发低)，经常身材不适要销假(SQL束缚太多)。现在大家都会搞点分布式，应用程序扩容比数据库要容易得多，所以施行准则是 数据库少干活，应用程序多干活 。 充分利用但不滥用索引，须知索引也耗费磁盘和CPU。不举荐应用数据库函数格式化数据，交给利用程序处理。不举荐应用外键束缚，用应用程序保证数据准确性。写多读少的场景，不举荐应用惟一索引，用应用程序保障唯一性。适当冗余字段，尝试创立两头表，用应用程序计算两头后果，用空间换工夫。不容许执行极度耗时的事务，配合应用程序拆分成更小的事务。预估重要数据表(比方订单表)的负载和数据增长态势，提前优化。数据表设计数据类型数据类型的抉择准则：更简略或者占用空间更小。 如果长度可能满足，整型尽量应用tinyint、smallint、medium_int而非int。如果字符串长度确定，采纳char类型。如果varchar可能满足，不采纳text类型。精度要求较高的应用decimal类型，也能够应用BIGINT，比方准确两位小数就乘以100后保留。尽量采纳timestamp而非datetime。 相比datetime，timestamp占用更少的空间，以UTC的格局贮存主动转换时区。 防止空值MySQL中字段为NULL时仍然占用空间，会使索引、索引统计更加简单。从NULL值更新到非NULL无奈做到原地更新，容易产生索引决裂影响性能。尽可能将NULL值用有意义的值代替，也能防止SQL语句外面蕴含 is not null的判断。 text类型优化因为text字段贮存大量数据，表容量会很早涨下来，影响其余字段的查问性能。倡议抽取进去放在子表里，用业务主键关联。 索引优化索引分类一般索引：最根本的索引。组合索引：多个字段上建设的索引，可能减速复合查问条件的检索。惟一索引：与一般索引相似，但索引列的值必须惟一，容许有空值。组合惟一索引：列值的组合必须惟一。主键索引：非凡的惟一索引，用于惟一标识数据表中的某一条记录，不容许有空值，个别用primary key束缚。全文索引：用于海量文本的查问，MySQL5.6之后的InnoDB和MyISAM均反对全文索引。因为查问精度以及扩展性不佳，更多的企业抉择Elasticsearch。索引优化分页查问很重要，如果查问数据量超过30%，MYSQL不会应用索引。单表索引数不超过5个、单个索引字段数不超过5个。字符串可应用前缀索引，前缀长度管制在5-8个字符。字段唯一性太低，减少索引没有意义，如：是否删除、性别。正当应用笼罩索引，如下所示：select loginname, nickname from member where login_name = ? loginname, nickname两个字段建设组合索引，比login_name简略索引要更快 SQL优化分批解决博主小时候看到鱼塘挖开小口子放水，水面有各种漂浮物。浮萍和树叶总能顺利通过出水口，而树枝会挡住其余物体通过，有时还会卡住，须要人工清理。MySQL就是鱼塘，最大并发数和网络带宽就是出水口，用户SQL就是漂浮物。不带分页参数的查问或者影响大量数据的update和delete操作，都是树枝，咱们要把它打散分批解决，举例说明：业务形容：更新用户所有已过期的优惠券为不可用状态。SQL语句：update status=0 FROMcoupon WHERE expire_date <= #{currentDate} and status=1;如果大量优惠券须要更新为不可用状态，执行这条SQL可能会堵死其余SQL，分批解决伪代码如下： 操作符<>优化通常<>操作符无奈应用索引，举例如下，查问金额不为100元的订单：select id from orders where amount != 100;如果金额为100的订单极少，这种数据分布重大不均的状况下，有可能应用索引。鉴于这种不确定性，采纳union聚合搜寻后果，改写办法如下： ...

INFS2200/7903 PROJECT ASSIGNMENTSemester Two 2021 Total marks: 100 marks (25%)Due Date: 11:59PM, 28 October 2021What to Submit: SQL script file + short reportWhere to Submit: Electronic submission via BlackboardThe goal of this project is to gain practical experience in applying several databasemanagement concepts and techniques using the Oracle DBMS.Your main task is to first populate your database with appropriate data, then design,implement, and test the appropriate queries to perform the tasks explained in the nextsections.You must work on this project individually. Academic integrity policies apply. Pleaserefer to 3.60.04 Student Integrity and Misconduct of the University Policy for moreinformation.Roadmap: Section 1 describes the database schema for your project and it alsoprovides instructions on downloading the script file needed to create and populate yourdatabase. Section 2 describes the tasks to be completed for this project. Finally,Section 3 provides you with all the necessary submission guidelines.Enjoy the project!-----------------SECTION 1. THE MOVIES DATABASEThe Database: The MOVIES database (Figure 1) captures the information regardingmovies and the actors in these movies. The database includes six tables: film, actor,category, language, film_actor, and film_category. Film keeps track of film details.Actor stores information about all actors in the movie industry. Category stores theinformation about the different types of film categories. Language stores the differentlanguages in which these movies are released. Film_actor and film_category keeptrack of which actors have acted in which films, and which films are classified underwhich categories, respectively.Figure 1 Database schemaThe Script File: Please go to Blackboard and download the supplementary script filefor this project “prjScript.sql”.actor_idfilm_idfilm_idtitledescriptionrelease_yearlanguage_idoriginal_language_idrental_durationrental_ratelengthreplacement_costratingspecial_featuresfilm_idcategory_idlanguage_idnamecategory_idnameactor_idfirst_namelast_namefilm_category film film_actorcategory languageactorThe Database Constraints: The following table lists all the constraints that should becreated on the MOVIES database.No Constraint Name Table.Column Description1 PK_ACTORID actor.actor_id actor_id is the primary key ofactor2 PK_CATEGORYID category.category_id category_id is the primary keyof category3 PK_FILMID film.film_id film_id is the primary key of film4 PK_LANGUAGEID language.language_id language_id is the primary keyof language5 UN_DESCRIPTION film.description Film description values areunique6 CK_FNAME actor.first_name Actor’s first name must not beempty (not null)7 CK_LNAME actor.last_name Actor’s last name must not beempty (not null)8 CK_CATNAME category.name Category name must not beempty (not null)9 CK_LANNAME language.name Language name must not beempty (not null)10 CK_TITLE film.title Film title must not be empty(not null)11 CK_RELEASEYR film.release_year film.release_year is less than orequal to current year (Hardcodethe current year 2020)12 CK_RATING film.rating Rating type must be one of thefollowing: 'G', 'PG', 'PG-13', 'R','NC-17'13 CK_SPLFEATURES film.special_features Special features type must beeither empty or one of thefollowing: 'Trailers','Commentaries', 'DeletedScenes', 'Behind the Scenes'14 FK_LANGUAGEID film.language_idand language.language_idfilm.language_id refers tolanguage.language_id15 FK_ORLANGUAGEID film.original_language_idand language.language_idfilm.original_language_id refersto language.language_id16 FK_ACTORID film_actor.actor_id andactor.actor_idfilm_actor.actor_id refers toactor.actor_id17 FK_CATEGORYID film_category.category_idand category.category_idfilm_category.category_idrefers to category.category_id18 FK_FILMID1 film_actor.film_id andfilm.film_idfilm_actor.film_id refers tofilm.film_id19 FK_FILMID2 film_category.film_id andfilm.film_idfilm_category.film_id refers tofilm.film_idTable 1. Database constraints-----------------SECTION 2. ASSIGNMENT TASKSCreate and Populate Database: You need to execute the script file “prjScript.sql” tocreate and populate your database before working on the following tasks. Wait till yousee the message “DONE! All data has been inserted.” It should only take one minute.The script will also drop related tables.Task 1 – Constraints ...

2021年度腾讯数字大会有多硬核？ 此次嘉宾阵容和内容密度空前，并且首设Techo Day技术峰会； 产业首领亲历助阵，能够说是“半壁数字化产业“，最新科研成果都在这里了！！ 1场技术峰会、11场技术分论坛、100+演讲主题； 腾讯最高级别科学家、多位技术带头人联袂带来各种技术干货！ 2021.11.04 线上见！

根本应用数据库DataBase学习数据库次要学习的就是如何对数据进行增删改查操作平时所提到的数据库(DBMS数据库管理系统)实际上就是款软件, 电脑上装置了这个软件,电脑就能够成为数据库服务器常见的DBMS(数据库软件): MySQL: Oracle公司产品, MySQL在08年被Sun公司收买,09年Sun公司被Oracle收买, 目前市占率第一, 开源软件, 原MySQL创始人从Oracle到职开办MariaDBOracle: Oracle公司产品,闭源, 性能最强价格最贵, 市占率第二 , 拉里埃里森SQLServer: 微软公司产品, 市占率第三 , 闭源 . 次要利用在微软的整套解决方案中(开发网站须要用到的所有= 编程语言+web服务软件+操作系统+数据库软件)DB2: IBM公司产品,闭源 次要利用在IBM的整套解决方案中SQLite: 轻量级数据库, 安装包只有几十k, 性能只具备最根底的增删改查 .开源和闭源 开源: 凋谢源代码, 有技术大拿无偿保护降级, 产品收费 靠卖服务盈利闭源: 不凋谢源代码, 有黑客或技术大拿攻打,然而闭源公司有钱 雇人保护降级, 靠卖产品和卖服务盈利学习数据库次要是学习一门语言: SQL(Structured Query Language) 结构化查询语言 , 用于程序员和数据库软件之间进行交换执行SQL语句须要先连贯数据库软件 window: 开始->所有程序->MySQL或MariaDB->MySQL Client 点击 运行输出明码后回车Linux零碎: 在桌面上右键 关上终端, 输出 mysql -uroot -p 回车 输出明码再回车.如何查看MySQL服务是否开启? 在我的电脑上右键->治理->服务->MySQL 查看是否启动 如果没有,右键启动 SQL语句分类:DDL: 数据定义语言,DML: 数据操作语言DQL: 数据查询语言TCL: 事务管制语言DCL: 数据管制语言DDL数据定义语言包含数据库相干和表相干的SQL语句应用数据库软件保留数据须要先建库再建表数据库相干的SQL查问所有数据库 格局: show databases;创立数据库 格局: create database 数据库名;举例: ...

腾讯云TDSQL发明了国产数据库一项新的里程碑，这个里程碑，值得国内每一位技术人为之振奋。 9月30日，腾讯云正式对外发表企业级分布式数据库TDSQL金融外围零碎客户曾经超过20家，尤其在银行传统外围零碎畛域，位居国内第一营垒。 名单涵盖多家国有大行，及安全银行、张家港银行、昆山农商行等头部银行及宽泛金融行业机构。 除了TDSQL，目前国内还鲜有一款国产数据库，在银行的传统外围零碎胜利上线。 规模化投产银行外围零碎的国产数据库，是金融行业数据库利用国产化替换质的冲破。 20家，一个不算太大的数字 然而对于TDSQL及国产数据库行业来说，不仅点燃了金融科技国产化的星星之火，而且也吹响了国产数据库在金融外围零碎规模化利用的冲锋号。 何为金融外围零碎能不能胜利利用在银行的传统外围零碎上，是一款数据库胜利与否的试金石。 金融外围零碎是金融机构最为要害的IT零碎，零碎之上寄存着关系着国计民生的老百姓的资金，账号等重要信息，必须确保安全可靠，容不得有丝毫过错。 近年来，因为国际形势风云变幻，金融机构，尤其是银行业逐步开始尝试借助国产数据库技术代替传统的国外数据库。然而，出于对稳定性的高度审慎，国产数据库还是多被利用在互联网外围以及相干外围零碎中。 在业务品种繁多、流程简单的传统金融外围零碎中，始终被老牌国外几家数据库厂商把持，国产数据库想要涉足该畛域，一个字，难！ 说的直白一点，你的稳定性怎么保障？性能扛得住吗？呈现问题如何兜底？ 诞生于2007年的TDSQL，经验了腾讯业务的飞速发展，海量业务群雄并起时代，通过有数外围业务和亿级利用的刻薄打磨，在性能上逐步冲破了性能瓶颈、数据可靠性保障、高可用等“不可能三角”的技术难题，逐步在金融、政务等市场锋芒毕露。 技术很好，然而真正落地怎么样，没有人晓得. 业界需一位吃螃蟹的人来引领分布式数据库的这帮“信徒”，这个时候微众银行呈现了。 作为国内首家互联网银行，微众银行自成立之际就选用腾讯云企业级分布式数据库TDSQL作为其外围交易系统的数据库解决方案，来实现高性能、低成本、高可用、可扩大的分布式银行外围零碎架构，不仅创始了银行交易系统采纳国产分布式数据库的先河，还推动了普惠金融的数字化倒退。 目前，微众银行基于TDSQL搭建的分布式银行外围零碎，不仅能够做到7*24小时全天候不间断服务，还胜利服务超过2.7亿客户，实现年均日交易3.6亿笔，单日交易峰值近7.5亿笔，最高TPS（每秒传输的事物解决个数）达到10 万+，为微粒贷、微业贷等业务的数百个外围零碎提供了松软撑持。 再到起初，TDSQL相继助力张家港行实现国内银行业首家传统外围零碎数据库国产化、再到助力安全银行信用卡外围实现业界第一个将金融机构外围业务零碎由大型机集中式架构迁徙到国产分布式架构，TDSQL基于腾讯外部历年海量场景技术创新打磨，曾经实现根底技术系统升级翻新，助力我国产业实现更宽泛的数据库安全可控。 此外，在数据库国产化替换中包含政务、电信运营商等行业场景，TDSQL也实现了率先冲破，如在2021年中标某省挪动外围零碎从传统集中式数据库下移至国产数据库我的项目，是行业首家运营商外围零碎数据库分布式国产化革新我的项目；在2020年，助力十亿级数据规模的“第七次全国人口普查”电子化高效推动。 某银行CIO坦言，“2019 年咱们抉择 TDSQL 的时候，还会放心抉择是不是对的，往年就齐全没有这个疑难了，抉择 TDSQL，很稳。” 替换的实质单纯从安全性上来说，从国外数据库换成国产数据库，对于金融机构来说并不是驱动做出扭转的惟一能源。 替换国产数据库更多的还有来自对将来、对效率、对翻新的布局。 以刚刚实现新一代外围零碎胜利上线的昆山农商银行来说，往年8月，历经300多个日夜，基于TDSQL打造的昆山农商银行新一代外围零碎首次采纳“微服务利用+国产分布式数据库”架构，该架构在同类银行中尚属首次。 “微服务”是近年来热门的架构模式，它提倡将繁多应用程序划分成一组小的服务。服务之间互相协调、互相配合，每个服务独立开发测试、部署降级，灵活性强。在金融畛域，微服务的横向扩大能力、场景化数据切分等特点，能满足当下金融科技翻新的倒退需要。 而在数据库国产化的大背景下，微服务如何跑在国产分布式数据库上，破除原先的“集群模式”， 始终是技术难点。 昆山农商行做到了。 新外围采纳长亮V8技术，无缝连接国产分布式数据库TDSQL，并融入微服务、读写拆散、多源同步等的技术，实现在保障金融级数据全局一致性的根底上，把大零碎拆分成小型微服务，以升高零碎的复杂性，打消耦合，并无效解决了传统集中式外围并发量瓶颈，晋升了外围零碎的高可用性和动静扩容能力，同时大幅升高零碎建设、降级、运维的危险和老本，实现了平安可控。 通过替换国产数据库TDSQL ，昆山农商行新外围零碎反对每日亿级交易量，交易并发数大于2000个，每秒交易处理量大于6300笔，日终批量缩短至8分钟，性能远超原外围零碎，在全国同类型银行中处于领先地位。 为什么是TDSQL要答复这个问题，须要追溯到互联网的“上古世代” 互联网思维在国内大行其道，各种亿级利用层出不穷，这其中以腾讯为最。 “2006年，QQ用户量增长速度发明了历史记录，QQ同时在线人数迫近2000万，开源的数据库没见过这么大的阵仗，市面上的开源数据库和传统商业数据库没有一家可能撑持腾讯宏大的流量需要，也更难实现金融级的一致性、可用性要求。” 李纲拉了潘安群、雷海林等几个人筹备研发一款可能反对腾讯海量计费需要的国产数据库——TDSQL诞生了。 在顺利撑持了互联网利用的暴发时代，从2012年开始，云计算衰亡，数据库上云、多租户、标准化成为标配，腾讯云数据库的能力逐步外溢，TDSQL因为优异的性能、高可用强统一的保障，曾经领有泛滥内部客户。 同时，在通过私有云海量数字化、大规模高并发业务场景的打磨，内核级的深度自研优化之后，逐步造成标准化的国产分布式数据库产品，包含金融级分布式的 TDSQL-D、计算与存储拆散的云原生数据库 TDSQL-C 、剖析型数据库TDSQL-A等产品，取得了云原生技术、多租户隔离、大规模实时剖析计算等能力。 2014年至今，数字化降级成为行业大势，TDSQL走向大规模利用阶段，包含微众银行，TDSQL 作为其分布式数据库底座承当了核心作用；帮忙张家港农商银行上线新一代外围业务零碎；帮忙安全银行打造信用卡“A+”新外围零碎。 随同着能力的不断完善，腾讯云数据库整体能力也正在以前所未有的速度倒退。 依据最新信息，TDSQL数据库的金融政企用户数曾经冲破3000家。作为一款腾讯自主研发的金融级数据库，TDSQL曾经成为泛滥金融机构数字化降级过程中的“使命担当”。 TDSQL依然在路上！

8 月 11 日，记者获悉，腾讯云数据库开源产品 TDSQL PG 版（开源代号 TBase）推出重磅降级：通过一年半的打磨，上万张表拜访场景下，内存占用节俭 60%；查问性能晋升百倍；SQL 语句兼容性加强。同时，鼎力晋升原有数据库版本在分布式场景下的易用性。 在“新时代下数据库开源生态的倒退与实际”技术沙龙上，腾讯云数据库技术总监李跃森介绍，TDSQL PG 版是一款具备 HTAP 能力、通过腾讯多年继续投入研发的数据库产品，可能提供成熟的一站式解决方案。在首次开源的 10 天内，Star 数就回升到超过 500 个。开源不久，就受到了欧洲航天局、国家天文台，以及医疗衰弱、批发等各个行业用户的青眼。 以微信领取为例，应用 TDSQL PG 版，能满足微信领取单表数据轻松冲破 TB 级海量存储的需要；腾讯云开源数据库高吞吐、高并发，主动扩容的能力，也适宜微信领取的业务场景。 腾讯云自主研发的分布式数据库引擎 TDSQL PG 版从 2019 年正式开源（开源代号 TBase）开始，依靠社区，在通过外部业务零碎的实际测验后，根本放弃每月一次小型降级、每半年一次重大降级的节奏，助力泛滥开发者利用前沿数据库技术，推动开源社区生态不断完善。 PG 中国社区主席张文升也指出：“PostgreSQL 社区将和 TDSQL 在技术、生态、企业服务上发展更深的单干，敢于创始，为客户和企业提供更好的反对与服务。独特建设数据库开源生态。” 值得一提的是，TDSQL PG 版开源只是腾讯云数据库开源的代表作之一。事实上，腾讯云数据库在开源畛域动作频频。腾讯云副总裁李纲介绍，腾讯云数据库开源已涵盖三大体系：数据库产品能力开源、产品服务工具开源、前沿钻研平台能力的开源。从技术创新、到产品利用，到根底钻研深入，构建残缺的技术演进周期。 在产品能力开源方面，除了 TDSQL PG 版这种兼顾了剖析型场景的数据库产品，腾讯云数据库近期还将推出企业级 MySQL 内核的开源我的项目，代号为 TXSQL，这是一款针对于大规模交易场景的企业级分布式数据库内核。多款产品的继续开源，独特为社区、行业提供欠缺的国产数据库产品能力体系。 此外，腾讯云数据库也在推动数据库 SaaS 服务工具的开源，包含能够实现 90% 日常主动调优、智能诊断的 AI 自动化运维工具，以及能够进行大规模异构数据迁徙、散发、聚合的数据库迁徙平台。“面对企业客户、开发者，咱们心愿提供的是一个成熟残缺的产品，而不仅仅只是一份代码，”李纲示意。 而在根底钻研畛域，腾讯还开源了根底钻研平台型框架，来帮忙升高研究者的钻研门槛，减速根底钻研。据介绍，2020 年，腾讯和中国人民大学单干开源的 3TS—事务处理技术验证零碎，积淀了腾讯与人大在数据库核心技术方面的许多研究成果，能够提供对立的事务处理框架，帮忙研究者疾速构建新的并发控制算法，以及检测数据异样。 “腾讯云数据库致力于打造可继续倒退的国产数据库开源生态。将来国产数据库技术倒退将像飞船一样减速，腾讯数据库开源我的项目愿做这个过程加速器的松软底座”，腾讯云副总裁李纲表白了腾讯云数据库在开源生态上的投入和信心。 开源是腾讯保持的长期价值之一。腾讯 2010 年起就确立了拥抱凋谢的策略，并始终秉承重数量、更重品质的态度倒退开源。在自主开源方面，截至目前，腾讯共对外开源超过 130 个优质我的项目，我的项目笼罩了云原生、大数据、人工智能、数据库等多个技术畛域，代码贡献者超过 2000 人，开源我的项目 star 总数超过 37 万个。 ...

历经300多个日夜，2021年8月，基于国产企业级分布式数据库腾讯云TDSQL打造的昆山农商银行新一代外围零碎胜利投产上线。它采纳“微服务利用+国产分布式数据库”架构，该架构在同类银行中尚属首次。 新外围零碎整体解决能力能够达到6300TPS（事务处理数/秒），可反对每日亿级交易量，在性能方面，高频帐户类交易均匀响应工夫在300毫秒之内，查问类交易均匀交易响应工夫在100毫秒之内，日终批量工夫缩短至8分钟左右，季度结息17分钟左右，96秒实现10万笔社保代发，性能远超原外围零碎，在全国同类型银行中处于领先地位。 “微服务”是近年来热门的架构模式，它提倡将繁多应用程序划分成一组小的服务。服务之间互相协调、互相配合，每个服务独立开发测试、部署降级，灵活性强。在金融畛域，微服务的横向扩大能力、场景化数据切分等特点，能满足当下金融科技翻新的倒退需要。 而在数据库国产化的大背景下，微服务如何跑在国产分布式数据库上，破除原先的“集群模式”， 始终是技术难点。因为数据库自身的开发利用就关涉多项服务，要满足“微服务”架构，做到多个服务数据的一致性并非易事，在多个服务之间进行数据查问也充斥挑战。 昆山农商行和腾讯云做到了。新外围采纳长亮V8技术，无缝连接国产分布式数据库TDSQL，并融入微服务、读写拆散、多源同步等的技术，实现在保障金融级数据全局一致性的根底上，把大零碎拆分成小型微服务，以升高零碎的复杂性，打消耦合，并无效解决了传统集中式外围并发量瓶颈，晋升了外围零碎的高可用性和动静扩容能力，同时大幅升高零碎建设、降级、运维的危险和老本，并实现了平安可控。 **新外围零碎有三个微服务集群：公共服务微服务集群、账务微服务集群和历史微服务集群。每个微服务集群由一系列性能职责繁多、高度聚合的服务组成，可反对灵便部署。这三个微服务集群运行在一套TDSQL集群中。 **架构部署细节上，整个昆山农商行的架构是“两地三核心”部署，数据库采纳一主三备，核心间数据强同步，实现核心级别劫难疾速主动复原，且数据零失落。 腾讯云数据库TDSQL早有丰盛的深刻区域银行外围零碎的先例。例如，此前TDSQL曾落地张家港农商银行，实现银行传统外围数据库首次国产化。 昆山是全国百强县之首。昆山农商银行，是一家扎根于昆山地区，且是当地营业网点最多、服务覆盖面最广的银行，昆山农商行的翻新转型，对“微服务+国产分布式数据库”架构在银行业的利用具备标杆意义。

10月20日，一年一度的数据库技术交换盛会——DTCC 2021（第十二届中国数据库技术大会）在京圆满闭幕。 大会以“数造将来”为主题，重点围绕数据架构、人工智能与大数据利用、传统企业数据库实际和国产开源数据库等内容开展分享和探讨。 在本次数据库年度盛会交流平台上，腾讯云数据库团队集结多位顶级技术达人亮相，针对以后热门数据库技术主题，独特为大家带来了满满技术干货分享。 错过现场？没关系，一文带你回顾腾讯云数据库大咖演讲要点~ 数造将来HTAP数据库解决方案、利用实际和将来倒退 林晓斌，腾讯云数据库总经理，数据库畛域资深技术专家。 演讲要点：为应答大规模事务和剖析型需要，TP&AP交融是数据库技术倒退的重要方向之一，而构建HTAP数据库面临着数据一致性和计算实时性等挑战。本次大会林晓斌老师和大家独特探讨了HTAP数据库解决方案，并具体解读了HTAP数据库利用实际场景和将来发展趋势。 数据存储与减速实时存储时代的数据库改革 罗云，腾讯云数据库副总经理，腾讯云NoSQL和SaaS团队整体业务负责人 演讲要点：互联网曾经进入了实时服务的时代，实时计算、实时存储、实时的响应，这所有对数据库来说都是全新的挑战，怎么样为企业提供实时、高效、低成本的数据库服务，腾讯云NoSQL团队在新硬件、新引擎、新服务方向上进行了诸多的摸索，推出了兼顾性能与老本的高性能分布式KV数据库Tendis，具备高并发、超低延时、数据安全可靠、热冷数据分级存储等个性，为企业客户带来了全新的高性能实时存储解决方案。 数据库内核技术数据异样的实质和价值 李海翔，腾讯金融云数据库资深技术专家，腾讯TDSQL分布式数据库首席架构师。中国人民大学信息学院工程硕士企业导师，CCF数据库专委会委员，DTCC（中国数据库技术大会）专家委员会委员。 演讲要点：数据异样是关上并发访问控制技术大门的金钥匙 ，尤其是在认知了所有数据异样（己有的技术是case by case的形式提出了无限个数的异样）后（TDSQL团队系统地提出了所有的数据异样并进行分类），可探索到数据异样的实质和外在法则，并揭示出隔离级别和并发算法的实质，进而可对ACID的C进行定义。 数据库内核技术HTAP零碎的问题与主义之争 朱阅岸，毕业于中国人民大学数据库技术业余，DTCC数据库内核场技术分享嘉宾，先后在蚂蚁金服Oceanbase、腾讯云数据库、华为云数据库等部门从事数据库前沿技术的钻研和内核技术的开发工作。 演讲要点：学术界与工业界对HTAP零碎的钻研曾经发展了十多年之久，争执的焦点在于：是否采纳一个大而全的零碎，同时响应OLTP与OLAP查问申请。本次大会朱阅岸老师将HTAP的零碎实现分为两种方向，一种是one size fits all模型；另外一种是loosely couple零碎。别离为大家分享了两种实现计划的优缺点，以及现有产品的对应的技术实现细节。 金融行业数据库技术实际TDSQL 全局一致性读技术详解 张文，腾讯云数据库专家工程师，领有多年分布式数据库系统研发教训，目前在TDSQL团队负责集群治理以及数据库内核方面研发，同时领有大量金融行业客户迁徙割接案例教训。 演讲要点：分布式数据库通过引入分布式事务，解决了各节点之间数据的最终一致性问题。对于局部较为刻薄的银行业务零碎来说，不仅要求数据的最终一致性，更要求可能获取到数据库的全局一致性快照。 这种全局一致性快照要求：针对一个分布式事务不容许读取到该事务的中间状态，即读取到波及该事务的局部节点提交，局部节点未提交的数据状态。TDSQL通过对计算节点和存储引擎进行深度革新，同时引入高性能全局工夫戳组件，并对整个计划继续调优，以一种高性能且轻量的形式解决了分布式场景下的一致性读问题。 云原生数据库开发与实际腾讯云原生自研数据库内核深度优化最佳实际 李昕龙，腾讯云高级工程师，领有多年分布式数据库研发教训，目前在TDSQL-C团队负责内核优化以及数据库内核方面研发。 演讲要点：腾讯云TDSQL-C(原CynosDB）分布式关系型云原生数据库，是一款面向海量在线数据存储和实时数据分析通用型高性能数据库系统。该数据库腾讯云TDSQL-C（原CynosDB）采纳计算存储拆散构造，所有计算节点共享一份数据，提供分钟级的配置升降级、秒级的故障复原、全局数据一致性和极速的数据备份容灾服务。 TDSQL-C交融了传统数据库、云计算与新硬件技术的劣势，在可用性，可靠性，可扩展性和性能方面做了深度优化。面对多变简单的业务场景，数据库提供最大15个备机读扩大能力；面对不定性数据爆炸需要，数据库提供PB级别的存储扩招能力；在资源受限的高压力场景，数据库优化事务、锁零碎，同时提供多级缓存机制，满足用户性能需求。 数据架构设计与实际企业级与智能化的MySQL云服务 刘迪，腾讯云数据库高级产品经理，中国计算机行业协会开源数据库业余委员会副会长、北京航空航天大学特聘讲师。 演讲要点：在云计算倒退浪潮一直涌入的明天，咱们不难预测，云上的MySQL在将来的数据库市场也将是支流。随着时代的倒退，数据量井喷式增长，开源版本的MySQL很难满足很多企业的业务需要，在某些场景下，无论是性能、平安还是稳定性，都面临着各种各样的问题。 腾讯云数据库 MySQL为用户提供安全可靠，性能卓越、易于保护的企业级云数据库服务。其具备6大企业级个性，包含企业级定制内核、企业级高可用、企业级高牢靠、企业级平安、企业级扩大以及企业级智能运维。 云原生数据库开发与实际DBbrain：新一代量化指标驱动的云上数据库自治平台 雷尚顺，腾讯云数据库高级工程师，腾讯云DBbrain产品负责人。 演讲要点：以后数据库智能运维曾经步入深水区，腾讯云 DBbrain 产品针对数据库自治服务率先提出实时闭环诊断，零碎负载监测以及业务领域建模几大重点方向。 本次分享雷尚顺老师介绍了对数据库自治的一些思考以及腾讯云 DBbrain 产品的设计思维和能力评估办法，并重点解读了腾讯云 DBbrain 产品如何通过量化指标帮忙用户精准的定位和解决深层次问题。 分布式数据库技术实际TDSQL在国产化及HTAP畛域的最佳实际 陈爱声，腾讯云数据库高级工程师，腾讯云TDSQL PG首席架构师，Postgresql中国社区七星之一。 演讲要点：腾讯TDSQL-PG(原TBase）分布式关系型数据库是一款面向海量在线实时分布式事务交易和MPP实时数据分析通用型高性能数据库系统。面对利用业务产生的不定性数据爆炸需要，不论是高并发的交易还是海量的实时数据分析，TDSQL-PG都有足够能力解决。TDSQL-PG产品原型起源于技术成熟，功能强大的PostgreSQL。 腾讯公司对TDSQL-PG齐全自主可控，具备齐全自主知识产权。具备在中高端市场能够规模代替国外数据库的能力，在数据库根底软件层面撑持国家自主可控策略倒退。以后TDSQL-PG曾经在腾讯微信领取、金融、保险、税务、公安、消防、政务等行业的外围交易系统上线运行。 正如罗云老师所言，互联网曾经进入了实时服务的时代，腾讯云数据库也将继续摸索，打造新的时代下更便捷易用的数据库产品。同时腾讯云数据库也在回馈社区、拥抱开源。在将来，面对开发者，腾讯云数据库也将持续携手各畛域大咖，为各位数据库爱好者带来数据库畛域最前沿的洞察与实践经验分享。

在 2017 、2018 年和 2019 年的 10 月 24 日，爱可生开源社区出品了 MySQL 分布式中间件 DBLE 、数据复制产品 DTLE 和全局事务框架 TXLE 。时隔两年，这三款产品在社区积攒了更多的设计教训和用户反馈，有更多的企业和用户在生产环境中应用它们，实现了产品的疾速迭代。 此次开源的 SQLE ，它是一款面向数据库使用者和管理者的 SQL 审核工具，旨在标准 SQL 审核上线流程，进步 SQL 品质。社区放弃每年开源一款产品的传统，为丰盛 MySQL 开源生态添砖加瓦。 SQLE 反对多场景审核，反对标准化上线流程，原生反对 MySQL 审核且数据库类型可扩大的 SQL 审核工具。次要性能平台治理反对用户和角色治理；反对配置上线数据库；反对基于角色的资源隔离；反对配置审核规定模板；反对对不同的数据库利用不同的规定模板。SQL 审核反对工单审批流程，反对工单隔离；反对邮件推送审批事件；反对 SQL 上线；反对生成回滚语句；反对审核 MyBatis XML 文件；反对审核倡议按 SQL 归类去重展现；反对审核报告下载。SQL 审核打算反对通过标准接口收集来自业务的 SQL 统计信息；提供 MyBatis 文件扫描上传程序（scanner），可集成CI/CD；反对动态审核，即脱离上线数据库审核；反对定时审核，既有 SQL 进行生成审核报告。企业版性能反对审核白名单；反对审批流程可视化配置；反对 MySQL 慢日志采集进行 SQL 审核。个性一览自动化审核反对多SQL同工单关联审核反对审核 MyBatis 文件齐备的SQL标准与规定库，解决SQL标准难题自定义SQL规定模板，解决不同业务规定不对立问题反对白名单，解决利旧特例SQL的审核难题标准化上线流程SQL审核流程按需自定义，满足企业外部不同流程治理要求反对多级审批，反对疾速上线多场景审核反对事前事后审核，笼罩开发、测试、上线、生产等环节凋谢接口规范HTTP API接口可与客户外部流程零碎对接多数据库反对反对通过插件的模式扩大可审核上线的数据库类型，无需降级软件，导入审核插件即可获对应数据库类型的审核上线能力，应用平台所有性能。反对服务业余的传输组件专家队伍沉闷的开源社区交换气氛7×24 小时的护航团队反对稳固的研发测试团队保障提供企业级的管家式服务反对应用场景标准上线流程： 多场景审核： 我的项目地址: https://github.com/actiontech... 文档地址: https://actiontech.github.io/... 社区官网： https://opensource.actionsky.... 开源福利流动:即日起至 2021年11月24日，用户试用 SQLE ; ...

SeaTable 是一个反对多种数据类型的协同表格和信息管理工具。它不仅不便记录大量结构化的数据，还提供了多种数据处理、剖析和可视化的性能。本文将介绍如何综合地应用 SeaTable 的 SQL 插件、数据链接性能、函数计算性能，来从一份在线订单数据中剖析出每年的复购比例、用户留存比例。 通过本文，咱们会看到，相比于 Excel，SeaTable 在数据分析方面有以下的劣势： 反对 SQL 查问，能够实现绝对简单的数据查问。反对数据的扩表关联。一些场景下，只有扩表关联才能够实现数据的剖析，比方订单表须要和用户表关联。可能解决 10 万行甚至百万行以上的记录。相比于传统的数据库，SeaTable 则更加直观易用： 能够通过界面间接把两头后果导出为新的表格，而后再进行剖析。能够间接建设公式列，对数据进行计算加工，而后再进一步剖析。能够间接通过界面对一些不合理的数据进行清理或批改。数据集介绍如下图，这是一张软件产品的在线订单数据表，记录了所有订单的详细信息，如 ID、用户名、付费金额、创立工夫（首次付费工夫）等等。其中软件是以年付费的模式销售的，用户须要每年续费一次以便持续应用软件。Price 记录的是美元价格。 咱们增加 SQL 插件，并且搁置到工具栏后，就能够疾速地进行数据查问了。 首先，咱们想查问所有订单的数量，那么 SQL 语句如下： select count(*) from Orders count(*) 示意对所有条目数量的计数，后果为 1855，示意目前为止总共的订单数量有 1855 个。 接下来，咱们想看一下，这些订单来自多少个不同的用户，那么语句如下： select count(distinct User) from Orders limit 1000同上，用 count 函数，distinct 示意去重，雷同的值只保留一次。后果为 598，示意总共购买的用户有 598 人。 那么在这么多用户中，咱们想看一下， 2020 年付费能力最强的前十个用户是哪些人，则能够写入如下语句： select User, sum(Paid) from Orders where `Created At` > '2020-01-01' and `Created At` <= '2021-01-01' group by User order by sum(Paid) desc limit 10咱们将付费工夫限定为 2020 年，对用户的付费金额求和，并且以付费金额的大小来降序显示十条记录。 ...

传统数据库主备形式： 存储各自独立主备间通过数据流复制保证数据统一，主库故障则切换到备库可用性与可靠性无奈兼顾 腾讯自研云原生数据库 TDSQL-C，基于全新计算存储拆散架构，交融传统数据库和云计算技术劣势，100%兼容MySQL和PostgreSQL，专为云而生，具备高性能、低成本、大存储、低提早、秒级扩缩容、极速回档、serverless化七大个性： ● 高性能：单体实例读性能晋升到125W，写性能晋升到25W ● 低成本：老本降落可达40% ● 大存储：单实例存储容量达到128TB（超过448TB反对能力行将公布） ● 低提早：彻底辞别主从复制提早/异样问题（< 20ms ） ● 秒级扩缩容：规格升降级/增删RO < 60s ● 极速回档：回档速度晋升200%，高达1.2GB/s ● serverless化：主动扩缩容、按使用量计费，不应用不计费 当传统主备形式数据库遇上腾讯云云原生数据库TDSQL-C，“C”位出道的腾讯云原生数据库说：“你的有余，我来补！” 1.可用性、可靠性无奈兼顾 vs 可用性、可靠性兼顾； 传统数据库基于binlog的主从逻辑复制，复制提早较大，存在数据失落的危险。备机同步日志之后需串行回放，HA工夫不可控，导致业务的可用性受损。云原生数据库TDSQL-C基于计算存储拆散的架构，底层是共享存储，解决了传统主备架构弹性能力差，业务压力大时的同步效率低，主备切换工夫不可控等问题，在提供高性能同时保障了零碎的高可用性和业务的连续性，极大的加重了经营和运维人员的工作量。●高可用秒级RTO：计算层重启，间接从存储层读取页面，无需日志复原主备提早低：物理复制，间接回放到物理页面，无需SQL层参加共享内存：计算节点疾速重启，热页面依然保留在内存●高牢靠RPO=0，存储层页面多正本同步PITR（Point In Time Rollback）,得心应手回滚数据至任意工夫点，保证数据不仅以后牢靠，而且历史牢靠 2.只读扩大受限、建设工夫长 vs 秒级扩大、分钟级快照备份； 在理论业务中，只读申请占比远高于写申请，传统数据库因其自身架构，只读扩大受限，进而影响整体性能。规格降级、增加只读节点都须要导入全量数据到新机器，耗时随数据量增长，可达到天级别。云原生数据库TDSQL-C架构上计算节点无任何状态，同时进行了多方面的优化，使得计算节点的HA和扩大均能在数秒内实现；数据在存储中进行分片，分片互相独立，基于云盘的快照机制，实现疾速的并行备份和回档，较传统架构晋升了一个数量级。秒级的快照备份和疾速回档能力，在多正本的根底上对用户的数据进行间断爱护，是互联网和游戏行业的最佳抉择。 3.老本高企 vs 存储、计算别离计费； 传统线下数据库保护形式中，须要提前准备整台机器、做三年折旧开销，能力失常运行一个数据库实例。而在大部分工夫里，主机资源往往较为充裕、长时间没有失去充分利用，造成重大节约；而如果业务存在波峰波谷状况下，则须要时刻准备最高资源，使老本居高不下。 云的呈现，肯定水平上缓解了这一难题。云数据库，能够即开即用，在预估好资源应用后，预计能够十分钟左右用上数据库。而老本，能够根据所需的资源申请，在必要时（如业务爆增）能够降级到较高规格，从而防止资源的节约、实现老本的肯定水平升高。而云原生数据库，则将老本管制的粒度往前迈进了一大步。以后惯例云数据库，存储购买的粒度依然较粗，至多以数十G为单位；而规格的升降级，起码为分钟级、最多有可能是在数小时、甚至数十小时级别（视数据总量而定），且计算规格与存储规格有较大绑定关系，导致相互影响，即存储规格变动、计算规格变动都有可能导致较慢的降级工夫。 而云原生数据库，则做到了秒级弹性、甚至极致的Serverless弹性。在失常业务运行时，采纳较低规格运行，在业务波峰来长期，能够在秒级晋升计算规格，此时存储上毋庸为此做任何动作；而存储上，用多少付多少，无须再思考存储规格问题。整体上，实现资源规格的灵便、细粒度管制，更优的弹性、更好的管制老本形式，无效帮忙应答业务的微小波瀾。4.备份工夫长 vs 灵便调度、动态控制老本传统数据库的逻辑回档采纳计算层SQL解析后再落盘，回放的速度较慢；其物理回档则通过拷贝数据到所属磁盘，单线程回放redo日志，速度也较慢。传统数据库在备份会锁表，影响实例；若从备机上进行备份，速度过快则会导致主从差距变大，影响可用性。云原生数据库TDSQL-C采纳存算拆散架构，存储反对快照备份。备份期间对计算节点无影响，可随时发动；反对按1MB并发上传/下载数据，备份/回档可达GB/s。特地是对于互联网和游戏业务麻利灵便的弹性扩大，无需事后购买存储，可依据业务须要疾速升降级，疾速扩缩容，轻松应答业务峰值。 4.传统数据库容量天花板低 vs 云原生数据库轻松反对海量存储 传统数据库采纳物理硬盘作为存储空间，受单盘容量的限度，如果某个数据库超过了这个存储的限度，须要运维和开发的人员一起进行数据归档来升高数据库容量或者进行分库分表操作扩散数据库的容量问题，整个过程十分耗时耗力，对于业务来说也不太敌对。 云原生数据库TDSQL-C，最高存储容量可达128TB（超过448TB反对能力行将公布），主动扩缩容，可能轻松应答业务数据量动态变化和持续增长，运维无需再为实例的存储容量而发愁。

一、背景随着各行各业电子信息化的一直加深，线上交易数据放弃了长时间高速增长的态势，对数据存储的需要越来越大，数据库管理系统（DBMS）面临越来越大的性能、空间和稳定性压力。在此过程中，得利于计算&存储&网络等硬件畛域的不断进步，业界风行的数据库管理系统逐渐从单机架构向分布式架构演变。笔者期望从梳理数据库管理系统所面临的一个又一个理论挑战及业界所提出的诸多解决方案的过程中，发现片缕灵感以指引将来的数据库开发工作。 二、从单机数据库到分布式数据库业界起步阶段诞生的第一代交易型数据库具备以下次要特点：和程序一起运行在大型机/小型机为代表的高端计算机上; 利用硬件层面大量冗余设计带来的弱小可靠性来保障数据库可用性，通过间接降级硬件规格的形式来扩容数据库性能容量。即便到明天依然有很多银行外围零碎以这样的形式运行。 很快，这种堆硬件模式来获取晋升的模式局限性就裸露进去了。首先，数据库可用性对硬件层面冗余的依赖贬低了大型机等存储型设施的造价，动辄单台上千万美元的价格是诸多中小客户难以承受的累赘。次之，因为性能扩容只能通过晋升硬件规格的形式实现，而硬件规格的10%性能容量晋升，往往须要客户付出成倍的购买老本，且整体性能极限也受限于过后的硬件倒退的天花板。因为上述所说的诸多老本起因，业界始终没有进行过尝试以x86服务器为代表的“便宜”硬件替换大型机来提供交易型数据库服务的致力。 三、基于共享存储的分布式数据库计划1. 共享存储计划 首当其冲要解决的是，如何保障数据库服务的可用性。因为交易型业务往往都是企业中较为外围的往往会波及金钱相干的线上业务，因而对数据库服务的可用性有比拟高的要求。最简略地，通过把数据库架设在共享存储系统，将数据文件存储在共享存储，实现数据库实例和存储介质的解耦，从而实现数据库服务的高可用。 当数据库所在机器呈现故障时，另一台备用机器通过接管共享存储的数据文件并疾速对外持续提供数据库服务，从而保障数据库可用性。 不过，传统的共享存储也是一种昂扬的硬件设施，其自身的老本&可用性&容量同样面临着硬件的限度，所以采纳共享存储的数据库计划始终难以大规模风行开来。直到起初分布式文件存储系统的日益成熟，这种数据库计划才真正地风行开来。时至今日，事实证明云盘产品能在云分布式环境提供稳固牢靠的存储服务，以RDS为代表的各类云数据库产品广泛通过云盘的可用性来保障数据库服务的可用性。 共享存储计划的毛病也很显著。一方面，数据放在远端的共享存储意味着数据库须要通过网络能力拜访数据，这导致比单机数据库更显著的拜访提早和性能开销。数据库计划引入共享存储，意味着额定引入了对网络&共享存储等更多的内部依赖，进而导致整个数据库的稳定性有所升高。 另一方面，共享存储计划须要另一台备用机器时刻期待着接管数据库服务，意味着一个数据库服务须要两台机器但却只能有一台机器在提供服务，无奈充分利用备用机器资源。因而，如何更好地将闲置的备用机器利用起来，也是一个重要的技术课题。与此同时，以后互联网时代流量特点除海量数据/海量吞吐外，还包含写入批改只占据申请总览的一小部分，用户申请绝大部分都是对内容的查问展现，内容查问场景对数据实时性的要求并不高。基于上述特点，既然另一台备用机器自身闲暇又能拜访到所有的数据，那是不是能够让它也同时提供一些历史版本的只读查问服务呢？是的，云盘存储计划就能通过只读节点的形式把本来灾备用的节点对外提供只读服务，从而晋升整个数据库系统的查问能力。 2. 共享存储计划的演进 然而，云盘存储计划只是绝对简略地将数据库服务架构在云盘上，只读节点无奈和读写节点同时访问共享存储的同一份数据文件，只能通过独自应用一份共享存储文件后再通过额定机制来和主节点进行同步来实现。共享存储中的数据文件自身就是有多正本的，这意味着数据库层面的多节点会带来乘法效应，节约更多的存储资源。这和进步机器资源利用率的初衷是想违反的，而且没有利用上共享存储能够被多个机器拜访到的人造劣势。那么，有没有方法让数据库实例的主节点和多个只读节点同时应用一份共享存储数据文件呢？ 共享盘存储计划，通过在数据库层实现多节点间的协调同步，躲避多个节点各自对数据文件的变更抵触，从而实现一份数据存储多个节点服务的数据库架构。共享盘存储计划在利用存储产品高可用性保障数据库可用性之余，又很好地利用了共享存储的数据共享劣势提供多节点服务。 3. 可计算存储 共享盘存储计划的查问性能能够通过多个只读实例进行扩大，但写入申请只有一个读写节点能够提供服务。而读写节点的性能极限依然受限于单机硬件的性能下限，特地是网络IO设施的性能下限，不仅没从分布式架构中取得收益，甚至因为共享存储的额定开销反而有所下滑。那么，要怎么样能力让数据库服务的写入性能从分布式共享存储中获益呢？ 可计算存储计划即是业界对这一问题给出的一份答卷。通过长时间的察看钻研，工程师们发现线上数据库服务的写入性能瓶颈通常都在网络IO。特地是RDS数据库在运行期间须要不停刷写预写日志（write ahead log）/数据文件（data file）等多种数据到远端的分布式共享存储，占用了大量机器IO容量。但与此同时，RDS数据库长久化到分布式共享存储的预写日志/数据文件等数据中蕴含了大量的冗余信息。比方，针对MySQL/innodb数据库架构下的binlog/redolog这两种预写日志，尽管日志格局各不相同（逻辑日志/物理日志），但二者都是对同一份数据批改的记录，却占用两倍IO流量。再比方数据库以页为单位长久化数据文件，而数据文件的页大小通常是16KB，意味着即便只批改某一页中的一行记录，在写数据文件的时候数据库实例也会产生16KB IO流量，存在比拟大的写放大景象。甚至更近一步地，这一行记录的数据变更其实曾经随着之前的预写日志写到分布式共享存储，写数据文件的脏页数据齐全没有必要，是一种节约！！ 单机数据库之所以采纳预写日志技术，是为了通过把数据脏页的随机写操作变成预写日志的程序写操作，从而晋升单机数据库整体性能。但预写日志技术只能推延并尽可能合并对数据文件的随机写入操作，却不能完全避免对数据文件的随机写入。单机数据库须要一直地把脏页逐渐刷写到数据文件来推动检查点，从而开释出更多的日志容量&管制实例故障的复原时长。而刷脏页通常属于磁盘随机写操作，特地在随机写入的业务场景下，十分影响数据库性能，是单机数据库的一大性能瓶颈点。 因而，工程师们提出了Log is Database的技术理念，这也是可计算存储计划的核心理念。数据库读写节点只通过必要的预写日志把数据库数据变更信息传递给分布式共享存储，而不再须要传递数据文件脏页等额定信息，读写节点机器的IO开销大大减少。那么，数据文件的数据变更怎么办呢？既然预写日志外面曾经有所有的数据变更信息，那分布式共享存储系统能够间接从预写日志里获取到数据变更信息，间接将其更新到相应的数据文件中。针对MySQL/innodb数据库架构，更是能够进一步把binlog日志间接省略，单单传递redolog日志就足以把整个数据库的数据变更传递到共享存储系统，大大减少了RDS MySQL数据库实例的IO流量，无效晋升了MySQL数据库的性能下限。 在此计划中，数据库读写节点只须要负责传递必要的预写日志给存储系统，不再须要解决数据文件更新保护的工作。而这部分数据保护工作因为波及大量迟缓的数据IO操作，往往正是整个数据库系统的性能瓶颈所在。数据库读写节点从保护数据文件的昂扬开销中脱身后，也得以领有了极高的数据写入性能。而分布式共享存储系统在解决数据保护工作时，因为本身的分布式架构劣势，人造能够通过增加新节点的形式进行程度扩大，一直晋升整个零碎的吞吐性能下限。 在海量写入的场景中，数据库通常会延缓推动检查点&保留较多预写日志，尽量避免频繁刷脏页导致影响数据库性能。而数据库在故障复原时又必须回放在检查点后的所有预写日志，以保障数据一致性。因而，数据库在海量写入场景故障复原中可能会因回放预写日志而耗费大量工夫，导致数据库服务较长时间无奈服务。因为存储系统的分布式架构劣势，可计算存储计划预写日志回放操作被打散到多个存储节点上并行执行，极大晋升故障复原的速度，无效缩小数据库服务的不可用工夫。 更进一步的，因为领有数据库全量历史信息，分布式存储系统可能提供历史版本数据页内容。在读取历史版本数据的时候，数据库节点只须要在数据页申请中带上历史版本信息。分布式存储系统在收到历史版本申请时，通过读取该数据页以后的数据文件和历史相干的回滚日志（undolog），而后将两者解决生产历史版本数据页后返回。由此，数据库历史数据处理工作也被下沉到存储系统，得以利用分布式存储系统的程度扩大劣势来晋升数据库的历史数据查问性能。 至此能够看到，与共享盘存储计划相比，可计算存储计划尽管写入申请只有一个读写节点能够提供服务，但该读写节点只须要负责申请解析、查问执行、事务管理、缓存治理等工作，而数据文件更新保护、数据页版本保护这部分数据库中开销极重的局部流程却领有了程度扩大的能力。这意味着可计算存储计划在保障可用性的根底上，曾经在肯定水平上解脱了传统单机数据库面临的硬件瓶颈，大大晋升了服务能力下限。 四、总结文章篇幅所限，本文简略地介绍了基于共享存储的架构下数据库产品从单机数据库逐渐向分布式数据库眼睛的倒退历程中逐渐面对的问题和对应的解决思路。后续文章中，笔者将尝试探讨数据库的另一条倒退路线，即基于独立存储的架构下数据库产品如何从单机数据库逐渐走向分布式数据库。

Redis篇 日常听到的Redis有两个概念，反对Redis协定的ckv和腾讯云Redis。ckv+是腾讯自主研发的NoSQL零碎，上云之前的次要key-value存储选型。然而目前曾经不在云上售卖了。腾讯云上售卖的都是腾讯云Redis。广州集群的key-value是应用的是ckv+，而北京集群应用的是腾讯云Redis。 从ckv+到腾讯云Redis的间接数据迁徙无奈通过简略的工具实现，腾讯云Redis实例之间能够通过DTS（数据迁徙服务）迁徙（https://cloud.tencent.com/doc...）。 数据迁徙服务DTS是腾讯云提供的不同数据存储实例之前的对立迁徙能力。从页面上的类型来看，提供以下类型存储作为迁入源，还是挺丰盛的。并且在迁入实例类型中看到了TDSQL的身影，感觉有戏。 回到Redis的迁徙问题上来，确定ckv+无奈迁徙到Redis之后，剩下的路只有rdb文件导入了。那么接下来的第一个问题是怎么拿到ckv+的rdb文件呢？http://redis.oa.com 的管制台上是没有rdb下载链接的。腾讯云Redis就有。 https://iwiki.woa.com/pages/v... ckv+的cos冷备获取办法。这里要留神把文档看完，cos下载失去的是cdb的格局，须要应用文档附件的redis-dump-tool进行rdb的格局转换。 TDSQL篇Redis数据的迁徙尽管没有工具，然而有具体的冷备迁徙策略。再加上之前DTS服务中如同有TDSQL主动迁徙的可能。这文章就要完结啦。https://cloud.tencent.com/doc...，拿上参考文档就登程。等等，这里文档是Mysql版本的。 首先依照一贯操作，业务方帮咱们申请了资源。而后我关上DTS页面，填好对应的信息，测试连贯通过，间接下一步。这里略过了表构造对齐，账户权限创立等等。这些能够依照上述文档的阐明操作。而后咱们遇到了第一个谬误： 文档中提过要查看lower_case_table要统一。问问helper能不能设置而后重启。而后helper同学说搞不了，因为tdsql shard实例比拟非凡，只能人肉操作。很容易有坑。行，我让业务方同学从新申请一个，毕竟是我没看文档的锅。而后我又筹备好了，感觉本人行了，各种查看终于通过了，而后，而后是这样的 lush Table这个作为Mysql的操作之一，有趣味的同学能够参考 https://blog.csdn.net/qingson...。能够简略了解为全库锁表。于是乎，再次求教helper同学，helper同学说TDSQL shard类型的实例搞不了这个。呃…那我干了个啥？？？ 好吧，DTS的路堵死了。在和helper同学的一番致力下，找到了TDSQL sharding多源同步计划。能够的是只反对同地区实例的同步。还有一种可行办法就是为广州集群的TDSQL创立一个北京的灾备集群。依照helper同学的说法，低负载时可能实现准实时同步。然而此时北京集群是个只读集群，不合乎北京集群也接入写流量的想法。临时放弃。 兜兜转转又是最原始的sql文件导入办法，helper同学很贴心的送上了文档 https://cloud.tencent.com/doc...，这次我认真看了，dump阶段没有任何问题。而后到了导入阶段，死活搞不定。最初和helper同学确认这文档后半段是谬误的，要应用mysql source sql文件的办法导入。 弄完Redis和TDSQL的迁徙后，最大的问题就是新的集群数据和旧集群是割裂开的。是两个没有任何关联的集群。不能实现用户从旧集群无缝切换到新集群的目标。在参考了常见的高可用部署计划后，发现异地双活可能是咱们可能采纳的计划。在和helper同学确认之后发现redis和tdsql sharding都做不了双向同步。Tdsql mysql版本 https://cloud.tencent.com/doc...可能通过DTS反对。所以以后这还只是个欲望，心愿未来在业务须要时可能用上。

TDSQL-C再创佳绩9月16日，Distributed Cloud｜2021寰球分布式云大会在上海召开，腾讯云原生数据库TDSQL-C荣获“云原生卓越技术提供商”奖项，TDSQL-C 是腾讯自研的云原生分布式数据库（原CynosDB）, 基于共享存储，实现了弱小的扩大能力和超百万级QPS的高吞吐性能，深度定制的数据库内核TXSQL是撑持要害业务安稳运行的基石。 TDSQL-C的总体架构是基于共享存储，存储和计算拆散的架构。 1.传统的MySQL主备通过binlog进行的逻辑复制，而TDSQL-C是通过redo日志进行的物理复制。 2.传统的MySQL须要向存储写多份数据包含data，binlog，redo log， 而TDSQL-C只需向存储写一份redo日志即可。 3.传统的MySQL主备各存储一份数据，而TDSQL-C基于共享存储只有一份数据。 TDSQL-C具备以下要害个性： 1、可靠性 多正本/RPO=0 存储多正本保证数据高牢靠 共享存储，主备数据统一 即时回滚，任意工夫数据都牢靠 2、高性能 极致性能 主备机读写性能全面优化 不同规格针对性优化 绝对传统MySQL有6倍晋升 3、高可用性 秒级RTO 秒级RTO，故障简直无感知 毫秒级主备提早，数据极速同步 共享内存，数据恢复，疾速预热 4、弹性扩大 得心应手 数据疾速、通明扩大，按需应用 大容量1PB，满足“大”需要 来自官网的屡次认可在MySQL官网近几次release notes中都有腾讯云数据库内核团队的重要奉献，也意味着腾讯云数据库内核技术TXSQL在国内是走在前列的；2020年底，腾讯云数据库内核团队又获MariaDB社区的官网感谢信，对团队的奉献予以感谢。 TDSQL-C的要害个性之高可用-秒级RTO，能够达到故障无感知。 过往buffer pool大实例重启，初始化耗时长，用户体验差，对此的团队给出优化计划是：并行初始化加上page上的mutex提早初始化。 并行初始化是指按innodb buffer pool instance来并行初始化。 page mutex提早初始化，是指当page首次应用时才初始化，而不是在启动时全副都初始化。 优化后的后果是之前500G buffer pool初始化从23s降到了1.3s，晋升近20倍。 这个优化计划奉献给了MySQL官网（lmprove lnnoDB buffer pool initialization） 腾讯云数据库内核团队始终保持以稳定性为第一位，保障了线上服务的可用性达到 99.95%，可靠性达到99.9996%，同时，深入研究技术细节，继续优化零碎性能，使得数据库内核TXSQL的性能远超官网版本，并达到业界领先水平。 业界独创，蓄力技术创新在官网MySQL8.0反对 instant add column 后，批改列类型操作便成为MySQL中最不敌对的DDL类型。而在用户实际中，批改列类型也是用户执行比拟频繁的DDL之一，此操作会长工夫阻塞用户的读写申请，对业务的影响十分大。 TDSQL-C 业界独创，翻新地反对了instant modify column性能，达到了秒级批改列的成果。具体的实现形式是： 1.元数据多版本化, 表元数据保留列的多个版本信息，用户只能看到的总是最新的表元数据。 2.行记录减少版本信息对应到不同版本的表元数据上。 3.批改列只批改元数据，批改列的过程中不批改理论的行记录。 4.行记录读取时，老版本记录会主动转换为最新版本的记录。 5.行记录更新时，老版本记录会自动更新为最新版本的记录。 此计划为业界独创 TDSQL-C 批改列能够毫秒级实现，并且不受数据量大小的影响。 ...

INST0001 Coursework Assignment BriefAssignment Title CourseworkComponent/Module INST0001 Database systemsAssignment Code AS01-INST0001Set by D. RomanoModerated by L. DickensLearning outcomes to be assessed: Describe in brief how a business operates Utilise standard graphical notations for communicating the form of the database to the customer and theprogrammer in a standard manner Analyse the requirements for business database, create and query it utilising the SQL language in a databasemanagement system (this year XAMMP has been explained and MySQL) Elicit the database specifications from brief documents Perform the database conceptual requirements analysis Describe the logical diagrammatic model of the data and how to normalise itSubmission requirements:Brief AssignmentDescriptionThis assignment requires students to work in pairs towards describing a business case study,and its database needs considering both the conceptual and normalised logical model of thedata. The student must also demonstrate the ability to query the database and the dataresulting from such queries.The complete coursework will be produced in the form of a report that represents 20% ofthe final mark.Conditions Assignment Submission must be completed through a designated Moodle Area:https://moodle-1819.ucl.ac.uk...Make sure the course code (INST0001) and your name and the name of the other person youhave worked with are clearly marked below the report tile.Only one student can submit for the pair.Marking Criteriaand WeightingRubricThese are described in Appendix A below.The assignment is worth 20 % of the overall assessment for this courseThis assignment must be completed: Report (in pairs)Date work set (provisional): 07/02/2019Date and time due in (provisional): 15/03/2019 - for the submission of the reportStandard lateness penalty will apply.The target date for the return of marked work and full feedback(provisional): Marked work is returned on: 12/04/2019 (tentatively within 4 weeks, according to DIS policy)A detailed description of the assignment isavailable at: https://moodle-1819.ucl.ac.uk...INST0001 Coursework Assignment BriefUCL DEPARTMENT OFINFORMATION STUDIES2Detailed Assignment DescriptionYou are building an online business database of your choice. The database must have the followingselements: A manner for the customer to login to the online system the list of product and their attributes (e.g. price, which should range between ￡1.00 to ￡100) Customer transaction history (e.g. what they bought, how many items, and all the data relevant to thetransaction).You need to produce a Written Report (1500 word max) which includes the title of the report, the authors(and percentage each has contributed to its creation) and the following:A. (23% of mark) Customer Brief – this is an essential part of both the project development and thecontract with the client as it helps guarantee that the work for a project will be done according tospecific guidelines and expectations of the client. Your brief should include:o An Overview of what the business does (a short paragraph of max 500 words)o A Concept Table (who, when, where, why, how)o A conceptual model of the business and its attributes (e.g. main tables and columns needed inthe database) displayed visually in two manners as:§ Axis Technique§ Conceptual ER modelo A definition of all the key-works utilised by the business and their meanings.B. (25% of mark) Show how from the conceptual ER model you have produced the logical ER model andnormalised it. In the report you need to present:o First logical ER model (this is likely to be the same as the Conceptual ER model, where youhave ensured it has all the columns, but might not have all the keys)o Logical ER model (1NF)o Logical ER model (2NF)o Logical ER model (3NF)C. (10% of mark) Build the database in XAMMP (in the report you should provide the screen-shots of thedatabase creation)o Create the databaseo Create all the tables, with columns and keysD. (32% of mark) Code the following queries in XAMMPS (in the report provide the screen-shots of thequeries code and results/print out):o Produce a list of items which are low stock (e.g. below 20 items in the warehouse)o Produce a list of customers that live in specific UK city that bought items above ￡20.00o List the products of the company that have sold the most in the last montho Produce an invoice on that day (date) for a specific customer (customer name and address)that has more than one item and more than one quantity, and the total to be paid by thecustomerE. (10 % of mark) Composition of reporto Include a table of content and figureso Include all screen-shot and graphics. These must be readable, that is of good quality andappropriate for the size of the papero Ensure spelling and grammars have been taken care off.NOTE:v A penalty reduction by a grade will be applied for every additional 500 words used.v Penalties are applied for late submissions (refer to the department guidelines).v The Marking Scheme in Appendix A provides further details on how your work will be marked and can be used to guideyour work. Please study the marking scheme carefully and use it as a checklist before submitting the work.v Students that do not work in pairs as directed will be penalised unless a special exemption has been granted.v You may consult the lecturer or ask for further advice about your coursework by posting a query on the Moodle3INST001- Database SystemsAPPENDIX A – MARKING SCHEMEREPORT Criteria Inadequate(up to 39)Poor/Missing(40-49)Adequate(50-59)Good(60-69)Very Good(70-79)Excellent(80+)COMPOSITION OFREPORT:Is the report readable,well-structured with nogrammatical errors?There is little or noevidence of thoughtabout structure, andthe document'sreadability andgrammar are severelyimpairedThere is a structure;however, the documentis still hard to readand/or has severegrammatical errorsThere is some evidenceof thought towardsstructure, but poorchoices impairreadability andgrammarThe report isstructured, perhapsusing sub-headings orparagraphs to directthe reader through thecontent, has good useof language, and figuresare readableThe report is wellstructured,probablyusing sub-headings orparagraphs to lead thereader through thematerial, has good useof language, and thefigures are legible. Thecontent is wellexplainedExcellent writing andstyle, topics excellentlyexplained visualisedand structuredCOMPLETENESS andCORRECTNESS OF EACHELEMENT:Does the reportcontain all the itemsrequired in thecourseworkdescription? Havethese items been wellexecuted?(e.g. A,B,C,D, E)Most items aremissing or are not wellexecuted.The majority of itemsrequested are missing orincomplete, or they havea poor executionThe majority or allitems are present;however, they mightnot be well executed ordescribedAll items requested arepresent and wellexecuted and describedAll items are present,very well executed,very well describedThe report goes wellabove the task andguidelines providedPAIRS WORK:Does the report explainhow the work wasapportioned?(e.g. collaborationtable)The report does not describe how the work wasallocatedThe reportexplains adequatelyhow the work wasdistributed, however,the collaborationdeclaration is missingor both members of thepair have not signedthe tableThe report describes how work was apportioned.The collaboration declaration is present andsigned by all group membersThe student hasexplainedhow work wasdistributed. Thestudent has evaluatedthe way in which workwas apportioned. 4Student Name: __ First Marker initials: __ Second Marker initials __Elements assessed Comments RatingsComposition of report 0 1 2 3 4 5Completeness & Correctness of A 0 1 2 3 4 5Completeness & Correctness of B 0 1 2 3 4 5Completeness & Correctness of C 0 1 2 3 4 5Completeness & Correctness of D 0 1 2 3 4 5Completeness & Correctness of E 0 1 2 3 4 5Pairs work 0 1 3 5 ...

CSC 321/621 – Spring 2019Test 1 – Take Home PortionYou may access textbooks and course materials but the WORK SUBMITTED MUSTBE DONE BY YOU AND YOU ALONE! No communication regarding these questionswith anyone real or virtual. No Exceptions. I reserve the right to ask you to explainyour responses orally if I have a question about your response.I will try to clarify any questions you have. Send your questions in e-mail. I’ll broadcast aresponse as quickly as possible. Please submit your responses on paper (printed orhandwritten) at the start of class on Tuesday. The deadline is 12:30pm next Tuesday, 2/19/19.Setup:Download the following files: Resources ? Test 1 Materials ? { yadkin.db, make-yadkin.sql } from Sakai.You will need to open the yadkin.db database in SQLite Studio to write and check queries. The file namedmake-yadkin.sql contains the SQL code used to create the database schema. You will only need to open it ina text editor, not in SQLite Studio.Explanations regarding Yadkin: ...

在计算机领域有许多平凡的设计理念和思维，例如： 在 Unix 中，所有皆文件。在面向对象的编程语言中，所有皆对象。关系数据库同样也有本人的设计思维：在 SQL 中，所有皆关系。 关系模型关系模型（Relational model）由 E.F.Codd 博士于 1970 年提出，以集合论中的关系概念为根底；无论是事实世界中的实体对象还是它们之间的分割都应用关系示意。咱们在数据库系统中看到的关系就是二维表（Table），由行（Row）和列（Column）组成。因而，也能够说关系表是由数据行形成的汇合。 关系模型由数据结构、关系操作、完整性束缚三局部组成。 关系模型中的数据结构就是关系表，包含根底表、派生表（查问后果）和虚构表（视图）。罕用的关系操作包含减少、删除、批改和查问（CRUD），应用的就是 SQL 语言。其中查问操作最为简单，包含抉择（Selection）、投影（Projection）、并集（Union）、交加（Intersection）、差集（Exception）以及笛卡儿积（Cartesian product）等。完整性束缚用于保护数据的完整性或者满足业务束缚的需要，包含实体完整性（主键束缚）、参照完整性（外键束缚）以及用户定义的完整性（非空束缚、惟一束缚、查看束缚和默认值）。咱们明天的主题是关系操作语言，也就是 SQL。本文应用的示例数据来源于这篇文章。 面向汇合SQL（结构化查询语言）是操作关系数据库的规范语言。SQL 十分靠近英语，应用起来非常简单。它在设计之初就思考了非技术人员的应用需要，咱们通常只需阐明想要的后果（What），而将数据处理的过程（How）交给数据库管理系统。所以说，SQL 才是真正给人用的编程语言！ 接下来咱们具体分析一下关系的各种操作语句；目标是为了让大家可能理解 SQL 是一种面向汇合的编程语言，它的操作对象是汇合，操作的后果也是汇合。 在关系数据库中，关系、表、汇合三者通常示意雷同的概念。SELECT上面是一个简略的查问语句： SELECT employee_id, first_name, last_name, hire_date FROM employees;它的作用就是从 employees 表中查问员工信息。显然，咱们都晓得 FROM 之后是一个表（关系、汇合）。不仅如此，整个查问语句的后果也是一个表。所以，咱们能够将下面的查问作为表应用： SELECT * FROM (SELECT employee_id, first_name, last_name, hire_date FROM employees) t;括号内的查问语句被称为派生表，咱们给它指定了一个别名叫做 t。同样，整个查问后果也是一个表；这就意味着咱们能够持续嵌套，尽管这么做很无聊。 咱们再看一个 PostgreSQL 中的示例： -- PostgreSQLSELECT * FROM upper('sql');| upper ||-------|| SQL |upper() 是一个大写转换的函数。它呈现再 FROM 子句中，意味着它的后果也是一个表，只不过是 1 行 1 列的非凡表。 SELECT 子句用于指定须要查问的字段，能够蕴含表达式、函数值等。SELECT 在关系操作中被称为投影（Projection），看上面的示意图应该就比拟好了解了。 ...

简介： 存储策略该怎么设计 写这篇存储布局的文章次要是想通知大家该如何给存储做一个布局，在关系数据库的时代存储低廉且珍惜，掰手指头花钱是存储布局的常态。然而到了大数据时代大家又立刻就都变成印美元的美国政府了，感觉存储很多能够随便霍霍，然而又不停的求国会再晋升政府债权下限。反而造成了一种日子过的还不如关系数据库的感觉，至多是看着人家没有咱们这么焦灼和生灵涂炭。怎么就让咱们动则以PB计算的大数据产品，日子过的比论GB过日子的关系数据库还惨呢？ 公共云费用测算在私有云，MaxCompute为了吸引新用户去理解和应用产品，实际上做到了1元钱学习MaxCompute和DataWorks的成果，学习应用老本非常低，账户充值10块钱都能轻易畅游这两款产品1年。所以，咱们要看下真正的用户免费是什么样子的。 l 套餐资源链接：https://help.aliyun.com/docum... 套餐蕴含计算资源和存储资源，如下表所示。 l 套餐价格 l 存储费用测算 依据上表咱们做一个简略测算。应用160CU的规格存储为150TB的套餐，超出100TB时每天的费用是0.019元1000GB100TB=1900元，每月费用是57000元，大于套餐包价格35000元。 存储爆炸起因 从下面的例子咱们能够看到，假如在计算资源够用的状况下，存储的减少带来的老本的回升是难以承受的。而且计算是跟业务需要强关联，如果没有新的业务需要，每天解决数据的量不会大幅变动，然而批量零碎每天都会产生新一天的数据。 假如咱们应用MaxCompute集成一个大小为100G的交易型零碎的数据库，数据加工的时效是T+1，会有两方面因素导致数据存储的收缩。 快照表。快照表是指MaxCompute的表的每一个分区的数据都是业务零碎对应的表的一份镜像。依照集成频次T+1，一个100G的业务零碎每天在MaxCompute存储一份快照，一年的存储要求是（365*100G）36.5TB。分层架构。依照个别数据仓库的分层架构，至多会分为3层，镜像层、中间层、应用层。数据入仓后每回升到一个新的分层，数据都会被复制一份。尤其是到了应用层，不同的利用会多份复制数据进行共性加工。咱们暂且拍一个比拟激进的比例：1:1:1，那么每年对存储的需要就减少到了36.5*3=100TB。所以，通过下面的测算咱们失去了一个非常简单的换算（正当然而可能不够准确），如果应用MaxCompute集成一个存储规模为100GB的业务零碎，采纳T+1频次计算，那么咱们每年须要的存储空间是源零碎的1000倍（也是就说100GB变成了100TB）。 存储设计通过下面局部的剖析，咱们晓得了快照表的存储模式是导致数据被复制了很多份的最大的起因。1行1年内没有更新的记录应用快照存储，会被复制365份。那么为什么数据仓库ETL过程会大量应用快照表呢？总的来说就是构造简略好用，适宜ETL加工。 杜绝快照表是不可能的，那就须要思考如何设计存储。存储优化有两个方向，第一个方向就是压缩，第二个方向是清理。 数据清理数据清理比较简单，重要的是把不须要的数据及时清理掉。数据清理的办法有： 业务下线。曾经不再应用的应用层数据表，是否能够清理下线。主动回收。利用lifecycle设定分区的生效工夫，零碎后盾主动回收。ALTER TABLE table_name SET LIFECYCLEDAYS; ALTER TABLE table_name partition[partition_spec]ENABLE|DISABLE LIFECYCLE; 被动治理。个别用于生产环境管控，不同的档次采取不同的策略，例如存储最近N天+月末时点快照。被动治理应用自定义脚本的办法定时清理不须要的数据分区。还有被动治理能够对开发环境或者一些我的项目空间设置存储下限，疏导开发人员去设计和治理存储。要求长期表应用完就立刻开释。反复存储。一些数据表只是一个两头后果集，并没有长期存储的必要，能够倡议开发人员应用视图或者长期表代替或者缩小不必要的历史存储周期。数据清理会删除一部分分区的数据，这也代表着一部分工夫的快照的状态被从历史中革除了。T+1的批量会记录每行数据每天的最初一个状态，然而如果保留策略是月末+最近N天，那么最初咱们能从历史数据中获取到的数据状态就是每月的最初一个状态。 这种状况下，历史数据清理到什么水平，是须要一个业务领导。还有倡议在数仓分层架构的最上面的档次对历史数据进行保留。 以清理策略为“保留月末+最近10天”的数据存储需要为例，一年的存储需要从100TB裁剪到100GB(12个月+最近10天)3层=6.6TB，变成了原来策略的1/15。原来160CU规格的存储150TB，能够让存储为100GB业务零碎的数据存储1.5年，当初则变成了20年。 数据压缩数据压缩是指利用产品自带的存储压缩个性，或者利用拉链表构造压缩存储。 l 在以后表上进行压缩 归档。将存储比从1:3进步到1:1.5，能够节俭一半的物理空间，同时也采纳了更高压缩比的压缩算法。alter table my_log partition(ds='20170101') archive; 如果启用归档策略，对历史数据进行归档。咱们能够看到存储会在原有根底上放大一半。能够让每年100TB存储需要，缩小为50TB。 l 备份到另外一张表 分区合并。对于一些数据量十分小的表，历史数据的备份存储能够采纳把一个区间内所有数据合并到一个分区的办法来优化存储（次要还是优化小文件）。拉链表。拉链表是传统数仓得以运行的外围数据存储办法，在MaxCompute上依然能够应用这个办法。拉链算法的外围是让每条记录的每个状态变动都保留为1行记录，而不是快照表的N份，这种办法能大量节约存储资源。如果启用拉链表策略，数据存储能够认为与源零碎根本持平，只是须要计算分层复制。一年的存储需要从100TB裁剪到100GB1天3层=0.3TB，变成了原来策略的1/300。原来160CU规格的存储150TB，能够让存储为100GB业务零碎的数据存储1.5年，当初则变成了500年。(这个计算过于理想化，因为ETL过程都次要应用快照表来施行，所以，只能对临时不须要应用的历史数据备份)。 备份就相当于表构造与原来不统一了，会发生变化。所以，拜访历史数据须要应用与快照表不一样的办法。 拉链表链接：https://developer.aliyun.com/... 压缩比照快照表与拉链表拉链表与快照表比拟起来有更低和更正当的存储个性。 快照表与拉链表构造比照如下： • 拉链表的每个主键在存储周期的所有时点，一个状态只存储了一行数据。 • 快照表的每个主键在存储周期的所有时点，每个时点都会存储一行数据。 从下面的比拟能够看进去，应用快照表存储数据，每个MaxCompute的数据分区都会存储一份数据，而拉链表只存储了一份数据。看起来存储大小比照是N：1，N就是快照表的分区个数，而1就是1个最新快照表的分区大小。 拉链表的压缩比上面是依据理论数据测算的两种数据表的压缩比，一种是记录增长率低的表，另外一种是记录增长率高的表。比照发现，应用拉链表存储后一月的数据大概都只是1天数据的1倍左右。 A表：记录增长率低表【用户信息】 日期：20170501-20170531 天数：31天 B表：记录增长率高表【交易日志/事件表】 日期：20170501-20170531 天数：31天 存储归档的压缩比如果Project里的空间比拟缓和，须要进行数据删除或数据压缩，能够思考MaxCompute里对表的Archive性能，成果是能够将存储空间压缩50%左 右。Archive性能将数据存为Raid File，数据不再简略的存三份，而是6份数据+3份校验块的形式，这样无效的将存储比从1:3进步到1:1.5，能够节俭 一半的物理空间，同时也采纳了更高压缩比的压缩算法。 上述的操作也是有代价的，如果某个数据块损坏或某台机器损坏，复原数据块的工夫要比原来的形式更长，读的性能也会有肯定损失。所以当初这种性能能够用在一些冷数据的压缩存储上，例如一些十分大的日志数据，超过肯定工夫期限后应用的频率非常低，然而又须要长期保留，则能够思考用 Raid File来存储。 ...

简介： MaxCompute作为企业级数据仓库服务，集中存储和治理企业数据资产、面向数据利用解决和剖析数据，将数据转换为业务洞察。通过与阿里云内、内部服务灵便组合，可构建丰盛的数据利用。全托管的数据与剖析解决方案，可简化平台运维、治理投入，晋升面向业务的服务能力，减速价值实现。本文作者 孔亮 阿里云智能 产品专家 一、MaxCompute 根底介绍阿里云数据与剖析产品解决方案MaxCompute作为企业级数据仓库服务，集中存储和治理企业数据资产、面向数据利用解决和剖析数据，将数据转换为业务洞察。通过与阿里云内、内部服务灵便组合，可构建丰盛的数据利用。全托管的数据与剖析解决方案，可简化平台运维、治理投入，晋升面向业务的服务能力，减速价值实现。 从下图能够看出 MaxCompute 是处于一个外围地位，首先 MaxCompute 是一个数据仓库，而且是一个基于 Serverless架构超大规模集群产品，具备平安治理能力等企业级能力。之前是偏离线数据处理平台，以后曾经具备BI剖析能力的企业级数据仓库。 个别企业的离线数据链路，从数据源蕴含关系型数据库、非结构化存储、大数据存储、音讯队列等等，都能够通过数据集成离线的形式，批的形式，进入到数据仓库中。前端的各种剖析利用，也能够有一些实时的剖析，通过 MaxCompute-Hologres做查问减速，这是离线的场景。实时链路是从音讯队列数据源，通过Datahub数据总线，到实时计算Flink，对接到实时数仓Hologres，再对接到前台。两头的数据是通过 Hologres 和 MaxCompute 还有 Flink，做流批一体。MaxCompute在数据仓库的根底上，扩大了数据库的一些联邦查问能力，包含Data Lake、Mysql、Hbase等，数据的集成，包含元数据的同步和查问去同步数据数据湖数据处理的能力。还蕴含基于数据仓库数据之后，人工智能PAI机器学习的能力。形成了残缺的大数据底座。在这之上，DataWorks提供了，一站式的开发治理平台，能够做任务调度、元数据数据数据品质的血统治理、数据开发等能力。 MaxCompute 大数据计算服务简介MaxCompute（大数据计算服务）是一款多功能、高性能、易于应用的数据仓库服务。 MaxCompute内建欠缺的企业级平安及治理性能、反对凋谢数据生态，以对立平台满足多应用场景（数据仓库/BI、数据湖剖析、机器学习）须要，被宽泛用于数据化经营、画像及举荐、智能预测等利用场景。 MaxCompute 底层有对立Iass层的存储和计算调度，存储是盘古，调度是伏羲，把存储跟计算资源做了一层封装，用资源池的形式对下层利用无感知的提供应用，下层利用只须要应用这个资源组，而不须要晓得具体的工作运行在什么资源下面。MaxCompute 能够提供结构化数仓的存储能力，也能够提供数据湖包含凋谢格局、半结构化、非结构化等数据处理的能力。对于用户来说，所有应用场景都在我的项目外面，每个我的项目之间租户隔离，能够有本我的项目的资源，也能够共享资源。我的项目间接通过平安共享的形式，能够同步数据。再下层用对立的拜访认证、治理、平安、监控、元数据等能力。 能够总结出以下几点： 简略易用的SQL 端到端开发方式，反对Spark，分布式Python（Mars）等开源技术栈，内置欠缺的企业治理性能和凋谢的接口，简略易用凋谢对立元数据、对立数据存储，一份对立的企业数据资产，云原生的多租户零碎，最高效的跨业务&跨组织数据连贯与共享自适应的按需弹性资源，精准匹配业务规模的变动，防止资源节约或有余，业务负载隔离，打消业务间资源争抢存储与计算独立伸缩，反对TB到EB级的存储扩大；连贯宽泛内部数据源，发展联邦计算深度优化，主动数仓，集成多年双11优化能力，智能调优+专家服务反对 MaxCompute 性能介绍MaxCompute 性能能够分为下图几类。最外围的存储计算能力是不对外开发的。存储次要用的是数据库表，计算资源会在SQL工作或者其余计算模型上应用时体现进去。看SQL计算能力，能够端到端实现整个数仓的数据处理和数据模型治理等能力，包含一些根底的数据类型，外部表做一些分区，内部表处理非机构化数据等。反对流式写入，流式upsert插入数据，删改数据等能力。查问时能够用非常复杂的查询方法，能够看解析打算Explain。UDF侧，MaxCompute反对Java UDF和Python UDF，还包含内容平安UDF。 治理能力，下图深色局部是在专有云里会有独立的加强包来对企业提供额定的计算能力。公共云上是间接Serverless形式提供给用户，只收资源费用。 治理能力也蕴含计量计费的能力，包含预付费和按量计费。工作有工作治理，查问有查问减速，专有云部署时，大规模跨域计算等企业级能力。MaxCompute除了SQL引擎外，还有向量检索，TensorFlow，Spark，Mars，Hologres，这些都能够基于MaxCompute的底层存储计算资源，用不同的引擎，提供对应场景的能力。合规治理局部，灰色局部有一些是DataWorks提供，包含自身数仓平安治理能力，元数据管理能力，审计能力，数据加密，数据脱敏，数据品质等性能。再通过SDK/API和MaxCompute提供的配套工具来实现数据开发，数据上传下载，还有一些三方利用，二方利用来实现整个数仓的生态构建。 MaxCompute 次要解决方案企业数据仓库/数据中台 将原始数据整合为可被宽泛应用的常识，用于后续生产应用，包含： •集成存储：收集、存储和集中管理企业内外数据； •解决剖析：荡涤、加工、整合多方数据；面向业务需要统计、开掘；对立的存储和解决能够提供弹性伸缩的存储计算能力，缩小老本 •标准化：建设企业数据仓库模型（分层/分主题），建设数据规范，造成可复用数据资产，并且通过数据治理，进行数据生命周期平安、老本治理等、继续保障数据品质和标准化 •数据互通：在企业内流转共享规范数据，买通数据孤岛，让关联的数据施展更大的价值 数据中台不仅是技术平台，还蕴含组织和治理流程要求，强调以公共数据产品服务业务，实现”数据业务化”，可认为数据仓库的一种最佳实际。MaxCompute+DataWorks是开箱即用的数据仓库解决方案。 BI剖析/数据分析 BI剖析并不必然要应用数据仓库，如可间接基于交易数据库剖析 数据仓库可能帮忙提供BI剖析须要的企业视角的全面数据 通过数据仓库的数据资产治理，BI剖析人员可更好地检索、了解数据 数据仓库还可能以弱小的性能，满足多用户并发、剖析不同数据规模需要 MaxCompute提供数据的集中管理、解决剖析，可间接对接BI或者将数据同步到内部剖析型数据库(OLAP)进行BI剖析 预测剖析/智能利用 数据仓库与AI集成日益严密 数据仓库为机器学习进行数据加工、数据筹备 机器学习对数据进行模型训练，数据预测，后果可间接固化在数据仓库进行常识共享，如用户画像剖析对客户性别、偏好的预测 MaxCompute无缝集成PAI、SparkML，1个平台无需数据挪动即可在企业数据之上建设基于机器学习的智能利用，如CTR预估、个性化举荐 二、MaxCompute半结构化数据处理什么是半结构化数据本文的主题是MaxCompute半结构化解决能力，咱们先看一下什么是半结构化数据。 结构化数据，即行数据，存储在数据库里，能够用二维表构造来逻辑表白实现的数据 非结构化数据，包含所有格局的办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等 半结构化数据，就是介于齐全结构化数据（如关系型数据库、面向对象数据库中的数据）和齐全无构造的数据（如声音、图像文件等）之间的数据，HTML文档就属于半结构化数据。它个别是自描述的，常常变动的，数据的构造和内容混在一起，个别由一个三元组示意，包含标记、类型和对象的值。 通过数据模型比拟： 结构化数据：关系型（二维表）半结构化数据：由一个由节点汇合和弧段汇合组成的具根有向图构造。(树、图)非结构化数据：无最初从wiki带的定义看，半结构化的特点是简单类型构造，易变，须要从自描述构造中提取数据进行计算。 Semi-structured data[1] is a form of structured data that does not obey the tabular structure of data models associated with relational databases or other forms of data tables, but nonetheless contains tags or other markers to separate semantic elements and enforce hierarchies of records and fields within the data. Therefore, it is also known as self-describing structure. ...

摘要：本篇文章将硬核解说M-SQL：一种将自然语言转换为SQL语句的多任务示意学习办法的相干论文。本文分享自华为云社区《【云驻共创】M-SQL，一种超强的多任务示意学习办法，你值得领有》，作者： 启明。 数据集整体介绍定义介绍国际惯例，先来一段定(bai)义(du)介(bai)绍(ke)：Text to SQL，顾名思义，就是在给定数据库（或表）的前提下，依据用户的发问，产生SQL语句。其数学形容如下： 令X示意用户的自然语言发问，D示意与发问相干的数据库（或表），Y示意其对应的SQL语句。 SQL语句生成工作能够表述为：对于每一组独立的(X,D,Y)，将(X,D)映射到对应的Y。 用一个大家相熟的场景为例。假如咱们有一张学生信息表，咱们能够用自然语言发问：大于18岁的学生都有谁，模型须要返回一个与之相干的SQL语句，那么就是： SELECT 姓名 FROM 学生信息 WHERE 年龄 > 18 场景分类Text to SQL有很多种分类，其中一种是按问题分类： 一种是上下文无关的（发问之间不存在关联）：Spider 一种是上下文相干的（两个发问之间存在肯定关联）：SparC “上下文无关”是指发问之间没有任何的关联，而“上下文相干”是前后两个发问之间，存在一些指代关系或者说存在肯定的关联。 同样，咱们举一个简略的例子来阐明： 发问1：有预约的医生ID是什么？ SELECT physician FROM appointment 发问2：他们的名字是什么？ SELECT T2.name FROM appointment AS T1 JOIN physician AS T2 ON T1.Physician = T2.EmpoyeeID 以上就是一个上下文相干的例子，第一句的确定医生ID，第二句依据医生ID确定医生名字。 另一种是按畛域分类：单畛域 or 多畛域 如果所有的发问都是有对于航空方面的，这就是一个单畛域的数据集。而跨畛域数据集，则是在训练集当中可能有很多种畛域，在测试集当中也有很多种畛域，然而训练集中的畛域和测试集中的畛域不重合，这就要求咱们的模型具备肯定的泛化能力。 第三种是依照数据库进行分类： 单表数据库：WikiSQL，其发问只针对一个表，或者是它所针对数据库当中只有一个表 多表数据库：Spider，其发问针对的数据库当中有许多个表，它所产生的 SQL语句可能波及到多个表之间的连贯。 第四种种分类是依照标注类型进行分类： 最终后果：WikiTableQuestion SQL语句：WikiSQL、Spider 有一些数据集没有给出相干的SQL语句，而是间接给出了一个后果。以后面的例子为例，“大于18岁的学生都有谁”，输入有可能是给出SQL语句，也有可能是最终后果：把这些人名都给列出来，而没有给出SQL语句，这其中波及到的“弱监督学习”，本次不做具体解说。 TableQA 数据集本次要解说的论文所采纳的是一个TableQA数据集，它也是一个单表数据。也就是每一个发问都只针对一个表进行发问。TableQA和WikiSQL有有很多相似之处，然而也有肯定的差别，如下图所示： 论文概述介绍完数据集之后，咱们来对论文中所提出的模型进行一个简略的介绍。 首先来思考这样一个问题：通过自然语言生成SQL语能够有什么办法？其实一个最简略的思路：输出端是自然语言句子，输入端是与之对应的SQL语句（依照SQL语句依照一个token一个token进行生成）。 比如说咱们后面那个例子，Encoder是“大于18岁的学生都有谁“，输入端是SELECT name FROM XX表 Y条件。 这个办法很简略，然而也随同着一些问题：SQL语句是结构化的查询语言，它是具备肯定的构造的，这和个别的语言生成工作是有肯定差异的。 对于个别的语言生成工作来说，如果变更其中的一两个词，可能它的语义不会产生太大变动。然而对于 SQL语句来说，如果某个词不一样了，那么其就可能就没有方法继续执行。所以咱们须要利用好SQL语句外部的一些语法信息，也就是构造信息。依照它的构造来进行生成，这就是论文当中所提出来的，依照 SQL的框架来进行生成。 ...

摘要：如果能够将外连贯转换为内连贯，那么就能够简化查问优化过程。本文分享自华为云社区《GaussDB(DWS)外连贯向内连贯的转换》，作者：wangxiaojuan8。 在查问优化的过程中，内连贯的表之间的连贯程序能够随便替换，where或on条件中只波及单表的条件能够下推到表上作为表的过滤条件；而对于外连贯来说，表的连贯程序不能随便替换，约束条件也不能随便的下推。如果能够将外连贯转换为内连贯，那么就能够简化查问优化过程。 外连贯可转为内连贯需满足的条件为了形容不便，引入两个名词： 不空侧：外连贯中所有数据都被输入的一侧。比方：左外连贯的左表、右外连贯的右表可空侧：外连贯中会被补空值的一侧。比方：左外连贯的右表、右外连贯的左表、全外连贯的左表和右表只有满足以下条件之一，就能够将外连贯转换为内连贯： Where条件中有“严格”的约束条件，且该约束条件中援用了可空侧的表中列。这样，该谓词便能够将可空侧产生的空值都过滤掉了，使得最终后果等同于内连贯。参考《PostgreSQL技术底细-查问优化深度摸索》一书中对“严格”的定义如下： “严格”的准确定义是对于一个函数、操作符或者表达式，如果输出参数是NULL值，那么输入也肯定是NULL值，就能够说这个函数、操作符或者表达式是严格的；然而宽泛的说，对于函数、操作符或者表达式，如果输出参数是NULL值，输入后果是NULL值或者FALSE，那么就认为这个函数或者操作符是严格的。如果在约束条件里有这种严格的操作符、函数或者表达式，因为输出是NULL值，输入是NULL或者FALSE，那么对于含有NULL值的元组就会被过滤掉。 本文沿用GuassDB(DWS)的连贯类型介绍一文中的表和数据进行举例说明。 例1：查问数学问题不为空的学生的数学问题postgres=# select s.id, s.name, ms.score from student s left join math_score ms on (s.id = ms.id) where ms.score is not null; id | name | score ----+-------+------- 1 | Tom | 80 2 | Lily | 75 4 | Perry | 95(3 rows)postgres=# explain select s.id, s.name, ms.score from student s left join math_score ms on (s.id = ms.id) where ms.score is not null; QUERY PLAN ---------------------------------------------------------------------------- id | operation | E-rows | E-width | E-costs ----+----------------------------------------+--------+---------+--------- 1 | -> Streaming (type: GATHER) | 30 | 126 | 36.59 2 | -> Hash Join (3,4) | 30 | 126 | 28.59 3 | -> Seq Scan on student s | 30 | 122 | 14.14 4 | -> Hash | 29 | 8 | 14.14 5 | -> Seq Scan on math_score ms | 30 | 8 | 14.14 Predicate Information (identified by plan id) --------------------------------------------- 2 --Hash Join (3,4) Hash Cond: (s.id = ms.id) 5 --Seq Scan on math_score ms Filter: (score IS NOT NULL)(14 rows)例2：查问数学问题高于80的学生的数学问题postgres=# select s.id, s.name, ms.score from student s left join math_score ms on (s.id = ms.id) where ms.score > 80; id | name | score ----+-------+------- 4 | Perry | 95(1 row)postgres=# explain select s.id, s.name, ms.score from student s left join math_score ms on (s.id = ms.id) where ms.score > 80; QUERY PLAN ---------------------------------------------------------------------------- id | operation | E-rows | E-width | E-costs ----+----------------------------------------+--------+---------+--------- 1 | -> Streaming (type: GATHER) | 10 | 126 | 36.44 2 | -> Hash Join (3,4) | 10 | 126 | 28.44 3 | -> Seq Scan on student s | 30 | 122 | 14.14 4 | -> Hash | 10 | 8 | 14.18 5 | -> Seq Scan on math_score ms | 10 | 8 | 14.18 Predicate Information (identified by plan id) --------------------------------------------- 2 --Hash Join (3,4) Hash Cond: (s.id = ms.id) 5 --Seq Scan on math_score ms Filter: (score > 80)(14 rows)下面两个例子中，条件where ms.score is not null和where ms.score > 80，如果输出的score为NULL，则这个约束条件返回的是false，满足了宽泛的“严格”定义。所以能够将外连贯打消，转换为内连贯。从下面的查问打算也失去了验证。而且这种外连贯打消是能够有数据库的查问优化器来主动解决的。 ...

为什么T-TDSQL要去实现全时态数据库？ 原创技术的背地，是什么在驱动着T-TDSQL团队做出这样的一个全时态数据库系统？ 这些问题，其实更为重要。开掘这些问题的起因，为提倡原创而致力，当是TDSQL团队致力于技术分享时更看重的价值因素。 在TDSQL团队看来，“数据富裕价值，历史数据富裕价值”。在业务当中，开掘数据的价值是十分重要的一环，这也是很多人在思考的内容，认为任何数据都有价值是很有意义的。 因而，T-TDSQL我的项目的思考之后的观点是“Historical data are valuable. Business is a sword, Technology is only ashield.”。那么，什么是盾？什么是剑？盾和剑之间有什么关系呢？ 在TDSQL看来，技术只是一个防守工具，用于把幻想变成事实。幻想是技术人想利用各种高大上、高精尖的技术解决事实问题的美妙愿景，诸如分布式、一致性、快照、RDMA、NVM、AI、全数据挖掘等各种技术的炫酷应用。业务只是一个防御的工具，用于发现幻想。TDSQL并不提倡业务为王的观点，而是左手盾右手剑，两手都要硬。但仅是左手盾右手剑，行走在技术的江湖，这只能成就技术人行侠仗义的幻想。其背地，还短少灵魂的支柱。 而历史数据富裕价值，在（金融/腾讯/互联网/所有…）业务中，开掘数据的价值，更是富裕意义。 然而，百尺竿头更进一步。 数据的发明是由用户和其业务决定的，他们是发明数据的甲方。数据库承载了数据的治理职责，是否数据库系统也能够参加到数据的发明环节中来呢？ 在TDSQL团队看来，全时态这一概念，正是数据库系统参加到数据发明环节的最佳契机。数据库系统为数据赋于了事务时态、赋于了DML操作过程中的事件源，甚至可能为数据之间赋于关联关系（如下图中的5W、Lineage），这使得数据库系统也成为了数据的创造者。 这就是咱们、TDSQL团队在技术和业务背地的驱动因素：“为数据赋能”的理念。 在“为数据赋能”这个理念的撑持下，基于TDSQL的T-TDSQL因而而诞生。为数据赋能，因此能让数据领有更多的价值，让数据库变成数据的生产者，参加数据的发明。下图表明，为数据赋能，T-TDSQL从5W角度，让数据领有了工夫（双时态，WHEN）、地点（存储的历史表，WHERE）、人物（用户ID，WHO）、对象（全态数据，WHAT）、起因（DML等操作，WHY）等因素，使得数据不再仅仅是用户应用CREATETABLE语句所创立的数据，而是蕴含了多种由数据库系统所发明的数据、且在数据的生命周期中融入了数据历史使其富裕纵深的有价值的全副数据。 有了这些，数据库系统可能更加被动地追溯数据的历史，推演数据的变迁，预测数据（世界）的将来。

时态信息处理曾经成为许多新一代数据库与信息系统的关键技术，特地是在金融畛域 、电子商务、数据仓库、地籍管理系统、土地利用规划系统、地理信息系统中扮演着日益重要的角色。 电子商务、金融业务零碎中，存在大量的支出、收入、余额等数据，并且随着业务的推动，新数据源源不断地产生，这些数据将在对账、审计、用户画像等业务中施展重要作用。通过实现事务时态性能，T-TDSQL能疾速、精密、实时地获取这些数据。 在互联网金融业务中，对账业务是一个经典的业务。 T-TDSQL为腾讯的计费对账业务提供了完满的解决方案。 1.对账业务互联网金融行业对数据的准确性要求极高，而在互联网环境中，数据不统一或数据谬误时有发生，因而，通过对账来升高账户余额等数据谬误造成的危险非常重要。 在腾讯计费业务中，采纳将账户余额表(user)和账户流水表(water)按小时/天为周期进行比对的形式，来发现账户余额与交易流水的不统一景象，从而及时对谬误交易进行修改。 传统的对账采纳按固定时间段（如分钟/小时/天）为单位进行对账。如现对2018年4月11日的交易进行对账，首先须要失去4月11日期初账户余额表和期末账户余额表，以及当天的交易流水表；而后对账户表通过按用户ID分组，并计算每个用户的期末余额减去期初余额，记为后果A，对流水表按用户ID分组，并将交易金额分组求和，记为后果B；最初将每个用户的后果A和后果B进行比对，如果A=B，则交易没有问题，否则该用户在当天的交易存在谬误。 对于按固定时间段对账，次要存在以下三个问题： 1. 时效性差：对于谬误交易，不能立刻发现并反馈，提早了以固定时间段为单位的一段时间后能力发现错误。 2. 对账不精准：定位谬误交易较简单。例如：如果用户在一天内产生的多笔交易，其中一笔呈现了谬误，通过按天对账的形式不能间接定位到具体的哪条交易呈现谬误，而只能定位到用户级别，即依然须要人工参加，将该谬误用户的当天交易都确认一遍，能力找到具体的谬误交易。 3. 对账不灵便：按固定时间段对账，如以天为单位，则只能等这一天内的增量数据积淀下来，能力进行对账，如果有跨天对账需要（如昨天下午至今天上午），对账所用数据须要跨多个表能力执行，这可能扭转对账业务的流程。 2.对账优化基于本文提出的数据模型和增量计算方法，能够很好的解决按天对账所存在的问题。联合3.1.2中的示例，咱们给出在互联网金融的对账业务中，增量计算的理论利用。 T-TDSQL能够基于增量计算的性能将账户余额表(user)和账户流水表(water)进行精准比对，进行流水级别的细粒度对账，从而即时发现交易谬误，并能够立刻定位到谬误的那一条交易，省去繁冗的谬误交易定位过程。 优化后的对账的核心思想是：总账算摘要、细账笔笔精。 优化后的对账的成果是：总账快对、细账准确、不受时限、任意对账[1]。 对账步骤1—总账对账：首先读取给出对账时间段[s_start,s_stop]内的所有账户表数据块，对每个数据块内数据采纳与传统对账形式相似的公式来确认账户状况，即进行“总期末余额-总期初余额=总交易变动”试算[2]，总期初余额代表s_start时的总余额，总期末余额代表s_stop时的总余额，总交易变动代表每块内账户对应产生的流水，如果有数据块内的总账不平，意味着有细账谬误，因而要进行步骤2、3所形容的精准对账。 对账步骤2—精准对账—对账过程：执行如下SQL，将账户余额块和对应账户流水块进行“快照差连贯”，返回后果集中每条记录将含有{交易前余额，交易后余额，交易变动}。 对账步骤3—精准对账—精准之意：对步骤2后果里的每一条返回记录进行“交易后余额-交易前余额=交易变动”的试算[3]（After-Before=Change），即可确认交易是否有误。如果有不满足此等式的状况存在，即为谬误交易。 谬误交易次要分为账户表谬误和流水表谬误两种。例如，上图中，后果集中第2条元组，不满足试算公式，表明流水ID为2的交易进行了谬误的帐户余额更新或流水记录的交易变动值出错。后果集中的第4条元组，Change字段的值为NULL，代表该条交易的流水缺失。通过上图中的表，咱们对各种谬误状况进行总结，这些谬误，都须要在对账过程中进行报警。 3.无效工夫的时态类利用基于T-TDSQL的全时态核心技术，本次分享还从双时态的角度对典型利用做了介绍。 4.数据安全类利用基于历史状态查问这一个性，T-TDSQL零碎在数据勘误、历史追踪等方面，提供灵便弱小的数据安全保障性能，能够大大简化和放慢审计、对账等业务。 查问时间段内插入的数据，用于数据统计和追踪，如统计新开账户、异样记录何时被增加等。 查问时间段内删除的数据，在平安保障和数据统计等方面作用显著，如复原误删的数据、统计销户人数等。 查问时间段内更新的数据，可能追踪数据异样的产生工夫和产生异样前的数据，用于数据异样的修复。 综合查问所有状态的历史态数据，在数据重演方面，能够辅助灾后复原，或用于线下演练；数据统计方面，因反对任意时空节点的数据计算，对对账等业务大有裨益；平安保障方面，简化了谬误数据、误删数据的追踪和复原。 除此之外，基于全时态态数据，实现数据重演、更有价值的数据分析和开掘、应用AI技术对系统主动调优等成为可能。

T-TDSQL的核心技术之一，是数据模型的定义，全态数据模型和双时态数据模型的联合，造就了T-TDSQL。 1.T-TDSQL的核心技术一，数据模型 在这个模型中，全态数据体现在了数据项的历史版本上；时态数据不仅有事务时态、还有无效工夫时态。而全态数据的历史态数据，不仅能够追溯数据库系统的操作产生工夫，还能够追溯产生的操作类型，如下图中的“Operation”列，能够晓得在数据项上已经产生的DML操作是UPDATE还是INSERT还是DELETE。这是一个十分酷的个性，这使得用户在T-TDSQL零碎中能够实现“所有过往兼可追溯”的幻想。 2.T-TDSQL的核心技术二，历史数据转储机会 历史数据的存储机会，是T-TDSQL的另外一个核心技术。 T-TDSQL用全态的数据概念，奇妙地利用MySQL的回滚段和Purge机制，实现了历史态数据的转储。一个原理图如下： 3.T-TDSQL的核心技术二，一致性快照点 在PostgreSQL中，如果实现本技术，能够思考联合多版本的存储特点，实现以后态数据与历史态、过渡态的存储拆散，这须要批改已有的数据可见性判断算法、页面存储格局、数据的合并机会、缓冲区的读写和heap的结构形式等，更重要的是要实现新的数据一致性快照点。 而T-TDSQL基于MySQL实现了新的数据一致性快照点的构建，因此能够获取任何时间段（包含历史产生过的工夫）上的任何状态的数据。 作为原创技术，T-TDSQL的核心技术点及其思路，相干论文曾经在World Wide Web journal上以题为《Efficienttime-interval data extraction in MVCC-based RDBMS》发表，详情可参见： https://link.springer.com/art...

TDSQL的原创技术，不是为技术而技术，而是基于业务的需要，为解决业务问题而进行的翻新。 腾讯公司的计费业务零碎，是世界上当先的金融云计费业务零碎。这个零碎包含SAAS、PAAS、IAAS三个层面。在SAAS层面，包含米巨匠、云商店、TDSQL等零碎。 TDSQL托管账户近280亿，米巨匠依靠TDSQL进行金融交易,腾讯充值及其相干合作伙伴的日流水量超过150亿条，每天解决的交易量超过100亿笔。金融数据在TDSQL数据库中进行结算、对账、审计、风控数据分析、构建用户画像等业务。如王者光荣游戏点券的对账业务、用户账户生产充值变动审计与风控业务等。 要进行诸如对账、审计等业务，数据起源有两局部。一部分数据起源是从不同零碎（关系数据库或NoSQL零碎）的日志数据中来，称为流水日志。但某个这样的零碎每天的日志流水数据近百G且从趋势看增量数据递增很快。另外，有些数据是在TDSQL中按工夫分表，需在一段时间完结后对按工夫分表的数据利用流水日志进行对账计算。 对账次要是解决几种异常情况： 零碎存在BUG，或者在故障时，未体现出预期的状况。这可能导致发货胜利扣款不胜利，或者扣款胜利未发货的状况。如腾讯视频VIP管理系统的充值、发货。躲避黑客/外部危险。例如不法人员绕过业务零碎去给本人充值等舞弊行为。这样的对账业务品种很多，不同的利用其日志流水格局不完全相同，TDSQL托管的账户须要定时对多级数千种业务和账户做数据一致性对账测验。 从技术的角度看，存在四个问题： 利用开发简单：应用业务日志，须要业务零碎一直产生日志信息，而后消耗计算资源对不同的日志格局进行解析，把日志信息存储到剖析零碎。由此带来了开发的累赘和资源的节约。数据逻辑割裂：TDSQL中按工夫分表，只能按确定的时间段进行结算，不能灵便、不便的计算。如计算任意时间段内的数据，按时间段的分表在物理上割裂了数据按工夫的逻辑间断个性，须要指定若干个特定的分表能力进行计算。实时个性失落：如上两个问题，隐含地，意味着进行计算的数据须要导入到一个新的剖析零碎进行计算，导出/导入数据的过程也带来了资源和工夫的耗费、使得剖析零碎难以具备实时计算个性。数据管理简单：另外，日志等信息，是历史态数据，须要长期保留。在腾讯公司每日对不同格局的、超过150亿条流水日志进行生成、存储、解析与治理等，这成为一个微小的挑战。古代的数据库系统只保留有数据的以后值，而因存储老本等起因，历史态数据被抛弃。而数据作为重要的资产，不论是以后数据，还是历史上已经存在过的数据，都具备重要价值。因而，历史态数据存储、被剖析、被开掘、被重复应用，是以后互联网等企业的需要。尤其是金融类历史态数据，因为平安、须要被屡次计算的起因，在腾讯公司的计费业务中，带有时态属性的数据被治理的需要日益旺盛。 基于上述起因，腾讯公司基于TDSQL关系型数据库研发了时态数据库 T-TDSQL，由数据库系统对立治理海量的全时态数据、以后数据，解决了上述四个业务中的问题。 业务痛点的解决，是基于数据库的特点和业务场景进行深入分析和思考而得以解决的。 因为数据有价值，所以TDSQL团队认为：历史数据富裕价值。这是TDSQL时态数据库T-TDSQL的外围价值观。因而，咱们给出了TDSQL对于数据的新的意识。 TDSQL认为： 数据的状态属性，标识数据的生命周期轨迹。数据的生命周期分为三个阶段，每个阶段刻画数据的不同状态属性，以标识数据的生命周期轨迹中所处的状态。 以后态（Current State）：数据项的最新版本的数据，是处于以后阶段的数据。处于以后阶段的数据的状态，称为以后态。历史态（Historical state）：数据项在历史上的一个状态，其值是旧值，不是以后值。处于历史阶段的数据的状态，称为历史态。一个数据项的历史态，能够有多个，反映了数据的状态变迁的过程。处于历史态的数据，只能被读取不能再被批改或删除。过渡态（Transitional State）：不是数据项的最新的版本也不是历史态版本，处于从以后态向历史态转变的过程中。处于过渡态的数据，称为半衰数据。这三个状态，涵盖了一个数据项的生命周期，合称为数据全态（full-state），或称为全态数据。在MVCC机制下，数据的三种状态均存在；在非MVCC机制下，数据只存在历史态和以后态。 以后态：MVCC或封闭并发访问控制机制下，事务提交后的数据的新值处于以后态。历史态：MVCC机制下，以后沉闷事务列表中最小的事务之前的事务生成的数据，其状态处于历史态。在封闭并发访问控制机制下，事务提交后，提交前的数据的值变为历史态的值，即数据项的旧值处于历史态。过渡态：MVCC机制下，被读取的版本上尚有沉闷事务（非最新相干事务）在应用，因最新相干事务批改了数据项的值，其最新值曾经处于一个以后态，被读取到的值绝对以后态曾经处于一个历史状态，故其数据状态介于以后态和历史态之间，所以称为过渡态。数据的双时态属性，别离为无效工夫属性、事务工夫属性。 无效工夫属性示意数据表示的对象在工夫属性上的状况。如Kate中学起止工夫是2000-09-01到2003-07-30，而大学起止工夫是2003-09-01到2007-07-30，这里的工夫就是无效工夫。 事务工夫属性示意数据的某个状态的工夫产生时刻。数据具备其时态属性，即在何时数据库系统进行了什么样的操作。某项操作在数据库系统内被封装为事务，而事务具备原子性。因而，咱们采纳了事务标记来标识一个数据的事务时态属性。 从模式上看，无效工夫属性和事务工夫属性，在数据模型中用一般的用户自定义字段进行示意，只是用特定的关键字加以形容，供数据库引擎进行束缚检查和赋值。 TDSQL团队冀望，构建一个数据库系统，解决如上问题，新零碎应该提供的个性如下： 因而，基于TDSQL的T-TDSQL时态数据库，有了如下的个性，这些个性，可能涵盖双时态的数据利用、数据安全、数据分析、简化利用开发等四大方面的问题：

2007年，计费平台的一帮年轻人为了实现银行级的高可用、零错账的交易系统，加班加点探讨计划，长达几个月的重复头脑风暴与论证，终于提出了“TBOSS 7*24”容灾计划，并用了一年多工夫落地推广后，斩获09年公司级技术冲破奖，取得了Tony的首肯，从此开启了计费平台打造金融级数据库的摸索之路。 一路走来，技术谋求永无止境，打造一款更好用的高统一、高可用、高性能分布式数据库产品的初心从未扭转，零碎架构历经三代优化，2012年立项的第四代产品TDSQL，通过5年打磨与海量业务的理论经营优化，并与腾讯金融云单干产品化，正式以腾讯云金融级数据库对外输入，目前500+金融客户笼罩银行、保险、基金证券、生产金融、第三方领取、计费、物联网、政企等多个畛域，尤其在多家银行的外围交易系统落地，标记着TDSQL真正冲破成为一款金融级数据库产品，正是这里的冲破，使得我的项目团队往年再次斩获公司级技术冲破奖，这也是公司对团队始终专一金融级数据库底层研发耕耘的认可。 当然，道阻且长，随着硬件一直在更新，业务越来越多样且简单，数据库畛域还有许多新的挑战还需咱们去攻克。本文尝试着记录下过来十年一路摸爬滚打过程中，团队的一些思考与总结，心愿前面的路越走越宽！ 从实质上来说，数据库产品要思考的问题仍然还是用户体验的问题！细化来说，数据库产品次要有两类间接用户，别离是开发人员与运维人员，外围就是他们要用得爽。 例如对开发人员来说，他们常常关怀的问题有： 1、开发接口是不是规范的？是否提供欠缺的开发指引？ 2、在故障劫难呈现时，开发人员需不需要关怀数据是否会失落？需不需要写很简单的容灾切换逻辑？ 3、零碎性能好不好，能不能扛住业务浪涌式压力？ 4、零碎是否足够凋谢等等？ 而对于运维人员DBA来说，他们常常关怀的问题如： 1、零碎的惯例操作是否有标准化的工具或页面间接应用？ 2、零碎是否足够通明，使得在异样时，是否疾速的定位问题？ 3、是否提供了欠缺的零碎经营手册？ 4、配套设施是否欠缺，例如监控零碎、公布零碎、冷备零碎、审计零碎等等？ 当然也还有一类间接用户，那就是这些应用数据库的业务零碎的实在用户，他们关怀的问题有： 1、他们的领取、转账等操作是不是失常的，会不会不到账，多扣钱？ 2、他们是否可能随时随地发动交易等等？ 通常来说，在资源和工夫无限的状况下，这几类用户的需要是要辨别不同优先级的，甚至有时候是抵触的，所以咱们一路走来，始终保持这样一个准则：在保障用户的根本诉求（数据不丢，不错账）的状况下，而后一直优化开发人员与运维人员的应用体验。例如咱们的第一代产品“TBOSS 7*24”就是优先保障高可用、高一致性，确保用户数据不错不丢，然而极大的侵害了开发人员与运维人员的体验，须要业务开发人员开发大量的容灾代码，运维人员须要保护大量的劫难模式等，也就是说很多工作交给了业务开发与运维人员。在前面的几代零碎更迭中，咱们就是一直的将性能下沉，让业务开发和运维越来越简略，必然的数据库自身会更加简单一些。尽可能的在数据库层面去解决三类用户的诉求，也就变成了TDSQL的外围挑战。 TDSQL的外围挑战 TDSQL经验大大小小有数版本，始终面对的外围挑战是： 1、数据的可靠性。在任何劫难状况下，例如主机故障、网络故障等等，都不能存在数据失落的状况。 2、零碎的可用性。基于数据多正本的状况下，零碎如何保障在一些异常情况下，疾速复原可用，把不可用时长降至最低。 3、高性能。首先，单机性能晋升，对于海量业务来说，可能极大的升高服务器等老本；其次，性能指标也是用户最能间接感触到的指标之一，所以性能优化始终是咱们优先级最高的工作之一。 4、扩展性。也就是通常说的分布式。其实在金融行业，之前对分布式这块的需要并不大，然而随着第三方领取的疾速倒退，给银行的一些零碎造成了很大的冲击，例如双11、春节红包等流动，这类零碎应用传统的IOE架构很吃力，所以他们也心愿能采纳分布式架构来解决这个问题。抛开从思维层面，分布式架构对传统金融IT行业人员的冲击外，其实从技术上来说，这里其实挑战很多，TDSQL也是在逐渐的优化与解决，例如最简单的两个点分布式事务与分布式Join操作。目前咱们曾经实现了分布式事务性能的公布，而分布式Join还在内测过程中。 5、配套工具。一个数据库软件要体验好，那么就不能仅仅提供几个外围的包，必须要有相应的经营管理工具、问题诊断工具、性能剖析工具等，并且是一个凋谢的、规范的接口，只有这样大家能力更好更无缝的应用。 下面的几个问题，后面2个是基本功能的问题，在第一个版本就曾经基本保障了，然而是不是就足够了？远远不够，路走得不够多，遇到的坎太少，碰到新的坑时，仍然可能会摔跤。咱们只有在足够丰盛的场景中，通过大量的实际经营教训，使得本人的零碎经验足够的磨难，能力使得零碎的可用性和数据可靠性保持足够多的9。前面几个问题，自身也应该是一个继续优化的过程，TDSQL也始终在寻找最优雅的形式去解决，所以上面就从这几个问题，看看TDSQL具体是如何做的。 外围架构 Set机制：TDSQL所有的高可用机制均是在Set之内实现，每个Set之内多个数据节点（1主N备），主备之间能够是基于Raft协定的强同步复制机制，也能够是异步复制机制。在主机呈现故障的状况下，在调度模块的帮助下，将筛选备机依照规定流程晋升为主机，疾速复原业务，全程无需人工干预。在咱们惯例的应用过程中，通常是倡议1主2备，主备之间强同步，这样在主节点故障状况下，能确保主动切换，RTO为40s，RPO为0。 程度扩容。分布式版本对外出现为一个残缺的逻辑实例，后端数据实际上是散布在若干Set上（独立的物理节点）组成。逻辑实例屏蔽了物理层理论存储规定，业务无需关怀数据层如何存储，也无需在业务代码中集成拆分计划或再购买中间件，只须要像应用集中式（单机）数据库一样应用即可。同时反对实时在线扩容，扩容过程对业务齐全通明，无需业务停机，扩容时仅局部分片存在秒级的只读（只读是理论在做数据校验），整个集群不会受影响。 分布式事务。TDSQL基于MySQL的XA实现了分布式事务机制，对各种异样解决做了充沛的鲁棒测试，且绝对于单机事务，性能损失仅30%。 高级个性 二级分区。第一级即咱们常说的程度拆分，原理是应用HASH算法，使得数据能平均的扩散到后端的所有节点；第二级分区应用RANGE算法，使得相干的数据可能落在一个逻辑分区，例如能够按工夫分区（相似每天每周每月一个分区等），亦能够按业务个性分区（相似每个省市一个分区等）等等。二级分片能够平衡数据分布和拜访，为疾速一键扩容提供根底撑持，也能够满足疾速删除数据等场景。 读写拆散。基于数据库拜访账号的读写拆散计划，DBA能基于业务需要对账号设定相干参数，以确保既不会读取到过旧的数据，也不会影响写业务，且业务无需改变代码即可实现读写拆散。这能够极大的升高业务经营老本。 此外，TDSQL还有全局惟一数字序列、对立参数治理、兼容MySQL函数，热点更新等泛滥高级个性，可满足各类业务需要。 内核优化 TDSQL在数据库内核这块的优化，次要集中在数据复制、性能、安全性等方面。 强同步机制。TDSQL针对金融场景的强同步机制，无效解决了MySQL原生半同步机制的问题：性能升高以及超时进化为异步。目前TDSQL在强同步模式下，零碎的并发量（TPS/QPS）与异步模式已无差别，根本能做到性能无损失。 性能优化。 1）咱们对MariaDB/Percona的线程池调度算法进行了优化，改良当零碎处于重负载时，查问和更新申请在线程组间散布不平衡等极其状况。并且可能更好地利用计算资源，缩小无谓的线程切换，缩小申请在队列中的等待时间，及时处理申请。 2）组提交（Group Commit）的异步化。工作线程在其会话状态进入组提交队列后，不再阻塞期待组提交的Leader线程实现提交，而是间接返回解决下一个申请。 3） InnoDB Buffer Pool应用优化。例如全表扫描时，防止占满InnoDBBuffer Pool，而是只取一块来应用。 4） InnoDB 在MySQL组提交期间防止与组提交有mutex抵触的流动，例如InnoDB Purge，升高抵触，以晋升性能。 相似的性能优化的点，还有不少，可能在某些场景下，单个点成果不显著，然而集合起来看，目前性能指标整体是不错的。基于SysbenchOLTP测试后果，雷同的硬件及测试环境下，TDSQL性能相比原生版本晋升85%。 平安加强。在平安方面做了大量优化及加强，包含数据文件加密、SQL防火墙、SSL接入、平安审计等。 此外，咱们长期关注MySQL的三个分支版本：MariaDB、Percona、MySQL community，对于社区的新个性，也会定期的合入。 部署计划 TDSQL的强同步机制，自身是能够做到全球化部署的，但其实咱们绝大部分客户无论是老本看，还是从业务场景看，都不须要做寰球部署，常见的两地多核心根本都能满足需要。客户能够基于老本、本身业务数据的容灾要求，以及数据中心散布状况，抉择不同的部署计划。TDSQL有针对性的在数据可靠性与可用性上做出衡量，做到灵便部署。目前常见的两种部署计划包含： 两地三核心 ZK散布在两地的三个核心内。 1、主IDC故障不会丢数据，主动切换到备IDC，此时堕落成单个IDC的强同步，存在危险。 2、仅仅主机故障，在比照两个同城备节点及一个同城Watcher节点后，切换到数据最新的节点，优先选择同IDC的Watcher节点，尽可能减少跨IDC切换。 3、备IDC故障，通过另外一个城市的ZK能主动做出选举： a) 备IDC的确故障，主动晋升主IDC的Watcher节点为Slave,由主提供服务 b) 主备网络不通，与a)一样的解决形式 ...

十年摸索，TDSQL专为“金融”而生 “一款金融级的分布式数据库，必须要通过数年的积淀，以及海量业务场景的锻炼 ”， 腾讯云分布式数据库TDSQL负责人潘安群示意。 TDSQL的诞生正是如此。 工夫回溯到2002年，因为过后腾讯的计费产品还处于起步阶段，技术团队抉择齐全基于开源MySQL构建数据库体系。随着凋谢策略的衰亡，同时为了解决计费等公司级敏感业务高可用、外围数据的零散失、外围交易的零错账等问题，腾讯数据库团队从07年开始自研了一款数据库产品，这也是TDSQL的前身，这款数据库在过后很好的撑持了09年的开放平台浪潮。 随着腾讯凋谢单干的倒退扩充，行业场景越来越多，这款数据库在反对腾讯外部业务体系是很完满的，然而无奈很好的为合作伙伴提供服务，因而从2012年开始，腾讯基于“开源定制化＋自研”策略构建更加通用的数据库产品，正式命名为TDSQL。指标就是解决金融零碎中高可用、数据一致性、程度伸缩问题。 能够说TDSQL的诞生，一开始就是为金融场景而生。 2014年对于TDSQL来说是极具重要意义的一年，第一家互联网银行微众银行筹建，在强调自主可控技术的前提下，他们技术团队对过后国内诸多数据库产品技术选型后，最终决定抉择TDSQL作为其外围零碎的数据库计划，这是寰球首家采纳分布式的数据库解决方案的银行。 2016年当前，TDSQL正式开启自主可控之路，凋谢给更多的金融企业应用，得益于海量业务场景的锻炼，使得TDSQL成为一款产品化数据库，具备一个残缺的产品体系。 “赤兔”和“扁鹊”，空地双层平安体系 作为一款金融级数据库，TDSQL具备六大外围个性，包含数据强一致性、金融级高可用、高性能低成本、企业级安全性、线性程度扩大、智能化运维。 在一些事关数据安全的个性上，TDSQL做了重点的增强，比方针对高可用等问题。TDSQL能够轻松反对异地多活。 除了技术上保障之外，TDSQL还从经营角度保障数据的平安。据剖析，目前金融行业大部分数据库产品化水平不够，相当多的安全事故均是由经营操作不标准带来的。TDSQL通过提供“赤兔”自助经营和“扁鹊”智能DBA彻底躲避人为误操作带来的安全隐患。 “赤兔”自助经营服务，能够从管理员视角，在可用性、平安、效率、老本维度进行全方位管控，90%的日常经营操作均能够通过Web页面实现，缩小人为过错同时帮忙金融用户节约治理及经济老本、升高危险。 “扁鹊”智能DBA则帮忙金融用户防备零碎异样，通过采集超过400+经营指标，基于AI+Policy的智能诊断技术，帮忙金融用户疾速定位解决问题，并预防潜在危险，防备于未然。 此外，分布式数据库TDSQL为用户提供数据库防火墙、通明加密、主动脱敏等平安防护措施，缩小用户误操作和黑客入侵带来的平安危险。 行业首次：“两点四核心”成功实践 微众银行对于TDSQL的自主可控实际起到重要的推动作用。作为业内首家齐全基于TDSQL自主可控数据库技术的构建分布式外围零碎的银行，其1.0架构采纳两地三核心模式，在2017年初，启动2.0架构，采纳的两地四核心（同城三核心多活）架构，相较于传统银行的两地三核心架构，实现数据中心级故障的状况下，仍然能保证数据零失落。 这也是两地四核心架构在银行外围零碎的首次利用，目前曾经稳固经营1年多。值得一提的是微众银行“基于分布式架构的同城三核心多活钻研与实际”的课题，荣获中国银保监会公布的2018年度银行业信息科技风险管理钻研一类成果奖。 目前截止2019年，TDSQL曾经为超过500+的政企和金融机构提供数据库的私有云及公有云服务，客户笼罩银行、保险、证券、互联网金融、计费、第三方领取、物联网、互联网+、政务等畛域。弱小的安全性、高可用性正疾速推动国内金融行业自主可控过程。

“两地三核心”部署体系 “两地三核心”架构顾名思义：在一个城市有A、B两个机房，另一个城市有C机房，在第一个城市中TDSQL数据库实例采纳同IDC异步、跨IDC强同步的形式，咱们须要在第一个城市将四个数据节点部署在二个机房，其中主节点和一个备节点在一个机房，另外两个备节点在另一个机房。并且在第一个城市和第二个城市的数据库实例间，采纳的是异步复制，保障金融城市级高可用容灾。 “两地四核心”部署体系 “两地四核心”的架构，是一个自动化切换的强同步架构，对任何数据中心及故障都能30秒内切换，并且数据零失落，性能也稳固牢靠，对业务和用户来说是实现更高的可用性和更低的老本。 TDSQL品质保障服务： 全生产流程自动化巡检 最初，最重要的是咱们如何保障TDSQL的交付品质服务的品质。 TDSQL的交付品质通过一个自动化巡检的计划保障。TDSQL自动化巡检计划通过三个维度保障交付品质： 监控指标剖析 第一个维度基于TDSQL现有的监控核心进行相干指标性的剖析，包含以后时刻的指标剖析和历史时刻的指标剖析。当咱们要在验证一个集群是否有问题的时候，往往除了要剖析此时此刻的集群是否存在异样和告警、是否存在资源负载过重等状况，还须要剖析历史性的问题，比如说在历史过来七天中各个指标的曲线如何。为什么要剖析过来历史七天的指标曲线？举个简略的场景案例，例如一个场景在每天下午三点到五点是业务高峰期，在业务高峰期期间可能有很多业务的慢查问，甚至有一些慢查问带来的性能的问题。零碎如何监控在历史某个时刻呈现的问题？那么咱们发动自动化巡检计划的时候，比方是上午8点钟，适逢业务低峰期，此时是发现不了问题的，所以咱们须要对历史指标进行剖析。 计划中具体分析的指标包含检测前台连通性、实例的复制形式、主备切换形式等。监控次要分为两个方面：第一是监控指标的采集、上报、收集，这是监控核心负责。第二是对监控数据进行剖析，并对认为异样的剖析进行告警。剖析和告警过程中会遵循肯定的策略——怎么的监控数据才是异样、有必要告警的？以后TDSQL保护了一套告警模板，也给客户提供了可配置的、定制化的选项，客户能够依据本人的理论状况进行告警策略的批改；同时提供基于实践经验积攒的告警策略比照，以防用户做出不合理的批改，裸露告警策略的潜在危险。 在这个维度，TDSQL多源同步等模块能够对数据同步状况进行监控，他们以后同步的稳定性、同步的性能如何，等其余就是各个模块的告警的监控指标。 集群环境扫描 第二个维度是对第一个维度的补充。第二个维度的剖析是机器级的，不是通过采集的监控数据，是间接拜访服务器后盾，对机器级的IO、CPU、内存、磁盘、稳定性等进行检测。 除了机器级和过程级，咱们还会进行实例级的定制化扫描，这个体现在实例体检模块——实例的体检就是TDSQL智能诊断剖析平台“扁鹊”的接口，能够为实例提供从经营、开发、性能等各个指标的系统性剖析。 集群级层面，咱们会关注这个集群各个机器之间是否是同步、实例下元数据集群是否是有备份、备份是否是失常等。 自动化演练 在咱们以各个维度去扫描以后集群没有问题的状况下，TDSQL还会从后果登程，对整个集群做一次P0级别的自动化演练，演练的场景就是咱们失常经营和治理的场景，包含购买实例、创立用户、用户受权、创立库表，在这个库表上做一些表构造的变更、程度扩容、垂直的扩容、多重备机、慢查问入库、备份和回档等。最初零碎会对购买的实例进行删除，实现对P0级别的场景进行闭环的自动化演练。 总结来说，TDSQL自动化巡检计划从指标级，到整个集群环境进行扫描，以及通过自动化演练这三个维度确保整个交付的集群平安、稳固、牢靠、高可用。 除了技术上的保障计划，TDSQL同时积淀了大量产品化工作，帮忙用户疾速、不便地应用分布式数据库。 咱们也会对客户信息进行定期维护，首先对客户定期发动集群的巡检，通过这个巡检能够保障客户以后以及历史一段时间内环境是没有问题的。巡检次要进行功能性和容灾性的演练，通过主动的定期巡检，管理系统如果扫描到有倡议客户要降级的版本，则会主动推送到客户代表，由客户代表推动客户降级。 最初，在客户日常经营、日常变更中，可能经营面临的大部分问题是怎么扩容、降级、解决告警？TDSQL对各个节点的扩容提供了自动化的扩容计划，能够一键扩容。同样降级也是提供了前台化一键操作的性能，既能够进行点对点降级，也能够进行整个集群的批量降级。TDSQL的高可用性一方面在于本身的弹性架构和容灾能力，以及数据强一致性。 可用性方面TDSQL提供了自动化告警解决计划，可实现自动化告警剖析，并对局部告警主动解决，缩小现网经营的工作量。 以上咱们以交付为外围介绍了TDSQL在历史过程中遇到的几个交付上的挑战，和针对这些交付挑战，咱们提出的自动化交付计划，以及最初对整个TDSQL标准化交付的品质和客户服务提供了一系列机制和能力方面的晋升。 以上是明天的分享，谢谢大家！ PartⅣ Q＆A Q：TDSQL反对数据库离线备份吗？ A：TDSQL反对多种备份形式，能够基于物理式的备份，也能够基于逻辑备份。整个备份过程在备机上进行，不会影响失常的业务拜访，也不会对业务拜访的性能带来影响。 Q：TDSQL的告警信息如何接入短信、语音、邮件告警平台？ A：TDSQL的告警接入比拟灵便，首先TDSQL的告警信息是文本的模式，能够发送到任何平台，以后客户曾经适配过的告警接入形式有很多，比如说客户有HTTP接口的告警平台，也有一些其余接口的。依据客户想要的接口，TDSQL能够对应地发一个包，蕴含了告警信息，发到你的告警接管平台就能够了。

自动化交付计划布局 TDSQL是基于一个分支来实现多场景、简单关系下的自动化交付的，其实也能够说是基于三个分支去做的——TDSQL内核包，以后有三个分支：基于CPU的多分支进行公布，以后反对X86、arm、power。TDSQL对客户的公布包中，一个包主动集成了不同CPU版本的TDSQL packet——以ansible组件为根底，加上了条件检测、操作系统调优、环境依赖的解决、平安标准、兼容性问题，是TDSQL规范公布包，可针对于客户不同的场景和不同的环境做适配。 TDSQL的组件分为四个角色，疾速交付TDSQL集群，打个比方说就是把不同的鸡蛋放到不同的篮子里。鸡蛋是指这些组件；篮子就是咱们筹备的机器，能够是虚拟机，也能够是物理机。 首先集体体验的环境：集体体验环境更重视的是较低门槛，在这里咱们只须要一台虚拟机的配置就能够达到目标。而后能够把治理节点、DB节点、数据节点和其余的节点都部署在这台机器上。当然在体验的环境下，数据节点和其余的节点这两个性能能够不进行部署。 测试环境：该环境下重视的是性能、性能。首先从治理节点来看，治理节点提供的是元数据的治理和工作的散发性能，要求的是稳定性和容灾能力。在测试环境能够略微弱化这个要求，比方能够筹备一台或者三台虚拟机、配置4C/8G一般磁盘；在测试环境下要做DB节点的话，要思考到TDSQL的性能问题，这里举荐应用物理机；进行性能测试的时候要求肯定是SSD盘，否则性能数据没有任何参考性——这也是由数据库的场景决定的，因为SSD和一般的磁盘，一方面次要体现在随机读写能力上的差距会比拟大；数据节点和其余的节点方面，如果有一些客户对测试的性能要求没有那么强，就能够不部署这些节点的性能，而如果想体验残缺的TDSQL的性能，则须要筹备这些机器，以体验残缺的TDSQL的性能；如要部署数据节点，能够抉择一台机器或者三台虚拟机，以及筹备较大容量的磁盘做数据节点；其余的节点，比方负载平衡和日志剖析平台，TDSQL的负载平衡比拟灵便，位于SQL引擎层上的上一层，这里举荐开源的LVS，当然也有很多客户会应用F5。最初，以上环境咱们的举荐是部署两节点来实现容灾能力。总体而言，为了保障测试的性能，测试环境要求最多的是DB节点模块。 生产环境：生产环境中要求治理节点能够部署在三台或者五台虚拟机，但最好是跨三个机房，比如说“1+1+1”的模式或者“2+2+1”的模式，因为元数据集群是基于少数选举的机制来保障高可用，如果只有两个机房则会失去了自身容灾的意义，因而咱们倡议生产环境中部署三个机房；DB节点生产环境更举荐的是NVME接口的SSD，因为传统的SSD和NVME的SSD在接口性能上会有比拟大的差距，而数量上举荐的是3*N台——事实上这个要去评估生产环境TDSQL集群的数据量，TDSQL是一个分布式数据库，数据量级能够依据用户机器数量实现程度拓展。 举个例子假如客户有3T数据，如果单台物理机是1T、一个set内做的是一主两备三个节点，咱们此时须要三个set，三个set能够承当3T数据量，同时会有两个正本的冗余，DB节点的这些数就须要9台这样的机器，这三个set会组成group shard；数据节点的机器也是举荐物理机，同时在生产环境须要思考容灾能力，因而举荐是三台机器以上。此外，须要一个高性能磁盘来保障回档和备份的效率；最初，拜访链路上接入层是十分重要的一层，咱们强烈推荐物理机来进步稳定性。 TDSQL自动化交付特色与要求 在TDSQL真正交付过程中，为了保障交付品质，联合金融级场景的平安合规、高可用容灾思考，咱们积淀出一些根本要求和个性： 网络：离线部署无外网依赖，机器互通；存储：反对单磁盘、多磁盘和raid；冷备核心：反对hdfs和挂载式分布式存储(如ceph)；机器散布：反对跨机架和跨机房上架服务器，反对多种机器分布模式下的高可用容灾；CPU：在国产化趋势下，目前机器CPU除了适配x86，还包含arm、power ，而且首要举荐以上其中一款；操作系统：适配反对centos、ubuntu、以及包含国产化操作系统在内的诸多支流操作系统； 在交付过程中咱们只有理分明如何把鸡蛋放到对应的篮子里即可实现自动化交付：咱们先选出篮子，一组物理机就是一个篮子，随之把一组的组件DB节点放到这个篮子里。 灵便交付 当然这其中有很多细节，客户要做的，是自在决定模块的机器散布和集群规模，TDSQL能够通过模块之间的数量差别，自适应地做出单点计划和多节点高可用容灾计划。这个过程用户在操作上是无感知的。举个例子，比方TDSQL是反对HDFS作为冷备核心，如果HDFS选的是一个节点，零碎会做一个HDFS的单点计划。如果是三节点的配置布局，它会主动感知到要做的是一个高可用容灾计划。HDFS用的高可用容灾计划是基于QJM的形式。 简略高效：整个部署过程最快仅需9分钟 做完部署布局，第二件事件是解决各个组件之间的一些关系，包含兼容性等问题。举个例子，如果部署的TDSQL环境是基于ARM国产服务器的操作系统的国产化环境。咱们如何通过一个交付物料包去适配不同的环境？其实机密就在这个配置文件里： 用户无需关注TDSQL较为简单的各模块的相互依赖和配置管理问题，只须要依据理论，填写变量文件配置即可；用户填写一个机器规格配置文件、一个变量配置文件，填写后能够适配操作系统和CPU实现一键自动化交付操作简略用户可独立实现，自动化部署命令可反复执行，在北京信通院机构现场对TDSQL产品化的测试显示，整个部署过程最快仅需9分钟 适配与集成：国产化、全栈式 以后国产化曾经成为一个趋势，TDSQL在国产化适配方面也做了很多工作，从底层的服务器到存储器、操作系统、CPU、行业软件、数据库软件等，都在相干部门领导下进行了与各个厂商单干实现从上层到下层全方位的国产化适配。在国产化的浪潮下，TDSQL作为一个腾讯自研分布式数据库，咱们也是责无旁贷的担当了国产化的责任。包含腾讯外部的操作系统tlinux，以及中标麒麟、河汉麒麟、UOS等支流国产化操作系统，TDSQL都实现了适配。除了适配全系国产操作系统，TDSQL同时已相继实现对全系国产芯片，全系列国产服务器等的兼容适配工作。而在实现适配工作的同时，腾讯也提供了对应的技术服务，帮忙行业用户更好地迁徙到国产根底技术生态当中。这些是咱们国产化方面的工作。 技术服务生态方面，TDSQL不仅可作为一个独立公布的产品，在TDSQL倒退的历程中，也被其余很多平台厂商和合作伙伴接收，包含腾讯外部的TCE、Tstack、MDB架构等。TCE是腾讯云金融级平台，TDSQL和TCE在部署计划、告警、用户权限等等各种维度和TCE进行了深度的集成，可为金融政务机构提供全方位的PaaS根底技术服务，在实现高性能的分布式架构转型降级的同时保障金融级稳固高可用。除了外部的平台，TDSQL许多合作伙伴的行业解决方案中也集成了TDSQL，把TDSQL的能力输出到他们本人的平台。 平安保障：秒级监测 TDSQL在倒退中对交付场景做了许多优化： 条件检测：首先会主动对布局的TDSQL集群下的所有机器做前置检测，包含机器工夫同步、时区统一、端口占用、零碎默认sh、机器规格等做检；环境优化：针对关系型数据库场景，对系统50处左右进行针对性调优，并解决一些根底的依赖；机器秒级监控：大部分的监控平台都是基于分钟级的，对于金融级数据库这种敏感场景，分钟级的监控是不够的，所以咱们针对这样的场景提供了秒级监控，包含针对机器的IO、CPU、网络、内存等多个维度。

1.1 简单产品组件交付 首先咱们想讲的是TDSQL的交付挑战，咱们也是以三个方面去开展，第一个咱们遇到的挑战是咱们TDSQL产品架构所带来的特点：一是产品化不断完善带来的特点——组件多，包含领有数据库内核，工作散发、冷备核心、平台告警、性能诊断等；二是组件之间相互依赖关系比较复杂。 首先从档次上把这些组件进行划分：赤兔、监控采集、OSS、metacluster、扁鹊、onlineddl等能够划分为一个角色，叫治理节点。对业务来说，理论拜访数据库的过程是，先是负载平衡层，而后到SQL引擎层，而SQL引擎层会间接拜访底层DB，DB上会部署Agent。图中左侧列这些叫做治理节点；右侧列如冷备核心、音讯队列、多源同步等，个别划分为数据节点。而日志剖析平台其实是一个其余模块，可划分为其余的节点。 这些节点之间的依赖关系比较复杂。比方治理节点，其次要负责元数据管理，元数据包含比方以监控采集模块为外围的监控数据、以工作散发零碎为外围的工作节点数据；第二是DB模块，DB会和治理节点有一些交互——除了DB节点，还有其余的节点都会向治理节点发送监控信息；而治理节点也会下发工作，比方客户在前台进行的垂直扩容、程度扩容、主备切换等变更动作，也会到理论的DB进行交互；数据节点会向治理节点发送数据，和DB节点做一些交互…… 所以其实各个组件之间的依赖关系比较复杂，这对于交付带来肯定的难处。 1.2 多场景适应性交付 第二个挑战来自于TDSQL多个场景。 TDSQL多个场景次要来源于应用TDSQL的对象是不同的，包含集体、企业、第三方平台。不同的对象应用TDSQL的需要和场景也不同。集体应用可能更想低门槛疾速上手产品。企业应用最次要是POC测试和生产场景，关注的是整个产品的性能和性能，包含高可用性、容灾能力、国产化适配等。 不同场景的需要如何高效满足？是要做多个分支去适配不同的场景，还是用一个分支去适配不同的场景？当然咱们是用一个分支去适配不同的场景。 1.3 TDSQL交付品质保障：平安、合规、多层级扫描 第三个挑战是，因为工夫的推移，负责TDSQL交付的人产生了变动。晚期TDSQL由产品研发团队、DBA同学去现场给客户做交付。产品研发团队和DBA团队，大家都是一个团队，团队内因为长期的单干协同造成了规范和品质牢靠。而随着TDSQL产品化做大做强，用户规模不断扩大当前，交付人员会发生变化。不同的交付施行方，他们的操作和应用如果不够标准化，则容易带来隐患，体现在几个方面： 第一个是平安。比如说环境的平安，咱们晓得数据库场景是对内存、CPU、硬盘、IO等能力都是要求比拟高的场景，包含对TCP的内核参数优化等这些工作都是作为潜在危险来对立思考。 第二个是监控。对整个集群、过程、机器的监控，以及主动拉起，即机器级别故障之后，疾速复原的能力，这些都要作为欠缺的体系来思考。其余比方定时工作，包含定时清理一些日志，清理一些历史数据，否则磁盘就会撑满，这在生产的环境上也是危险很大。最初是如何保障整个集群的高可用性、容灾能力；如何杜绝潜在旧版本带来的隐患，检测这些版本的破绽等方面，都是交付质量体系中须要解决的问题。 其实TDSQL交付品质服务和保障就是围绕着上述的各方面问题，实现由不同的施行人、施行方去交付TDSQL产品，都能保障TDSQL的投产品质。这是咱们在做的事件。

家喻户晓，TDSQL是一款十分优良的数据库产品 因而，TDSQL获奖应该也是不值得诧异的事件了。但这次，TDSQL拿了两个！ 2021年4月7日至8日，2021 GDCC 寰球分布式云大会在北京举办。 在所有企业乘“云”而上的生态背景下，诞生了泛滥行业的领航者和开拓者，产生了引领分布式云技术的优良产品。借这一趋势，寰球分布式云联盟通过数月的策动、在报名的泛滥企业中进行认真的遴选和评审，最终设立了“分布式云奖项”，并通过“寰球分布式云大会·颁奖典礼”进行先进力量的传递。 而在此次颁奖典礼中，腾讯云数据库获“分布式数据库领导力奖”和“最佳分布式数据库实际奖”两项大奖，且是极少数取得了两项奖项的厂商。 分布式数据库领导力奖 “分布式数据库领导力奖”的评比，是通过评析腾讯云企业级分布式数据库 TDSQL 的三大产品系列后决定的，三大产品系列别离为分布式数据库 TDSQL、剖析型数据库 TDSQL-A和云原生数据库 TDSQL-C。 作为金融级分布式数据库产品，TDSQL 具备数据强一致性、金融级高可用性、高性能低成本性、线性程度扩展性、企业级安全性、运维便捷性等 6 大外围个性。与此同时，提供智能 DBA、自动化经营、监控告警、数据多源异构同步迁徙等配套设施，为客户提供残缺的分布式数据库解决方案。凭借外围事务处理技术的冲破，以及欠缺的零碎生态，解决了国产分布式数据库市场通用化难题。 最佳分布式数据库实际奖 而“最佳分布式数据库实际奖”的评比在腾讯云分布式数据库 TDSQL三大产品系列的根底上，依据具体案例实际进行评析的。 具体案例为，张家港行新一代外围零碎采纳腾讯云TDSQL来承载外围业务数据，是银行传统外围零碎利用国产分布式数据库的首次尝试。为此，张家港行用一年多的工夫进行大量的技术验证，并在中间业务平台等生产环境下也积攒了丰盛的测试数据。 据主办方称，每一项奖项的设定是有着其粗浅意义，每一个获奖企业的选定是通过全面剖析和评审，因而，获奖企业和产品都是实至名归、当之无愧。 近年来，各行业数字化过程一直放慢。而作为国内数据库行业先行者，腾讯云深耕数据库畛域十余年，服务客户数曾经超过50万。 将来，腾讯云还会在数据库的赛道上继续加码，联合其余云产品一起，并利用好在微信和QQ等服务十几亿用户的教训和资源，打造出更加好用、易用、平安的数据库产品。

通过excel生成sql语句有的时候业务部门间接甩过去一个excel表格让咱们插入或者更新到数据库中。插入还好说，只有字段对应，就能够插入，然而更新呢？所以咱们须要一个其余的操作形式，将excel生成想要的sql语句。具体操作步骤 1.写好插入、更新语句，将指定地位替换成列序号。① insert table into (name,age,sex) values('张三','11','1');② insert table into (name,age,sex) values('"&A2&"','"&A2&"','"&A2&"');2.在excel中抉择公式，在抉择CONCATENATE将之前写好的语句放入CONCATENATE括号中。记得肯定要有双引号，否则不是公式。=CONCATENATE("insert table into (name,age,sex) values('"&A2&"','"&A2&"','"&A2&"');")3.鼠标点击生成的语句那个单元框的右下角向下拖动，即可生成

1、查找整个职员表的所有内容。select *from employees2、查看雇员名字(last_name)。select last_namefrom employees3、查看雇员编号、名字和工种。select last_name，job_id，employee_idfrom employees4、显示所有雇员的姓名、工资并将DEPARTMENT_ID显示为（Department_Id）。select last_name,salary,DEPARTMENT_ID as Department_Idfrom employees5、查找在60号部门工作的雇员。select last_name+first_name name,department_idfrom employeeswhere departmet_id=606、要求查找职位为SH_CLERK和SA_MAN的雇员姓名(last_name)。select last_name job_idfrom employeeswhere job_id in ('sh_clerk','sa_man')7、查找职位不是SH_CLERK和SA_MAN的雇员工种及姓名。将姓名显示为(first_name+last_name命名为”Name”)。select first_name+last_name Name, job_idfrom employeeswhere job_id not in ('sh_clerk','sa_man')8、查找哪些雇员的工资在2000到3000之间select *from employeeswhere salary between 2000 and 30009、查找哪些雇员的工资不在3000到5000之间select *from employeeswhere salary not between 3000 and 500010、查找first_name以D结尾，前面仅有三个字母的雇员信息。select *from employeeswhere first_name like ‘D___' and first_name not like ‘d__ ‘11、查找last_name以K结尾的雇员信息。select last_name,first_name,department_idfrom employeeswhere last_name like ‘k%'12、查找名字以字母M结尾，以l结尾，并且第三个字母为c的雇员名字(First_name)、工种和所在部门号select first_name,job_id,department_idfrom employeeswhere first_name like ‘m_c%l'13、查找哪些雇员的工种名不以SA结尾。select job_idfrom employeeswhere job_id not like 'sa%'14、查找没有奖金的雇员信息。select *from employeeswhere commission_pct is null15、查找有奖金的雇员信息。select *from employeeswhere commission_pct is not null16、查找30号部门里不是CLERK的雇员信息。select *from employeeswhere department_id=30 and job_id not like ‘%clerk%'17、查找在30号部门工作或不是CLERK的雇员信息。select *from employeeswhere department_id=30or job_id not like ‘%clerk%'查找60号部门且工资大于5000的员工的信息select *from employeeswhere department_id=60and salary>500018、按字母程序显示雇员的名字(last_name)。select last_namefrom employeesorder by last_name19、按部门号降序显示。select * from employees order by department_id desc20、查找工资高于$2000的雇员信息，按部门号和雇员名字排序。select * from employees where salary>2000 order by department_id,employee_id21、抉择奖金高于5%的雇员信息SELECT FIRST_NAME, LAST_NAME, COMMISSION_PCTFROM dbo.EMPLOYEESWHERE (COMMISSION_PCT > .05)22 查问年工资高于50000的员工信息select from employees where 12salary>5000023 查问奖金高于5000的员工姓名 ...

简介： 多元索引是表格存储产品中一个重要的性能，多元索引应用倒排索引技术为表格存储提供了非主键列上的疾速检索性能，另外也提供了统计聚合性能。表格存储近期凋谢了SQL查问性能，SQL引擎默认从原始表格中读取数据，非主键列上的查问须要扫描全表。 作者 | 政豪起源 | 阿里技术公众号 多元索引是表格存储产品中一个重要的性能，多元索引应用倒排索引技术为表格存储提供了非主键列上的疾速检索性能，另外也提供了统计聚合性能。表格存储近期凋谢了SQL查问性能，SQL引擎默认从原始表格中读取数据，非主键列上的查问须要扫描全表。开启了多元索引之后，如果一个查问的过滤条件或者统计聚合能够下推至多元索引执行，那么SQL引擎将局部查问打算转换为多元索引申请，将从多元索引中获取数据，进步查问效率。 一 多元索引SQL算子反对1 前提条件在应用SQL查问多元索引之前，首先须要在表格上创立多元索引。如果多元索引蕴含SQL语句中波及的数据列，则SQL引擎会通过多元索引读取数据并下推多元索引反对的算子。例如有一张表exampletable有a, b, c, d四列，多元索引中蕴含了b, c, d三列，只有当SQL语句中只波及b, c, d中的数据列时，才会从多元索引读取数据。 SELECT a, b, c, d FROM exampletable; /* 多元索引不蕴含a,b,c,d，扫描全表读取数据，不反对算子下推 */SELECT b, c, d FROM exampletable; /* 多元索引蕴含b,c,d，通过多元索引读取数据，反对算子下推 */2 反对下推的算子 二 多元索引SQL查问实战为了直观地展现SQL查问多元索引性能，下文将以某自行车租赁商的订单表为例，应用多元索引上的SQL性能实现一些简略的查问剖析工作。某自行车租赁商的订单表如下： 整张表格名为trips，每一笔租车订单都有惟一的订单号作为主键，订单中记录了租车时长、开始日期、完结日期、开始站点、完结站点等信息。表格中蕴含120万行数据，在没有开启多元索引的状况下对表格行数进行统计，查问会因为超出扫描配额限度而终止。 同样地，如果以非主键列作为查问条件进行查问，也会因为波及全表扫描超过扫描配额而被终止。 为了可能依据非主键列的值进行查问以及统计聚合，须要创立笼罩全副数据列的多元索引。对于数据量比拟大的表格，须要较长的工夫期待多元索引同步实现。 1 过滤条件下推在开启多元索引之后，即可在非主键列上进行条件查问。例如，下图查问终点编号31208到终点编号31209的租车订单，借助多元索引，SQL引擎可能在500毫秒之内查问到全表中满足条件的140行记录。 多元索引反对多个条件的组合，例如查问2010年10月1日当天，站点31208的订单。因为外国10月1日不放假，那天的订单数量并不是很多。 2 统计聚合下推除了非主键列查问，多元索引还提供了弱小的统计聚合能力。在未创立多元索引的时候无奈统计行数，然而有了多元索引，能在500毫秒左右查问到行数、站点数、均匀租车时长等信息。 同样地，分组统计聚合也能够疾速获取后果，例如列出每个站点总订单数目。 过滤条件和统计聚合能够一起应用，例如查问2010年10月1日当天每个站点订单数目。 3 TopN下推SQL中蕴含ORDER BY和LIMIT的语句成为TopN查问，多元索引反对疾速查问TopN，图中的查问展现了最近的10条数据。 原文链接本文为阿里云原创内容，未经容许不得转载。

简介： AnalyticDB For MySQL为用户提供了高效、实时、功能丰富并且智能化的「SQL智能诊断」和「SQL智能调优」性能，提供用户SQL性能调优的思路、方向和具体的办法，升高用户应用老本，进步用户应用ADB的效率。 SQL是一种简略易用的业务逻辑表白语言，但随着扫描数据量和查问复杂度的减少，查问性能会变得越来越慢。想要对SQL进行调优，往往须要关注以下几个局部： 须要理解引擎架构：用户往往须要对SQL引擎的架构特点有肯定的理解，能力和业务的数据分布特色以及业务场景特色完满联合，来进行数据建模，从而设计出合乎SQL引擎架构特点的表构造。SQL特色差别较大：即席查问的SQL往往变动较大，包含参加Join的表个数、Join条件、分组聚合的字段个数以及过滤条件等。数据特色差别较大：用户的数据分布特色是会随着业务特色的变动而变动的，如果始终依照最后的建模形式和SQL语句，也是无奈保障能施展出SQL引擎的最大劣势，数据特色或者业务模型的变动，都会导致SQL性能回退。基于此，AnalyticDB For MySQL（新一代云原生实时数据仓库，语法兼容MySQL，以下简称ADB）为用户提供了高效、实时、功能丰富并且智能化的「SQL智能诊断」和「SQL智能调优」性能，提供用户SQL性能调优的思路、方向和具体的办法，升高用户应用老本，进步用户应用ADB的效率。 上面咱们通过「发现慢查问」+「诊断慢查问」两个步骤，并联合一个场景Case，来介绍ADB新公布的「SQL智能诊断」性能。（PS：「SQL智能调优」会在后续版本中公布） 一、发现慢查问用户要定位慢查问，首先须要找到慢查问。ADB的用户控制台提供了多样的形式来帮忙用户，例如「甘特图」和「查问列表」等，都能够在多个维度进行检索，帮忙用户疾速定位慢查问，而且诊断工具确保用户能够进行最近两周的全量查问检索和剖析。 （一）甘特图用户能够通过「集群控制台」-「诊断与优化」 - 「SQL诊断」进入SQL智能诊断性能。 首先会看到一个甘特图（也称泳道图，查问从不同的泳道流过，这里的泳道并不是ADB的查问队列，只是为了辨别开不同工夫执行的查问），甘特图以图形化的形式形象的展现了查问在ADB实例上的执行程序，每个色块示意了一条查问，色块左侧为查问的提交工夫，色块右侧为查问的完结工夫，色块的绝对长度示意了某条查问的执行工夫，色块的色彩没有非凡含意，只是为了辨别不同的泳道。 通过甘特图，用户能够十分直观的看到以后工夫范畴内执行耗时较长的查问，并且能够直观的看到哪些查问是在并行的执行以及并行执行的时间段，这能够帮忙用户判断出哪些查问是受到了某条Bad SQL的影响。色块的密集度则能够用来直观的判断ADB实例压力较大的时段是否和某些查问的并发度较高相干。 （二）查问列表甘特图可能以直观的形式体现出查问之间的工夫相关性，然而当用户抉择的工夫范畴较大，甘特图中的色块会密集散布不容易分辨，而且甘特图上的指标较为无限，此时用户能够应用诊断工具中的查问列表性能。查问列表提供了多大10余项查问级别的重要指标，例如数据库名、用户名、客户端段IP、耗时、耗费内存以及扫描量等，这些信息和指标能够帮忙用户进一步判断慢查问的起源和资源耗费等。 高级检索能力方面，诊断工具提供了三种类型的检索办法： 1.含糊检索和准确检索：用户能够依据SQL中的关键字进行含糊匹配，准确检索性能则帮忙用户在确定查问ID的状况下，准确的检索到这条查问；2.字符串类型的检索条件：检索工具会自动识别出用户所选工夫范畴内应用的数据名、用户名、客户端IP以及资源组等，提供下拉框的模式供用户抉择，进步用户检索效率；3.数值类型的检索条件：用户能够自由选择检索的指标单位，例如KB、MB、GB等，不须要进行手动的换算。 同时，用户在应用诊断工具时，往往有对慢查问的下载需要，下载后的慢查问能够在例如Excel等工具中进行更多自定义的慢查问治理和剖析，所以咱们也提供了查问列表的下载性能。 二、诊断慢查问（一）查问在ADB中的执行流程在介绍ADB执行流程前须要简略介绍一下三个相干的基本概念： Stage在执行阶段，ADB中的查问会首先依据是否产生Shuffle被切分为多个Stage来执行，一个Stage就是执行打算中某一部分的物理实体。Stage的数据起源能够是底层存储系统中的数据或者网络中传输的数据，一个Stage由散布在不同计算节点上雷同类型的Task组成，多个Task会并行处理数据。 TaskTask是一个Stage在某个Executor节点上的执行实体，多个同类型的Task组成一个Stage，在集群外部并行处理数据。 OperatorOperator（算子）是ADB的最小数据处理单元。ADB会依据算子所表白的语义或算子间的依赖关系，决定应用并行还是串行执行来解决数据。 上面以一个典型的分局聚合查问为例来理解ADB中查问的执行流程，SQL语句如下： SELECT COUNT(*), SUM(salary)FROM emplayeeWHERE age>30 ADN age<32GROUP BY sex在ADB外部，首先由前端的Controller节点接管SQL语句申请，并对SQL语句进行语句解析和语法分析（Parser），最初应用优化器（Optimizer）生成最终的执行打算，整体执行打算会依据Stage的划分准则被切分为子打算，如图中的Plan0、Plan1和Plan2，别离被下发到对应的节点上。 其中子打算Plan2会并行的在4个计算节点上以Task实例的模式解决数据，首先执行数据的扫描和过滤，而后执行数据的部分聚合，解决完之后的数据会依据sex字段Repartition到上游的计算节点，即Stage1的节点，依照子打算Plan1的要求执行数据的最终聚合。最初，数据由Stage0的节点汇总并返回到客户端。 和典型的数据仓库一样，ADB的执行打算个别分为「逻辑执行打算」和「物理执行打算」： 逻辑执行打算：宏观层面理解查问的解决流程逻辑执行打算在较高的层面展现查问的解决逻辑，基于规定的执行打算（RBO）会判断过滤条件是否能够下推，而基于代价的执行打算（CBO）会判断出多表关联时的程序等。所以逻辑执行打算并不关注在物理执行时的具体解决形式，例如是否在执行时须要对多个算子进行交融以缩小函数调用，或者主动生成代码的粒度，这些逻辑执行打算并不关注，这也就导致了逻辑执行打算往往只蕴含了Stage级别的执行统计信息。然而用户调优时往往是须要准确到算子级别的统计信息。 物理执行打算：宏观层面理解每个算子的解决性能绝对于逻辑执行打算，物理执行打算蕴含了算子间的数据处理流图，也蕴含了算子的执行统计信息，能够准确的看到某个Join算子或者聚合算子占用的内存，也能够看到过滤算子过滤前后的数据量。然而并不是所有的算子用户都须要能正确理解其含意，特地是有些物理算子和用户的SQL语句找不到关联之处，这也会给用户独自应用物理执行打算定位问题带来较大的纳闷。 ADB的「SQL智能诊断」性能，提供给了用户一个逻辑执行打算和物理执行打算的交融视图，用户应用交融的执行打算即能够从宏观层面理解查问的解决流程，也能够从宏观层面理解每个算子的解决性能，从而能够更加精确疾速的帮忙用户定位查问的性能瓶颈点。 （二）SQL自诊断性能尽管咱们提供了交融的和分层的执行打算来帮忙用户剖析查问的性能问题，然而咱们发现在两类场景中用户应用交融执行打算会遇到困难： ADB的高级使用者 ADB为了缩小MySQL用户的学习和迁徙老本，做到了绝大多数语法和MySQL兼容，然而ADB的后盾并非MySQL内核，而是独立自研的一套分布式数据存储和分布式计算零碎，面对ADB的执行打算，ADB的高级使用者往往不晓得优化的重点在哪里，无从下手。 ADB中的简单SQL 对于简单的SQL，往往波及几百张表的连贯操作，Stage个数会达到几百个以上，算子个数更是会达到上千，执行打算图十分大，即便是ADB的高级使用者，面对这样简单的执行打算，往往也无从下手，如下图是个196个Stage的执行打算图： 针对以上问题，咱们在执行打算图中退出了SQL自诊断能力，SQL自诊断能力会将专家教训以规定的模式体现在执行打算中，对于ADB的首次接触者，即能够依据诊断后果确定查问执行过程中的性能瓶颈点，也能够依据诊断后果学习到ADB执行打算中须要关注的重点算子。针对简单执行打算，SQL自诊断能够帮忙用户疾速定位到执行打算中须要调优的地位，并提供了调优的相干办法和文档，让用户在调优过程中更有针对性。 SQL自诊断能力通过「Query级别诊断后果」、「Stage级别诊断后果」、「算子级别诊断后果」这三层来展现诊断后果和优化倡议。 咱们以一个线上的简单SQL为例来介绍应用执行打算和SQL自诊断工具来进行性能问题定位的例子。首先咱们通过慢查问检索工具搜寻到一个内存耗费较大的查问，点击「诊断」关上该查问的诊断页面，切换到「执行打算」页签，咱们会看到查问级别诊断后果曾经判断出以后查问数据一个内存耗费较大的查问，如下图中的1所示： 这时，咱们须要定位内存成果较大的起因，咱们点击按内存排序，能够看到在右侧，会依据Stage耗费的内存百分比进行了顺叙排序，能够非常明显的看出，Stage[1]占用的以后查问87%以上的内存比例，咱们点击Stage[1]，诊断工具会主动聚焦到执行打算树的Stage[1]的地位，点击Stage[1]，咱们能够看到Stage[1]的执行统计信息，同时，咱们能够看到在5的地位，提醒咱们以后Stage1外部有个算子占用内存较大，然而并没有详细信息，所以接下来，咱们须要进入到Stage[1]的外部，看看Stage[1]具体是哪个算子占用了较多内存。 点击「查看Stage执行打算」，进入到Stage[1]外部，首先，咱们仍然依据内存排序，能够看到，其中的Join[317]这个算子占用了整个Stage 99%以上的内存，点击该算子，算子执行打算树主动定位到以后算子，这时咱们就能够看到算子诊断后果的详细信息了，信息提醒咱们，在构建Hash表用户Left Join时，占用了较大的内存，诊断后果还提供了官网的调优文档链接，依据文档中给出的调优办法，咱们就能够缩小该算子的内存占用。 以上的例子通过「查问级别诊断后果」和「算子级别诊断后果」进行SQL性能问题定位的办法，咱们再来看一个「Stage级别诊断后果」的例子。 如下图所示，咱们能够看到依据耗时排序后，Stage[10]的耗时比例最大，点击执行打算图中的Stage[10]，能够在诊断后果栏看到两类诊断后果，一类是“Stage诊断”，一类是“算子诊断”，其中的Stage诊断通知咱们以后Stage的输入数据有歪斜，并且通知咱们歪斜的字段是哪些（数据歪斜是分布式系统中重大影响性能的问题，Stage输入数据歪斜岂但会过后以后Stage解决数据在工夫上存在长尾，而且会导致上游的数据处理存在长尾），同时能够看到有一个算子诊断后果，提醒咱们表扫描存在歪斜，那么咱们能够初步判断以后Stage输入数据歪斜是因为扫描了一个数据歪斜的表导致的。接下来咱们进入到Stage[0]外部进行定位和剖析。 进入到Stage内存，咱们依据耗时排序，能够看到TableScan算子耗时最大，这时咱们点击TableScan算子，能够看到在诊断后果里，有对于该表数据歪斜的具体诊断后果信息，这张表因为数据分布字段抉择的不适合，存在重大的数据歪斜问题，同时能够看到有相干的官网调优文档，咱们依据调优文档，就能够调整为适合的散布字段，缩小表数据歪斜对查问性能的影响。 通过以上的两个例子，咱们能够看到，交融执行打算和SQL自诊断性能，能够疾速的帮咱们定位到查问的性能问题，并给出肯定的调优倡议，缩小大量不必要的工夫和精力的节约，升高了高级使用者应用ADB的门槛。对于SQL自诊断更多的诊断后果能够参考官网文档：SQL自诊断，目前曾经有20+诊断规定上线，波及查问相干的内存耗费、耗时、数据歪斜、磁盘IO以及执行打算等多个方面，后续还有更多诊断规定陆续上线。 三、 后续布局通过以上的论述和例子剖析，能够看到以后的诊断调优工具曾经能够帮忙用户进行多方面的SQL性能问题排查，然而咱们在理论的线上问题解决和值班时依然发现总结了多个用户在剖析实例性能问题时的需要： 我应该调优哪些SQL？用户在关上诊断调优页面时，面对实例上运行的上万甚至上千万条SQL，尽管能够通过耗时、内存耗费或者扫描量等进行排序来初步筛选出须要调优的SQL，然而其实其实用户欠缺了一个特定诊断后果的视角，例如： 哪些SQL是数据扫描歪斜的？哪些SQL是索引过滤不高效的？哪些SQL是Stage输入歪斜的？哪些SQL是分区抉择不合理的？用户在针对某一个SQL的特定诊断后果调优实现后，其实须要晓得有哪些相似的SQL都须要调优的，所以咱们后续会提供给用户一个从特定诊断后果维度进行剖析的工具，一次性地解决某个特定问题。 我的SQL有问题，和建表形式不优无关吗？ADB后盾是一个分布式的数据存储和分布式的执行框架，依赖数据平均的散布到各个后盾节点上，同时ADB针对不同的业务场景设计了不同的表类型，例如分区表、复制表，有些表字段在存储时进行汇集存储，也会晋升查问性能，然而用户往往不晓得建表形式不优到底影响了哪些查问。后续咱们会把「数据建模诊断后果」和「查问诊断后果」关联，用户通过数据建模的诊断后果即可疾速晓得不良的表构造影响了哪些SQL，同时反过来也能够通过某条SQL的诊断后果晓得哪些表须要优化。两类诊断后果联动调优，能够从本源上解决实例的查问性能问题。 四、总结瞻望「SQL智能诊断」性能曾经于近日上线，用户能够结合实际业务进行疾速上手应用。 原文链接本文为阿里云原创内容，未经容许不得转载。  ...

SeaTable 开发者版是一款收费易用、可扩大的数据中台产品。它同时联合了协同表格的易用性和数据库弱小的数据处理能力。从 2.3 版本开始，SeaTable 在数据分析方面又有了一个重大的加强，那就是对 SQL 查问的反对。SQL 查问性能能够通过界面的插件来应用（如下图），也能够通过 API 来拜访。 上面来具体介绍 SQL 查问。 SQL 查问语句介绍SeaTable 中的 SQL 查问语句的语法和 MySQL 是统一的，能不便大家疾速上手。语法如下： SELECT [DISTINCT] fields FROM table_name [WhereClause] [OrderByClause] [GroupByClause] [Limit Option]查问后果是以 JSON 的格局进行返回。当然目前还有一些限度，次要是不反对多表查问 join 语句。 特色函数 SeaTable 目前次要的利用场景是对数据进行统计分析。所以它反对一些非凡的的函数，不便对数据做统计： STARTOFWEEK(date, weekStart)：返回一个日期所属的星期，不便依照星期来统计。Quarter(date)：返回一个日期所属的季度，不便依照季度来统计。ISODate(date)：返回一个 ISO 格局的日期， 如: "2020-09-08"，不便依照天来统计。ISOMonth(date)：返回 ISO 格局的月份， 如 "07"，不便依照月份来统计。举一个例子，如果咱们有一个表记录了订单流水，咱们要统计每天的销售额，只须要用以下的查问语句： select sum(sale) from SalesRecord group by ISODate(SalesTime)如果咱们想要失去以下统计图须要的数据，也能够用 SQL 语句来轻松失去： 怎么应用查问接口SeaTable 提供了三种办法，不便你在任何中央通过网络来查问数据，包含： RestAPIPythonAPISQL 查问插件Rest API 应用 Rest API 非常简单，你不必再调配和治理用户名、明码，只须要调配一个 API token 就能够。通过网页界面就能够生成一个表格的 API token： ...

背景 《横看成岭侧成峰，远近高下各不同。不识庐山真面目，只缘身在此山中。》保持一直学习就能达到《千山同一月,万户尽皆春。千江有水千江月,万里无云万里天》 jdbc连贯数据库原理 概念：Java DataBase Connectivity Java 数据库连贯， Java语言操作数据库,JDBC实质：其实是官网（sun公司）定义的一套操作所有关系型数据库的规定，即接口。各个数据库厂商去实现这套接口，提供数据库驱动jar包。咱们能够应用这套接口（JDBC）编程，真正执行的代码是驱动jar包中的实现类。 java链接办法温习操作步骤导入驱动jar包 mysql-connector-java**.jar包 注册驱动 获取数据库连贯对象 Connection 定义sql 获取执行sql语句的对象 Statement 执行sql，承受返回后果 处理结果 开释资源 参考代码：public static void main(String[] args) throws ClassNotFoundException, SQLException { //1. 导入驱动jar包 //2.注册驱动 Class.forName("com.mysql.cj.jdbc.Driver"); //3.获取数据库连贯对象 Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/7d?useUnicode=true&characterEncoding=UTF-8&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC", "root", "123456"); //4.定义sql语句 String sql = "select * from user_table"; //5.获取执行sql的对象 Statement Statement stmt = conn.createStatement(); //6.执行sql ResultSet resultSet = stmt.executeQuery(sql); while (resultSet.next()) { System.out.println("用户: " + resultSet.getString("create_user") + "明码：" + resultSet.getString("pass_word")); } ...

简介： PostgreSQL是一个性能十分弱小的、源代码凋谢的客户/服务器关系型数据库管理系统（RDBMS），被业界誉为“先进的开源数据库”，反对NoSQL数据类型，次要面向企业简单查问SQL的OLTP业务场景，提供PostGIS地理信息引擎、阿里云自研多维多模时空信息引擎等。本文着重介绍PostgreSQL的数据目录，其中保留着配置文件、数据文件、事务日志和WAL日志等重要文件，所有客户创立的数据文件和初始配置文件都能够在数据目录中找到，因而数据目录是重要的客户价值所在。 作者 | 市隐起源 | 阿里技术公众号 一 概述PostgreSQL是一个性能十分弱小的、源代码凋谢的客户/服务器关系型数据库管理系统（RDBMS），PostgreSQL被业界誉为“先进的开源数据库”，反对NoSQL数据类型（JSON/XML/hstore），次要面向企业简单查问SQL的OLTP业务场景，提供PostGIS地理信息引擎、阿里云自研多维多模时空信息引擎等。 本文着重介绍PostgreSQL的数据目录，其中保留着配置文件、数据文件、事务日志和WAL日志等重要文件，所有客户创立的数据文件和初始配置文件都能够在数据目录中找到，因而数据目录是重要的客户价值所在。 二 名词1 OID数据库对象是数据库存储或援用的数据结构体，数据库自身也是数据库对象，同时包含表、索引、视图、序列和函数等。Object ID是数据库对象的惟一标识符，保留在无符号四字节的整形变量中，所有数据库对象各自对应一个OID。PostgreSQL有两个视图各司其职，别离保留着不同类别的OID，其中pg_database保留数据库自身对象的OID，pg_class保留表、索引和序列等对象的OID。 2 Relation关系代表非数据库自身的数据库对象，包含表、视图、索引和toast等，不包含数据库自身。 3 MVCCMulti-Version-Concurrency-Control是一种并发管制机制，数据库引擎依据不同的事务隔离级别，通过查问事务快照和事务提交日志来实现元组的可见性查看。如果心愿了解数据库机制原理，MVCC是必不可少的学习常识。 4 Page数据库文件在Linux平台被划分为默认8K固定长度的page进行治理，通过启动参数BLCKSZ能够预设page的大小。如果page设低了，雷同数据量的文件须要决裂成更多的page，IO次数和索引决裂次数都会减少，性能会升高较多；如果page设高了，page外部的数据检索效率会升高，性能一样会升高不少，一般来说8K和16K对于数据库系统来说是最优解。 三 数据目录数据目录默认在/var/lib/pgsql/data下，反对应用环境变量$PG_DATA治理。下图所示是数据目录的一级构造，后续会重点介绍具备代表性的重要文件和目录，比方base、pg_xact等。 四 base1 概述base目录存储用户创立的数据库文件，及隶属于用户数据库的所有关系，比方表、索引等。 2 一级目录目录构造分为两级，第一级构造如下图所示，一级目录名是用户数据库对象的OID，1代表的是postgres数据库，一级目录内的二级子文件都是隶属于该数据库对象的关系，包含表、索引、视图等。 3 二级文件二级子文件如下图所示，存储着某个数据库内的所有关系，包含表、索引、视图等，这里以postgres数据库目录示例。二级子文件分为三大类，第一类是以关系OID命名的主数据文件，第二类是文件名以_fsm结尾的闲暇空间映射文件，第三类是文件名以_vm结尾的可见性映射文件。 4 主数据文件主数据文件存储隶属于对应数据库下的数据库关系文件，包含数据、索引等，客户最重要的业务数据便是存储在主数据文件中。 当关系文件大小低于RELSEG_SIZE × BLCKSZ时，数据库引擎创立名称为pg_class.relfilenode的单文件，反之会切分为名称如pg_class.relfilenode.segno的多个文件。单个关系文件外部被划分为默认8K固定大小的多个page并存储在磁盘上，8K能够在initdb时通过BLCKSZ参数批改配置。主数据文件写入时，会先将元组数据从行指针数组的底部开始重叠，直到空间耗尽。 用户通过SQL查问到的单行数据记录对应单个元组（tuple），因为MVCC机制的起因，元组可能是无奈查问到旧版本数据，也可能是沉闷的新版本数据，旧版本数据会在将来的某个时刻被清理。当查问没有命中索引触发程序扫描时，数据库引擎程序扫描page的行指针读取到元组，反之如果命中B树索引，引擎会通过索引文件的元组，通过索引键的TID值读取到元组。 下图是主数据文件的层级构造。 下表格是上图所示page内部结构的元数据信息。 下表格是上图所示tuple内部结构的元数据信息。 5 FSMFSM是闲暇空间映射文件，记录着heap和index的每个page的闲暇空间信息，有利于疾速定位到有短缺闲暇空间的page以便存储tuple，如果没有定位到则须要扩大新page。除了Hash Index文件没有FSM文件，其余heap和index都须要FSM文件。 总体上，FSM采纳3-4级多叉树的构造组织FSM page，单个FSM page外部采纳齐全二叉树的构造进行治理，高级别FSM page的叶子节点关联低级别的FSM page，低级别FSM Page的叶子节点存储着heap、index page的可用空间数目，而非叶子结点顺次存储叶子节点的最大可用空间数目，每个节点占用1个字节。 6 VMVM是可见性映射文件，记录着每个heap page的可见性信息，因而index page并没有vm文件。一方面它能够进步vacumn的执行效率，另一方面通过vm文件能够感知到page内的元组是否全副可见，如果全副可见的话，查问引擎查问索引元组间接获取到数据即可，不用再拜访数据元组查看可见性，缩小了回表次数，极大晋升了查问的效率。 VM采纳位图的构造存储可见性信息，每个heap page只在vm文件中存储2位，第一位代表元组是否全副可见，第二位代表元组是否全副被解冻。 #define VISIBILITYMAP_ALL_VISIBLE 0x01#define VISIBILITYMAP_ALL_FROZEN 0x02五 global1 概述global目录存储pg_control及数据库集群维度的数据库及其关系，非客户维度的数据，例如pg_database、pg_class等。目录内的文件构造和base是统一的。 global目录文件构造如下图所示。 ...

前言在利用开发的晚期，数据量少，开发人员开发性能时更器重性能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个零碎性能的瓶颈。 如果有不同意见，欢送留言斧正，一起学习！ SQL优化个别步骤1、通过慢查日志等定位那些执行效率较低的SQL语句2、explain 剖析SQL的执行打算须要重点关注type、rows、filtered、extra。 type由上至下，效率越来越高 ALL 全表扫描index 索引全扫描range 索引范畴扫描，常用语<,<=,>=,between,in等操作ref 应用非惟一索引扫描或惟一索引前缀扫描，返回单条记录，常呈现在关联查问中eq_ref 相似ref，区别在于应用的是惟一索引，应用主键的关联查问const/system 单条记录，零碎会把匹配行中的其余列作为常数解决，如主键或惟一索引查问null MySQL不拜访任何表或索引，间接返回后果尽管上至下，效率越来越高，然而依据cost模型，假如有两个索引idx1(a, b, c),idx2(a, c)，SQL为select * from t where a = 1 and b in (1, 2) order by c;如果走idx1，那么是type为range，如果走idx2，那么type是ref；当须要扫描的行数，应用idx2大概是idx1的5倍以上时，会用idx1，否则会用idx2。 举荐： ExtraUsing filesort：MySQL须要额定的一次传递，以找出如何按排序程序检索行。通过依据联接类型浏览所有行并为所有匹配WHERE子句的行保留排序关键字和行的指针来实现排序。而后关键字被排序，并按排序程序检索行。Using temporary：应用了长期表保留两头后果，性能特地差，须要重点优化Using index：示意相应的 select 操作中应用了笼罩索引（Coveing Index）,防止拜访了表的数据行，效率不错！如果同时呈现 using where，意味着无奈间接通过索引查找来查问到符合条件的数据。Using index condition：MySQL5.6之后新增的ICP，using index condtion就是应用了ICP（索引下推），在存储引擎层进行数据过滤，而不是在服务层过滤，利用索引现有的数据缩小回表的数据。show profile 剖析理解SQL执行的线程的状态及耗费的工夫。 默认是敞开的，开启语句“set profiling = 1;” SHOW PROFILES ;SHOW PROFILE FOR QUERY #{id};tracetrace剖析优化器如何抉择执行打算，通过trace文件可能进一步理解为什么优惠券抉择A执行打算而不抉择B执行打算。 set optimizer_trace="enabled=on";set optimizer_trace_max_mem_size=1000000;select * from information_schema.optimizer_trace;确定问题并采纳相应的措施优化索引优化SQL语句：批改SQL、IN 查问分段、工夫查问分段、基于上一次数据过滤改用其余实现形式：ES、数仓等数据碎片解决场景剖析案例1、最左匹配索引 KEY `idx_shopid_orderno` (`shop_id`,`order_no`)SQL语句 select * from _t where orderno=''查问匹配从左往右匹配，要应用order_no走索引，必须查问条件携带shop_id或者索引(shop_id,order_no)调换前后程序。 ...

简介：云计算的呈现促使物联网实现爆炸式增长。在设施规模和业务复杂度一直攀升的趋势之下，边缘计算因其可能将计算能力更凑近网络边缘和设施，从而带来云性能老本的升高，也在这波浪潮之下失去疾速倒退。作者 | OpenYurt 社区 云计算的呈现促使物联网实现爆炸式增长。在设施规模和业务复杂度一直攀升的趋势之下，边缘计算因其可能将计算能力更凑近网络边缘和设施，从而带来云性能老本的升高，也在这波浪潮之下失去疾速倒退。 诚然，物联网边缘计算尚处倒退初期，有许多挑战须要被解决。比方在大量软件及通信协议极为简单的设施异构环境下，须要具备疾速解决业务数据，并对异常情况作出疾速响应的能力；另外，在大多数状况下，出于平安或其余思考，边缘节点在物理上无奈从云节点间接拜访，使部署变得艰难，也无奈实现云到边缘的治理。这些问题都使业务的连续性、稳定性和可用性蒙受威逼。 当初，企业和开发者通过开源社区就可能找到应答以上问题的解决方案。近日，OpenYurt 与开源我的项目 eKuiper 正式达成单干，实现了集成对接：从 v0.4.0 版本开始，OpenYurt 将正式反对部署和治理 eKuiper ，单方将独特帮忙开发者轻松、高效地解决物联网边缘计算场景下流式数据处理和运维挑战。 eKuiper:轻量级 IoT 数据分析和流解决开源软件 物联网边缘计算很多场景下须要流式数据处理能力。所谓流数据是指一组程序、大量、疾速、间断达到的数据序列。个别状况下，流数据可被视为一个随工夫连续而有限增长的动态数据汇合，它能够帮忙用户实时理解零碎设施的状态，并对异常情况做出疾速响应。 在边缘端，计算资源（CPU，内存等）不像在云端个别丰盛，因而传统的流式数据处理框架相似于 Apache Spark 或者 Apache Flink 等，因为其安装包过大，或者部署构造与过程过于简单、运行时的高耗费等起因，并不适宜于在这些资源受限的边缘设施（工控机、网关，或者配置不高的 X86 或者 ARM 服务器等设施）上运行。而 eKuiper 就是为了解决在物联网边缘设施上的这些问题而设计开发。 eKuiper 的前身是由开源物联网数据基础设施软件供应商 EMQ 于 2019 年正式开源的 Kuiper 我的项目。2021 年 6 月，Kuiper 我的项目退出 LF Edge 基金会并更名为 eKuiper，开始作为独立的我的项目经营。eKuiper 的实质是一个轻量级物联网数据分析和流处理软件，能够运行在各类资源受限的边缘设施上，心愿使边缘端的流式数据处理领有如 Spark 与 Flink 的能力。 如下图所示，eKuiper 整体架构大抵分为三局部： 左侧为 Sources，代表数据起源的地位，数据起源可能是 OpenYurt 里部署边缘端的 MQTT Broker，也可能是音讯队列、文件和数据库等；右侧为 Sinks，代表数据处理实现后所要存储的地位，也就是指标零碎，指标能够是 MQTT，能够将其存到文件、数据库外面，也能够调用 HTTP 服务；两头局部为 eKuiper 的运行时，最上层为数据业务逻辑解决，这个层面提供了 SQL 与规定解析器，SQL 处理器进行解决后并将其转化成 SQL 执行打算；上面层为流运行时和 SQL 运行时, 运行最终执行进去的执行打算；最底层为存储，存储在运行过程中须要长久化的一些信息。在 eKuiper 中，用户可通过治理仪表板来治理一个或多个 eKuiper 实例。通常，这些仪表板部署在云节点中，用于治理跨多个边缘节点的 eKuiper 实例。正如前文所述，因为大多数状况下边缘节点在物理上无奈从云节点拜访， 使得部署变得艰难，无奈进行高效的 eKuiper 云边治理。 ...

简介：在数字化背景下，咱们有许多思考。数据库跟以前那有什么不一样呢？什么是所谓的云原生数据库呢？作为应用数据库的开发者，对数据库的需要有什么变动？现在应用数据库咱们个别会提什么样的诉求？本文将一一为大家解答。一、概述云原生数据库（一）云计算是数字化的基础设施 家喻户晓，目前云计算曾经成为数字化的基础设施，整个社会也在数字化。数字化浸透进咱们的日常生活中，除了衣食住行，还包含教育、医疗、游戏等。 以医疗畛域为例，早些年去医院，不论是验血还是拍胸片，肯定是要去取纸质报告，而后打一张塑料的胸片图。然而最近一两年，除了三甲医院，其余医院也根本是通过网上向患者提供无论是报告还是胸片之类的资料，医疗畛域数字化景象非常显著。 而这些数据全副都数字化当前，面临一个十分大的问题，它在哪些平台承载，怎么样承载？阿里云是其中十分重要的一个环节，数据库在数字化过程中承载了数据的生产、集成、实时处理和剖析的整套流程。在整个数据库周边，可能还有硬件、平安、弹性计算等能力，这些大大小小的货色最终组成阿里云这个平台。 （二）什么是云原生数据库技术云计算在重塑数据库技术与商业。 在数字化背景下，咱们有许多思考。 数据库跟以前那有什么不一样呢？什么是所谓的云原生数据库呢？作为应用数据库的开发者，对数据库的需要有什么变动？现在应用数据库咱们个别会提什么样的诉求？ 现在，下层的业务变动十分快，包含以前阿里巴巴淘宝外部其实也有同样的问题。业务的疾速变动让开发者面临一个十分大的挑战，就是要十分疾速地适应变动。在云遍及之前，这个过程其实还是比较慢的，从构建服务器，而后网络打好，装置操作系统和数据库等，整个流程十分长。 对数据库的诉求，总结起来可能有以下几个。 第一个就是咱们心愿更专一在业务开发上，不要把太多工夫放在底层的硬件、软件、机房、网络等设施的配置上。 第二个是开箱即用的，咱们心愿数据库创立好了能够间接应用，不须要再去做配置、优化等十分繁琐耗时且专业性强的事件。 第三个是平安可信，把数据放在第三方平台上，平安可信是一个十分根本的要求。 第四个是凋谢兼容，咱们不心愿被哪个云厂商锁定，心愿能十分自在地迁徙进来和迁徙进来。 第五个是海量扩大，随着业务爆发式的增长，零碎压力很快就会变成原来的数倍甚至数十倍。在这种状况下，如果没有一个很好的横向、纵向扩大的数据库系统，那么很难撑持业务失常运行，解决起来就会十分辣手。 第六个是全球化。中国很多游戏厂商在海内的拓展和推广做得十分不错，尤其是在东南亚一带，另外也有一些游戏在欧美日本取得了十分大的胜利，所以当初有些开发者也面临着全球化的诉求，作为数据库的基础设施，应该思考如何提供全球化的能力。 第七个是继续可用，咱们原来本人做一套数据库系统，继续可用也是外围思考之一。 除此之外还有可靠性，要求不能产生数据失落。 最初是低成本，当业务倒退到比拟成熟的阶段，咱们会关注低成本。 在这些客户诉求下，咱们思考下一代数据库或者说新的数据库要具备哪些个性，也就是云原生数据库它所具备的产品能力，如下所示。 第一个是全面托管，用户不再须要去关注装置、备份、部署、监控、高可用等，能够一键创立实例，创立进去的实例具备以上货色。 第二个是按量付费，按量付费能够让业务起步的老本变得非常低，否则机房、硬件、网络等一整套设施配置下来，老本十分昂扬。 第三个是按需弹性，它分为两个方面，一方面是要具备往上弹的能力，当业务在疾速倒退的过程中，数据库也要可能疾速往上弹。另一方面是往下弹，当业务顶峰过来了，须要很快地把资源使用量降下来，达到降低成本的目标。 第四个是生态兼容，无论用户目前应用的是MySQL，还是Oracle，或者是其余数据库，咱们能迁徙进来，也能迁徙进来。 上方是咱们认为云原生数据库它所具备的产品能力。 在这些产品能力底下，还是有很多的技术在反对。 六大核心技术别离是智能化、多模、软硬件一体化、平安可信、HTAP：大数据库数据库一体化、云原生+分布式。这六大核心技术撑持了上文的产品能力，解决开发者诉求。 （三）云原生关系型数据库 PolarDBPolarDB是阿里巴巴自研的新一代云原生数据库，在存储计算拆散架构下，利用了软硬件联合的劣势，为用户提供具备极致弹性、高性能、海量 存储、安全可靠的数据库服务。100%兼容MySQL 5.6/5.7/8.0，PostgreSQL 11，高度兼容Oracle。 PolarDB-X为PolarDB分布式版本，交融分布式SQL引擎与分布式自研存储X-DB，专一解决海量数据存储、超高并发吞吐、简单计算与剖析等问题。 （四）云原生关系型数据库PolarDB产品架构PolarDB产品架构图 PolarDB产品有以下个性： 存储计算拆散1）分钟级弹性升降级 2）分钟级新增/删除只读节点 智能代理转发1）实现数据库通明扩容 2）多种一致性级别 3）自定义Endpoint 分布式存储1）反对100TB 2）疾速备份与复原 3）更高单实例IO能力 libpfs+rdma+optane1）高性能通明实现三正本 RPO=0 2）高性能写入：实现高并发的写入 基于redo复制1）只读实例毫秒级提早 2）解决binlog/redo双日志一致性与性能问题 并行执行1）局部场景下的查问与剖析 2）能够自在管制的并行度，保障性能与稳定性 这里次要讲一个和开发者应用过程中关系比拟大的个性：智能代理转发。 在数据库中有一个十分难的点，它跟应用服务器不一样，当应用服务器零碎压力特地大的时候，还是比拟容易做扩大的，能够加一组应用服务器，把相干的流量扩大到新的应用服务器上就能够了。 但数据库通常做不到，因为数据在查问和应用上都是互相关联的，数据不能简略地做拆分。PolarDB在下层有一个智能代理层叫Proxy，它为开发者解决了这个问题。当数据库系统压力特地大的时候，通过智能代理能够主动把一些查问的Query散发到别的只读节点上。比方原来是一主一备，能够变成一主三备，就能够把流量主动散发到三个节点。 大家可能想，这个不就跟原来数据库加几个备库是一样的情理吗？ PolarDB通过智能代理解决了一个十分要害的问题，那就是加了这些只读节点当前，应用服务器上的连贯配置是不须要做任何改变，能够随时加上去，智能代理收到Query当前会主动转发过来。 以事实业务场景举例，比方某天前端的业务零碎通知咱们，今天早上10点要做一个促销流动，请做好数据库的扩容。 以前如果加了只读节点，可能遇到的问题是前端应用服务器基本就拜访不到这个只读节点，或者能够拜访到只读节点，但要对应用服务器的配置做一些扭转，可能导致利用要把应用服务器重启。当初通过PolarDB的智能代理能够无效解决这个问题，方便快捷地做容量扩大。 二、传统关系型数据库向云原生环境迁徙（一）传统商业数据库替换的挑战现在，如果要从别的商业数据库迁徙到 PolarDB上，比方从Oracle数据库，一般来说有几个比拟大的挑战。 第一个挑战是利用耦合度高。通常状况下，数据库跟利用的耦合度十分高，如果要对数据库做一个动作的话，利用前端的利用要配合着一起做，可能会影响前端的可用性，因为通常状况下数据库底下承载的业务都是比拟要害的，动数据库往往意味着动前端利用。 第二个挑战是稳定性要求高。数据库一出问题，前端的业务就会出问题，所以数据库的变更和动作常常会在早晨执行。 第三个挑战是数据量大。因为当初业务都比拟大，因而外围数据库的数据量通常会比拟大。 第四个挑战是语法兼容要求高。尽管大家应用的都是 SQL，然而不同数据库的SQL还是不一样的。如果从Oracle数据库迁徙到PolarDB，SQL要做太多的革新的话，就意味着前端业务零碎的革新要十分大，状况也很简单。 （二）应用云原生数据库PolarDB替换传统商业数据库是一个迷信的标准化、产品化的过程。 ...

简介：Flink CDC 2.0.0 版本于 8 月 10 日正式公布，点击理解详情～ 本文由社区志愿者陈政羽整顿，内容起源自阿里巴巴高级开发工程师徐榜江 (雪尽) 7 月 10 日在北京站 Flink Meetup 分享的《详解 Flink-CDC》。深刻解说了最新公布的 Flink CDC 2.0.0 版本带来的外围个性，包含：全量数据的并发读取、checkpoint、无锁读取等重大改良。 GitHub 地址： https://github.com/ververica/flink-cdc-connectors 一、CDC 概述CDC 的全称是 Change Data Capture ，在狭义的概念上，只有是能捕捉数据变更的技术，咱们都能够称之为 CDC 。目前通常形容的 CDC 技术次要面向数据库的变更，是一种用于捕捉数据库中数据变更的技术。CDC 技术的利用场景十分宽泛： 数据同步：用于备份，容灾；数据散发：一个数据源分发给多个上游零碎；数据采集：面向数据仓库 / 数据湖的 ETL 数据集成，是十分重要的数据源。CDC 的技术计划十分多，目前业界支流的实现机制能够分为两种： 基于查问的 CDC： 离线调度查问作业，批处理。把一张表同步到其余零碎，每次通过查问去获取表中最新的数据；无奈保障数据一致性，查的过程中有可能数据曾经产生了屡次变更；不保障实时性，基于离线调度存在人造的提早。基于日志的 CDC： 实时生产日志，流解决，例如 MySQL 的 binlog 日志残缺记录了数据库中的变更，能够把 binlog 文件当作流的数据源；保障数据一致性，因为 binlog 文件蕴含了所有历史变更明细；保障实时性，因为相似 binlog 的日志文件是能够流式生产的，提供的是实时数据。比照常见的开源 CDC 计划，咱们能够发现： 比照增量同步能力， 基于日志的形式，能够很好的做到增量同步；而基于查问的形式是很难做到增量同步的。比照全量同步能力，基于查问或者日志的 CDC 计划根本都反对，除了 Canal。而比照全量 + 增量同步的能力，只有 Flink CDC、Debezium、Oracle Goldengate 反对较好。从架构角度去看，该表将架构分为单机和分布式，这里的分布式架构不单纯体现在数据读取能力的程度扩大上，更重要的是在大数据场景下分布式系统接入能力。例如 Flink CDC 的数据入湖或者入仓的时候，上游通常是分布式的零碎，如 Hive、HDFS、Iceberg、Hudi 等，那么从对接入分布式系统能力上看，Flink CDC 的架构可能很好地接入此类零碎。在数据转换 / 数据荡涤能力上，当数据进入到 CDC 工具的时候是否能较不便的对数据做一些过滤或者荡涤，甚至聚合？ ...

简介：8.7 线上 Meetup 视频和 PPT 分享来啦～另外，下一期实时数仓 Meetup 议题征集中！GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 8 月 7 日，Apache Flink Meetup 线上直播圆满结束！ 来自腾讯、第四范式、阿里巴巴的 4 位资深行业技术专家分享了企业如何借助 Flink 的高实时，低提早解决万亿级实时数据入湖、智能诊断与监控的问题，以及 Flink 1.14 版本行将带来的新性能个性与体验优化。 尽管流动由线下改为线上，然而同学们对本场 Meetup 的关注度仍旧不减，不仅观看直播借着留言 “线下面基”，而且还积极参与社区活动博得了福利～ 议题回顾：社区活动 | Apache Flink Meetup 8.7 深圳站改为线上 流动亮点：Flink 如何帮忙腾讯搭建万亿级实时数据入湖利器 Auto Optimizer Service；腾讯如何借助 Flink 开发智能化的故障诊断和配置监控工具；Flink 帮忙第四范式建设 OpenMLDB 数据库实时更新零碎；Flink 1.14 版本的新个性预览。实时数仓 Meetup 议题征集：另外！8 月 29 日左右 (工夫暂定)，Flink 社区打算举办 Meetup 实时数仓专场，现征集议题中！ 对于实时数仓，大家的关注度始终很高，目前业界也有许多落地的公司。在 Meetup 实时数仓专场， 咱们将更加重视 “交换”，心愿将大家汇集在一起互相探讨对于实时数仓的话题，重点在踩过的坑、碰到的痛点都是怎么解决的～ 现征集实时数仓 Meetup 的议题，围绕 “实时数仓踩坑痛点和避坑教训”，欢送各位老师和同学带上贵公司的介绍，以及议题的初步纲要来找小松鼠。 ...

简介：在互联网行业红利已过、在获客老本越来越高、在用户在线时长全网根本无增长以及信息大爆炸的状况下，如何更好的转化新用户和晋升老用户粘性就变得至关重要，智能化的个性化举荐无疑是通过验证的重要伎俩之一，咱们每天应用的挪动App或企业内都处处有其身影。本文作者 吴世龙 阿里云智能 高级产品专家 直播视频请点击 直播 观看。 一、背景介绍行业趋势“2018年天猫双11共产生了453亿次AI个性化举荐，阿里巴巴副总裁、淘宝总裁蒋凡示意淘宝可能是全世界最大人工智能的利用，他说：“在往年双11咱们也能够看到，基于个性化举荐的流量曾经超过了搜寻等形式带来的流量，这是一个十分十分大的变动” 信息爆炸一词最早呈现在20世纪80年代，各种信息以指数级增长，如何解决过载的信息成为了重要的问题，而这对于无论是消费者还是信息发布者还是承载的平台，都意味着眼下和将来都面临着微小的挑战，而个性化举荐零碎的实质则是高效连贯信息和用户，于用户满意度晋升，于信息发布者取得正当的用户群，于平台价值转化最大化。 MaxCompute产品背景MaxCompute 是面向剖析的企业级 SaaS 模式云数据仓库，以 Serverless 架构提供疾速、全托管的在线数据仓库服务，打消了传统数据平台在资源扩展性和弹性方面的限度，最小化用户运维投入，使您能够经济并高效的剖析解决海量数据。数以万计的企业正基于 MaxCompute 进行数据计算与剖析，将数据高效转换为业务洞察。 智能举荐产品背景智能举荐，基于阿里巴巴当先的大数据和人工智能技术，依据用户的趣味偏好，解决用户需要和内容展现两头的关联问题。联合阿里巴巴在电商、内容、新闻、视频直播和社交等多个行业畛域的积攒，为寰球企业及开发者提供云举荐服务与机器学习平台。 智能举荐在咱们生存和工作中都是会遇到的，比方某工业客户，在企业外部有许多的材料供员工查看。智能举荐不止是对于ToC的企业，ToB的企业在企业外部，包含一些出名的企业，外部都是用很多材料，可能让员工不便的，疾速的，高效的供员工查看。这个需要在ToB企业中也是普遍现象。ToC企业的需要更加显著，如果大家关注行业报告，会发现互联网的红利曾经根本完结，用户的渗透率曾经很高。那在行业倒退和用户增量达到瓶颈时，用户的在线时长从2020年的6.1小时，仅仅减少到6.3小时，用户的在线工夫基本上处于停滞不减少的阶段。那企业随之也会面临两个问题，一企业用户获客老本越来越高，增量的难度也越来越高。二获客老本越来越高的状况下，存量客户怎么去减少在线时长。从这两个问题表明，如何充沛、高效转化不论是增量还是存量的用户，对于企业来说都是十分重要的一环。 二、智能举荐业务场景与价值哪些行业须要智能举荐不论是电商行业、内容行业、新闻行业包含上文讲到的行业，其履行行业业都会用到智能举荐。大家一听到智能举荐都会想到ToC的行业，但ToB的行业也是须要智能举荐，因为企业外部有大量的材料和文章。举荐自身曾经渗透到咱们平时用到的产品的方方面面，从产品状态来看电商，内容，新闻等都有它的身影，通过大数据+算法预测出咱们更感兴趣的内容，极大的改善了用户体验； 痛点电商/批发行业•获客老本高用户留存差 •成交转化率低复购率低 •人工规定举荐效率低成果差 内容/资讯/视频行业•获客老本高用户留存差 •用户粘性/活跃度低 •人工规定举荐效率低成果差 场景电商/批发行业•App首页瀑布流 •店铺首页瀑布流 •商品详情页 •卖场流动页 •其余 内容/资讯/视频行业•首页瀑布流 •内容/资讯/视频详情页 •主题/专题瀑布流 客户应用智能举荐后的成果从下图表中能够看出，在企业应用完智能举荐之后，各项成果指标有了显著的晋升。 某出名垂类社区商城某出名垂类电商中青看点个性化举荐某食谱类APP<span class="lake-card-margin-top lake-card-margin-bottom"><img src="https://ucc.alicdn.com/pic/developer-ecology/29125aa578e14917923e8081b50c8113.png" class="image lake-drag-image" alt="1.png" title="1.png"></span><span class="lake-card-margin-top lake-card-margin-bottom"><img src="https://ucc.alicdn.com/pic/developer-ecology/1874f184ac86427c962cb6aeb3799ee7.png" class="image lake-drag-image" alt="2.png" title="2.png"></span><span class="lake-card-margin-top lake-card-margin-bottom"><img src="https://ucc.alicdn.com/pic/developer-ecology/81640348d2154164a37cea5af6abfbb8.png" class="image lake-drag-image" alt="3.png" title="3.png"></span><span class="lake-card-margin-top lake-card-margin-bottom"><img src="https://ucc.alicdn.com/pic/developer-ecology/e3f797463dbf4f15b0f7be2e51c37364.png" class="image lake-drag-image" alt="4.png" title="4.png"></span>成交转化率晋升 <span>40%+</span>CVR晋升 <span>100%</span>CTR晋升 <span>80%+</span>PV_CTR晋升 <span>38%</span>GMV晋升 <span>50%+</span>每用户下复数晋升 <span>89%</span>用户均停留时长晋升 <span>10Min</span>UV_CTR晋升 <span>34%</span> ### 基于数据仓库的智能举荐架构智能举荐是典型的大数据利用场景，所以强依赖于数据仓库。智能举荐在数据对接方面，基于MaxCompute来实现，通过利用MaxCompute外部的一些计算能力，可能更好的剖析、治理企业的数据，从而实现智能举荐的业务场景。如果您的数据量较小，也能够通过SDK把数据推送到智能举荐，实现您的业务场景。智能举荐反对算法定制和业务定制，给予企业充沛的灵便自主可控的能力。 ## 三、自建痛点与产品劣势### 自建痛点(智能举荐)#### 搭建老本•人员要求高：自建举荐系统对人员要求较高，零碎开发、数据处理、召回、排序模型开发及调优，均须要高级开发&算法工程师长期参加。•上线周期长：举荐零碎架构简单，为达到上线成果须要重复调优，所需开发工夫多于3个月。•运维老本高：降级迭代、自建零碎前期有较高的保护老本。#### 举荐成果•成果调优艰难：套用支流算法不肯定有好的成果，还需思考应用领域数据、相关性、新鲜度、时效性等多维度举荐成果•外围指标难对立：想进步CTR的同时又减少用户停留时长，无奈兼顾多个外围指标•迭代周期长与业务快节奏：业务节奏通常很快，而外部人力无限，既要快节奏又要人力占用少还要服务稳定性高更要见效快 #### 后续保护•适配难度大：任何一套举荐引擎都无奈齐全适配企业的业务诉求，阿里云智能举荐提供了黑白盒一体化•经营易用性：举荐零碎较简单，不具备算法常识但须要干涉的经营人员上手难度大•服务稳定性：举荐场景通常用于高流量页面，对系统性能及稳定性以及弹性要求极高### 自建数据仓库面临的挑战企业为了应用数据驱动业务倒退，在建设和经营企业数据仓库时面临的问题：1、启动老本高、建设周期长，价值难以疾速验证2、如何解决多样数据，拥抱新技术，充沛开掘数据价值3、难以共享企业数据资产、数据翻新老本高4、平台架构简单、经营老本高5、满足业务须要的扩展性和弹性 ### 业务增长通过自建的形式搭一套智能举荐零碎是没问题的，但搭建举荐的成果如何保障。智能举荐的成果在不同行业的定义不同，在晋升成果的同时，须要在举荐零碎内做大量的工作。#### 多场景&业务适配•不同企业(业务指标和成果不同）•同一企业不同阶段•同一阶段不同场景•同一场景不同诉求#### 试验平台•选品•召回•排序•业务诉求阿里云智能举荐=当先的算法能力+稳固且高效的工程体系+残缺且灵便的产品能力 ### 智能举荐产品劣势#### 开箱即用•高度产品化、行业化(电商/内容/新闻)•笼罩全链路（反对友盟SDK行为采集）#### 举荐精准•行业、场景定向优化•行业与阿里自研支流算法封装•猜你喜爱&相干举荐•多指标模型训练#### 全托管•保障在线服务稳定性•灵便升降配服务•丰盛的数据品质诊断性能，在线服务监控告警#### 灵便适配•经营助手：产品和经营可疾速干涉举荐•开发和算法：集成弱小的离线、在线链路开发能力 ### MaxCompute产品劣势#### 简略、易用* 数据仓库(Data Warehouse) 面向数仓优化高性能存储、计算 * 多服务预集成、规范SQL，开发简略 * 企业级服务-内建欠缺的治理和平安能力* 服务化(As a Service) Serverless、免运维 * 按量付费、不必不花钱 * 主动降级#### 匹配业务倒退的弹性扩大* 动静扩缩容，无需提前容量布局，满足突发业务增长* 存储-计算独立扩大，无扩展性限度* 业务增长性能不降级#### 多剖析场景反对近实时化、交互剖析、AI剖析、数据湖剖析方面加强，反对更多业务场景* 机器学习 PAI原生集成 * 内置Spark ML * Mars科学计算* 传统数仓 ETL:SQL +UDF * BI:查问减速、MC-Hologres* 数据湖剖析 SQL表面 * 联邦查问 * 非结构化数据处理* 近实时数仓 近实时写入 * 近实时剖析#### 凋谢的平台全托管服务上反对凋谢接口和生态，为数据、利用迁徙、二次开发提供灵活性。* 治理接口凋谢 Java/Python SDK * 规范JDBC接口* 数据凋谢 凋谢的导入导出数据接口(Tunnel 高低传） * LOAD/UNLOAD：收费、高性能导入/导出ORC、Parquet凋谢格局到数据湖* 兼容支流语法 MaxCompute SQL兼容Hive SQL语法 * 反对原生Spark作业* 凋谢的生态 Flink/Kafka/Presto Connector * Airflow/Azkaban/Kettle调度 * 反对Tableau、FineBI及通用JDBC BI工具.jpg")## 四、配置与启动服务### 产品应用根底流程老本优化：可在POC阶段应用入门版实例测试，测试实现后一键升配标准版正式切流。次要分成四个步骤：1、数据筹备；2、创立实例；3、策略配置；4、测试、公布。实现根底服务搭建只需1个一般程度的工程师破费3-5天即可实现。 ### 通过历史数据( MaxCompute)启动实例 #### 控制台配置流程### 通过服务端SDK启动实例 ### 通过友盟+服务端SDK启动实例 ## 五、重点性能解读### 猜你喜爱+相干举荐在电商行业，智能举荐反对猜你喜爱、相干举荐这2种举荐服务类型。猜你喜爱次要利用于首页以及商品TAB页的商品瀑布流举荐，相干举荐次要利用于商品展现页、详情页的举荐。其中，种草社区可基于AIRec内容行业搭建。 ### 实时举荐实时交互是促成消费者沉迷式浏览的必备根底性能。智能举荐可实时学习消费者以后趣味表白、变动，并更新在下一次生成的举荐后果中，从而实现实时的互动式举荐性能。 ### 负反馈举荐零碎在与用户互动的过程中，有可能呈现不符用户预期的举荐后果，而负反馈成为举荐与用户对话的重要入口。智能举荐反对单个商品维度、商品类目维度以及商品其余特色类维度的负反馈性能。### 业务策略配置可针对精品做人工加权，实时高低架，保障举荐品质。可通过设置去重规定，保障在设置工夫区间内，不反复给用户举荐同一商品或内容。通过设置类目多样性规定，保障举荐的多样性，防止产品单一性。### 多场景场景作为个性化举荐的流量入口，在不同的页面/不同的用户群可进行差异化的定制。如，首页的举荐、频道页举荐、集体核心页、搜寻空后果页、商品详情页、购物车页等等。举荐PLUS反对定制差异化的场景选品规定。#### 控制台配置规定左侧业务定制->场景治理#### A/B试验平台流程如下控制台配置规定### 机器学习平台100+算法组件、残缺业务开发框架、拖拽式开发平台举荐业务逻辑封装、算法模型开箱即用可视化分析模型指标反对离线、在线的模型部署形式## 六、MaxCompute + 智能举荐学习阵地### MaxCompute学习阵地SaaS 模式云数据仓库 MaxCompute 官网，海量学习材料，助您开启云数仓之旅！### 智能举荐学习阵地智能举荐（Artificial Intelligence Recommendation，简称AIRec）基于阿里巴巴当先的大数据和人工智能技术，联合在电商、内容、新闻、视频直播和社交等多个行业畛域的积攒，为寰球企业及开发者提供个性化举荐服务。> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：本文次要解说开源ETL工具如何连贯MaxCompute直播视频请点击 直播 观看。 本次分享将从五个方面解说。 01 走进MaxCompute生态 02 开源ETL工具 03 客户端简介 04 PyODPS简介 05 实操展现 一、走进MaxCompute生态首先来看下 MaxCompute 产品能反对的内部工具，大略能够分为商业智能、开发治理、传输调度、编程接口。本次分享次要关注商业智能（BI）工具这一板块，能够看到 MaxCompute 官网集成有Tableau、FineReport、FineBI、Quick BI。其中Tableau、FineBI、FineReport是在特定的版本会内置 MaxCompute 驱动，如果须要通过JDBC连贯 MaxCompute ，还是须要手动加载 MaxCompute JDBC驱动，Quick BI作为阿里云的产品，是能够通过阿里云账号和AK信息间接连贯的，同时在8.6及以上版本的Yonghong Desktop也是能够通过内置驱动连贯 MaxCompute。在商业智能局部还有开源BI工具，Superset、Davinci也能够连贯 MaxCompute。 在开发治理局部，是咱们第二讲的内容，包含DBeaver、DataGrip、SQL Workbench/J。 同时咱们的产品还集成了 Kafka和Flink开源引擎。反对的ETL开源工具有Kettle、Airflow、Azkaban，这一部分是本次分享来介绍。反对的编程接口有Python、JDBC、SQLAlchemy。 除了反对的内部工具，MaxCompute 本身也有凋谢生态，包含内建开源引擎 Spark，迁徙工具MMA，开发生态PyODPS、Mars，工具生态Web-Console等。同时 MaxCompute 也与阿里云外部产品独特构建了丰盛的解决方案生态和数据利用生态。 二、开源ETL工具次要介绍一下开源ETL工具通过哪些形式连贯 MaxCompute 。开源ETL工具蕴含，Airflow、Azkaban、Kettle。 首先看下Airflow，Airflow是python编写的一款调度工具，外部有Python Operator和Bash Operator ， 等各种Operator。也反对自定义插件的开发，Airflow是通过command Operator管制MaxCompute客户端通过命令行的形式，提交SQL工作，对于Python SDK能够通过Python py文件这种形式提交，Java sdk能够通过java -jar形式提交。因为Airflow反对Python Operator，所以能够间接集成PyODPS，能够间接写Python代码。第二局部是Azkaban，Azkaban次要是通过command提交咱们的工作，能够通过MaxCompute提供的编程接口提交SQL工作。Kettle能够通过JDBC间接连贯MaxCompute。 三、MaxCompute CLI客户端简介MaxCompute客户端反对运行在Linux/Mac/Window三个零碎上。 装置•JDK 1.8以上。 •曾经创立MaxCompute我的项目，领有该我的项目权限的账号 配置•批改conf文件夹下的odps\_config.ini文件 •填写ak、我的项目名、endpoint 应用•Linux/Mac上执行bin目录下的odpscmd,windows执行bin目录下的odpscmd.bat •反对执行单个sql语句，执行sql文件，上传资源，上传下载数据(Tunnel)、受权等操作 四、MaxCompute Python SDK（PyODPS）简介装置•PC客户端装置依赖于python环境，执行 pip install pyodps ...

你对于正在运行的mysql 性能如何？参数设置的是否正当？账号设置的是否存在安全隐患？是否了然于胸？俗话说工欲善其事，必先利其器，定期对你的MYSQL数据库进行一个体检，是保障数据库安全运行的重要伎俩。 明天和大家分享几个mysql 优化的工具，你能够应用它们对你的mysql进行一个体检，生成awr报告，让你从整体上把握你的数据库的性能状况。 1、mysqltuner.pl这是mysql一个罕用的数据库性能诊断工具，次要查看参数设置的合理性包含日志文件、存储引擎、平安倡议及性能剖析。针对潜在的问题，给出改良的倡议，是mysql优化的好帮手。 在上一版本中，MySQLTuner反对MySQL / MariaDB / Percona Server的约300个指标。 我的项目地址：https://github.com/major/MySQLTuner-perl 1.1 下载[root@localhost ~]#wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl1.2 应用[root@localhost ~]# ./mysqltuner.pl --socket /var/lib/mysql/mysql.sock>> MySQLTuner1.7.4- MajorHayden<major@mhtx.net>>> Bug reports, feature requests, and downloads at http://mysqltuner.com/>> Runwith'--help'for additional options and output filtering[--] Skipped version check forMySQLTuner scriptPlease enter your MySQL administrative login: rootPlease enter your MySQL administrative password: [OK] Currently running supported MySQL version 5.7.23[OK] Operating on 64-bit architecture1.3、报告剖析1）重要关注[!!]（中括号有叹号的项）例如[!!] Maximum possible memory usage: 4.8G (244.13% of installed RAM)，示意内存曾经重大用超了。 ...

简介：MaxCompute 7月刊将带您理解7月最新公布的我的项目删除、SQL性能优化举荐等性能以及7月、8月精彩直播课程，欢送浏览。本期月刊将为您带来 MaxCompute 7月份产品最新动静。 导读 7月产品公布最新动静最佳实际好文举荐7月技术直播回顾8月技术直播预报7月产品公布最新动静 1、MaxCompute我的项目删除新性能公布 查案文档 >> 实用客户 大数据开发者、管理者 公布性能 MaxCompute反对 "通过MaxCompute控制台-我的项目列表-更多操作" 删除我的项目，提供“逻辑删除，15天内可复原”、“立刻删除”两种删除形式，抉择立刻删除后可立刻创立同名我的项目。 形式一，逻辑删除，删除后我的项目不可用，15天内可复原（包含复原数据），超过15天会彻底删除并永恒无奈复原。 形式二，立刻删除，彻底删除，永恒不可复原，此形式删除后可马上创立同名我的项目。 2、MaxCompute管家公布新的SQL性能优化举荐 查看文档 >> 实用客户 实用于通过 MaxCompute 进行大数据开发的开发者和审计运维人员 公布性能 MaxCompute管家定期举荐须要进行性能或老本优化的作业列表，本次次要是针对 “适宜启用 Dynamic Filter 进行性能优化的蕴含JOIN的SQL周期作业”。举荐的后果列表将给出最近一次执行的instance id（点击可进入Logview），以及join的输入输出数目，同时预测通过 Dynamic Filter 优化后SQL的减速效率和HINT形式辅助信息，很不便的获取到须要优化的作业信息，通过信息判断是否须要对作业进行优化。若举荐的列表里感觉有作业无需进行优化，则可针对此作业进行勾销订阅。 3、MaxCompute SQL 子查问反对多列运算的语法查看文档 >> 实用客户 大数据开发者，分析师 公布性能 MaxCompute SQL 兼容postgresql子查问语法，提供in subquery/scalar subquery反对多列运算的语法，in 类型的子查问语法反对在where语句中的in的表达式value为简略的多列select，或value蕴含聚合函数，或value为多个常量。scalar 类型的子查问语法反对select语句中蕴含多列scalar子查问等值比拟表达式，或select语句为多列与scalar子查问等值比拟boolean表达式，或where语句中多列与scalar子查问等值比拟表达式。 4、MaxCompute SQL 反对对局部聚合函数输出预排序 查看文档 >> 实用客户 开发者、分析师 公布性能 MaxCompute SQL 反对对WM\_CONCAT、COLLECT\_LIST及UDAF输出预排序。 MaxCompute SQL 的聚合函数WM\_CONCAT, COLLECT\_LIST及对数据输出程序敏感的UDAF函数，如果指定了排序列 WITHIN GROUP （ORDER BY col1[, col2...])，那么聚合函数的输出会保障有序。 最佳实际好文举荐 ...

简介： Kettle是一款开源的ETL工具，纯java实现，能够运行于Windows, Unix, Linux上运行，提供图形化的操作界面，能够通过拖拽控件的形式，不便地定义数据传输的拓扑。Kettle反对丰盛的数据输入输出源，数据库反对Oracle，MySql，DB2等，也反对业界各种开源的大数据系统，例如HDFS, HBase, Cassandra, MongoDB等。本文将介绍如何利用MaxCompute的插件无缝对接阿里云的大数据计算平台——MaxCompute。 本示例应用的工具及驱动版本 Setup下载并装置Kettle下载MaxCompute JDBC driver将MaxCompute JDBC driver置于Kettle装置目录下的lib子目录（data-integration/lib）启动spoonJob咱们能够通过Kettle + MaxCompute JDBC driver来实现对MaxCompute中工作的组织和执行。 首先须要执行以下操作： 新建Job新建Database ConnectionJDBC连贯串格局为：jdbc:odps:<maxcompute_endpoint>?project=<maxcompute_project_name>JDBC driver class为：com.aliyun.odps.jdbc.OdpsDriverUsername为阿里云AccessKey IdPassword为阿里云AccessKey SecretJDBC更多配置见：https://help.aliyun.com/docum... 之后，能够依据业务须要，通过SQL节点拜访MaxCompute。上面咱们以一个简略的ETL过程为例： Create table节点的配置如下： 须要留神： 这里Connection须要抉择咱们配置好的不要勾选Send SQL as single statement Load from OSS节点配置如下： 须要留神的点同Create table节点。无关更多Load的用法，见：https://help.aliyun.com/docum... Processing节点配置如下： 须要留神的点同Create table节点。 原文链接本文为阿里云原创内容，未经容许不得转载。

explain所有人都应该很相熟，通过它咱们能够晓得SQL是如何执行的，尽管不是100%管用，然而至多大多数场景通过explain的输入后果咱们能直观的看到执行打算的相干信息。 早一些的版本explain还只能查看select语句，当初曾经能反对delete，update，insert，replace了。 刚开始我想写这个的时候只是因为这个货色经常性不必就遗记，写了发现其实这个货色真的挺麻烦的，要把每个场景都整进去麻烦的很。 id查问编号，如果没有子查问或者联结查问的话，就只有一条，如果是联结查问的话，那么会呈现一条id为null的记录，并且标记查问后果，因为union后果会放到长期表中，所以咱们看到这里的表名是<union1,2>这种格局。 select_type关联类型，决定拜访表的形式。 SIMPLE 简略查问，代表没有子查问或者union。 PRIMARY 如果不是简略查问，那么最外层查问就会被标记成PRIMARY。 UNION&UNION RESULT 从上图能够看进去了，蕴含联结查问，第一个被标记成了PRIMARY，union之后的查问被标记成UNION，以及最初产生的UNION RESULT DERIVED 用来标记呈现在from里的子查问，这个后果会放入长期表中，也叫做派生表。 这个对于低版本的Mysql可能显示是这样的，高一点可能你看到的还是PRIMARY，因为被Mysql优化了。我换一个版本的Mysql和SQL执行能够验证到这个后果。 SUBQUERY 不在from里的子查问。 DEPENDENT 代表关联子查问（子查问应用了内部查问蕴含的列），和UNION，SUBQUERY组合产生不同的后果。 UNCACHEABLE 代表不能缓存的子查问，也能够和UNION，SUBQUERY组合产生不同的后果。 MATERIALIZED 物化子查问是Mysql对子查问的优化，第一次执行子查问时会将后果保留到长期表，物化子查问只须要执行一次。 比方上述DERIVED就是物化的一种体现，与之对应的就是DEPENDENT，每次子查问都须要从新调用。 这个后果无奈直观的看进去，能够用FORMAT=JSON命令查看materialized_from_subquery字段。 table显示表名，从上述的一些图中能够察看到UNION_RESULT和DERIVED显示的表名都有一些本人的命名规定。 比方UNION_RESULT产生的是<unionM,N>，DERIVED产生的是<derivedN>。 partitions数据的分区信息，没有分区疏忽就好了。 type关联类型，决定通过什么形式找到每一行数据。以下依照速度由快到慢。 system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>ALL。 system&const 这通常是最快的查找形式，代表Mysql通过优化最终转换成常量查问，最惯例的做法就是间接通过主键或者惟一索引查问。 而system是const的一个特例（只有一行数据的零碎表），轻易找一张零碎表，就插入一条数据就能够看到system了。 eq_ref 通常通过主键索引或者惟一索引查问时会看到eq_ref，它最多只返回一条数据。user_id是惟一索引，为了测试就关联以下主键索引。 ref 也是通过索引查找，然而和eq_ref不同，ref可能匹配到多条符合条件的数据，比方最左前缀匹配或者不是主键和惟一索引。 最简略的方法，轻易查一个一般索引就能够看到。 fulltext 应用FULLTEXT索引 ref_or_null 和ref相似，然而还要进行一次查问找到NULL的数据。 这相当于是对于IS NULL查问的优化，如果表数据量太少的话，你或者能看到这里类型是全表扫描。 index_merge 索引合并是在Mysql5.1之后引入的，就像上面的一个OR查问，依照原来的想法要么用name的索引，要么就是用age的索引，有了索引合并就不一样了。 对于这种单表查问（无奈跨表合并）用到了多个索引的状况，每个索引都可能返回一个后果，Mysql会对后果进行取并集、交加，这就是索引合并了。 unique_subquery 依照官网文档所说，unique_subquery只是eq_ref的一个特例，对于下图中这种in的语句查问会呈现以进步查问效率。 因为Mysql会对select进行优化，根本无奈呈现这个场景，只能用update这种语句了。 index_subquery 和unique_subquery相似，只是针对的是非惟一索引。 ...

一、转置idnamecount12Joe10012Neo20012Lve300SELECT列名，GROUP_CONTACT(CASE WHEN 列名 = 特定值 THEN 列名 END) AS 新名称，GROUP_CONTACT(CASE WHEN 列名 = 特定值 THEN 列名 END) AS 新名称，GROUP_CONTACT(CASE WHEN 列名 = 特定值 THEN 列名 END) AS 新名称FROM 数据表 WHERE 条件 GROUP BY 列名转置后 idjoe->newNameneo->newNamelve->newName12JoeNeoLve

简介：本文着重从 shuffle、join 形式的抉择、对象重用、UDF 重用等方面介绍了京东在 Flink SQL 工作方面做的优化措施。 本文作者为京东算法服务部的张颖和段学浩，并由 Apache Hive PMC，阿里巴巴技术专家李锐帮忙校对。次要内容为： 背景Flink SQL 的优化总结GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、背景 目前，京东搜寻举荐的数据处理流程如上图所示。能够看到实时和离线是离开的，离线数据处理大部分用的是 Hive / Spark，实时数据处理则大部分用 Flink / Storm。 这就造成了以下景象：在一个业务引擎里，用户须要保护两套环境、两套代码，许多共性不能复用，数据的品质和一致性很难失去保障。且因为流批底层数据模型不统一，导致须要做大量的拼凑逻辑；甚至为了数据一致性，须要做大量的同比、环比、二次加工等数据比照，效率极差，并且非常容易出错。 而反对批流一体的 Flink SQL 能够很大水平上解决这个痛点，因而咱们决定引入 Flink 来解决这种问题。 在大多数作业，特地是 Flink 作业中，执行效率的优化始终是 Flink 工作优化的要害，在京东每天数据增量 PB 级状况下，作业的优化显得尤为重要。 写过一些 SQL 作业的同学必定都晓得，对于 Flink SQL 作业，在一些状况下会造成同一个 UDF 被重复调用的状况，这对一些耗费资源的工作十分不敌对；此外，影响执行效率大抵能够从 shuffle、join、failover 策略等方面思考；另外，Flink 工作调试的过程也非常复杂，对于一些线上机器隔离的公司来说尤甚。 为此，咱们实现了内嵌式的 Derby 来作为 Hive 的元数据存储数据库 (allowEmbedded)；在工作复原方面，批式作业没有 checkpoint 机制来实现failover，然而 Flink 特有的 region 策略能够使批式作业疾速复原；此外，本文还介绍了对象重用等相干优化措施。 二、 Flink SQL 的优化1. UDF 重用在 Flink SQL 工作里会呈现以下这种状况：如果雷同的 UDF 既呈现在 LogicalProject 中，又呈现在 Where 条件中，那么 UDF 会进行屡次调用 (见https://issues.apache.org/jira/browse/FLINK-20887))。然而如果该 UDF 十分耗 CPU 或者内存，这种多余的计算会十分影响性能，为此咱们心愿能把 UDF 的后果缓存起来下次间接应用。在设计的时候须要思考：(十分重要：请肯定保障 LogicalProject 和 where 条件的 subtask chain 到一起) ...

简介：阿里云超强专家阵容倾力打造的实时数仓 “王炸组合”，更有合集电子书收费下载哦！架构、场景、实操全方位解读，实时数仓不再是“夸夸其谈”！王炸组合《实时数仓入门训练营》正式结营啦！本次受到了宽广开发者同学们激情的关注！训练营邀请了阿里云研究员王峰、阿里云高级产品专家刘一鸣等技术大咖作为讲课嘉宾。课程内容由浅入深全方位解析实时数仓的架构、场景、以及实操利用，让实时数仓不再是“夸夸其谈”！ 精品的内容促使训练营十分受大家的欢送，为满足大家求知学习的劲头，咱们现将《实时数仓入门训练营》的课程内容全副整顿了进去！汇编成《实时数仓“王炸组合”-实时计算 Flink 版+Hologres》的合集电子书！供各位小伙伴学习参考，收费下载！ 点击收费下载《实时数仓“王炸组合”-实时计算 Flink 版+Hologres》 **《实时数仓“王炸组合”-实时计算 Flink 版+Hologres》合集电子书 点击下载:https://developer.aliyun.com/topic/download?id=7944** 超强嘉宾阵容： 阿里云研究员王峰、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次课程和电子书的架构，由浅入深，精心打磨的技术内容，直击当下同学们所遇到的痛点问题。 超级干货内容： 零根底的同学不要愁，本次入门训练营蕴含7 门课精品课程搭配新鲜出炉的精装版电子书《实时数仓“王炸组合”-实时计算 Flink 版+Hologres》，就能帮忙你实现从 0 到 1 疾速上手搭建实时数仓。 以下是本系列课程的内容概括： 不会是 ”望而生畏“。讲课嘉宾别离解说 Flink 与 Hologres 的架构与原理，以及数仓架构的演进，再深度解析如何降级到 Flink + Hologres 实时数仓。内容由浅入深，小白也能轻易了解！不只是 “略懂略懂”。技术专家手把手实操演示，例如 Flink SQL 上手示例，Flink 读写 Hologres 上手示例等；还会将日常开发中可能遇到的各种典型问题都一一解惑，例如开发 Flink SQL 过程中常见问题和解决办法，Hologres 常见性能问题剖析等。有问题咱就解决，回绝只懂皮毛！不再是 “夸夸其谈”。产品专家将从实时数仓演变史，到基于 Flink + Hologres 实时数仓举荐架构，再到营销剖析实时数仓实际，全方位讲授如何将实时数仓利用到实际，助力互联网的实时决策和精准营销。实时数仓自身再好，不会使用也不行！精品课程回顾： 《实时数仓入门训练营》视频课程回顾 视频链接:https://developer.aliyun.com/learning/course/807 内容领先看： 【第一课】《实时计算 Flink 版总体介绍》 【第二课】《Hologres 总体架构》 【第三课】《基于 Flink + Hologres 的实时举荐零碎架构解析 》 ...

MySQL：ON DUPLICATE KEY UPDATE参考 https://blog.csdn.net/qq_2277... PostgreSQL：ON CONFLICT参考 https://blog.csdn.net/weixin_... MyBatis： <selectKey keyProperty="count" resultType="int" order="BEFORE"> select count(1) as count from xxx where aaa=1</selectKey><if test="count > 0"> update set xxx</if><if test="count == 0"> INSERT INTO xxx</if>Ps：MyBatis的形式在遇到并发插入报反复key时，能够用重试的形式解决

简介：本次直播将次要分享MaxCompute查问减速性能、数据库管理工具DBeaver、DataGrip、SQL Workbench/J的局部连贯演示。作者 木弈 阿里云智能 产品经理 直播视频请点击 直播 观看。 本次分享将从四个方面解说。 01 上节回顾 02 数据库管理工具概览 03 实操展现 04 查问减速 一、上节回顾在第一讲中咱们次要讲了 MaxCompute 生态，重点介绍了商业BI工具，包含Tableau、FineReport、FineBI、Quick BI、Yonghong Desktop BI工具的连贯原理以及实操的展现。本文主讲数据库管理工具，次要是开发治理局部的DataGrip、DBeaver、SQL Workbench/J。 .jpg") 二、数据库管理工具概览数据库管理工具，即数据库图形化工具，是数据库人员必须的工具之一，MaxCompute反对与DBeaver、DataGrip和SQL Workbench/J 通过JDBC驱动连贯，并能够形象化方便快捷地进行列举数据库、列举表、查看表构造、查问表数据、建表、写表、建视图、查问视图等相干操作。 连贯形式JDBCJDBC（Java DataBase Connectivity）是一种用于执行SQL语句的Java API，能够为多种关系数据库提供对立拜访，它由一组用Java语言编写的类和接口组成。简略来说就是用Java语言向数据库发送SQL语句来操作数据库。 MaxCompute JDBC 驱动MaxCompute JDBC 驱动是 MaxCompute 提供的能够拜访 MaxCompute 的JDBC接口。您能够通过规范的JDBC 接口基于 MaxCompute 执行海量数据的分布式计算查问。MaxCompute JDBC 驱动还能够用于连贯MaxCompute 和反对 JDBC 的工具。 MaxCompute 相干根本参数信息•URL：jdbc:odps:<MaxCompute\_endpoint\>?project=<MaxCompute\_project\_name\> ：必填。MaxCompute我的项目所属区域的Endpoint。：必填。待连贯的指标MaxCompute项目名称。此处为MaxCompute项目名称，非工作空间名称。•User：有拜访指定我的项目权限的AccessKey ID。 •Password ：AccessKey ID对应的AccessKey Secret。 三、实操展现DBeaver实操展现请点击 视频 查看实操局部 其余实操文档DataGrip连贯MaxCompute SQL Workbench/J连贯MaxCompute 四、查问减速MaxCompute 查问减速 – 针对实时性要求高的查问作业，全链路放慢 MaxCompute 查问执行速度 ...

简介：为什么说Quick Audience是集数据资产构建、用户剖析、精准营销投放、跨端社交互动和全域会员治理为一体的全域消费者经营平台，其中一个很大的起因是置入了经典营销模型，如RFM模型与AIPL模型，由方法论撑持消费者经营，实现高效增长与拉新。-更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index 背景在营销过程中须要思考如何剖析数据以及如何出现数据，因为这是施展数据价值很重要的环节。通过数据的剖析与可视化能够更加直观的洞察，发现数据背地的价值，从而辅助业务决策，实现真正的数据赋能业务。 Quick Audience是集数据资产构建、用户剖析、精准营销投放、跨端社交互动和全域会员治理为一体的全域消费者经营平台。Quick Audience置入了经典营销模型：RFM模型与AIPL模型，由方法论撑持消费者经营，实现高效增长与拉新。 RFM模型RFM模型基本概念：RFM模型是一种通过客户的R生产距离（Recency）、F生产频率（Frequency）、M生产金额（Monetary）三项指标来掂量客户价值的伎俩。 RFM模型对客户的三项指标的值别离进行量化评分，而后通过单个客户的得分与对比值相比拟，得出该客户在群体中的绝对价值程度，进而综合三项指标将客户群体划分为多种类型，从而便于为不同类型的客户采取有针对性的经营伎俩。 RFM用户类型划分规定将用户的RS、FS、MS得分别离与RS对比值、FS对比值、MS对比值相比拟，得出该用户在群体中的绝对价值程度： 用户得分大于对比值，价值较高。用户得分小于对比值，价值较低。阐明： RS、FS、MS别离为用户的生产距离、生产频率、生产金额得分。 RS对比值、FS对比值、MS对比值别离为RFM模型中所有用户的生产距离、生产频率、生产金额得分的平均值（即统计学中的加权平均值），或为自定义值。 用户在R、F、M任意一项中的价值可被分为高、低两类，综合R、F、M三项的体现，用户可被划分为8种类型，具体类型及分类规定如下表所示。 RFM用户类型RSFSMS阐明<span class="lake-fontsize-11">高价值客户</span><span>大于等于RS对比值(高)</span>大于等于FS对比值<span>(高)</span><span class="lake-fontsize-11">大于等于MS对比值</span><span>(高)</span><span class="lake-fontsize-11">将最近生产日期较近、生产频次较高、生产金额较高的人群定义为高价值人群</span><span class="lake-fontsize-11">重点放弃客户</span><span class="lake-fontsize-11">小于RS对比值</span><span>(低)</span><span class="lake-fontsize-11">大于等于FS对比值</span><span>(高)</span><span class="lake-fontsize-11">大于等于MS对比值</span><span>(高)</span><span class="lake-fontsize-11">将最近生产日期较远，然而生产频次和生产金额较高的人群定义为重点放弃客户。</span><span class="lake-fontsize-11">重点倒退客户</span><span>大于等于RS对比值</span><span>(高)</span><span class="lake-fontsize-11">小于FS对比值</span><span>(低)</span><span class="lake-fontsize-11">大于等于MS对比值</span><span>(高)</span><span class="lake-fontsize-11">将最近生产日期较近，生产金额较高，然而生产频次不高的人群定义为重点倒退客户。</span><span class="lake-fontsize-11">重点挽留客户</span><span>小于RS对比值</span><span>(低)</span><span class="lake-fontsize-11">小于FS对比值</span><span>(低)</span><span class="lake-fontsize-11">大于等于MS对比值</span><span>(高)</span><span class="lake-fontsize-11">将最近生产日期较远，生产频次较低，然而生产金额较高的人群定义为重点挽留客户。</span><span class="lake-fontsize-11">个别价值客户</span><span>大于等于RS对比值</span><span>(高)</span><span class="lake-fontsize-11">大于等于FS对比值</span><span>(高)</span><span class="lake-fontsize-11">小于MS对比值</span><span>(低)</span><span class="lake-fontsize-11">将最近生产日期较近，生产频次较高，然而生产金额不高的人群定义为个别价值客户。</span><span class="lake-fontsize-11">个别放弃客户</span><span class="lake-fontsize-11">小于RS对比值</span><span>(低)</span><span class="lake-fontsize-11">大于等于FS对比值</span><span>(高)</span><span class="lake-fontsize-11">小于MS对比值</span><span>(低)</span><span class="lake-fontsize-11">将最近生产日期较远，生产金额不高，然而生产频次较高的人群定义为个别放弃客户。</span><span class="lake-fontsize-11">个别倒退客户</span><span class="lake-fontsize-11">大于等于RS对比值</span><span>(高)</span><span class="lake-fontsize-11">小于FS对比值</span><span>(低)</span><span class="lake-fontsize-11">小于MS对比值</span><span>(低)</span><span class="lake-fontsize-11">将最近生产日期较近，然而生产频次和生产金额不高的人群定义为个别倒退客户。</span><span class="lake-fontsize-11">潜在客户</span><span class="lake-fontsize-11">小于RS对比值</span><span>(低)</span><span class="lake-fontsize-11">小于FS对比值</span><span>(低)</span><span class="lake-fontsize-11">小于MS对比值</span><span>(低)</span><span class="lake-fontsize-11">将最近生产日期较远、生产频次不高、生产金额不高的人群定义为潜在客户。</span> ## RFM模型构建过程及利用：### RFM模型构建过程: ### RFM模型利用：RFM模型在Quick Audience中，能够用于剖析用户的外围指标及用户的分类占比状况。依据不同的用户类型进行不同营销流动的投放。#### RFM模型交易数据分析外围指标展现交易用户数、交易金额、人均交易金额、人均交易频次的具体数值及趋势图。在Quick Audience中RFM剖析界面成果如下：RFM用户形成（用户类型）依据RFM模型的用户分类定义，展现受众的用户类型散布状况。在Quick Audience中RFM剖析界面成果如下：RFM用户形成（生产散布）依据用户的生产距离、生产频率、生产金额,展现生产潜能散布。在Quick Audience中RFM剖析界面成果如下：生产能力散布（MF-R）：横坐标为F交易频率，纵坐标为M交易金额，点大小为R上次交易距离。通过MF散布来直观看到客户的生产能力散布，进而通过R的大小来锁定哪些客户更为虔诚。点越大，客户忠诚度越高。生产潜能散布（MR-F）：横坐标为R最近一次交易距离，纵坐标为M交易金额，点大小为F交易频率。通过MR散布来直观看到客户的生产潜能状况，进而通过F的大小来开掘更有价值的客户。点越大，客户越有开掘价值。生产散布（RF-M）：横坐标为F交易频率，纵坐标为R上次交易距离，点大小为M交易金额。通过RF散布来直观看到客户的生产异动状况，进而通过M的大小来判断哪些客户更有必要挽回。点越大，客户越有必要挽回。 通过下面的剖析，能够为绝对应的客户打上客户特色标签，这样就能够针对某类客户指定不同的营销策略。## RFM模型构建过程中的问题： #### 1、对于千万级数据量的客户剖析数据加载过慢解决方案：在创立RFM模型的时候进行预计算，应用模型id作为缓存key。#### 2、对于同一个RFM模型对于不同的部门权限的行列级权限管制及剖析的解决解决方案：在创立RFM预计算和行列级配置生成sql，依据sql进行md5计算加上模型id作为缓存key # AIPL模型 ## AIPL模型基本概念：AIPL模型是一种将品牌人群资产定量化、链路化经营的伎俩。其中：* A（Awareness）：品牌认知人群，个别指与品牌被动产生接触的人群，例如品牌广告触达和品类词搜寻的人。* I（Interest）：品牌趣味人群，个别指与品牌被动产生接触的人群，例如广告点击、浏览品牌/店铺主页、参加品牌互动、浏览产品详情页、品牌词搜寻、支付试用、订阅/关注/入会、加购珍藏的人。* P（Purchase）：品牌购买人群，包含产生过购买行为的人。* L（Loyalty）：品牌虔诚人群，例如购买人群中，产生了复购行为或对品牌有侧面评估、分享的人。 ## AIPL模型构建过程及利用：AIPL模型在Quick Audience中，将品牌人群划分为认知人群、趣味人群、购买人群、虔诚人群。能够查看消费者总数及消费者的变化趋势。依据不同的人群进行营销流动投放，及回流的数据查看不同人群的营销成果。### AIPL模型构建过程: ### AIPL模型利用：#### AIPL用户剖析：基于计算基准日期的认知、趣味、购买、虔诚四类用户的具体人数，及消费者的变化趋势。如在Quick Audience中AIPL用户剖析界面成果：#### AIPL流转剖析：用户数量展现认知、趣味、购买、虔诚四类用户在日期区间完结时的用户数以及环比差额。如在如在Quick Audience中AIPL流转界面成果：在营销过程中,用户可依据不同营销后果查看用户的转换状况。查看每个等级用户的转化状况。用户转化用户转化量为某一类用户转换为其余类型用户的数量。以下图中的认知人群为例，用户转化量为1，代表认知人群中有1人转化为趣味、虔诚或购买人群。下图中，1人转化为趣味。起始日期的认知人数等于仍放弃为认知的人数，加上认知的用户转化量（即从认知转化为趣味、虔诚、购买的人数），再加上认知散失的人数之和。## AIPL模型构建过程中的问题：#### 1、如何避免数据量的收缩缩小数据的存储解决方案：在每天计算完A、I、P、L的用户只放弃增量数据，如第一天有500w的数据，第二天有501w的数据，其中2w的新增和1w的散失，再原来数据的根底上只有3w数据量的变更。在商业活动中，营销实战积淀下了多种经典的方法论，领导着企业业务的倒退。随着数智化过程的放慢，Quick Audience产品在封装技术能力之外，更将方法论融入其中，以帮忙企业更好的利用数据，获取继续的增长。 *数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云对外输入系列解决方案，包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包含：* - Dataphin，一站式、智能化的数据构建及治理平台；* - Quick BI，随时随地 智能决策；* - Quick Audience，全方位洞察、全域营销、智能增长；* - Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；* - Quick Stock， 智能货品经营平台；* - Quick Decision，智能决策平台；官方站点：数据中台官网 https://dp.alibaba.com钉钉沟通群和微信公众号> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： 这里的慢SQL指的是MySQL慢查问，是运行工夫超过long_query_time值的SQL。实在的慢SQL通常会随同着大量的行扫描、临时文件排序或者频繁的磁盘flush，间接影响就是磁盘IO升高，让失常的SQL变成了慢SQL，大面积执行超时。本文将和大家分享慢SQL的治理过程。 作者 | 史伟民起源 | 阿里技术公众号 一 为什么要做这个事件1 什么是慢SQL？这里指的是MySQL慢查问，具体指运行工夫超过long_query_time值的SQL。 咱们常听常见的MySQL中有二进制日志binlog、中继日志relaylog、重做回滚日志redolog、undolog等。针对慢查问，还有一种慢查问日志slowlog，用来记录在MySQL中响应工夫超过阀值的语句。 大家不要被慢查问这个名字误导，认为慢查问日志只会记录select语句，其实也会记录执行工夫超过了long_query_time设定的阈值的insert、update等DML语句。 查看慢SQL是否开启 show variables like "slow_query_log%"; 查看慢查问设定的阈值 单位:秒 show variables like "long_query_time";对于咱们应用的AliSQL-X-Cluster即XDB来说，默认慢查问是开启的，long_query_time设置为1秒。 2 慢查问为何会导致故障？实在的慢SQL往往会随同着大量的行扫描、临时文件排序或者频繁的磁盘flush，间接影响就是磁盘IO升高，失常SQL也变为了慢SQL，大面积执行超时。 去年双11后，针对技术侧裸露的问题，菜鸟CTO线推出多个专项治理，CTO-D各领一项作为sponsor，我所在的大团队负责慢SQL治理这个专项。 二 要做到什么水平1 怎么来掂量一个利用的慢SQL重大水平？微均匀 sum(aone利用慢SQL执行次数)-----------------------sum(aone利用SQL执行次数)咱们认为，该值越大，影响越大；该值越小，影响可能小。 极其状况就是利用里每次执行的SQL全是慢SQL，该值为1；利用里每次执行的SQL全不是慢SQL，该值为0。 然而这个指标带来的问题是区分度不佳，尤其是对SQL QPS很高且大多数状况下SQL都不是慢查问的状况，偶发的慢SQL会被吞没。 另外一个问题，偶发的慢SQL是真的慢SQL吗？咱们遇到很多被慢查问日志记录的SQL，实际上可能受到其余慢SQL影响、MySQL磁盘抖动、优化器抉择等起因使得惯例查问下体现显然不是慢SQL的变成了慢SQL。 宏均匀 sum(慢SQL 1执行次数) sum(慢SQL n执行次数)----------------- + ------------------sum(SQL 1执行次数) sum(SQL n执行次数)--------------------------------------- n这个算法建设在被抓到的慢SQL有肯定执行次数的根底上，能够缩小假性慢SQL的影响。 当某些利用QPS很低，即一天执行SQL的次数很少，如果碰到假性SQL就会引起统计误差。 执行次数 sum(aone利用慢SQL执行次数)----------------------- 7统计最近一周均匀每天的慢SQL执行次数，能够打消掉宏均匀带来的假性SQL问题。 慢SQL模板数量 以上维度均有个工夫限定范畴，为了追溯慢SQL历史解决状况，咱们还引入了全局慢SQL模板数量维度。 count(distinct(aone利用慢SQL模板) ) 2 指标外围利用：解决掉所有的慢SQL一般利用：微平均指标降落50% 3 CTO报表以CTO-D为单位依据以上多维度指标统计汇总利用的加权均匀，由低到高得出排名，突出头尾top3，每周播报。 三 为什么由我来做猜想可能与我的背景无关，有C/C++背景，曾在上家公司负责过公司层面异地多活架构的设计和落地，对于MySQL比拟理解一些。 另外可能是利益无关，我所在小团队业务刚起步，不存在慢SQL，这样能够插入到各个业务线去。 四 口头撑持1 团体MySQL规约索引规约摘录局部： 【强制】超过三个表禁止join。须要join的字段，数据类型放弃相对统一；多表关联查问时，保障被关联的字段须要有索引。 阐明：即便双表join也要留神表索引、SQL性能。 【强制】在varchar字段上建设索引时，必须指定索引长度，没必要对全字段建设索引，依据理论文本区分度决定索引长度。 阐明：索引的长度与区分度是一对矛盾体，个别对字符串类型数据，长度为20的索引，区分度会高达90%以上，能够应用count(distinct left(列名, 索引长度))/count(*)的区分度来确定。 ...

先记录，后整顿查问某字段最大值的数据，按另一字段分组.表名:testidquantityproduct_id...-- 这里是查问雷同 product_id 中 quantity 最大的那条数据。SELECT *FROM test aWHERE id = (SELECT id FROM test b where b.product_id = a.product_id order by quantity desc LIMIT 1);

简介：本期咱们将揭秘Hologres如何反对超高QPS在线服务（点查）场景。Hologres（中文名交互式剖析）是阿里云自研的一站式实时数仓，这个云原生零碎交融了实时服务和剖析大数据的场景，全面兼容PostgreSQL协定并与大数据生态无缝买通，能用同一套数据架构同时反对实时写入实时查问以及实时离线联邦剖析。它的呈现简化了业务的架构，为业务提供实时决策的能力，让大数据施展出更大的商业价值。从阿里团体诞生到云上商业化，随着业务的倒退和技术的演进，Hologres也在继续一直优化核心技术竞争力，为了让大家更加理解Hologres，咱们打算继续推出Hologres底层技术原理揭秘系列，从高性能存储引擎到高效率查问引擎，高吞吐写入到高QPS查问等，全方位解读Hologres，请大家继续关注！ 往期精彩内容： 2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》Hologres揭秘：首次公开！阿里巴巴云原生实时数仓核心技术揭秘Hologres揭秘：首次揭秘云原生Hologres存储引擎Hologres揭秘：Hologres高效率分布式查问引擎Hologres揭秘：高性能原生减速MaxCompute外围原理Hologres揭秘：优化COPY，批量导入性能晋升5倍+本期咱们将揭秘Hologres如何反对超高QPS点查。 传统的 OLAP 零碎在业务中往往扮演着比拟动态的角色，以通过剖析海量的数据失去业务的洞察（比如说预计算好的视图、模型等），从这些海量数据分析到的后果再通过另外一个零碎提供在线数据服务（比方HBase、Redis、MySQL等）。这里的服务（Serving）和剖析（Analytical）是个割裂的过程。与此不同的是，理论的业务决策过程往往是一个继续优化的在线过程。服务的过程会产生大量的新数据，咱们须要对这些新数据进行简单的剖析。剖析产生的洞察实时反馈到服务，让业务的决策更实时，从而发明更大的商业价值。 Hologres定位是一站式实时数仓，交融剖析能力（Analytical）与在线服务(Serving)为一体，缩小数据的割裂和挪动。本文的内容将会针对Hologres的服务能力（外围为点查能力），介绍Hologres到底具备哪些服务能力，以及背地的实现原理。 通常咱们所说的点查场景是指Key/Value查问的场景，宽泛用于在线服务。因为点查场景的宽泛需要，市场上存在多种KV数据库定位于反对高吞吐、低延时的点查场景，例如被大家广而熟知的HBase，它通过自定义的一套API来提供点查的能力，在许多业务场景都可能取得较好的成果。然而HBase在理论应用中也会存在肯定的毛病，这也使得很多业务从HBase迁徙至Hologres，次要有以下几点： 当数据规模大到肯定水平的时候，HBase在性能方面将会有所降落，无奈满足大规模的点查计算，同时在稳定性上也变得不如人意，须要有教训的运维反对HBase提供的是自定义API，上手有肯定的老本。Hologres间接通过SQL提供高吞吐、低延时的点查服务。相比于其它KV零碎提供自定义API，SQL接口无疑更加的简略易用。HBase采纳Schema Free设计，没有数据类型，对于检查数据品质，修改数据品质也带来了复杂度，查错难，修改难。Hologres具备与Postgres兼容的简直所有支流数据类型，能够通过Insert/Select/Update/Delete规范SQL语句对数据进行查看、更新。在Hologres中的点查场景是指行存表基于主键（PK）的查问。--建行存表BEGIN;CREATE TABLE public.holotest ( "a" text NOT NULL, "b" text NOT NULL, "c" text NOT NULL, "d" text NOT NULL, "e" text NOT NULL,PRIMARY KEY (a,b));CALL SET_TABLE_PROPERTY('public.holotest', 'orientation', 'row');CALL SET_TABLE_PROPERTY('public.holotest', 'time_to_live_in_seconds', '3153600000');COMMIT;-- Hologres通过SQL进行点查select * from table where pk = ?; -- 一次查问单个点select * from table where pk in (?, ?, ?, ?, ?); -- 一次查问多个点点查场景技术实现难点失常状况下，一条SQL语句的执行，须要通过SQL Parser进行解析成AST（形象语法树），再由Query Optimizer解决生成Plan（可执行打算），最终通过执行Plan拿到计算结果。而要想通过SQL做到高吞吐、低延时、稳固的点查服务，则必须要克服如下艰难： ...

clear bufferset define offset sqlblanklines onspool m_200_sproc.log--connect--ISMP V4 Order通用鉴权批价（电信版本） 实现性能：订购鉴权批价--订购入库、退订入库、产品收费期揭示鉴权、暂停/激活产品订购关系鉴权--暂停/激活产品订购关系更新 --订购鉴权批价prompt zxdbm_200.slp_200_telicomsubreqcreate or replace procedure zxdbm_200.slp_200_telicomsubreq( i_oa in varchar2, --发起方/赠送方用户号码i_ua in varchar2, --应用方/受赠方用户号码i_oatype in number, --发起方地址类型i_datype in number, --应用方地址类型i_servicetype in number, --业务能力类型i_serviceflowtype in number, --业务流程类型i_srvprodid in varchar2, --业务/产品代码i_actiontype in number, --动作类型i_cmdchannel in number, --动作起源i_countrycode in varchar2, --国家码i_spaccesscode in varchar2, --antuprice音讯中的SP接入码i_isthird in number, --0:一般订购 1:赠送i_silent in number, --缄默去激活开关i_needauthuser in number, --是否须要鉴权用户 0-不须要 1-须要i_direct in number, --订购方向 0:正向订购 1:SP反向定购i_supportproductid in number, --同步SP、SP下发应用service还是productid 0-serviceid 1-productidi_prepaidtype in number, --预付费接口类型 1-OCS 2-非OCS 3-依据号段抉择是OCS或者非OCSi_monthconsumedlimit in number, --零碎级月生产限度金额i_isnondreplay in number, --是否须要二次确认,1-不须要，0-须要i_checkpseudocode in number, --零碎开关:是否反对伪码 0-不反对 1-反对i_provinceorder in number, --零碎开关:是否反对跨省赠送 0-不反对 1-反对i_rentday in number, --账期截止日期i_mutidbmode in number, --是否多DB环境 0:否 1:是i_isfromnmsc in number, --是否nmsc过去的音讯 0:否 1：是i_spordernoticeuser in number, --sp反向订购是否与用户交互（告诉用户，二次确认） 0:否 1：是i_freemodule in number, --收费期计费形式： 0：失常形式 1：优惠形式i_eventid in varchar2, --事件IDi_channelid in varchar2, --渠道商ID--added by youqunxia 20130805 Order3.02.01i_webgwcnfmswitch in number, --用来管制来自WEBGW的申请，是否进行二次确认，0-不须要 1-须要i_startcmdchannel in number, --二次确认时的最后起源动作起源i_isexperience in number, --订购类型：0：失常订购 1：收费体验 2：积分兑换 3：体验转正式 默认为0i_fullmonthmode in number, --退订应用足月模式 0-可用到订购日 1-可用到订购日前一天i_effectiveswitch in number, --VSOP发动的订购退订立刻失效开关是否关上，0-敞开，1-关上o_retcode out number, --鉴权返回码 0代表胜利，否则代表错误码o_debugpos out number, --进口程序标识o_debuginfo out varchar2, --调试信息o_srcmsisdn out varchar2, --去掉前缀的发起方/赠送方用户号码o_usemsisdn out varchar2, --去掉前缀的应用方/受赠方用户号码o_paymsisdn out varchar2, --去掉前缀的计费方号码o_srcmsisdntype out number, --发起方号码类型，1:msisdn,2:phs,3:pstno_usemsisdntype out number, --应用方号码类型，1:msisdn,2:phs,3:pstno_userindex out number, --应用方号码序号o_payuserindex out number, --付费方号码序号o_needreplay out number, --产品订购是否须要用户二次确认，0-不须要，1-须要o_paytype out number, --计费号码的付费类型 0:后付费 1:预付费 2:准预付费o_oppaytype out number, --话单专用付费类型o_scptype out number, --对预付费扣费的设施类型 1：OCS；2：非OCSo_subfee out number, --本次订购须要扣取的费用o_colortype out number, --应用方号码名单类型 0-普通用户，1-黑名单，2-白名单， 3-灰名单，4-红名单o_usertype out number, --应用方类型 1-普通用户 2-运营商测试用户 3-SP测试用户o_producttype out number, --产品类型 1-失常产品 2-测试产品o_cpid out varchar2, --CP/SP代码o_cpindex out number, --CP/SP序号o_cpcnshortname out varchar2, --CP/SP名称o_cpsubscribeurl out varchar2, --CP/SP订购URLo_cptype out number, --CP/SP类型 0:本省 1：是全国业务o_protocoltype out number, --定购同步协定类型0-ismp(wbs形式)，1-smgp2.0（cngp1.0），2-smgp3.0o_msgtosp out varchar2, --SMGP/CNGP同步sp的音讯内容o_cnfmmsgtosp out varchar2, --SMGP2.0/CNGP1.0向sp发送同步确认音讯内容o_customersrvtel out varchar2, --CP/SP客服电话o_serviceid out varchar2, --业务代码o_serviceindex out number, --业务序号o_servicename out varchar2, --业务名称o_productid out varchar2, --产品代码o_productindex out number, --产品序号o_productname out varchar2, --产品名称o_smschargingcn out varchar2, --产品资费短信形容o_autocontinue out number, --周期性订购是否主动续订o_servicetype out number, --产品业务能力类型o_subcapability out number, --产品业务能力子类型o_srvtypeid out varchar2, --业务能力编码，对应ssys_service_type表中的srvtypeido_corpid out varchar2, --团体代码o_corpindex out number, --团体序号o_corpcnshortname out varchar2, --团体名称o_paymode out varchar2, --团体付费模式 团体付费/集体付费o_freetime out varchar2, --产品订购关系收费期o_nextrentdate out varchar2, --产品订购关系下次扣租日期o_substarttime out varchar2, --产品订购关系失效工夫o_subendtime out varchar2, --产品订购关系生效工夫o_substatus out number, --产品订购关系状态o_lastrenttime out varchar2, --产品订购关系上次扣租工夫o_payfordate out varchar2, --月租已付日期o_fixusetimes out number, --产品包量值o_chargetype out number, --产品计费类型o_cyctype out number, --产品周期类型o_linknum out varchar2, --业务话单中同一个流程中二次确认前后话单的关联o_maxlimitfee out varchar2, --用户月生产限额o_pseudocode out varchar2, --伪码o_pcodemsisdnswitch out number, --伪码和实在号码之间是否有转换: 0否 1实在号码转化伪码 2伪码转化为实在号码o_chanelplayerstate out number, --cp/sp状态，0-申请,1-失常，2-暂停（暂停代收费），3-预登记，4-登记,5-解冻，21-暂停端口o_eventstate out number, --0,失常 1,登记o_ordertype out number, --定购类型，1-定购，2-点播，3-不须要定购点播o_spaccesscode out varchar2, --SP接入码o_cancelaccesscode out varchar2, --产品退订接入码o_maincapability out number, --组合业务主业务能力类型o_submaincapability out number, --组合业务主业务能力子类型o_cpsrvtype out number, --CP服务类型：0：CP+SP,1：CP,2：SP ;3：自营业务SPo_cancelproductid out varchar2, --被189替换的产品代码o_issecondproduct out number, --订购流程子类型 0:一般订购 1:业务订购 2:待生效订购关系订购 3:纯包量反复订购 6:可变价的反复订购 7:体验转正式的反复订购o_cancelfeaturecode out varchar2, --短信,彩信退订指令o_provincesend out number, --是否跨省赠送 0.否 1.跨省赠送 2.跨省受增o_cdrbegintime out varchar2, --话单计费开始工夫o_cdrendtime out varchar2, --话单计费完结工夫o_cnfmtype out number, --产品二次确认类型 0:一般 1:0资费 2:收费期o_validmode out number, --产品属性：订购失效形式：0-立刻失效，1-下一帐期失效，2-N周期后失效，3-指定日期失效o_mutiluserexit out number, --用户存在状况： 0 多DB分库用户不存在 1 多DB分库用户存在或者单DB用户存在o_popustop out varchar2, --推广期完结工夫o_popuexist out number, --长期寄存订购时是否存在推广期： 0目前存在收费推广期 1.目前存在计费推广期 2.目前不在推广期或无推广期 3. 订购工夫在推广期，失效工夫在推广期之外；o_freenoticenow out number, --长期寄存收费期揭示短信立即下发(首次订购收费期为1天的产品)： 0否 1是o_freedays out number, --长期寄存收费期揭示短信立即下发(首次订购收费期为1天的产品)： 0否 1是o_productpkgname out varchar2, --套餐名称o_freenotitype out number, --收费期揭示形式 dwFreeNotiType 0：调用收费n天的短息模板，1:收费到月底 2：收费n小时 3：试用到足月 默认为0o_needcharge out number, --是否须要扣费 0否 1是 （只用于赠送状况下的替换）o_cityid out varchar2, --用户表中的cityid--added by youqunxia 2013.02.18o_freenotify out number, --收费试用期到解决形式，0-到期主动免费，1-到期需用户确认订购，2-到期主动勾销，3-到期用户确认退订--added by youqunxia 20130818 Order3.02.01o_hassubscription out number, --可变价订购时，是否有订购关系，0-否，1-是o_rentfee out number, --周期性费用金额，0-无此类费用o_haswebgw out number, --是否是签约WEBGW业务能力的SP，0-否，1-是o_lastvarifee out number, --WEBGW可变价时，当存在订购关系时，保留上次订购关系表中的可变价格o_issynctooidd out number, --是否同步订购关系给OIDD,0-否，1-是o_isexperience out varchar2, --订购类型：0：失常订购 1：收费体验 2：积分兑换 3：体验转正式 默认为0o_chargetime out varchar2 --首次扣费时间)as ...