rocksdb

本期招聘企业——哈啰出行 哈啰出行是专业的移动出行平台，旗下包括哈啰单车、哈啰助力车、哈啰打车等产品。公司秉持“科技推动出行进化”的企业使命，坚持“绿色低碳、轻松出行”的服务理念，为广大用户提供覆盖短、中、长距离的全方位无缝衔接的出行服务，努力缓解城市交通压力，减少车辆尾气排放，为智慧城市建设提供可持续发展的移动出行解决方案。 哈啰出行先后获得GGV纪源资本、成为资本、蚂蚁金服、复星等知名投资机构的投资，2017年10月与江苏永安行低碳科技有限公司合并，与蚂蚁金服、深创投、永安行等成为重要的战略合作伙伴。 工作地点：上海 - 闵行区 - 莘庄 - 旭辉莘庄中心 招聘岗位 Go 中间件、存储系统专家 工作职责 负责公司基础架构方向系统的设计与研发，重点方向为API 网关、分布式存储系统、微服务框架、异地多活架构、service mesh等； 任职资格 1. 3年以上golang/c++编程语言开发经验，深入了解主流的微服务框架和存储系统； 2. 熟悉微服务架构，深入理解分布式系统原理，了解Service Mesh相关服务治理框架； 3. 对存储和高性能系统有深入研究者优先，如Redis、Tair、Raft协议、leveldb/rocksdb、Nginx等； 4. 良好的团队协作和沟通能力，责任心强； 5. 具有很强的分析问题和解决问题能力。 投递方式 简历请发至邮箱

项目简介 Tendis是腾讯互娱CROS DBA团队 & 腾讯云数据库团队自主设计和研发的分布式高性能KV存储数据库，兼容Redis核心数据结构与接口。 可提供大容量、低成本、强持久化的数据库能力，适用于兼容Redis协议、需要大容量且较高访问性能的温冷数据存储场景。 Tendis目前已经被应用到腾讯内、外部大型项目中。 集群架构 Tendis使用去中心化集群架构，每个数据节点都拥有全部的路由信息，用户可以访问集群中的任意节点，并且通过redis的move协议，最终路由到正确的节点。 每个Tendis节点维护各自的slot数据，任意两个master节点之间的slot不重复，master节点之间支持基于slot的数据搬迁，主备节点之间通过binlog实现数据复制。 所有节点之间通过gossip协议进行通讯，类似于redis cluster的分布式实现，所有节点通过gossip协议通讯，可指定hashtag来控制数据分布和访问，使用和运维成本极低。 适用场景 兼容Redis协议，需要大容量且较高访问性能的温冷数据存储场景 适合成本为主要考虑因素，业务数据有高持久化要求的业务场景 解决原生Redis固有的fork问题而预留部分内存问题 主要特性 兼容Redis协议 完全兼容redis协议，支持redis主要数据结构和接口，兼容大部分原生Redis命令。 持久化存储

今天正式入职了字节跳动。办公环境也很好，这边一栋楼都是办公区域。公司内部配备各种小零食、饮料，还有免费的咖啡。15楼还有健身房。而且公司包三餐来着。下午三点半左右还会有阿姨推着小车给大家送下午茶。听说入职以后很容易长胖来着。不过如果想要保持身材的话，公司二楼还提供专门的健身餐。周二周四还可以预约专业的按摩服务，有效调理颈椎和腰椎。生活服务得这么贴心，感觉在这里就只需要好好工作就好了吧，哈哈 为什么想去字节跳动 实际上，这次的工作变动并不在我计划中。只是在四月份的时候偶然得知字节跳动上海要搬到合川路地铁站附近，我就忽然心动了。为什么呢，因为我家距离合川路地铁站步行只要十分钟。本身宇宙条待遇高名声在外，也就是说，只要我能来这里的话，人生最美满的钱多事少离家近的不可能三角我能拿俩。所以在五月份的时候我就开始悄摸摸地准备面试头条了。为的就是以后可以过上早上八点半起床，然后慢慢悠悠走到公司还不迟到（可能还是很早来的人之一）的生活。 当然，这是我为什么想去字节跳动的原因。换算到你们自己的时候，你们也要想一想是因为什么想要换一份工作、想要去某个公司。为了薪资？环境？平台？还是大公司的名头？记住，不管是为了哪一个，都OK的。谈钱不伤感情，目标明确，心智坚定以后，才好围绕着这个目标做一系列的准备。面试的过程中每次面试官问我为什么想来字节跳动，我都是直截了当地说离家近，还说假如这次面不上，准备准备

本文主要讨论一个问题： ValueS tate 中存 Map 与 MapState 有什么区别？ 如果不懂这两者的区别，而且使用 ValueState 中存大对象，生产环境很可能会出现以下问题： CPU 被打满 吞吐上不去 1、 结论 从性能和 TTL 两个维度来描述区别。 性能 RocksDB 场景，MapState 比 ValueState 中存 Map 性能高很多。 生产环境强烈推荐使用 MapState，不推荐 ValueState 中存大对象 ValueState 中存大对象很容易使 CPU 打满 Heap State 场景，两者性能类似。 TTL Flink 中 State 支持设置 TTL： MapState 的 TTL 是基于 UK 级别的 ValueState 的 TTL 是基于整个 key 的 举一反三 能使用 ListState 的场景，不要使用 ValueState 中存 List。 大佬们已经把 MapState 和 ListState 性能都做了很多优化，高性能不香吗？ 下文会详细分析 ValueState 和 MapState 底层的实现原理，通过分析原理得出上述结论。 2、 State 中要存储哪些数据 ValueState 会存储 key、namespace、value，缩写为 <K, N, V>。 MapState 会存储 key

本篇介绍典型的基于SStable的存储。适用于与SSD一起使用。更多存储相关见： https://segmentfault.com/a/11... 。涉及到leveldb,rocksdb。基本上分布式都要单独做，重点是单机架构，数据写入，合并，ACID等功能和性能相关的。 先对性能有个直观认识： mysql写入千条/s，读万应该没问题。redis 写入 万条/s 7M/s(k+v 700bytes，双核)读是写入的1.4倍 mem 3gb 2核。这两个网上搜的，不保证正确，就看个大概吧。 SSD上 rocksdb随机和顺序的性能差不多，写要比读性能稍好。随机读写1.7万条/s 14M/s （32核）。batch_write/read下SSD单线程会好8倍。普通write只快1.2倍。 没有再一个机器上的对比。rocksdb在用SSD和batch-write/read下的读写性能还是可以的。 第一章 levelDb 架构图 读取过程 数据的读取是按照 MemTable、Immutable MemTable 以及不同层级的 SSTable 的顺序进行的，前两者都是在内存中，后面不同层级的 SSTable 都是以 *.ldb 文件的形式持久存储在磁盘上 写入过程 1.调用 MakeRoomForWrite 方法为即将进行的写入提供足够的空间； 在这个过程中，由于 memtable

1.简介 RocksDB项目起源于Facebook的一个实验项目,该项目旨在开发一个与快速存储器（尤其是闪存）存储数据性能相当的数据库软件，以应对高负载服务。 这是一个c++库,可用于存储键和值,可以是任意大小的字节流。它支持原子读和写。 RocksDB具有高度灵活的配置功能,可以通过配置使其运行在各种各样的生产环境,包括纯内存,Flash,硬盘或HDFS。它支持各种压缩算法，并提供了便捷的生产环境维护和调试工具。 RocksDB借鉴了开源项目LevelDB的重要代码和Apache HBase项目的重要思想。最初的代码来源于开源项目leveldb 1.5分叉。它借鉴了了Facebook的代码和思想。 2.假设和目标 性能: RocksDB的主要设计目标是保证存取快速存储器和高负载服务器更高效，保证充分利用Flash或RAM子系统提供的高速率读写， 支持高效的查找和范围scan，支持高负载的随机读、高负载的更新操作或两者的结合。其架构应该支持高并发读写和容量大增时系统的一致性。 产品支持: RocksDB内置了用于生产环境中部署和调试的工具和实用程序。大多数主要参数应该是可调整的,以便可以被不同的应用程序在不同的硬件中使用。。 向后兼容性: 这个软件的新版本应该是向后兼容的,因此,当升级到新版本时现有的应用程序不需要改变。 3.高级体系结构 RocksDB是一个嵌入式键值存储器

written by Alex Stocks on 2018/03/28，版权所有，无授权不得转载 0 说明 近日工作中使用了 RocksDB。RocksDB 的优点此处无需多说，它的一个 feature 是其有很多优化选项用于对 RocksDB 进行调优。欲熟悉这些参数，必须对其背后的原理有所了解，本文主要整理一些 RocksDB 的 wiki 文档，以备自己参考之用。 1 Basic Operations 先介绍一些 RocksDB 的基本操作和基本架构。 1.1 LSM 与 WriteBatch 参考文档5 提到RocksDB 是一个快速存储系统，它会充分挖掘 Flash or RAM 硬件的读写特性，支持单个 KV 的读写以及批量读写。RocksDB 自身采用的一些数据结构如 LSM/SKIPLIST 等结构使得其有读放大、写放大和空间使用放大的问题。 LSM 大致结构如上图所示。LSM 树而且通过批量存储技术规避磁盘随机写入问题。 LSM 树的设计思想非常朴素, 它的原理是把一颗大树拆分成N棵小树， 它首先写入到内存中（内存没有寻道速度的问题，随机写的性能得到大幅提升），在内存中构建一颗有序小树，随着小树越来越大，内存的小树会flush到磁盘上。磁盘中的树定期可以做 merge 操作，合并成一棵大树，以优化读性能【读数据的过程可能需要从内存 memtable 到磁盘

1.OperatorChain 1.1 OperatorChain的优点 1.1.1 减少线程切换 1,1.2 减少序列化与反序列化 1.1.3 减少数据在缓冲区的交换 1.1.4 减少延迟并且提高吞吐能力 1.2 OperatorChain组成条件 1.2.1 没有禁用Chain 1.2.2 上下游算子并行度一致 1.2.3 下游算子的入度为1（也就是说下游节点没有其他节点的输入） 1.2.4 上下游算子在同一个slot group 1.2.5 下游节点的chain策略为always（可以与上下游链接，map、flatmap、filter等默认是always） 1.2.6 上有节点的chain策略为always或head(只能与下游链接，不能与上有链接,source默认是head) 1.2.7 上下游算子之间没有数据shuffle(数据分区方式是forward) 1.3 禁用OperatorChain几种方式 1.3.1 DataStream的算子操作后调用startNewChain算子 1.3.2 DataStream调用disableChaining来关闭Chain 1.3.3 StreamExecutionEnvironment.getExecutionEnvironment.disableOperatorChaining() 全局关闭 1.3.4 DataStream