rocksdb

目录 Docker搭建Hadoop集群（Docker & Hadoop & HDFS & Yarn & Cluster） Docker搭建Myrocks实例（Docker & Mysql & Rocksdb） Docker搭建Kafka集群（Docker & Kafka & Cluster） Docker Container开启ssh服务 Docker Host创建swarm overlay网络 Docker Host设置自启动、国内源、代理 Docker、Docker Compose、Docker Machine各平台安装 Docker 搭建Zookeeper集群(Docker & Zookeeper & Replication) Docker 搭建Pika分片多主集群（Docker & Codis & Pika& Replication & Sharding） Docker搭建Spark集群（Docker & Spark & Cluster & Local & Standalone） Docker搭建SSDB分片多主集群（Docker & Twemproxy & SSDB & Replication & Sharding） Docker搭建MongoRocks副本分片集群（Docker & Mongodb & Rocksdb & Replication & Sharding）

目录 跳表 使用场景 结构描述 查询算法 插入算法 删除算法 时间复杂度 空间复杂度 总结 Redis使用跳表而不是红黑树？ 跳表 使用场景 跳表(Skiplist ）是一个特殊的链表，相比一般的链表，有更高的查找效率，可比拟二叉查找树， 平均期望的查找、插入、删除 时间复杂度都是O(log n) ，许多知名的开源软件（库）中的数据 结构均采用了跳表这种数据结构∶ Redis中的有序集合zset LevelDB、RocksDB、HBase中Memtable Apache Lucene中的Term Dictionary、Posting List 结构描述 我们拿我们以前的有序链表相比： 我们可以很清楚的看出，有序链表的查询比较慢，时间复杂度为O(n)，它的删除和插入操作比较快，我们怎样才能让它的查询的时间复杂度也变快呢？ 能不能将我们的链表实现二分的查找，也就是longN，答案是肯定的，也就是我们下面所说的这种跳表。 查询算法 跳表的查询和我之前做过的一道题特别类似， 二维数组的查找 假设我们查询 31 这个数字 我们的header开始，依次进行查询， 31不在负无穷到17，往右边，到达17，继续比较，在17到正无穷之间，往下跑 … 整个查询过程如下所示 插入算法 对于插入来说，我们比如要插入一个21的数值 类似查询算法，到达17这个点，进一步到达20这个点，然后在20的后面进行插入

作者 | 唐云（茶干），阿里巴巴高级开发工程师 整理 | 张壮壮（Flink 社区志愿者） 摘要：本文根据 Apache Flink 系列直播整理而成，由阿里巴巴高级开发工程师唐云（茶干）分享。主要内容如下： 容器管理系统的演变 Flink on K8S intro Flink on K8S实战分享 Demo Tips：点击下方可查看更多 1.10 系列直播视频～ 1.10系列直播： https://ververica.cn/developers/flink-training-course-1-10/ 本文第一部分将简明扼要地介绍容器管理系统的演变；第二部分是 Flink on K8S 简介，包括集群的部署模式调度原理等等；第三部分是我们这一年以来关于 Flink on K8S 的实战经验分享，介绍我们遇到的问题、踩过的坑；最后一部分是 Demo，将手把手演示集群部署、任务提交等等。 容器管理系统的演变 首先是以一个 Kubernetes 非内核开发人员的角度去探讨其和 YARN 之间的关系。众所周知，Apache Hadoop YARN 可能是在国内用途最广的一个调度系统，主要原因在于 Hadoop HDFS 在国内或者是在整个大数据业界，是一个使用最广泛的存储系统。因此，基于其上的 YARN 也自然而然成为了一个广为使用的一个调度系统，包括早期的 Hadoop

本文作者系微信技术专家李本利 首发于 Nebula Graph 官方博客： https://nebula-graph.com.cn/posts/nebula-graph-for-social-networking/ 图数据在社交推荐、多跳实时计算、风控和安全等领域有可期待的前景。如何用图数据库高效存储和查询大规模异构图数据，是一个重大挑战。本文描述了开源分布式图数据库 Nebula Graph 实践中遇到的问题，并通过深度定制，实现：大数据集存储、小时级全量导入、多版本控制、秒级回滚、毫秒级访问等特性。 背景 为大众所熟知的图数据库大多在大数据集合上束手无策，如：Neo4j 的社区版本，采用 Cypher语言，由单机单副本提供服务，广泛应用于图谱领域。互联网公司只能在小数据集合下使用，还要解决 Neo4j 多副本一致性容灾的问题。 JanusGraph 虽然通过外置元数据管理、kv 存储和索引的方式解决了大数据集合存储问题，但其存在广为诟病的性能问题。我们看到大部分图数据库在对比性能时都会提到和 JanusGraph 相比有几十倍以上的性能提升。 面临大数据量挑战的互联网公司，普遍走向了自研之路，为了贴合业务需求，仅支持有限的查询语义。国内主流互联网公司如何解决图数据库的挑战呢： 蚂蚁金服： GeaBase [1] 金融级图数据库，通过自定义类语言为业务方提供服务，全量计算下推

排序规则: 首先按照roachpb.Key的字节序顺序比较 其次，在有一个时间戳值为空时，按照hlc时间戳正序比较，否则，按照hlc时间戳逆序比较 如下排序结果：　 key, hlc 123, 0 123, 0 123, 54 123, 24 123, 24 234, 0 234, 34 234, 24 234, 14 源码分析： pkg/storage/engine/mvcc.go type MVCCKey struct { Key roachpb.Key Timestamp hlc.Timestamp } c-deps/libroach/comparator.h class DBComparator : public rocksdb::Comparator { ... virtual int Compare(const rocksdb::Slice& a, const rocksdb::Slice& b) const override; ... } c-deps/libroach/comparator.cc int DBComparator::Compare(const rocksdb::Slice& a, const rocksdb::Slice& b) const { rocksdb::Slice key_a, key_b; rocksdb::Slice ts_a, ts

本系列文章主要介绍HTAP数据库BaikalDB的技术实现细节。 作者介绍： 罗小兵 ，百度商业平台研发部高级研发工程师，主要负责BaikalDB事务能力，全局二级索引等方向的研发工作。 欢迎关注 Star github.com/baidu/BaikalDB 国内加速镜像库 gitee 一、概述 BaikalDB系统简介 BaikalDB 是一个分布式可扩展的存储系统，兼容MySQL协议，整个系统的架构如下图所示： BaikalStore 负责数据存储，数据分区按region组织，三个Store的三个region形成一个 Raft-group 实现三副本，多实例部署，Store实例宕机可以自动迁移 Region数据； BaikalMeta 负责元信息管理，包括分区，容量，权限，均衡等， Raft 保障的3副本部署，Meta 宕机只影响数据无法扩容迁移，不影响数据读写； BaikaDB 负责前端SQL解析，查询计划生成执行，无状态全同构多实例部署，宕机实例数不超过 qps 承载极限即可； 分布式事务 BaikalDB将数据按照range进行切分，每个分区称为region，连续的region组成了数据的整个区间。不同的region位于不同的BaikalStore实例，在不同的机器上，那么当一个SQL语句涉及多个region的更新时，如何保证所有的更新，要么全部成功，要么全部失败呢

摘要： 在本篇文章中我们将对 RocksDB、Heap 和 Gemini 在相同场景下进行压测，并对其资源消耗进行对比。测试的 Flink 内核版本为 1.10.0。 微博机器学习平台使用 Flink 实现多流 join 来生成在线机器学习需要的样本。时间窗口内的数据会被缓存到 state 里，且 state 访问的延迟通常决定了作业的性能。开源 Flink 的状态存储主要包括 RocksDB 和 Heap 两种，而在去年的 Flink Forward 大会上我们了解到阿里云 VVP 产品自研了一款更高性能的状态存储插件 Gemini，并对其进行了测试和试用。 测试场景 我们使用真实的样本拼接业务作为测试场景，通过将多个流的数据 union后对指定key做聚合（keyby），在聚合函数里从各个流中获取相应的字段，并将需要的字段重新组合成一个新的对象存储到 value state 里。这里对每个新的对象都定义一个 timer，用 timer 功能来替代 TimeWindow，窗口结束时将数据发射到下游算子。使用 timer 功能的主要原因是 timer 更灵活，更方便用户自定义，在平台的实用性，可扩展性上表现更好。 MemoryStateBackend vs. RocksDBStateBackend 首先需要说明的是，MemoryStateBackend 不建议在线上使用

近年来，大型企业以及开源社区不断的推动中国开源技术的发展，今天的中国已然成为OpenStack & Ceph等开源技术大放光彩的乐土。 图为 Ceph中国行各地沙龙 Ceph 国内用户生态 Ceph作为全球最火热的开源分布式存储项目，同样在中国的发展也是非常火热，不断开始在不同领域不同行业及客户系统相融合。典型应用在国内一线互联网公司以及运营商、政府、金融、广电、能源、游戏、直播等行业。 当前中国Ceph形势对比前几年已经发生了决定性的变化，随着国内越来越多的各行业用户的使用，足以见证它的稳定性可靠性。Ceph中国用户生态已然形成，可以看到国内如：中国移动、腾讯、阿里、网易、乐视、携程、今日头条、中国电信、中兴、恒丰银行、平安科技、YY、B站、360等。正是由于众多用户的使用验证了它的稳定性和可靠性的同时也促进了Ceph的进步，使其出现了很多新东西，如 SPDK、BlueStore、RDMA等等这些高性能底层技术。 Ceph 国内贡献 豪迈在之前的文章也谈到过Ceph社区的贡 献者，非常有意思的是 Ceph 的使用用户占据了相当的贡献排名，一定程度上反映了 Ceph 目前的现状，要能够真正掌控Ceph 必须得深入社区并随之成长。因此，对于一个并不是像 Linux 一样成熟的开源项目，特别还是一个存储系统来说，代码贡献程度基本决定了对于Ceph 的理解，风险控制和使用程度

相信不少读者在开发 Flink 应用时或多或少会遇到在内存调优方面的问题，比如在我们生产环境中遇到最多的 TaskManager 在容器化环境下占用超出容器限制的内存而被 YARN/Mesos kill 掉[1]，再比如使用 heap-based StateBackend 情况下 State 过大导致 GC 频繁影响吞吐。这些问题对于不熟悉 Flink 内存管理的用户来说十分难以排查，而且 Flink 晦涩难懂的内存配置参数更是让用户望而却步，结果是往往将内存调大至一个比较浪费的阈值以尽量避免内存问题。 对于作业规模不大的普通用户而言，这些通常在可以接受的范围之内，但对于上千并行度的大作业来说，浪费资源的总量会非常可观，而且进程的不稳定性导致的作业恢复时间也会比普通作业长得多，因此阿里巴巴的 Blink 团队针对内存管理机制做了大量的优化，并于近期开始合并到 Flink。本文的内容主要基于阿里团队工程师宋辛童在 Flink Forward Beijing 的分享[2]，以及后续相关的几个 FLIP 提案。 Flink 目前（1.9）的内存管理 TaskManager 作为 Master/Slave 架构中的 Slave 提供了作业执行需要的环境和资源，最为重要而且复杂，因此 Flink 的内存管理也主要指 TaskManager 的内存管理。 TaskManager 的资源

本文旨在介绍 vivo 内部的特征存储实践、演进以及未来展望，抛砖引玉，吸引更多优秀的想法。 一、需求分析 AI 技术在 vivo 内部应用越来越广泛，其中特征数据扮演着至关重要的角色，用于离线训练、在线预估等场景，我们需要设计一个系统解决各种特征数据可靠高效存储的问题。 1. 特征数据特点 （1）Value 大 特征数据一般包含非常多的字段，导致最终存到 KV 上的 Value 特别大，哪怕是压缩过的。 （2）存储数据量大、并发高、吞吐大 特征场景要存的数据量很大，内存型的 KV（比如 Redis Cluster）是很难满足需求的，而且非常昂贵。不管离线场景还是在线场景，并发请求量大，Value 又不小，吞吐自然就大了。 （3）读写性能要求高，延时低 大部分特征场景要求读写延时非常低，而且持续平稳，少抖动。 （4）不需要范围查询 大部分场景都是单点随机读写。 （5）定时灌海量数据 很多特征数据刚被算出来的时候，是存在一些面向 OLAP 的存储产品上，而且定期算一次，希望有一个工具能把这些特征数据及时同步到在线 KV 上。 （6）易用 业务在接入这个存储系统时，最好没有太大的理解成本。 2. 潜在需求 扩展为通用磁盘 KV，支撑各个场景的大容量存储需求 我们的目标是星辰大海，绝不仅限于满足特征场景。 支撑其他 Nosql/Newsql 数据库，资源复用 从业务需求出发