leveldb

LevelDB是一个可持久化的KV数据库引擎，由Google传奇工程师Jeff Dean和Sanjay Ghemawat开发并开源。无论从设计还是代码上都可以用精致优雅来形容，非常值得细细品味。本文将从整体特性、架构和使用等几方面做一个解释，试图通过本文的介绍让大家对LevelDB有个整体的认识并能够使用。 设计思路 做存储的同学都很清楚，对于普通机械磁盘顺序写的性能要比随机写大很多。比如对于15000转的SAS盘，4K写IO， 顺序写在200MB/s左右，而随机写性能可能只有1MB/s左右。而LevelDB的设计思想正是利用了磁盘的这个特性。 LevelDB的数据是存储在磁盘上的，采用LSM-Tree的结构实现。LSM-Tree将磁盘的随机写转化为顺序写，从而大大提高了写速度。为了做到这一点LSM-Tree的思路是将索引树结构拆成一大一小两颗树，较小的一个常驻内存，较大的一个持久化到磁盘，他们共同维护一个有序的key空间。写入操作会首先操作内存中的树，随着内存中树的不断变大，会触发与磁盘中树的归并操作，而归并操作本身仅有顺序写。如下图所示： 图1 数据存储原理 图中2个红色区域是要进行归并的数据块，计算出顺序后会存储到如图下面的磁盘空间，而这种存储方式是追加式的，也就是顺序写入磁盘。 随着数据的不断写入，磁盘中的树会不断膨胀，为了避免每次参与归并操作的数据量过大

LSM-tree 在 NoSQL 系统里非常常见，基本已经成为必选方案了。今天介绍一下 LSM-tree 的主要思想，再举一个 LevelDB 的例子。 正文 3056 字，预计阅读时间 8 分钟。 LSM-tree 起源于 1996 年的一篇论文《The Log-Structured Merge-Tree (LSM-Tree)》，这篇论文 32 页，我一直没读，对 LSM 的学习基本都来自顶会论文的背景知识以及开源系统文档。今天的内容和图片主要来源于 FAST'16 的《WiscKey: Separating Keys from Values in SSD-conscious Storage》。 先看名字，log-structured，日志结构的，日志是软件系统打出来的，就跟人写日记一样，一页一页往下写，而且系统写日志不会写错，所以不需要更改，只需要在后边追加就好了。各种数据库的写前日志也是追加型的，因此日志结构的基本就指代追加。注意他还是个 “Merge-tree”，也就是“合并-树”，合并就是把多个合成一个。 好，不扯淡了，说正文了。 LSM-tree 是专门为 key-value 存储系统设计的，key-value 类型的存储系统最主要的就两个个功能，put（k，v）：写入一个（k，v），get（k）：给定一个 k 查找 v。 LSM-tree 最大的特点就是写入速度快

I have searched for key value stores that support integer keys and integer values. LevelDB seems a good option, though I can't find any information on whether integer values/keys are supported You can store pretty much anything in LevelDB. You provide opaque slices of data into LevelDB via the Slice structure. Here is an example: int intKey = 256; int intValue = 256*256; Slice key((char*)&intKey, sizeof(int)); Slice value((char*)&intValue, sizeof(int)); db->Put(leveldb::WriteOptions(), key, value); And that's pretty much it! However , one thing to note is that while it's generally fine to

一、概述 Reveldb 是个人在空余时间和周末完成(应该说还远远未完善)的一个基于 google leveldb 的 NoSQL 数据服务器，网络连接采用了 libevent 的 HTTP 接口，因此 reveldb 天生就适合处理 HTTP 请求。但更确切地说，reveldb 并没有直接采用 libevent 的 HTTP 接口，而是使用了另外一个基于 libevent 的网络连接库 libevhtp (https://github.com/ellzey/libevhtp)，并对它做了适当的修改，使之成为 reveldb 的底层组件 evhttpx ( https://github.com/forhappy/reveldb/tree/master/src/evhttpx ), evhttpx 为 reveldb 提供了 HTTP 和 HTTPS 支持，因此，reveldb 除了能够处理 HTTP 请求外，也能够处理 HTTPS 请求，这一特性是 Kyoto Tycoon 没有的，如果它有，请您告诉我 :-) Kyoto Tycoon （以下简称KT）是 Tokyo Tyrant 的作者Mikio Hirabayashi 的系列作品之一，KT 是一个数据库网络层服务。Reveldb 定位与 KT 类似，也是一个数据库网络层的服务，具体一点就是 Leveldb 的网络层接口(因为

用虚拟机搭建私链的问题 上一篇 Neo私链 中使用四台阿里云的windows搭建了私链，看到了网络建立的过程，但这样子有很多问题。 阿里云跑了一天花了100块，费钱。 手动搭建，下次又要重来。 我用的mac电脑，跑windows虚拟机很费劲。 总之，如果可以脚本化，自动化就更好了。所以总结一下用docker搭建私链。 另外我的目的是研究代码，而研究代码光看不行，还要深入细节，如果可以调试就好了。调试一般分为两种，最简单的是看log，这种方法其实已经很无敌了，加上时间可以看性能，时序相关的问题；输出到文件可以调查长期运行后发生的错误。不过作为一个工具控，我还是要找到打断点调试的方法，说白了，打断点比在源码中插入很多log要方便点，还是人懒。 创建私链并打断点调试的方案 现在有以下几个方案，我都试验了，因为在mac上搞Neo，花了不少时间： mac上用docker跑一个私链，用vs code远程调试。 mac上用docker跑一个私链，自己再开一个debug节点，调试本节点。 在windows虚拟机里面用docker跑一个私链，自己在再一个debug节点，调试。 结论： 方法1：在mac中用vs code远程调试总是失败，不能获取调试进程，获取到了也调试不了，浪费了一天时间检查各种问题，最终放弃。 方法2：在mac上用docker跑私链是没问题，但是mac上调试neo-cli。。

WebSQL and IndexedDB are both DB API for accessing (CRUD) the underlying embedded database in the web browser. Which, if I am correct, is like SQL for accessing (CRUD) any client-server database like Oracle etc. (in many case support for both WebSQL and IndexedDB is available on same browser) So, does it mean that both WebSQL and IndexedDB are accessing (CRUD) the same underlying embedded database and if that it the case then it will have same performance on all web browsers! But I think that is not the case, so does it mean that a web browser will have more than one underlying embedded

2013-11-17 性能超越 Redis 的 NoSQL 数据库 SSDB C语言编程 , SSDB Views: 749 | 4 Comments SSDB 是一个 C++ 开发的 NoSQL 数据库, 使用 Google 公司开源的 LevelDB 引擎作为底层的存储引擎. Redis 是一个 C 语言开发的内存 NoSQL 数据库. Redis 非常流行, 不仅仅是因为其高性能和可持久化的特点, 还因为它支持丰富的数据结构, 能很好的表达业务模型. Redis 的国内属新浪应用比较广泛. 但是, Redis 的缺点也很明显, 那就是它的内存数据库模型. 所有数据都存在内存中, 即使最有钱的互联网公司, 也没法承受 $5000 (一台服务器, 100G 内存)固定成本, 以及持续不断的 IDC 租金成本来存储区区的 50GB 的数据, 这个成本太高了! SSDB 拥有 Redis 的主要优点 – 高性能, 丰富数据结构, 并且拥有 Redis 所不具备的能力 – 大数据存储能力. SSDB 服务器的单机存储能力是 Redis 的 100 倍! 因为 SSDB 能将数据存储在硬盘中. 在使用 SSDB 自带的 ssdb-bench 工具, 以及 Redis 自带的 redis-benchmark 工具在相同机器上的测试中, SSDB 的读性能完全超过了 Redis ,

Leveldb是一个google实现的非常高效的kv数据库，是单进程的服务，能够处理十亿级别规模Key-Value型数据，占用内存小。 基于可复制LevelDB的集群方案，需要引入ZooKeeper。根据ZooKeeper的使用方式可以分为单节点的ZooKeeper和Zookeeper集群。这里我们只讲述ZooKeeper集群，单节点不是一个可靠的选择。 4.1 Zookeeper集群配置 ZooKeeper可以在网站http://zookeeper.apache.org/ 下载。我们使用的是zookeeper-3.4.6，假设ZooKeeper分部署在下面三个目录中。 D:\MQ\apache-activemq\cluster\zookeeper1 D:\MQ\apache-activemq\cluster\zookeeper2 D:\MQ\apache-activemq\cluster\zookeeper3 4.1.1 zoo.cfg 把3个节点中config目录下的zoo_sample.cfg复制一份，改成zoo.cfg。 因为是在一台主机上部署，所以每个zoo.cfg中的clientPort不能重复；如果有三台主机，那么采用默认的clientPort就行，同理server.1、server.2、server.3可以写作<各自ip>:2888:3888。