巨杉数据库

在喜迎双11剁手之际，杉杉也有个好消息想超大声地告诉你！随着社区用户的规模和范围日益扩大，社区用户测试的场景越来越多样，巨杉技术社区在积极为大家提供线下沙龙技术分享和线上服务支持的同时，希望能够通过一套官方的线上技术培训课程，打破时间和地域的限制，让更多的社区伙伴认识和理解 SequoiaDB 的原理架构，熟练掌握部署、使用、运维和调优等实操技能。因此，我们启动了 SequoiaDB University 计划，并在紧张的筹备后，于今天正式上线。 SequoiaDB University 目标围绕 SequoiaDB 巨杉数据库产品，提供核心研发级别的数据库深度培训支持培养熟悉分布式架构和数据库技术的一流人才，提升社区用户自主解决问帮助数据库从业人员拓展前沿技术视野，了解企业转型需求，不断提升个人在行业内的竞争力助力技术服务商获取用户对数据库的新需求，在开发项目和业务拓展方面更具技术优势 关于培训课程培训讲师团队强大：SequoiaDB University 的培训课程讲师团队由 SequoiaDB 官方的数据库架构师、核心研发工程师、资深分布式技术专家以及开源社区技术大咖共同组成，拥有专业且丰富的 SequoiaDB 实践及理论经验；培训课程原理实操并重：帮助学员深度理解 SequoiaDB 产品架构和原理，同时掌握运维和开发的实践能力，提升个人技术能力；课程持续更新，由浅入深：满足不同学习目标的学员，共分为三类： 初级入门课程，面向需要了解SequoiaDB基本原理和架构，以及需要掌握SequoiaDB日常运维能力的初级DBA学员高级进阶课程，面向需要掌握 SequoiaDB 高级原理，性能调优和实例开发等的高级DBA学员深度开发课程，面向使用SequoiaDB 开发应用程序的软件开发工程师具体课程目录如下：部分技术培训课程 关于认证考试 SequoiaDB University还推出了对应技术培训课程的专业认证体系。SequoiaDB University 的专业认证认可开发人员和DBA具有构建和维护 SequoiaDB 分布式数据库所需的知识和技能，并由 SequoiaDB 巨杉数据库作为唯一权威机构对考试通过学员颁发相应的认证证书。 目前共提供三类专业认证，分别是：SCDA，SCDP 和 SCDD。 SCDA(SequoiaDB Certified Database Associate) SequoiaDB 认证数据库助理 该认证对应SequoiaDB初级入门培训课程，SCDA认证要求学员熟练掌握SequoiaDB 架构原理、 安装部署、实例使用、日常管理和运维等内容。通过此考试后，学员可以选择继续参加 SCDP 和 SCDD 等进阶学习和认证考试。 SCDP(SequoiaDB Certified Database Professional) SequoiaDB 认证数据库专家 该认证对应 SequoiaDB 高级进阶培训课程，SCDP认证要求学员首先获得SCDA认证，并熟练掌握SequoiaDB 高级原理、大型集群管理、跨机房容灾、性能调优、高级问题诊断等内容。 SCDD(SequoiaDB Certified Database Developer) SequoiaDB 认证数据库开发者 该认证对应SequoiaDB深度开发培训课程，SCDD认证要求学员首先获得SCDA认证，对 SequoiaDB 基础知识有深刻理解并熟练掌握SQL开发、JSON开发和对象存储开发等内容。目前，初级入门培训课程和其对应的 SCDA 认证考试均已正式开放学习和注册，欢迎进入 SequoiaDB University 官网 （详情请点击这里）开始学习。 ...

近日，巨杉数据库与深度操作系统完成互认证工作，建立全面技术合作，共同推进国内基础软件生态的建设。 经双方共同严格测试，SequoiaDB 巨杉数据库与深度操作系统ARM服务器版软件V15共同稳定运行，安全可靠，性能卓越，相互兼容，可为企业级应用提供全面保障。 SequoiaDB 巨杉数据库是一款完全自研的，金融级分布式关系型数据库，其自研的原生分布式存储引擎支持完整 ACID，具备弹性扩展、高并发和高可用特性，支持 MySQL, PostgreSQL 和 SparkSQL 等多种 SQL 访问形式。SequoiaDB 适用于核心交易、数据中台、内容管理等应用场景。 深度操作系统ARM服务器软件V15，是深度科技发行的企业级 Linux 服务器操作系统软件，为数据库和应用中间件提供完整的运行支撑环境，支持大数据和虚拟化组件，支持企业级的应用软件和开发环境，集成丰富高效的管理工具，体现了当今 Linux 服务器操作系统发展的最新水平。 本次巨杉数据库与深度操作系统的产品兼容互认证，是自研数据库和操作系统的强强联合，代表国内基础软件生态圈的进一步扩大。 未来，巨杉数据库会继续坚持核心技术自研，保持产品技术创新，同时联合国内优质软件厂商，共同打造更加稳定、可靠和高性能的数据管理解决方案，携手促进国产基础软件生态建设发展！

SequoiaDB 会话（session）简介会话（Session）的基本概念容易弄混淆的两个概念是会话与连接。通俗来讲，会话(Session) 是通信双方从开始通信到通信结束期间的一个上下文(Context)。这个上下 文是一段位于服务器端的内存:记录了本次连接的客户端机器、通过哪个应用程序、哪个用户登录等信息。而连接(Connection):连接是从客户端到数据库实例的一条物理路径。连接可以在网络上建立，或者在本机通过IPC机制建立。通常会在客户 端进程与一个专用服务器或一个调度器之间建立连接。SequoiaDB 中的会话设计SequoiaDB 中的会话有很多种，不同的会话对应不同的服务。会话的主要任务是处理通信的对端发过来的请求。各种类型的会话能处理的请求不一样。通信平面为了提供不同类型的服务，并使各服务之间隔离，SequoiaDB 的节点提供了多个通信平面。简单来讲，一个通信平面对应一个服务端口，不同 的端口提供不同类型的服务，这也就是在安装 SequoiaDB 时，要求一定范围内的端口号预留的原因。SequoiaDB 中当前提供了如下几个通信平面:• local 平面(local service): 使用基础服务端口号 svcname• repl 平面(repl service):使用端口号 svcname + 1• shard 平面(shard service):使用端口号 svcname + 2• cat 平面(cat service):使用端口号 svcname + 3• rest 平面(rest service):使用端口号 svcname + 4• om 平面(om service):使用端口号 svcname + 5不同的节点上开启的服务平面不一样。节点上通过不同平面提供不同的服务，就像同一间屋子开了几个门，被访问的数据就如同屋子里面的东 西，是大家所共享的。每一个平面都可能有一个或多个用户来进行访问，因此，在系统内部要做好它们的并发控制。本地会话(Local Session)本地会话是在直连节点(即配置的 svcname)时创建。这里的直连含义比较宽泛，连接任意节点的本地服务端口即是直连，无论是单机，还是 集群中的任意节点。客户端连接到协调节点时，协调节点上也是创建的本地会话。 本地端口上的监听接收到新的连接请求时，会创建一个新的 会话(内存结构)及一个服务线程(执行单元)，将它们绑定(attach)起来。后续客户端直接与这个新的服务线程进行交互。代码导读 SequoiaDB 中各类型的会话继承关系如下图所示。从图中可以看到，本地会话、增量/全量同步会话、复制会话等，都是继承自同一个基类 _ISession。下面结合组网对其中几个关键的会话进行介绍，主要是会话建立/销毁的时机、会话的结构、操作等。 本地会话对应数据结构是类 _pmdLocalSession，线程的主函数是 _pmdLocalSession::run()，会话线程启动后，就在这个函数里循环， 接收及处理消息，直到会话需要结束时退出该循环。 本地会话能绑定不同的 processor，以执行不同的处理流程。对于协调节点，绑定的是 _pmdCoordProcessor，对于编目节点和数据节点，绑定的是 _pmdDataProcessor。对于协调节点，会先调用 _pmdCoordProcessor 的接口进行消息处理，在无法识别请求类型时，则会再次调用 _pmdDataProcessor 的接口进行处理。分区会话(Shard Session)分区会话存在于编目节点与数据节点上，因为是在这两种节点上真正分布式存储数据，真正与分片这个概念相关。协调节点上不存储数据，不 涉及到分片，因此它上面没有分片会话。在代码实现上，分片会话的管理整合到了 clsCB 中(它还管理着复制会话)。当通过 shard 平面连接到节点时，在节点上就会创建一个分区会话。 shard 平面与本地平面存在一些差异:shard 平面看不到节点上的系统集合空间，本地平面可以
通过 shard 平面进行的操作会写复制日志，通过本地平面的不会(这也就是为什么直连数据节点下进行数据操作会造成主备数据不一致 的原因，如果是通过 shard 平面连接数据节点操作，则数据变更会被同步到备节点上)分区会话是继承自统一的异步会话框架，包含一个分区会话管理器，由它来负责分区会话的创建等工作。会话的主要工作则是在被创建后，处 理客户的请求。关于异步会话的机制，详见相关的介绍。当协调节点通过 shard 平面连接到数据节点时，新创建的会话接收到的第一个消息是 init session(在 3.0 后的版本中是 package 消息，它将 init session 及部分其它消息打包到一个消息包中)。代码导读 分区会话管理器类是 _clsShardSessionMgr，分区会话类是 _clsShdSession 通过异步会话管理器( _clsShardSessionMgr 的父类) 的 getSession() 接口来获取已有 session，或者创建一个新的异步会话 _clsShdSession 的主消息处理入口是 _clsShdSession::_onOPMsg，它根据消息码，调用对应的消息处理函数，并发送应答消息同步(或复制)会话(Repl Session)分区组内的节点间，通过同步动作来保证数据的一致性，分为正常运行状态下的增量同步，和异常情况下的全量同步。同步也是通过对应的同 步会话与同步线程来处理的。由于同步涉及到两个节点，数据生产方称为源端，数据消费方称为目标端。由于只有数据节点与编目节点上会进 行数据复制，因此只有在这两种类型的节点上，才会存在同步会话。1）增量同步会话增量同步会话在复制组正常运行期间存在，分为增量同步源端会话和目标端会话。在数据/编目节点的启动过程中，就会开启增量同步的监听， 而无论其是主节点还是从节点。同时，它也会主动启动一个增量复制目标端会话，并向它选定的源端发送同步请求。源端节点上会被动创建一 个增量同步源端会话。然后，这两个会话开始进行交互，完成数据同步。详见 增量同步 相关章节。2）全量同步会话全量同步会话是进行全量同步时存在，在集群正常运行期间及全量同步完成后不存在，也分为源端和目标端。需要全量同步的场景有三种:• 节点的重放速度跟不上主节点，主节点上复制日志绕接，导致备节点还未获取到的复制日志被覆盖，备节点无法继续增量同步。• 节点异常重启，启动后根据读取到的异常启动状态决定全量同步。• 节点正常停止后正常重启，但停的时间较长，期间其它节点上的日志已经发生了绕接。无论是上述哪种情况，都是先有增量复制会话，然后由于这些原因导致增量同步无法继续进行的时候，就会在目标节点上主动创建一个全量同 步会话(以及对应的线程)，且当前的增量复制线程退出。全量同步会话一旦启动之后，就会向源端发送一个全量同步开始的消息。此时源端 上会被动创建一个全量同步源端会话。至此，全量同步的会话创建完成，然后，这两个会话之间开始进行交互，完成数据同步。详见 全量同步 相关章节。代码导读 同步相关的会话，都是异步会话，这四种会话，使用同一个会话管理器来进行管理:_clsReplSessionMgr 四种会话对应的类为:_clsReplSrcSession，_clsReplDstSession，_clsFSSrcSession，_clsFSDstSession 异步会话响应的消息类型及对应的处理函数，一般在对应的类中通过 OBJ_MSG_MAP 等宏进行定义，请参考代码。会话的查看可通过 snapshot 查看会话快照，可查看当前会话或系统中的所有会话。这个命令实现的其实是与线程对应，可返回所有线程的信息，包括系 统后台线程。查询会话的详细结果见相关文档。代码导读session 的导出动作在类 _monSessionFetcher 类中实现，在其 init() 函数中准备好数据。可选择查看当前会话(使用当前线程的 eduCB 接口 导出)或所有会话(使用 _pmdEDUMgr 的接口导出)。 在准备好数据后，由上层统一的 context 框架调用该类的 fetch 接口获取数据。SequoiaDB简介：SequoiaDB 巨杉数据库是一款金融级分布式关系型数据库， 其自研的原生分布式存储引擎支持完整 ACID，具备弹性扩展、高并发和高可用特性，支持 MySQL、PostgreSQL 和 SparkSQL 等多种 SQL 访问形式，适用于核心交易、数据中台、内容管理等应用场景。标准SQL支持，MySQL协议级兼容SequoiaDB目前支持 MySQL、PostgreSQL 和 SparkSQL 等多种 SQL 访问形式。SequoiaDB还提供了类S3对象访问以及Posix文件系统接口、MongoDB兼容的原生JSON引擎以及深度数据压缩等多项全新功能。金融级分布式OLTPSequoiaDB使用其自研的开源数据库存储引擎，全面支持ACID（原子性、一致性、隔离性与持久性）、分布式跨表跨节点事务能力、可配置强一致与最终一致性保证、同时在优化器端支持CBO（Cost-Based Optimization）、多维度数据分区、以及HTAP等多种技术特性。分布式架构SequoiaDB数据存储引擎采用原生分布式架构，数据完全打散在分布式节点间存储，自动化数据分布和管理，数据可以按需灵活扩展，目前生产环境实测支持超过1000个节点集群。Multi-Model多模数据引擎SequoiaDB灵活的数据存储类型，支持非结构化、结构化和半结构化数据全覆盖，实现多模（Multi-Model）数据统一管理，更符合云化数据架构下对于多样化业务数据的统一管理和运维要求。HTAP混合事务/分析处理SequoiaDB通过SQL的完全支持以及Spark的整合，实现HTAP混合事务和分析处理，快速实现业务应用的弹性开发，应对更多复杂应用场景。同时，通过分布式数据库多副本机制，将在线交易和离线分析业务物理隔离，实现同一组数据在应对不同类型业务时互不干扰。数据安全与多活容灾SequoiaDB巨杉数据库原生支持数据库内核级别的高可用以及跨数据中心灾备能力，目前已经实现异地容灾备份，可满足“三地五中心”的容灾支持。同时，巨杉数据库在异地容灾基础上，实现了数据异地多活，目前已经实现双中心同时读写，中心切换RPO为0和RTO达到秒级，提供了“超金融级”的数据安全保障。

使用SequoiaDB的分布式文件系统搭建流媒体服务器介绍如今使用移动互联网的年轻人开始越来越多使用短视频展示自我，而流媒体则是支撑在线视频播放的核心技术。当我们开始构建流媒体站点时，往往面临最大的难题在于大量媒体音视频文件所占用的海量磁盘空间。譬如说，一个标准高清短视频可能需要30-50MB的存储空间，那么存储百万短视频的系统就需要几十TB的存储。而如果我们更进一步需要播放高清电影等视频内容，每个电影需要大概2GB左右的空间，十万部各种电影剧集则需要200TB的存储容量。 为了满足如此海量的音视频文件存储需求，大部分流媒体服务器使用外接NAS甚至分布式文件系统进行PB级海量数据存储。 通过阅读本文，用户可以了解到如何使用SequoiaDB巨杉数据库的分布式文件系统功能，为开源流媒体服务器Emby构建后端可弹性扩展的分布式存储。 Emby是一款被广泛使用的流媒体服务器，允许用户简单一键式部署自己的视频播放系统，将家庭内部或企业存储的图片、音视频文件进行统一管理，并能够在几乎全部设备上在线播放观看。 用户可以在Emby的服务端设置服务器路径指定其所访问的文件系统。一般来说，使用PC机或NAS设备内置的磁盘存储容量有限，因此如果希望将Emby后端的存储使用分布式文件系统替换传统内置盘，可以使用SequoiaDB所提供的分布式文件系统SequoiaFS，提供用户近乎无限可弹性扩展存储容量。安装SequoiaDB本文使用Linux Ubuntu Server 18.10作为服务器，SequoiaDB巨杉数据库版本为3.2。 本教程默认使用sudo用户名密码为“sequoiadb:sequoiadb”，默认home路径为/home/sequoiadb。 对于使用CentOS等其他Linux版本的用户，本文所描述的流程可能略有不同，需要根据实际情况自行调整。 下载SequoiaDB标准虚拟机模板的用户可以直接跳过该安装部署步骤。更多安装细节可以查看SequoiaDB信息中心 1） 下载并安装SequoiaDB巨杉数据库$ wget http://cdn.sequoiadb.com/imag...$ tar -zxvf sequoiadb-3.2-linux_x86_64.tar.gz$ cd sequoiadb-3.2/$ sudo ./setup.sh之后一直回车确认各个默认参数即可。 2） 使用数据库实例用户创建默认实例 # 默认密码使用“sdbadmin”$ su – sdbadmin$ /opt/sequoiadb/tools/deploy/quickDeploy.sh3） 使用root用户创建SequoiaFS文件系统 # 确认fuse内核组件被安装，且版本大于2.9.4。$ which fusermount/bin/fusermount$ fusermount -Vfusermount version: 2.9.8# 创建名为Nas.Storage的集合容器$ /opt/sequoiadb/bin/sdb "db=new Sdb(); db.createCS('Nas'); db.Nas.createCL('Storage');" # 创建mountpoint挂载点目录$ mkdir -p /opt/sequoiadb/mountpoint# 退出sdbadmin用户，回到默认sequoiadb用户$ exit# 密码默认为“sequoiadb”$ sudo ln -s /opt/sequoiadb/bin/sequoiafs /usr/local/bin/sequoiafs# 为fuse内核开启多用户访问权限$ sudo sed -i "s/\#user_allow_other/user_allow_other/g" /etc/fuse.conf# 创建sequoiafs所需的目录与空配置文件$ sudo mkdir -p /opt/sequoiafs/conf/NasStorage/$ sudo mkdir -p /opt/sequoiafs/log/NasStorage/$ sudo touch /opt/sequoiafs/conf/NasStorage/sequoiafs.conf$ sudo chown -R sdbadmin:sdbadmin_group /opt/sequoiafs# 切换回数据库实例用户，密码默认为“sdbadmin”$ su – sdbadmin# 创建sequoiafs文件系统$ sequoiafs /opt/sequoiadb/mountpoint -i localhost:11810 -l Nas.Storage --autocreate -c /opt/sequoiafs/conf/NasStorage/ --diagpath /opt/sequoiafs/log/NasStorage/ -o big_writes -o auto_unmount -o max_write=131072 -o max_read=131072 -o allow_other# 检查文件系统加载正确$ mountsequoiafs on /opt/sequoiadb/mountpoint type fuse.sequoiafs (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001,allow_other,max_read=131072)安装Emby本教程使用Emby版本为4.1.1。 ...

一直以来，数据库的核心研发团队都十分神秘，作为隐藏在幕后的隐士高人，他们对数据库发展以及数据库研发团队的看法是什么呢？本文我们就由巨杉数据库核心技术研发团队的“老司机”，向大家分享他分布式数据库的自研之路。Q：作为数据库行业的“老司机”，您能否先介绍一下自己？A：我叫Danny，是巨杉数据库核心研发团队的成员，是一名数据库资深工程师和架构师，有超过20年的数据库核心研发经验，曾经作为DB2 内核研发团队成员参与了DB2 ，DPF等产品的架构设计和研发工作。目前，我们北美研发实验室的团队已经有很多数据库的专家“老司机”加入，全部来自DB2 的核心技术团队。虽然我们团队很多都是来自IBM、华为的“传统企业级IT人”，不太喜欢抛头露面。但是现在是技术圈一个变革的新时代，我们的产品已经开源了，所以我们之后也会让我们团队的技术大牛们多多参与社区活动，分享一下我们做数据库核心研发的心得，同时也和大家一起进步。Q：作为“老IBM”，您认为像IBM这样历史悠久的IT企业，他们的核心研发团队是怎么样的呢？您对此感受最深的是什么？A：IBM是最早提出“关系型数据库”这一概念和理论体系的公司，从技术上看，传统三大关系型数据库在发展过程中，其实已经具有很深远的技术储备了。DB2是三大传统关系型数据库中唯一的分布式产品，因此我们团队在分布式技术方面的积累是一脉相承的。我在DB2的十几年里，感受最深的就是技术底蕴和沉淀。比如说，在Unix真正支持线程机制之前，针对多线程模型，甚至是针对不同的硬件设备，他们早已使用汇编语言实现了逻辑线程的切换和调用，这些机制在当时其实是相当领先的。说到研发团队，IBM的实验室也是卧虎藏龙。从最初使用汇编语言开始的技术专家们，一直在参与数据库、操作系统和编译器底层的研发工作，可以说正是他们创造了最早的关系型数据库的概念，也是他们真正把数据库打造成为一个通用的软件平台。Q：像数据库这样的基础软件，技术上的难度是什么？A：数据库软件，特别是一款真正企业级ready的产品，并没有大家想象的，只是开发一款软件那么简单。从技术上来说，数据库既需要有技术基因的传承，又需要创新。数据库技术到现在已经发展了40多年了。在技术的发展中，数据库软件/平台已经成为一个功能复杂，架构庞大，安全要求很高的庞大软件产品体系。因此，技术上既需要技术的积累，也需要新的创新。同时，在应用端这边，由于用户都是银行、政府等这些30年前就开始使用数据库的老客户，他们通常无法承担全盘迁移的风险，因此在业务技术架构上，难免保留了各个时代的历史遗留，比如说，北美一些银行的核心IT系统，直到目前仍然运行在40年前的技术平台之上。这也要求企业级ready的数据库基础软件需要有很强的兼容能力，不但可以保证旧业务的运行，还可以不断地推陈出新。这种创新是必须的，但在技术上却又是最难的。Q：以您近20年的数据库行业经验，您认为数据库核心团队应该是怎么样的？A：我认为数据库核心研发团队的基因很重要，就比如说IBM的DB2团队，就是以多位数据库领域的“老炮儿”为核心，搭配有技术实力的资深工程师，而不像现在很多的开源新产品，他们都是以年轻的创新团队为主。就像我上面提到的技术复杂度和产品历史跨度的问题，数据库产品如果要在大型企业内使用，技术团队必须要有传统数据库的开发经验，这也就是技术老炮儿存在的作用。简单说，数据库基础软件就是创新技术和技术经验积累的融合体。Q：海内外基础软件研发有什么不同？A：相对来说，海外拥有技术人才的基础，也有像IBM Oracle这样的体系的沿袭，培养出了一批批技术人才和团队。所以现在北美很多新一代基础软件产品团队其实还是围绕了老一辈的“老司机”构建的。国内基础软件的人才积累还不够，因此基础软件领域还没有完全形成基础软件领域的武林门派，这也是近年来基础软件和AI领域国内企业疯狂往外招人的原因。但是数据库由于历史原因，国内无论是互联网还是科研团队想要形成独特的门派，还需要时间。巨杉这边我们的团队拥有以王涛为代表的很多DB2 团队的核心技术专家，以及来自华为的技术核心团队成员，是技术基因和技术创新很好的结合。Q：数据库开发和其他软件有什么不同？A：因为刚才提到的这些特点，基础软件特别是数据库的研发，和其他应用软件有很大的不同。其中最大的一个不同点就是开发语言和开发模式。从计算机的发展来看，C是最面向机器语言（汇编代码）的，原则上每一行C代码都可以很精准地映射到一些汇编指令上，因此从对操作系统底层的操控来看最为精准。C++则是在C之上发展起来的面向对象语言。在底层编程中，C++的高级特性被使用的非常少，但是其设计模式对于模块化开发很有帮助。因此使用C++既可以兼顾对操作系统底层最精准的把控，也可以将一些面向对象的理念融入代码中，在复杂系统构建时起到重要作用。如今新的一些新型开发语言则不是面向对象，因此在设计模式上不适合大型复杂系统的开发。同时，这些语言语言简化了很多C/C++里最为重要的指针概念，使其对内存的精准操作变得不可能完成。指针这个概念用好了是神器，用差了是垃圾，大部分能力不高的程序员，或者没有非常完善测试框架的项目很难完美把握指针这类高级特性，使得大型项目开发里面内存泄露和崩溃漏洞遍地都是。但是对于我们巨杉来说，有着DB2数据库内核的研发经验，从人员能力，到代码质量管理，到测试框架的完善都能够完美驾驭这类高级特性，最大程度挖掘出操作系统和数据库底层的性能与处理能力。Q：分布式数据库方向是什么？A：根据Gartner和我们CTO王涛的共同观点，真正特别大使得传统关系型数据库存不下的表相对来讲数量都是可控的。因此有很多workaround都可以搞定这个问题，这也是为什么传统以来大家用分库分表虽然麻烦，但也不是解决不了应用问题。数据库其实真正面临的痛点是“微服务”下，数据服务的资源池化。应用程序从传统烟囱式构建，向微服务转型的过程中，在每一个微服务上都放一个独立的数据库已经是不可能的事情了。这种情况下，数据服务资源池需要直接面向上层成百上千个，来自不同开发商、不同团队的，开发能力不一、应用类型不同、SLA安全级别不同等等的各类需求。因此，资源池必须拥有弹性扩张、资源隔离、多租户、可配置一致性、多模式（支持各类SQL协议）、集群内可配置容灾策略等一系列功能，同时每个数据库实例的计算和存储能力需要做到能够无限扩张，毕竟有些微服务可能会涉及到极多的流水数据，不能限定每个数据库实例使用的资源仅局限于一台物理设备。所以说，单纯为了分布式的OLTP只是解决了不构成刚需的问题（分库分表早可以解决），但是在微服务应用开发的环境下，数据库更是要从资源池化的角度对上层提供服务，同时资源池中的每个数据库实例内部也要支持分布式交易等一系列特性，做到与传统数据库的全兼容。Q：SequoiaDB自从发布3.0版本以来，在社区和市场得到的反馈都很好，能否透露一下产品的一些新动向？A：近期，我们会发布一个新的版本，其中OLTP场景选性能会有大的提升，同时对于SQL处理能力也会有很大提升。在分布式的交易型业务下，整体性能提升将比现在版本有23倍的提升,对比同类产品性能将高出56倍以上。这些在本周的活动我们也会做一个简单的分享和介绍。3月30号，本周末我们巨杉Techday的第二期活动也会在北京举办，我们也会带来一些深度的技术分享，届时也会有现场的视频直播，希望大家也能多多关注和参与！未来我们也会有更多“神秘”的数据库“老司机”给大家带来技术、趋势、见闻的分享~