在线数据库(在线数据库查询) 收藏 0

打通WPSJSA与AirScript在线表 轻松实现无数据库联网应用

• 不买服务器，不用数据库，只需要表格编程技术也可轻松实现在线表格应用!

浏览器搜索 郑广学JSA

终于要讲到AirScript以及WebApi了，大部分一直在vba和jsa里写代码的同学，一提到联网应用，就只想到数据库，服务器，域名，还有数据库驱动，普通人要实现一个联网应用似乎非常的困难，但是现在不一样了，wps提供的在线表AirSheet里面提供的AirScript和WebHook功能,可以让我们和使用表格一样使用在线数据库，只要学过一点wpsjsa基础的同学，就可以完全免费的使用wps的在线表服务来实现表格联网应用。

下面看我给大家准备的一个案例，里面展示了本地wps表格，通过jsa代码与在线表的AirScript联合应用，实现了数据的增删查改，以及用户登录鉴权，按不同用户返回不同结果，这个案例会在郑广学WPS-JSA火箭速成班第13章里完整讲解所有代码，以及配置过程。下面先看一下案例的功能。

今晚7点半，也欢迎大家在直播间和我一起学习AirScript的实战细节

抖音请搜索 郑广学 视频号直接从公众号进入即可

1 在线用户管理，登录控制

用户要查询数据必须知道正确的用户名和密码，不同于传统表格登录，这个用户名密码不在本地存储，用户即使看到所有代码，也无法得知用户名密码，必须经过管理员授权告过的人才可以登录，而管理员也可以随时在wps在线表网页端取消任意一个用户的授权，以及增加授权

账户密码不对只会得到报错信息

中途客户端也可以切换用户查询不同用户权限的数据 上面是admin管理账户，他可以查看所有数据，如果切换到jsa880账户,就只能看到jsa880权限下面的数据，传统本地表格，这个方式只要有开发能力的总是能看到所有数据，而webapi在线表形式 ，客户端在没有账户密码的情况下，绝对无法得到权限以外的数据

2 拉取在线数据到本地表格显示及处理

同样也需要登录验证

这里从在线表拉取了一万行数据到本地，本地表一条数据都不实际存储

3 上传新增数据

在线应用当然不能只下载数据，还要上传数据，上传数据一般来说数据本身要有一个唯一ID， 来确保不重复上传，这和数据库类似，当然这个比数据库灵活，实际上上传规则可以完全自定义，按表格形式的jsa代码来实现即可。

添加数据前也是需要登录验证的，而且这里只给admin用户可以上传，其他人登录上传数据也会失败

前面表格重新拉取数据，就可以看到刚才新增的数据了

4 删除指定数据

同样，删除数据这里只给了admin权限，当然实际操作中你可以自由控制什么人可以删除，也可以单独设立一个只有删除行权限的账户，随意控制

删除完毕

再拉取数据 前面的1-6就没有了

4 恢复数据

比如在线数据我们经常会备份，万一数据出了严重错误，那随时都可以恢复，这里就给了一个恢复数据的功能，同样是管理员权限登录后就可以一键恢复

比如我刚才的教学演示过程，数据增删查改都乱了，要重新演示，只需要点击这个恢复数据，就会恢复如初！

好了WPS无数据库在线联网表格系统演示完毕，本案例会在郑广学WPS-JSA火箭速成班第13章里完整讲解所有代码

郑广学WPS-JSA火箭速成班 课程介绍https://vbayyds.com/api/jsa880/index.html免费学习 https://www.bilibili.com/video/BV1kQ4y1H7o5

课程咨询请加微信EXCEL880B

浏览器搜索 郑广学JSA

5 个免费的在线 SQL 数据库环境，比Navicat 香

来源：blog.csdn.net/horses/article/details/108603935

作者：不剪发的Tony老师

文章目录

• • SQL Fiddle
  • DB Fiddle
  • db<>fiddle
  • SQL Online
  • Oracle Live SQL
  • 总结

今天给大家分享几个在线的免费 SQL 运行环境，也就是在线数据库。这些网站可以帮助我们快速运行一些 SQL 语句的测试或者验证，同时还可以在网络上进行分享，关键不需要自己安装数据库。

在线 SQL 数据库支持数据库是否需要注册备注SQL FiddleMySQL 5.6、Oracle 11g R2、PostgreSQL 9.6、SQLite 3.32.1 以及 SQL Server 2017不需要数据库不是最新版本DB FiddleMySQL 5.5 – MySQL 8.0、PostgreSQL 9.4 – PostgreSQL 13 以及 SQLite 3.30不需要支持团队协作db<>fiddleMySQL 5.5 – MySQL 8.0、MariaDB 10.3 – MariaDB 10.5、 Oracle 11g R2、Oracle 18c、PostgreSQL 9.5 – PostgreSQL 13、 DB2 11.1、Firebird 3.0、SQLite 3.27 以及 SQL Server 2014 – SQL Server 2019不需要支持产品最全，支持比较功能SQL OnlineSQLite 3.30、MariaDB 10.4、PostgreSQL 12.4 以及 SQL Server 2019不需要共享功能需要注册Oracle Live SQLOracle 19c免费注册学习 Oracle 首选

SQL Fiddle

SQL Fiddle 提供了 MySQL、Oracle、PostgreSQL、SQLite 以及 SQL Server 数据库环境，使用时无需注册。

其中，左侧文本框用于输入初始化语句创建表结构和数据，点击“Build Schema”运行；也可以通过“Text to DDL”将格式化文本转换为 DDL 语句。右侧文本框用于输入 SQL 语句，点击“Run SQL▶️”执行，执行结果显示在页面下方；“Run SQL▶️”可以选择输出结果的格式，包括表格、普通文本 以及 Markdown 三种格式。

另外，复制网页地址可以分享本次测试的数据和结果，以上截图的地址为：http://sqlfiddle.com/#!9/a6c585/1。

DB Fiddle

DB Fiddle 提供了 MySQL、PostgreSQL 以及 SQLite 数据库的最新版本，使用时无需注册，同时也提供了付费版本。

其中，最左侧文本框可以输入本次测试的标题和描述。中间文本框用于输入初始化语句，点击“▶️Run”运行；也可以通过“Text to DDL”将格式化文本转换为 DDL 语句。最右侧文本框用于输入 SQL 查询，点击“▶️Run”执行，执行结果显示在页面下方。点击“Copy as Markdown”可以将输出结果以 Markdown 格式进行复制。

点击“Save”或者“Update”可以保存并生成唯一 URL，以上截图的地址为： https://www.db-fiddle.com/f/83V6zUSzX42ZpzrbX1txd7/1。

DB Fiddle 另一个亮点是可以多人在线协作，点击“Collaborate”生成一个邀请链接，其他人点击即可加入协作，同时支持语音和文字聊天。

db<>fiddle

db<>fiddle 提供了 MySQL、MariaDB、Oracle、PostgreSQL、DB2、Firebird、SQLite 以及 SQL Server 数据库的各种版本，使用时无需注册。

这个网站应该是目前支持数据库种类最多的在线环境，而且每种数据库还提供了不同的版本。如果你点击“compare”，可以同时在两个不同的数据库中运行测试，比较它们的结果。

一旦点击“run”按钮之后，就可以生成一个唯一 URL。以上截图的地址为： https://dbfiddle.uk/?rdbms=sqlserver_2019l&fiddle=9bcd60e2bcd7966fc3be475addab8eb2。

SQL Online

SQL Online 提供了 MariaDB、PostgreSQL、SQLite 以及 SQL Server 数据库环境，Oracle 数据库正在计划中。

其中，“File”按钮提供了本地保存和打开功能；“Owner DB”可以连接到指定的远程数据库；“▶️Run”用于执行 SQL 语句；“Export”用于导出查询结果和 DDL 语句，支持 CSV、XML 以及 JSON 格式；“Import”用于从本地文件导入 DDL 和数据。页面右上角的“⚙️”可以用于设置界面风格。

另外，“Share”用于生成共享链接，需要注册一个免费账号才能使用。以上截图的地址为： https://sqliteonline.com/#fiddle=b10c1ad462ac37386ac200341b7bd05758a7059321bd675ecb6c2ed7aa563f38。

团队协作功能“Team”需要付费才能使用。

Oracle Live SQL

Oracle Live SQL 是 Oracle 官方提供的在线 SQL 学习和分享环境，需要注册一个免费账号。

其中，SQL Worksheet 是输入和运行 SQL 语句的工作区，支持脚本的在线保存（私有脚本和共享脚本）和离线保存功能以及结果导出功能；My Session 提供了历史会话管理功能；Schema 提供了模式对象的查看功能，包括系统提供的模式，例如 HR、OE 等；Quick SQL 可以通过格式化文本快速创建 SQL 语句；My Scripts 保存了历史脚本；My Tutorials 是自定义的教程；Code Library 是其他人共享的教程和脚本库，可以点击运行或者下载使用。

总结

在线数据库环境可以方便运行一些 SQL 测试和验证，同时可以在网络上分享和讨论。除了以上介绍的在线环境之外，还有一些 SQL 在线教程网站也提供了配套的运行环境，例如 SQL 学习网、XUESQL、SQLZoo、力扣、w3schools。

字节跳动数据库的过去、现状与未来

日前，字节跳动技术社区 ByteTech 举办的第四期字节跳动技术沙龙圆满落幕，本期沙龙以《字节云数据库架构设计与实战》为主题。在沙龙中，字节跳动基础架构数据库资深工程师张雷，跟大家分享了《字节跳动数据库的过去、现状与未来》，本文根据分享整理而成。

数据库技术一直是信息技术中极其重要的一环，在步入云原生时代后，云基础设施和数据库进一步整合，弥补了传统数据库的痛点，带来了高可扩展性、全面自动化、快速部署、节约成本、管理便捷等优势。

从 2018 到 2021 年，伴随业务和数据的迅猛增长，字节跳动的分布式数据库系统取得了令人振奋的发展。如下图所示，在这 4 年间，公司应用侧容器数量从 5 万个增长到了 750 万个，截至目前已经突破 1000 万。这 1000 万个容器筑成了字节跳动坚实的云原生基础设施，支撑着整个业务体系的发展。

从在线数据角度看，1000 万个容器构成了超过 10 万个微服务，这些微服务在线上运行期间会产生大量数据。在 2020 年，字节跳动的在线数据量级达到 EB 级；到 2021 年 5 月份，字节跳动数据库团队已支撑超过 10 EB 的存储规模。

面对如此庞大的应用规模和数据规模，如何在数据库领域进行数据管理和数据治理，成了摆在数据库团队面前的巨大难题。而在字节跳动内部，数据库建设主要面临三大挑战：

业务种类繁多。以抖音为例，为了管理用户之间复杂的社交关系，同时根据用户点赞、关注等行为进行智能推荐，我们需要用图进行管理。再如抖音电商商城设计订单、库存等数据，这些信息适合用关系型结构化的结构表达。除此之外抖音还存在大量结构化和非结构化数据，如用户上传的图片、视频，这些信息适合用云存储、对象存储这样的系统来管理。

业务增速快，诉求不断变化。如上图所示，近 3 年内，字节跳动的数据量迎来了近 100 倍的增长，业务对数据的诉求也产生了一些变化。一开始客户只需要几 TB 或几十 GB 的数据，到一年两年后，他们就要求基础架构能应对数十 TB 甚至数百 TB 的数据量级。如何快速满足应用侧的数据容量需求、吞吐需求变化，是我们遇到的第二个挑战。

数据存量太多，成本居高不下。随着业务的快速发展，如何管理庞大的结构化和非结构化数据，并有效应对高昂的成本，对我们而言也十分具有挑战性。

字节跳动数据库经历了以下三个阶段：

2015 – 2017 年：刀耕火种的石器时代。在这一阶段，字节跳动的业务量级比较小，主要的 App 是今日头条，因此数据库的实例大概在 1~2k 量级，产品主要以开源的 MySQL 和 MyRocks 为主，运维体系主要是依靠人工和脚本。

2018 – 2021 年：标准化、系统化。随着抖音的快速发展，字节的业务规模也迎来快速增长，达到数千套库和数万个数据库实例，原有产品体系已难以解决用户需求，因此我们引入了类似 MongoDB 等开源方案。此外，我们也从 2019 年开始研发云原生分布式数据库产品 veDB 。我们还更新了运维体系，由原来半自动化半人工的状态逐渐走向平台化，大大提升运营效率。

2021 年底至今：融合智能化。当前，字节跳动内部已经开始研发数据库的第三代产品技术体系。在未来几年内，我们预计公司业务规模会上升到数万套库、数十万数据库实例，因此在原有产品体系基础上，我们引入了 HTAP、Serverless DB、MemDB 等产品和技术，在运维体系上，也引入 AI 技术，使得运维更加智能化。

第一代数据库系统架构主要分三层，示意图如下：

• Application 层：前文提到的 1000 万个容器及其构成的 10 万个微服务都部署在应用层；
• Proxy 层：代理层主要负责数据库的一些接入工作，比如鉴权、流量染色、流量分发等；
• Database 层：这一层部署着数据库的一些实例，通过数据库的 Binlog 实现数据的同步、高可用。

整体来讲，第一代数据库系统架构以开源 MySQL 为主，通过分库分表中间件为用户提供较好的服务，以人工为主、脚本为辅进行运维。它主要存在以下三个问题：

• 系统弹性较差。首先是容量难以得到灵活扩展，抖音这类 App 通常都由数万个微服务构成，当微服务的数据量从早期的数十 GB 发展到之后的数十 TB，我们不得不需要花费大量时间拆解原先的库；其次，吞吐量弹性不如人意，互联网行业经常会有春晚、电商促销等活动，我们需要提前进行扩容以应对流量洪峰，活动过后，数据库难以立即收缩，也需要团队花费时间搬迁大量数据；
• 研发效率问题。在用户侧，从申请数据库到数据库上线，期间会经过漫长的讨论谈判，因此如何提高数据库的研发效率也是我们着重考虑的问题。此外，运维效率也有待提升——大量的拆库和合并工作会为研发带来不小的负担；
• 综合成本偏高。第一代数据库系统架构为了 reserve CPU 和存储资源以应对流量洪峰和业务增长，早期 CPU 使用率十分低下，比如 MySQL 数据库的 CPU 使用率通常只有 10%，有些节点甚至长期在 5% 以下；存储空间也非常浪费，整个空间的利用率只有 20%-30%。

为了解决这三个问题，数据库团队开发了第二代数据库，围绕标准化和系统化构建了庞大的产品矩阵和运维平台。

如上图所示，当前字节跳动数据库体系呈现产品多样化、产品智能化两个特征，其中矩阵底层的 Inf-Brain 是数据库管理大脑，主要承担流量预测、熔断预测、智能参数调优等能力。上层各模块则是各细分产品，比如智能运维、分布式中间件、分布式缓存、KV、图等，也有云数据库方向的 veDB、HTAP 相关的一些技术。

veDB 自身即一个较大的产品矩阵。它除了提供 MySQL、PG、MongoDB，也在字节跳动内部研发扩展了 Elastic Search 服务，包括自研的、用于处理 TP/AP 相关事务的产品 HTAP。数据库团队在设计上采用了分层式架构，由高性能网络连接上层的数据库和底层的分布式存储引擎平台。

整个 veDB 的架构遵循的基本哲学是分离。

首先是计算和存储的分离。如下图所示，veDB 分为计算层和存储层，其中计算层又被拆分出负责数据库流量调度、接入、鉴权的代理层以及数据库计算层。计算层中是数据库的一些运行实例，它兼容 MySQL、PG 和 MongoDB 等数据库引擎，是无状态的，可以动态地在数据中心里做分布和调度。最下方是存储层，我们把数据库日志、数据库 Page 和对应的处理逻辑都卸载到里面，它支持 HDD、SSD、PM。

其次是日志和数据的分离。我们把数据库的 Wal 和 Page 放到不同介质里，来实现成本和性能之间的平衡。

第三是读写分离。我们最大可以支持一组 15 从的配比，当读流量比较大时，用户可以通过弹性扩充应对读的负载，这在字节跳动内部已经被大规模应用了。

基于以上设计，veDB 呈现 6 大特点：

• 灵活性强：veDB 基于 shared-storage 架构，实现了计算存储分离，业务方可以按需弹性使用存储容量，解决了存储成本比较高的问题；
• 兼容性好：目前 veDB 基本上已做到 100% 兼容 MySQL 8.0 和 PostgreSQL 12，现已兼容 MongoDB 4.0；
• 高可用性：存储层多副本，支持单 AZ/跨 3 AZ 强一致部署，既保持了灵活性，又解决了传统通过 Binlog 跨多数据中心异步复制带来的 RPO 无法等于 0 的问题；
• 高性能：数据库团队做了大量优化工作，使 veDB 在高并发集群模式下的吞吐量 QPS 远超传统单机数据库；
• 成本低：按需独立扩缩计算/存储，存储层高压缩比，把存储空间利用率从第一代系统的 20%-30% 提升到了现在的 70%；
• 超大容量：单表 64 TB，并支持 PB-level 解决方案。

在业务实践层面，数据库团队主要面对以下三种类型。

第一类是容量型实例，比如电商某些订单虽然吞吐量不大，但数据量特别大，远超以往 2T-3T 的单机容量。基于第二代数据库系统，在计算存储分级之后，存储层可以无限扩容，使得用户无需担心数据库，只需聚焦业务开发。

第二类是 QPS 型实例。2021 年春晚，数据库团队支持了某中台的推送业务，目标用户量（设备）高达 10 亿级。最终我们的峰值吞吐量超过了 600 万 QPS，整体数据量也超过了 20TB。活动结束后，因为计算节点都是无状态的，且数据都放在共享存储层，我们轻松完成了节点下线，帮助公司节省了大量计算资源。

第三类是小型实例。字节跳动大部分线上实例都是小型实例，QPS 比较低，数据量也在 GB 级别，这类型的实例可以通过虚拟化、混部、容器等技术降低计算成本。在数据量层面，它们也可以通过共享存储空间降低整体存储成本。

伴随业务的发展，我们预计在 2022 年以后，字节跳动的数据库规模会达到数万套库、数十万实例。如何更好地支持业务的发展，如何建立管理这数万套库的实力，成了我们下一代技术重点关注的话题——如前所述，在产品方面，数据库团队会持续推出更多产品和引入新技术，使得产品在种类和协议上能出现一定的融合；在运维方面，团队也会引入 AI 技术解决着力解决当前的痛点。

在谈及未来之前，首先我们可以回顾两个问题：

• 数据库服务产品解决的问题是什么？
• 数据库服务产品面临的新环境是什么？

对于问题一，在 2018 年，数据库团队面临的问题是业务需要多种类型的数据，但当时的产品无法提供相应支持；发展至今，现在字节跳动已拥有日渐丰富的数据库产品矩阵，我们的新挑战变成了如何帮助用户选择合适的数据库。

对于问题二，早期因为数据规模不大，数据库团队关注的是怎么保留一些存储、计算资源用于构建运营环境的运维体系；现在我们已经拥有百万级服务器规模，如何利用这些资源、在云环境下构建数据库产品的服务成了我们的新探索方向。

如果我们回顾数据库技术领域的整体发展情况，不难发现这样的发展规律。

自 1980s DBMS 出现以来，IBM 等商业化公司在早期纷纷推出 OLTP 型数据库，这一时期数据库的典型特征是为了解决应用程序开发过程中管理数据的复杂性问题。随着时间的推移，1990s 企业开始出现大量数据分析型需求，比如银行报表，这催生了一个新的分支 OLAP。

到 21 世纪初，互联网行业迎来大规模爆发，OLTP 开始无法满足企业对于在线数据的一些管理诉求，OLAP 也难以管理离线分析、作业处理系统上的数据，加之商业化数据库和存储带来的巨大成本使企业难以承受，以 NoSQL 和 BigData 为代表的数据库革命正式爆发，无论是 Google 开源的 HDFS、Bigtable，还是 HBase、MongoDB，它们都旨在解决 OLTP 型数据库吞吐量、扩展性不足的问题。

到 2010 年，Google 开始大量使用 NoSQL 和 BigData 数据库系统，但很快它就发现了不少问题，比如 NoSQL 不支持事务且每个产品的 NoSQL 接口都不一样，这给应用程序迁移和学习带来了极大的成本，为此它又开发了 NewSQL 这一新分支。

整体来看，数据库在短短二三十年演进过程出现了大量分支，技术和产品也越来越复杂。到今天，大家又觉得这些东西太复杂，开始着手去做简化，比如 2015 年左右，AWS 结合 OLTP 和云原生发布了分布式数据库 Aurora，结合 OLAP 与云原生发布 Redshift，包括 BigData 也正与数据湖概念结合，衍生出一些新形态。

除此之外，近几年行业又开始流行 HTAP，把云、OLAP、BigData 做有机结合，使数据库既能处理复杂的 query，又能支持在线业务诉求。那么这样的三合一是不是未来的发展趋势呢？我们不知道。

数据库领域的技术和产品经历了从简单到复杂再到简单的过程，但如果审视做数据管理的真实初衷，恐怕大家的目标都是为了方便用户——而各种复杂分支恰恰让用户更难做技术选型。

我们能不能不要选择性地去解决一部分问题，而是构建一个大而全的系统去解决问题？我们能否为用户提供统一的数据管理服务？即使现在做不到，那我们能不能提供尽量少的数据管理服务，去简化研发人员的研发成本，包括用户的使用成本和学习成本？

基于以上思考，字节跳动数据库团队产生了两个重要的观察思考：

• 应用场景方面的融合：提升用户效率，降低用户的接入和使用成本；
• 基础设施层面的分离和整合：提升系统层面的效率，降低系统层面的成本，可以为用户让利。

首先是横向融合探索，简化业务应用数据管理体系。举个例子，过去构建一个微服务，数据层既要考虑在线数据，也会考虑离线数据，不可避免会涉及多种数据库及每种数据库下不同的表的管理，导致在线应用的复杂度较高。同时从在线数据生成到离线分析，数据的可见性通常会以天、小时、分钟级别计数。在数据 ETL 过程中，数据的 integrity 如何去保证，这也是一个非常大的挑战。

字节跳动数据库团队一直在尝试通过技术上的融合简化在线应用的数据管理，例如 veDB 正在探索把 MySQL、ES Protocols 的协议集成到数据库里，支持事务处理、分析查询、搜索等融合任务，使应用侧只需关注数据本身，无需关注数据和维护多种数据库。在事务处理层面，veDB 已经能做到数据可见性秒级，并且强一致，支持 snapshot 隔离级别。通过存储层的技术整合，veDB 也大幅优化了数据的存储成本，显著降低了数据冗余系数。

其次是纵向融合探索，重塑应用缓存和数据库边界。单体和微服务时代，用户在使用数据库时，需要在前面挂一个 Redis，因为数据库的吞吐量通常不能够做得很大，容易被过高的 QPS 打挂。当企业架构从单体时代发展到在线微服务时代，这种做法会带来大量缓存系统和数据库类型的复杂管理难题，因此我们希望通过一套系统重塑应用缓存和数据库，为用户带来便捷。比如我们正在 veDB 中做一些软件和技术硬件层面的探索，尽可能减少用户的数据管理成本和学习成本，同时消除用户 multi-tiering 数据流动管理，让用户聚焦业务逻辑，也帮助他们消除了原先数据与缓存不一致性等业界难题。

第三是分离和整合：新的变量、硬件和系统。除了用户层面一些应用场景的融合，我们也在公司基础架构体系内部看到了一些分离和整合的内容，比如软件、硬件和操作系统。下图左侧是数据库模块，从上到下分别是 SQL 层、事务层、缓存层和存储层；右侧则是云数据中心里应用的运行时环境，比如公司大部分微服务都跑在 K8s 上，硬件层面的新算力、新互联、新存储都在与时俱进地发生变化。

以算力为例，从只有 CPU 到发展到 CPU+GPU+DPU+FPGA，数据库团队一直在尝试把压缩、加密解密等复杂的、需要消耗算力的作业放到 FPGA 里去。当公司 CPU 算力从 96c 发展到 192c 甚至超过 300c，如何重塑数据库里的索引、事务处理也是我们要提前思考的问题。

第四是分离与整合：当前云数据中心的 building blocks。

总的来讲，数据库也是一种软件，当前我们能不能利用云中心里的硬件和运行时环境使数据库变得更强大、更弹性，也是一个重要方向。

数据库团队在软件、系统层面做了非常多的工作，比如把数据库 Severless 化，把数据库里的状态放到分布式的 Persistent Memory 构建的高性能存储引擎里，在存储层实现自动分层分级。通过这样，我们可以把计算层做得更加弹性。

以下图为例，有三个租户，其中租户 A 需要一些 MySQL 和 PG。我们可以把这些租户的数据库实例运行在容器中，动态地做计算资源调配，根据业务的高峰期和低谷期提供不同大小的数据库实例来实现弹性。在这种大一统运营模式之下，我们就可以摆脱以往独立物理机数量不足的窘境，利用公司百万级服务器实现算力复用。

未来，数据库团队会围绕应用场景层面的融合、纵向的技术整合以及硬件和系统的整合，重新构建云数据库，使它能够回归用户价值，帮助用户提升开发效率、运行效率和运营效率，降低学习和使用等各类成本。

Database & Cloud Storage Team，服务于字节跳动全系产品。在这里，我们有丰富的云存储产品，负责治理数十 EB 级别的海量数据；有多种数据库产品，提供极致时延、超大吞吐的云原生数据库服务；有前沿的技术研究，探索新硬件与新软件架构的融合，打造下一代革命性的云存储与数据库产品。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com