NoSQL应用现状什么是NoSQL？我们知道关系型数据库强调的是CAP理论：Consistency、Availability和PartitionTolerance，这三者不能结合。说到NoSQL，我们会介绍BASE的概念：BasicallyAvailable：分布式系统在发生故障时允许失去部分可用性，以保证核心功能可用。比如在电商场景中，有时交易支付出现问题，但用户仍然可以正常浏览商品。SoftState：由于不需要强一致性，BASE允许系统中有一个不影响系统可用性的中间状态，如订单支付、数据同步等，只有在数据达到最终一致状态后才改为成功.最终一致：指的是经过一段时间后，所有节点的数据都会一致。比如最终支付的状态会变成支付成功或者支付失败；订单状态与实际交易过程一致；但是这个过程有一定的时间延迟。BASE理论是CAP中AP理论的扩展，通过牺牲强一致性来获得可用性。发生故障时，允许部分不可用，但可以保证核心功能可用；数据允许在一段时间内不一致，但最后一定要一致。NoSQL大致可以分为以下几类：KV型：以Redis为代表；文档类型：以MongoDB为代表；列存：以HBase为代表；图、时间序列等新兴数据库也属于NoSQL范畴。现在字节跳动广泛使用NoSQL：数万个NoSQL应用实例，10W+物理服务器资源，字节跳动90%以上的在线服务都是由NoSQL系统提供的。NoSQL产品矩阵上图是字节跳动NoSQL的产品矩阵。我们对内对外提供生态产品，包括Redis、HBase、MongoDB、InfluxDB。此外，自研平台提供了ByteGraph和ABase，两者与字节跳动业务密切相关，也是内部业务高度依赖的两大产品。字节跳动NoSQL的最新实践字节跳动的大部分业务数据可以归纳为以下几种类型：用户之间的关系：比如关注的好友等；内容：视频、文章、广告等；用户与内容的连接：用户评论、点赞、转发等。发布内容后，自媒体也会关注广告点击、收益分成等数据。这三种数据关联在一起形成图结构。自研分布式图数据库为满足内部社交图的在线增删改查场景，字节跳动自研分布式图存储数据库ByteGraph。对于刚刚提到的图数据结构，ByteGraph支持具有有向属性的图数据模型，Gremlin查询语言，以及丰富的编写和查询接口。具有海量存储和吞吐能力，单个集群可达万亿条边。支持百万级QPS地图的多次读写。ByteGraph还支持SuperNode热点接入，单节点亿级以上可实现10KQPS级别的毫秒级读写。目前ByteGraph基本支持字节跳动所有产品。除了核心数据管理，BytrGraph还支持以下典型场景：风控防作弊：在风控场景下，业界以往的通行做法是使用HBase加计算引擎。事实上，图计算更适用于风控和反欺诈的异常识别和风险检测。推荐模型：图训练系统也支持推荐核心模型，这也是字节跳动的一个核心场景。ByteDance目前在ByteDance中使用了多少ByteGraph？下面是一组数据：服务2000+内部用户（这里的用户指的是一条业务线或者一个小app）1000+图数据库集群平均每天运行1000+图计算任务，服务器规模1W+。为什么字节跳动要自己开发这么庞大的系统？作为业界最大的图生态之一，现有的一些开源解决方案无法满足字节跳动对图场景的需求。于是在2018-2019年，字节跳动尝试自研分布式图数据库，初步解决抖音关系的多度在线查询（百万级QPS左右）。当时主要功能是支持自定义点和边接口。从2019年到2021年，ByteGraph已经支持了属性图模型和Gremlin语法，并且在公司内部也得到了广泛的应用。集群的数量正在迅速扩大并逐渐标准化。目前，字节跳动在图数据库方面的多篇论文已被VLDB等顶级数据库会议收录。预计到今年年底，ByteGraph将通过火山引擎提供给更多用户。图计算系统从图数据库中衍生出一个非常大的概念——图计算。例如在Google上搜索时，需要根据网页的链接关系计算出每个页面的pagerank，从而对页面进行排序。一个页面的链接关系其实就是一个图。基于一个网页的链接关系计算pagerank，就是在这个图上运行一个图算法，即图计算。小规模的图可以在单机上计算，但是现在随着业务数据量的增加，一般需要引入分布式计算系统来解决，需要系统能够高效运行处理大规模数据的各种图算法。在字节跳动早期，很多业务使用MapReduce和Spark来实现图算法。由于大量使用批处理系统，商科学生可以快速启动算法逻辑。但是批处理（batchprocessing）本身就是为了处理并行数据而设置的，可以很方便地将工作负载分配到不同的机器上，并行处理大量数据。MapReduce的流程是先切Map，然后并行处理，再Reduce。但是图数据比较特殊，本身就具有相关性，所以不能像过去常用的行数据那样直接切分。如果使用批处理系统来运行图算法，需要引入大量的shuffle操作来实现关系的连接。但是shuffle操作非常繁重，不仅导致任务运行时间变长，而且浪费了大量的计算资源。为了解决这一系列问题，字节跳动推出了图计算系统。目前系统支持超大规模图万亿顶点规模的计算训练，支持动态超高吞吐量（百万级吞吐量级别）训练和推理，支持内存/SSD混合媒体数据处理和故障处理-tolerance,billion点边超大图的处理仅在分钟级别。为了让用户更方便的使用，我们提供一站式的图数据分析管理平台，整合图计算和图训练的产品能力，广泛对接公司核心业务场景。字节跳动在风控、电商、搜索、推荐等领域的典型图分析应用解决方案都沉淀在这个平台上，开箱即用。ABaseABase是字节跳动自研的KV存储服务。具有大容量、高吞吐、高可用（容灾）、多区域、低延迟、易用、低成本等特点。随着字节跳动业务规模的不断扩大，快速增长的数据量对KV存储系统在可用性和性能、跨地域同步、同城容灾能力、资源和成本优化等方面提出了更高的要求。我们希望ABase能够支持的场景包括：持久化KV兼容Redis协议，提供比Redis更大容量的缓存。Redis复杂命令数据生态同步：支持数据备份/回滚、FaaS数据订阅，支持ABase转Hive、Hive转ABase，方便用户在线查询、分析跨地域转换。同步：支持多活边缘存储：为边缘机房提供近场读写服务。针对以上需求，第一代ABase还不能完全满足以上需求，所以我们引入了第二代ABase。无主架构的产生，实现了多点写入，从高可用到极高可用。机器硬件或网络都会有一定的故障率。常见的高可用方案是采用多副本和双机热备。常见的主从架构都有写点。当主节点出现故障时，系统通过HA策略自动切换到热备从节点，一般成为高可用。但是在生产过程中存在两个问题：主节点故障需要一系列的检测机制，业界实现一般在1s以上，而ABase用户最多只能接受毫秒级的延迟，而二级master切换还是会造成整个流程的写失败。传统的初级故障检测难以实现慢速节点的自动检测和快速处理。Abase二代采用无主架构来解决这两个问题，支持任意点写入，没有主节点失效后所需的主切换时间，不会受到单个慢节点的影响，因此任何单个节点失效对可用性零影响，同时避免慢速节点，缩短P99延迟。ABase核心流程架构传统的quorummasterless架构修复数据一般需要构建Merkle树，这会导致海量KV场景数据达成一致的时间非常长，理论上有时可能达到周级。数据一致性依赖于读quorum，而读吞吐能力是非常浪费的。ABase自研的masterless快速共识算法借鉴了master-based的同步方式，限制了写入流的数量，只在必要的时候乱序同步，大大提高了数据一致性的速度，数据修复无需进行再次执行。依靠阅读也可以充分发挥整个系统的阅读性能。另一方面，ABase为了解决冲突，将数据的HLC时间戳编码在key结构上，这样用户冲突自然就可以解决了。但是引入这种机制后，需要在同一个Key的所有版本中寻找时间戳最大的那个，这样点查询的性能就会变差。为了解决这个问题，我们引入了双引擎结构：多个版本只存在于日志引擎中。冲突解决后，将单一版本写入KV引擎，这样大部分查询都是点查询，不再需要查所有版本。日志引擎中的索引是全内存的，多版本查询不会影响性能。以上是二代ABase引入masterless架构的trade-off。ABaseStatus经过优化，ABase目前的易用性和性能都有了很大的提升。极高的可用性：直接屏蔽慢速节点，无主从切换不可用时间，可一直写入。全球部署：快速共识算法；支持Zset、List等复杂数据结构的CRDT方案。支持高性能架构：包括RunToComplete架构、KV分离/全内存索引、FIFO日志优化。支持Serverless存储：多租户QoS保障，多维度负载均衡调度，极致资源利用。字节跳动目前有5000+业务在使用ABase，5万多台服务器，百亿请求，数百PB数据，部署在30+地区。NoSQL技术的未来发展趋势最后，我们对NoSQL技术的未来发展趋势做一个简单的预测。我们再回答一下什么是NoSQL。我认为NoSQL不仅不是只有SQL，也不是没有SQL语言。我对NoSQL的定义是高性能弹性存储+可伸缩动态计算的数据库。现在我们从数据模式维度来看，NoSQL代表了半结构化和非结构化数据处理。“处理”包括计算和存储。从CAP理论来看，NoSQL强调“最大化”P，即弹性伸缩的能力。不同的场景对C和A有不同的权衡。最后，看未来的机会。据Gartner统计，2025年全球数据需求将达到175ZB，其中大部分为非结构化/半结构化数据，存储在TOS/S3等存储产品中。机会。当然，机遇与挑战并存。谁能解决数据处理（存储+计算）的问题，谁就立于不败之地。我觉得NoSQL未来会有两个极端的方向：一个是极致的高性能KV系统，以Redis为代表；另一种是以上面介绍的ByteGraph和ABase为代表的海量、大规模的KV系统。对于字节跳动的NoSQL，我们正朝着以下几个方向努力：利用CloudNative和Serverless的能力，实现极致的弹性、成本效益和精细化的资源调度；强调数据增值能力和数据共享，计算（包括分析和AI）的需求越来越严重；融合多种非结构化/半结构化数据模式，统一存储，统一计算；软硬件结合带来数量级的革命性技术升级；产品接口标准化，加强Redis生态能力建设和SQL生态能力建设。我觉得未来几年NoSQL最大的发展趋势就是能够把所有的数据都存储起来，又快又好地计算出来，让用户看到数据存储的价值。现在NoSQL和关系型数据库的界限越来越模糊，所以数据库在不断形成各种分支的同时，也在不断融合。这就是当今技术发展的趋势和方向。
