rocksdb

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 日志结构的合并树（log-structured merge-tree LSM 树）通常是在处理大量写任务时使用的数据结构。通过顺序写来优化写入路径。 LSM 树是许多数据库（包括 BigTable, Cassandra, Scylla,和 RocksDB）背后的核心数据结构。 排序字符串表 LSM 树使用排序字符串表（Sorted Strings Table 简称 SSTable）的格式保存到磁盘。如名称所示，SSTables 是一种用于存储键-值对的格式，其中键按有序排列。SSTable 将由多个名为段（Segments）的有序文件组成。一旦将这些数据段写入磁盘后，就是不可变的。简化示例如下： 我们可以看到，每个段中的键-值对都是按键排序的。接下来看看什么是片段以及它是如何生成的。 写数据 回想一下，LSM 树只执行顺序写入。我们可能想知道，当值以任意顺序写入时，如何以有序格式的顺序写入数据？这可以通过使用内存中的树结构来解决。通常被称为内存表（memtable），但底层数据结构通常是某种形式的排序树，如红黑树。当写入数据时，将添加到此红黑树中。 我们的写入将存储在这个红黑树中，直到树达到预定义的大小。一旦红黑树有足够的条目，它就会按有序的顺序作为磁盘上的一个段刷新到磁盘

延迟消息是实际开发中一个非常有用的功能，本文第一部分从整体上介绍秒级精度延迟消息的实现思路，在第二部分结合RocketMQ的延迟消息实现，进行细致的讲解，点出关键部分的源码。第三步介绍延迟消息与消息重试的关系。 1 延迟消息介绍 基本概念：延迟消息是指生产者发送消息发送消息后，不能立刻被消费者消费，需要等待指定的时间后才可以被消费。 场景案例：用户下了一个订单之后，需要在指定时间内(例如30分钟)进行支付，在到期之前可以发送一个消息提醒用户进行支付。 一些消息中间件的Broker端内置了延迟消息支持的能力，如： NSQ： 这是一个go语言的消息中间件，其通过内存中的优先级队列来保存延迟消息，支持秒级精度，最多2个小时延迟。Java中也有对应的实现，如ScheduledThreadPoolExecutor内部实际上也是使用了优先级队列。 QMQ： 采用双重时间轮实现。 https://www.toutiao.com/i6851807550690722312/ RabbitMQ： 需要安装一个rabbitmq_delayed_message_exchange插件。 RocketMQ： RocketMQ 开源版本延迟消息临时存储在一个内部主题SCHEDULE_TOPIC_XXXX中， 不支持任意时间精度，支持特定的 level，例如定时 5s，10s，1m 等。

作者：董亭亭、徐明 摘要：作为短视频分享跟直播的平台，快手有诸多业务场景应用了 Flink，包括短视频、直播的质量监控、用户增长分析、实时数据处理、直播 CDN 调度等。此次主要介绍在快手使用 Flink 在实时多维分析场景的应用与优化。主要内容包括： Flink 在快手应用场景及规模 快手实时多维分析平台 SlimBase-更省 IO、嵌入式共享 state 存储 Tips：点击下方链接可查看作者原版PPT及分享视频～ https://ververica.cn/developers/flink-forward-asia-2019/ Flink 在快手应用场景及规模 首先看 Flink 在快手的应用场景和规模。 1. 快手应用场景 快手计算链路是从 DB/Binlog 以及 WebService Log 实时入到 Kafka 中，然后接入 Flink 做实时计算，其中包括实时数仓、实时分析以及实时训练，最后的结果存到 Druid、Kudu、HBase 或者 ClickHouse 里面；同时 Kafka 数据实时 Dump 一份到 Hadoop 集群，然后通过 Hive、MapReduce 或者 Spark 来做离线计算；最终实时计算和离线计算的结果数据会用内部自研 BI 工具 KwaiBI 来展现出来。 Flink 在快手典型的应用场景主要分为三大类： 80% 统计监控 ：实时统计

 根据最新的统计显示，仅在过去的两年中，当今世界上90％的数据都是在新产生的，每天创建2.5万亿字节的数据，并且随着新设备，传感器和技术的出现，数据增长速度可能会进一步加快。 从技术上讲，这意味着我们的大数据处理将变得更加复杂且更具挑战性。而且，许多用例（例如，移动应用广告，欺诈检测，出租车预订，病人监护等）都需要在数据到达时进行实时数据处理，以便做出快速可行的决策。这就是为什么分布式流处理在大数据世界中变得非常流行的原因。 如今，有许多可用的开源流框架。有趣的是，几乎所有它们都是相当新的，仅在最近几年才开发出来。因此，对于新手来说，很容易混淆流框架之间的理解和区分。在本文中，我将首先大致讨论流处理的类型和方面，然后比较最受欢迎的开源流框架：Flink，SparkStreaming，Storm，KafkaStream。我将尝试（简要地）解释它们的工作原理，它们的用例，优势，局限性，异同。 ## **什么是流/流处理：** 流处理的最优雅的定义是：一种数据处理引擎，其设计时考虑了无限的数据集。 与批处理不同，批处理以工作中的开始和结束为界，而工作是在处理有限数据之后完成的，而流处理则是指连续不断地处理天

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 简介： 对比大多数开发者来说，杨飞的职业路线可以说是大相径庭。从大厂到创业公司，从一线城市回归二线……对于事业和生活，他的选择一直很独特。 以下为杨飞的个人专访，推荐阅读（约3分钟）。 度量权衡，做出属于自己的选择 我在互联网从业十年，至今有三段工作经历，行业和技术跨度都很大。毕业后进入腾讯做端游的C++服务器，有200万用户同时在线，在十年前这个数据已经是很不错的成绩。大厂有严格的人事体系和业务规划，由于缺乏场景历练，我渐渐觉察到如果自己再停留在后端的单一业务，很难有更多的发展空间。在腾讯做升级答辩时，评审专家给的唯一意见是可以多看看兄弟业务的做法，不同领域的实践都是基于什么样的场景。于是即使端游产品即将正式商业化，我还是毅然决然地选择离开腾讯。我是个不太看重短期回报的人，但家庭因素在我的所有选择中占很大比重。因为我太太在西安，所以我选择回归家庭，主动降薪入职西安的三星。 加入三星后我投身于跨度很大的基于SSD的数据库优化项目，算是半工业半科研性质。基于SSD的特性和开放出的能力，我们将RocksDB的IO的性能最多提升了80%。习惯了自由随意的互联网公司氛围，最初到三星被要求全天正装还有些不适应，同时还有更加严格的信息安全标准。由于三星自身的行业秘密

以键值对（Key-Value，简称KV）作为数据的存储方式，已经在很多场合得到了成功的应用。 KV存储以其直观性，降低了很多应用程序调用数据的复杂度，可以获得更高数据的存取效率，但也有其局限性。宝存科技的Open-Channel SSD（OCS）定义了一种通用的，高效率的主机端直接访问 FLASH 的标准接口，百度基于此开发出一套高性能KV存储引擎，有效减少写放大对设备性能的影响。 01 当前KV的不足之处 目前KV的成熟应用场合有： 内存数据库及其持久化，如Redis、Pika； 分布式文件存储系统底层存储接口，如Ceph中使用Bluestore； 关系数据库存储引擎，如MySQL中的MyRocks引擎。 由于单机内存总量的限制，内存KV有持久化到硬盘的需求，而基于硬盘的KV数据库多使用LSM Tree的方式在文件系统中实现（如RocksDB）， 在实际应用中会出现以下问题： 极高的写放大。由于WAL的机制，一份数据落盘即出现“双写”的效果，产生1倍写放大。WAL(Write-ahead logging)记录了数据持久写入DB之前的变更，是传统数据库保证数据安全性的必要动作。由于compaction机制的存在，新数据的写入会导致旧数据被反复合并，最终一份数据的写入实际会造成2倍以上的写入量。业界存储设备已经全面转向SSD，而SSD的寿命是有限的

https://zhuanlan.zhihu.com/p/45084771 分布式存储系统通过将数据分散到多台机器上来充分利用多台机器的资源提高系统的存储能力，每台机器上的数据存放都需要本地的单机存储系统，它是整个分布式存储系统的基础，为其提供保障。设计高性能、高可靠的分布式存储系统离不开高效、一致、稳定、可靠的本地存储系统。 ceph是目前业内比较普遍使用的开源分布式存储系统，实现有多种类型的本地存储系统；在较早的版本当中，ceph默认使用FileStore作为后端存储，但是由于FileStore存在一些缺陷，重新设计开发了BlueStore，并在L版本之后作为默认的后端存储。BlueStore的一些设计思想对于设计满足分布式存储系统需求的本地存储系统具有参考意义，因此我们将分多个章节对BlueStore的一些原理进行剖析，供读者进行参考和探讨。 在这一章中，我们将要了解BlueStore的诞生背景，以及它的一些设计思想。 为什么需要BlueStore 前面提到，BlueStore的诞生背景是由于FileStore存在的一些缺陷，这些缺陷具体是什么？ IO放大 FileStore底层使用POSIX规范的文件系统接口，例如xfs、ext4、btrfs，然而这类文件系统本身不支持数据或元数据的事务操作接口（btrfs提供事务钩子的接口，但是测试过程中发现会导致系统宕机）