本篇文章给大家谈谈仿西瓜视频网站php源码分享，以及西瓜视频伪原创对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
本文选自“字节跳动基础架构实践”系列文章。
“字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术团队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训，与各位技术同学一起交流成长。
RocksDB是世界上最被广泛使用的存储引擎之一，字节跳动内部大量的数据库产品（如图数据库、NewSQL等）都构建在RocksDB之上，对存储引擎的研发投入将会持续加大，为更多业务赋能。
本文将介绍字节跳动对RocksDB存储引擎的几方面改进，其中参考了大量社区贡献的经验，也有部分独创的技术，希望能为大家带来更多的优化思路。
1.背景
RocksDB作为最著名的LSM类存储引擎之一，在字节跳动内部占据非常重要的位置，大量的数据库、存储系统都在基于RocksDB进行构建或改进，但LSM系列众所周知的一些问题同样困扰着字节跳动的业务，包括性能问题、成本问题、功能问题等等。
本文首先尝试梳理和介绍我们对RocksDB在五个方面的改进（在内部存储引擎TerarkDB的基础上开发），希望能给社区带来一些参考价值，也欢迎对存储引擎感兴趣的技术专家加入我们一起为字节跳动构建更强大的底层支撑。
2.RocksDB的不足
读写放大严重应对突发流量的时候削峰能力不足压缩率有限索引效率较低等等
3.我们的改进
3.1LazyBuffer
RocksDB之前的某个版本引入了PinnableSlice作为数据在引擎内的传输载体，它的主要作用是可以减少数据复制，即当用户所要查找的数据在BlockCache中的时候，只返回其引用。
但是PinnableSlice在一些场景下无法发挥价值，比如用户的某个操作需要触碰大量不需要的Value时（如Value有很多版本或者有大量的tombstone），PinnableSlice依然会对这些无用的Value产生I/O操作，这部分开销是完全可以避免的。
我们为此构建了LazyBuffer替换PinnableSlice，当用户获得Value的时候，并不真正进行磁盘I/O，只有用户真正需要取值的时候才进行真正的fetch操作进行I/O。
LazyBuffer是对PinnableSlice的增强，从减少数据复制更进一步减少不必要的IO，对于大量的扫描、SeekRandom等场景有很大好处。
3.2LazyCompaction
自从LSM推广开来，针对LSMCompaction的各种策略优化层出不穷，其中主流的Compaction策略有以下几种：
LeveledCompaction全部层级都按照标准的从上到下进行层级合并读写放大都比较严重，但是空间放大较低在这篇论文（TowardsAccurateandFastEvaluationofMulti-StageLog-StructuredDesigns）中有详细的阐述TieredCompaction即RocksDB中的UniversalCompaction空间放大和读放大严重，但是写放大最小在这篇论文（Dostoevsky:BetterSpace-TimeTrade-OffsforLSM-TreeBasedKey-ValueStoresviaAdaptiveRemovalofSuperfluousMerging）有详细的阐述Tiered+LeveledCompaction即RocksDB中的LevelCompaction是一个混合的Compaction策略，空间放大比TieredCompaction更低，写放大也比Leveled低Leveled-NCompaction比LeveledCompaction写放大更低，读放大更高一次合并N-1层到第N层
从上面的分类我们可以看到，主流的Compaction策略主要在不同的合并时机之间进行权衡和选择，字节跳动在这里使用了稍微改进一点的方式。
首先，我们要理解如果能够允许SST可以不必保持强有序，那么就可以让我们收集到更多的统计信息后再真正执行外排序（Compaction），但缺点是会增加一定程度的读放大，对读延迟会有影响，那么有没有办法让增加的读放大可控，甚至几乎不增加读放大呢？
我们尝试构建了一种新的SST数据结构（AdaptiveMap，简称aMap），区别于RocksDB默认的结构，aMap是一个逻辑上的虚拟SST，如下图所示：
aMap结构示意图
图中SST1、SST2、SST3是三个物理上的SST文件，当需要对他们进行合并的时候，我们先构建虚拟遮罩，对上层暴露逻辑上的合并好的SST（逻辑上是一个大SST），同时记录和标记其中的覆盖度、KeySpace等统计信息。
它的主要功能有：
大的Compaction策略上，继承了RocksDB的LevelCompaction（UniversalCompaction也可以支持，看场景需要，默认是LevelCompaction）当需要进行Compaction的时候，会首选构建AdaptiveMap，将候选的几个SST构成一个逻辑上的新SST（如上图所示）AdaptiveMap中会切分出多个不同的重叠段，R1、R2、R3、R4、R5，这些重叠段的重叠度会被追踪记录后台的GC线程会优先选择那些重叠度更好的层进行GC，通过这种手段，我们可以让GC更有效率，即写放大远低于默认的情况
读写放大和原版RocksDB对比，理论分析上是有优势的：
复杂度分析对比（读放大和写放大）
3.3KV分离
在论文*WiscKey:SeparatingKeysfromValuesinSSD-consciousStorage*介绍了一种KV分离的SST设计，它的主要方式是构建一个ValueLog文件不断的在上面追加Value数据，同时原始的SST中Value只记录数据真实存在的位置即可。
KV分离的基本原理
其实KV分离的思路比较直接和简单，把符合阈值的value从直接存储在SST中，改为存储文件指针，降低Compaction、Seek等操作的开销。
RocksDB社区有一个KV分离的BlobDB功能，但是目前功能还不完善，还有大量的工作需要继续做，这里就暂不做对比。另一个TitanDB是一个实现上相对完整的KV分离存储引擎（以RocksDB插件的形式构建），我们在这里对他们进行一个简单的对比：
综合来看，在和社区的对比中，我们实现KV分离的大体思路是类似的，但由于我们有AdaptiveMap的存在，可以对真正的GC操作进行延迟到负载较低的时候进行，对于应对突发流量尖峰会有相当不错的效果。
但KV分离也带来了一些损失，最重要的就是对于范围查询造成了损害，后续可以通过逻辑层进行Prefetch来降低这部分的损耗。
3.4多种索引支持
对于原生的RocksDB，其SST格式大致如下图所示：
[datablock1]\n[datablock2]\n…\n[datablockN]\n[metablock1:filterblock](seesection:&34;MetaBlock)\n[metablock2:indexblock]\n[metablock3:compressiondictionaryblock](seesection:&34;MetaBlock)\n[metablock4:rangedeletionblock](seesection:&34;MetaBlock)\n[metablock5:statsblock](seesection:&34;MetaBlock)\n…\n[metablockK:futureextendedblock](wemayaddmoremetablocksinthefuture)\n[metaindexblock]\n[Footer](fixedsize;startsatfile_size-sizeof(Footer))
其中，indexblock和filterblock帮助用户快速定位目标key所在的block。RocksDB默认的index并没有考虑不同数据类型之间的差异，无法根据不同数据类型选择压缩效率和查询效率最高的索引结构，针对这个问题，我们构建了一种自适应的索引选择和构建机制。
对于输入的数据，我们会对其进行分段式探测，确定最高效的索引算法对于这批数据进行单独索引并把索引放在indexblock中的
目前已经支持的额外索引算法有：
压缩Trie索引，针对字符串类型进行通用压缩非降序整数索引，通过bitmap构建高度压缩的索引……
通过多种索引结构的支持，为以后的长期优化提供了更多可能，甚至在SST中内嵌B+树索引datablock等等，更加灵活、模块化的结构让引擎的适应能力更强，面对不同的存储介质、访问模式可以有更佳的综合表现。
3.5极致压缩
对于数据库应用来说，除了追求高性能外，成本控制也是一个很重要的话题，其中成本控制的重要一环就是数据压缩，对于LSM结构来说，默认是通过block进行压缩的，压缩率和块的尺寸强相关。
在这里为了解决块尺寸和压缩率的tradeoff问题，我们构建了一系列的压缩算法，其中最常用的是可以按记录抽取数据的全局压缩，其基本思路其实并不复杂，通过对LZ系列的改进，使用高效的手段保留每一个Record的Offset即可，而Offset表有很多种方法进行压缩存储（显然它是递增的非连续整数序列），利用pfordelta等方法进行优化变通存储不难办到。
全局压缩算法的概要流程
其大致流程是：
先对数据进行扫描采样构建数据字典所以默认情况下需要对CompactionSST进行改造以提供两遍扫描的能力根据数据字典，对原数据进行滑动窗口压缩最后再进行一轮可选的熵压缩（EntropyCompression）熵压缩业内主流的包括ANS和高阶Huffman等等，可以根据实际数据分布探测选择在压缩过程中，将会保存每条原始数据的offset信息构成偏移表
偏移表的构建和保存
偏移表采用常见的类pfordelta算法压缩保存即可，需要注意的是因为偏移表会被频繁访问，这里的适宜有一阶差分表和二阶差分表，根据实际情况选择即可。
索引后续可以直接映射到这里具体的recordoffset中来，方便后续的直接按记录寻址。
3.6新硬件支持
对目前流行的新硬件（如持久化内存、FPGA、QAT等），我们同样进行了适配和优化，比如在在设备有QAT硬件的时候，我们在主机CPU负载较高时，选择放弃一部分CPU压缩offload到QAT中进行压缩，再比如我们将一部分数据放在持久化内存上实现真正的Record级别数据访问（我们采用的并非常见的块级别的索引结构，而是直接按记录索引）等等。
这里我们以QAT压缩为例来说明：
我们知道随着PCIeNVMeSSD的大范围普及，磁盘的带宽和IOPS大幅度提升磁盘带宽的提升进而将系统瓶颈转移到了CPUCPU要做的工作包括数据排序（SST需要维护有序性）、CRC校验、数据压缩、查询比对等等我们初步目前的计划是把数据压缩和CRC校验卸载到专门的QAT硬件中进行加速目前QAT硬件的性价比较高，甚至部分主板还自带QAT本身能支持的压缩算法有限，主要以zlib的deflate为主当我们卸载了数据压缩和CRC校验后，就可以分配更多的CPU进行SST的GC和Compaction，尽快将SST形态调整到最佳
目前QAT的使用还在测试阶段，还没有正式上线，下一步计划对FPGA的应用进行深度的调研。
4.对比测试
我们使用RocksDB的bench工具进行了一些简单的测试，对比了RocksDB、TitanDB和TerarkDB的区别和差异，需要注意是，该工具使用的是随机生成的数据，对于TerarkDB的压缩算法不是很友好，所以压缩率差距并不大。
这次改进，我们重点关注的是KV分离的表现，所以只对比较大的Value进行benchmark确认其改进效果：
测试环境：原始测试数据集大小为256GB，内存128GBCPU:48CoreRAM:128GBDisk:IntelNVMe3.4T测试程序为db_benchLinuxversion4.14GCCVersion6.3.0测试内容：fillrandom：多线程随机写入,存在重复keyreadseq：多线程顺序Scanreadrandom：多线程随机Getseekrandom：多线程随机Seek
Valuesize=4KB
Valuesize=32KB
5.后续
字节跳动在单机引擎上的投入会持续加大，同时也会考虑为各类特定业务构建针对性的专用引擎，其目标是在单机内为上层业务提供更强大的性能，更灵活的功能和更可靠的服务。
为了实现这些目标，后续我们还需要做的有很多，包括卸载单机引擎的CPU到集群上进行分布式Compaction、引入SPDK相关的技术提升IO效率、引入AITuning针对不同负载做更灵活的I/O策略、引入新硬件（如持久化内存和FPGA）等等。
为了实现字节跳动存储引擎的多样性和走向业界前沿，我们迫切的希望有志者能够加入我们一起做新的探索，我们也希望未来在主流的期刊上、开源社区中能够看到字节跳动的活跃身影，为技术社区贡献自己的力量。
6.参考文献
WiscKey:SeparatingKeysfromValuesinSSD-consciousStorageBitcaskALog-StructuredHashTableforFastKey/ValueDataLSM-trie:AnLSM-tree-basedUltra-LargeKey-ValueStoreforSmallDataTowardsAccurateandFastEvaluationofMulti-StageLog-StructuredDesigns
更多分享
深入理解Linux内核–jemalloc引起的TLBshootdown及优化
字节跳动自研万亿级图数据库&图计算实践
字节跳动EB级HDFS实践
字节跳动基础架构团队
字节跳动基础架构团队是支撑字节跳动旗下包括抖音、今日头条、西瓜视频、火山小视频在内的多款亿级规模用户产品平稳运行的重要团队，为字节跳动及旗下业务的快速稳定发展提供了保证和推动力。
公司内，基础架构团队主要负责字节跳动私有云建设，管理数以万计服务器规模的集群，负责数万台计算/存储混合部署和在线/离线混合部署，支持若干EB海量数据的稳定存储。
文化上，团队积极拥抱开源和创新的软硬件架构。我们长期招聘基础架构方向的同学，具体可参见job.bytedance.com「链接」，感兴趣可以联系邮箱guoxinyu.0372@bytedance.com。
欢迎关注字节跳动技术团队
如果你还想了解更多这方面的信息，记得收藏关注本站。