leveldb

RocksDB属于嵌入式数据库，没有网络交互接口，必须和服务部署在同一台服务器。RocksDB是Facebook公司在LevelDB基础之上开发的一个嵌入式KV系统，在很多方面对LevelDB做了优化和增强，更像是一个完整的产品。有如下特征: 高性能 : RocksDB使用日志结构的数据库引擎，完全用C++编写，以获得最大的性能。 键和值是任意大小的字节流。 为快速存储而优化 : RocksDB针对快速、低延迟的存储(如闪存驱动器和高速磁盘驱动器)进行了优化。RocksDB充分利用了flash或RAM提供的高读/写速率的潜力。 适应性强 : RocksDB 可以适应不同的工作负载。 从 MyRocks 等数据库存储引擎到应用程序数据缓存到嵌入式工作负载，RocksDB 可以用于满足各种数据需求。 基础和高级数据库操作 : RocksDB提供了一些基本操作，比如打开和关闭数据库，读与写，合并和压缩过滤器等高级操作。 参考了如下文档: RocksJava Basics Java RocksDB简单入门 Maven依赖(pom.xml) <dependency> <groupId>org.rocksdb</groupId> <artifactId>rocksdbjni</artifactId> <version>6.6.4</version> </dependency> 完整代码示例

线上一台服务器在执行leveldb程序的时候，报错： "libc.so.6: version `GLIBC_2.14' not found" 。 排查原因及解决方法如下： 1）产生原因 是由于Linux系统的glibc版本太低，而软件编译时使用了较高版本的glibc引起的！ 查看系统glibc支持的版本 [root@localhost ~]# strings /lib64/libc.so.6 |grep GLIBC_ GLIBC_2.2.5 GLIBC_2.2.6 GLIBC_2.3 GLIBC_2.3.2 GLIBC_2.3.3 GLIBC_2.3.4 GLIBC_2.4 GLIBC_2.5 GLIBC_2.6 GLIBC_2.7 GLIBC_2.8 GLIBC_2.9 GLIBC_2.10 GLIBC_2.11 GLIBC_2.12 GLIBC_PRIVATE [root@localhost ~]# rpm -qa |grep glibc glibc-common-2.12-1.209.el6_9.2.x86_64 glibc-2.12-1.209.el6_9.2.x86_64 glibc-headers-2.12-1.209.el6_9.2.x86_64 glibc-devel-2.12-1.209.el6_9.2.x86_64 可以看到最高只支持2.12版本

想必看到此篇的同学对于newSQL已经不是很陌生了，那么直接进入今天的主题： mysql的问题在哪？ 一、不能通过mysql的server把InnoDB变成一个分布式数据库。 因为mysql生成的执行计划是个单机的 二、一个分布式的plan执行起来很复杂且低效。 比如使用分布式方案Proxy，因为它不支持分布式的transaction，也不支持跨节点的join 三、异步或半同步复制 因为有时候数据出问题你不知道是否应该切换节点，因为异步的方式会导致一部分数据“还在路上”。尤其是对于多数据中心的复制和数据中心的容灾。 而NewSQL真正发展起来是在2014年末到2015年初的时候，Raft论文发表之后，真正的NewSQL理论基础就基本确立了。 那么从技术实现的角度分析，为什么这样的技术会诞生呢？它又能解决哪些过去的产品解决不了或者不是最优方案的场景呢？ 首先，举一个范围查询的例子，如果要查找一个班级里成绩在80-90之间的学生，那么通过KV的API的要很麻烦的，但是SQL的优化器就很容易解决此类问题，写一句SQL就可以搞定。 其次是高可用，未来的系统肯定是要设计成Auto-Failover的，即自动恢复，需要人工去干预的容灾系统不是好厨子。 然后针对业务还要说几点： 比如按照ID去分库分表，比如使用一致性哈希去指导节点均衡。如果问题上升到了一定的复杂度

一、说明 　　实际的应用中，一般为了应用的高可用性，都会搭建集群环境去处理。部署多台应用，这样，即使一台有问题，其他热备应用可以立马顶上，继续提供服务。 　　ActiveMQ的集群部署，基于zookeeper的应用程序协调服务和levelDB的持久化方案。 　　本文中，基于一个系统环境，搭建伪集群模式，通过不同端口的配置，达到集群安装的效果。 　　基本环境：jdk-7u80-linux-x64.tar.gz、Centos 6.9、zookeeper-3.4.12.tar.gz、apache-activemq-5.9.1-bin.tar.gz、Xshell。 　　应用部署：zookeeper启动3个应用实例，ActiveMQ部署3套应用实例，构成最小单元的集群部署 　　其中zookeeper的集群搭建，参见之前文章： https://www.cnblogs.com/eric-fang/p/9283904.html 二、ActiveMQ的集群配置 　　ActiveMQ的主从模型，是一种高可用的解决方案，在zookeeper中注册若干的ActiveMQ Broker，其中只有一台作为主机master对外提供服务，其他作为备份slave保持待机。当master出现问题导致宕机不能正常提供服务的时候，zookeeper通过内部选举，在众多slave中推举出一台作为master继续对外提供服务

前言 在有代表性的关系型数据库如MySQL、SQL Server、Oracle中，数据存储与索引的基本结构就是我们耳熟能详的B树和B+树。而在一些主流的NoSQL数据库如HBase、Cassandra、LevelDB、RocksDB中，则是使用日志结构合并树（Log-structured Merge Tree，LSM Tree）来组织数据。本文先由B+树来引出对LSM树的介绍，然后说明HBase中是如何运用LSM树的。 回顾B+树 为什么在RDBMS中我们需要B+树（或者广义地说，索引）？一句话：减少寻道时间。在存储系统中广泛使用的HDD是磁性介质+机械旋转的，这就使得其顺序访问较快而随机访问较慢。使用B+树组织数据可以较好地利用HDD的这种特点，其本质是多路平衡查找树。下图是一棵高度为3的4路B+树示例。 与普通B树相比，B+树的非叶子节点只有索引，所有数据都位于叶子节点，并且叶子节点上的数据会形成有序链表。B+树的主要优点如下： 结构比较扁平，高度低（一般不超过4层），随机寻道次数少； 数据存储密度大，且都位于叶子节点，查询稳定，遍历方便； 叶子节点形成有序链表，范围查询转化为顺序读，效率高。相对而言B树必须通过中序遍历才能支持范围查询。 当然，B+树也不是十全十美的，它的主要缺点有两个： 如果写入的数据比较离散，那么寻找写入位置时，子节点有很大可能性不会在内存中

摘要： Hash索引有两个明显的限制：（1）当key的数量很多时，维护Hash索引会给内存带来很大的压力；（2）区间查询很低效。如何对这两个限制进行优化呢？这就轮到本文介绍的主角，LSM树，出场了。 我们通过 append-only log 的数据结构，实现了一个具备高写入性能的key-value数据库。 append-only log 之所以有很高的写入性能，主要 得益于磁盘的顺序写入 。这可能违反了我们对磁盘的认知，因为在我们的印象中，写磁盘总是很慢。其实不然，准确地说应该是 随机写磁盘很慢 ，因为在写之前可能会进行多次寻址。如果只是顺序写磁盘，性能是非常的高，如下的一个ACM报告中显示，顺序写磁盘甚至比随机写内存的性能还要高！ 举个例子，Kafka是一个高性能的消息队列，它的厉害之处就在于极致地利用磁盘的顺序写入性能，如果生产者和消费者的速率相当，消息甚至可以在操作系统的Page Cache层面就完成了传递。所以，以后别再认为写磁盘很慢了！ append-only log 大幅提升了数据写入性能，但是随之而来的是，非常低的数据读取性能。针对这一点，我们采用Hash索引进行了优化，优化的效果也非常的显著。然而，Hash索引有两个明显的限制：（1）当key的数量很多时，维护Hash索引会给内存带来很大的压力；（2）区间查询很低效。如何对这两个限制进行优化呢？这就轮到本文介绍的主角

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

本篇介绍典型的基于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 前言 内存管理是Linux内核中非常重要的部分，今天和大家一起学习一下。 当我们要学习一个新知识点时，比较好的过程是先理解出现这个技术点的 背景原因 ，同期其他解决方案，新 技术点解决了什么问题以及它存在哪些不足和 改进之处 ，这样整个学习过程是 闭环 的，个人觉得这是个很好的学习思路。 凡事都是相通的 ，计算机学科的一些问题在现实生活中都可以找到原型，所以我觉得计算机科学家大部分都是善于观察生活并总结归纳的。 人类社会就是一台复杂的机器，其中充满了机制和规则，所以有时候跳进代码海洋不如先回到生活之中， 寻找原型再探究代码 ，可能理解会更深刻。 linux内存管理 卷帙浩繁 ，本文只能 层层递进 地带你领略 冰山轮廓 ，通过本文你将了解到以下内容： 为什么需要管理内存 linux段页管理机制 内存碎片的产生机理 伙伴系统的基本原理 伙伴系统的优势和不足 slab分配器的基本原理 2 为什么需要管理内存 老子的著名观点是无为而治，简单说就是不过多干预而充分依靠自觉就可以有条不紊地运作，理想是美好的，现实是残酷的。 在linux系统中如果以一种原始简单的方式管理内存是存在一些问题的，我们来看几个场景。 2.1 内存管理的问题 进程空间隔离问题 假如现在有ABC三个进程运行在linux的内存空间，设定os给进程A分配的地址空间是0-20M 进程B地址空间30-80M