在我们的MySQL，Master和Slave进行主从切换的时候，Slave成功升级为主库，那么这个时候就需要彻底清理从库的信息，不然监控系统会认为这台服务器是Slave，而且会报主从同步失败。
    其实非常的简单，只需要以下两步：
   

stop slave;

reset slave all;

RESET SLAVE ALL是清除从库的同步复制信息、包括连接信息和二进制文件名、位置。
从库上执行这个命令后，使用show slave status将不会有输出。

收起阅读 »

         对于刚开始学习Jenkins的用户，在研究用户权限的时候可能会遇到因为权限设置失败导致无法正常使用Jenkins，连admin用户也无法正常使用。这个时候就需要通过修改配置来解决。

1.停止jenkins

[root@api-node1 ~]# systemctl stop jenkins

2.修改config.xml

[root@api-node1 ~]# vim /var/lib/jenkins/config.xml

true 修改为:false

删除和到

例如删除以下内容：

  

  

    true

    false

  

3.启动jenkins

[root@api-node1 ~]# systemctl start jenkins

4.再次访问Jenkins后，首先要设置登录认证。

  收起阅读 »

        GitLab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。
        GitLab拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
       1.基础环境准备

[root@linux-node2 ~]# yum install curl policycoreutils openssh-server openssh-clients postfix

[root@linux-node2 ~]# systemctl start postfix

    2.安装gitlab-ce

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

[root@linux-node2 ~]# yum install -y gitlab-ce-10.8.7

注：由于网络问题，国内用户，建议使用清华大学的镜像源进行安装：

 

[root@linux-node2 ~]# vim /etc/yum.repos.d/gitlab-ce.repo

[gitlab-ce]

name=gitlab-ce

baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7

repo_gpgcheck=0

gpgcheck=0

enabled=1

gpgkey=https://packages.gitlab.com/gpg.key

[root@linux-node2 ~]# yum makecache

[root@linux-node2 ~]# yum install gitlab-ce

3.配置并启动gitlab-ce

[root@linux-node2 ~]# gitlab-ctl reconfigure

可以使用gitlab-ctl管理gitlab，例如查看gitlab状态：

[root@linux-node2 ~]# gitlab-ctl status

run: gitlab-workhorse: (pid 12171) 231s; run: log: (pid 7817) 555s

run: logrotate: (pid 12175) 230s; run: log: (pid 7832) 548s

run: nginx: (pid 12181) 230s; run: log: (pid 7823) 549s

run: postgresql: (pid 12186) 229s; run: log: (pid 7683) 587s

run: redis: (pid 12194) 229s; run: log: (pid 7600) 592s

run: sidekiq: (pid 12198) 229s; run: log: (pid 7806) 558s

run: unicorn: (pid 14967) 6s; run: log: (pid 7774) 560s

关闭gitlab：[root@linux-node2 ~]# gitlab-ctl stop

启动gitlab：[root@linux-node2 ~]# gitlab-ctl start

重启gitlab：[root@linux-node2 ~]# gitlab-ctl restart

登录gitlab
      第一次登录gitlab，需要为root用户修改密码，root用户也是gitlab的超级管理员。



管理gitlab
    使用root用户和刚才创建的密码登录后，你就可以探索gitlab的奥秘了，可以点击图中红框的按钮进入管理区域。






  收起阅读 »

    Ambari是 Apache Software Foundation 中的一个顶级项目。Ambari可以创建、管理、监控 Hadoop 的集群。包括整个Hadoop生态圈（例如 Hive，Hbase，Sqoop，Zookeeper 等）。无论是初学者像快速部署一套Hadoop环境，还是用于生产的自动化部署，Ambari都可以满足。
     你可以在官网http://ambari.apache.org/获取最新的Ambari的内容，目前Ambari还支持流行的 Spark，Storm 等计算框架，Kafka消息队列、以及资源调度平台 YARN 等。
    Ambari 自身也是一个分布式架构的软件，主要由两部分组成：Ambari Server 和 Ambari Agent。我们可以通过 Ambari Server 通知 Ambari Agent 安装对应的软件；甚至连Ambari Agent我们都可以在Web界面上来进行安装和部署。
    Ambari Agent 会定时地发送各个机器每个项目组件的当前状态给 Ambari Server，并在Web界面上进行展示汇总，方面我们及时掌握集群状态。

基础环境准备
    本次实验环境还是使用两台虚拟机来实现，有条件的读者建议使用三台虚拟机来做。首先我们要实现Ambari Server到各个节点之间的SSH无密码登录。
在所有节点都执行ssh-keygen -t rsa 生成Key

[root@linux-node1 ~]# ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): 

Enter passphrase (empty for no passphrase): 

Enter same passphrase again: 

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

    虽然除了Server端之外其它节点可以不执行，但是ssh-keygen命令会帮我们创建相应的目录并设置权限，不在需要我们手动操作。

将Ambari Server的公钥scp到其它节点上

[root@linux-node1 ~]# scp .ssh/id_rsa.pub 192.168.56.12:/root/.ssh/authorized_keys

设置权限

[root@linux-node2 ~]# chmod 600 ~/.ssh/authorized_keys

测试连接

[root@linux-node1 ~]# ssh 192.168.56.12

Last login: Sat Apr  2 16:42:46 2016 from 192.168.56.1

[root@linux-node2 ~]#

设置完毕无密码登录后，我们就可以开始部署ambari-server了。

安装jdk
    由于ambari安装过程中的jdk下载比较缓慢，所以我们可以直接使用yum仓库里面的openjdk

[root@linux-node1 ~]# yum install -y java-1.8.0

部署ambari-server
    ambari-server的部署比较简单，很多实用实用默认即是最好的选择。
安装ambari-server

[root@test-node3 ~]# cd /etc/yum.repos.d/

# wget http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.2.0.0/ambari.repo

# yum install -y ambari-server

注意：在国内的用户要有心里准备，ambari-server这个包有354M，下载比较慢。

设置ambari-server

    安装完毕后，需要使用ambari-server setup命令进行设置，均可以使用默认设置，直接回车即可。

[root@linux-node1 ~]# ambari-server setup

Using python  /usr/bin/python2

Setup ambari-server

Checking SELinux...

SELinux status is 'disabled'

Customize user account for ambari-server daemon [y/n] (n)? 

Adjusting ambari-server permissions and ownership...

Checking firewall status...

Redirecting to /bin/systemctl status  iptables.service



Checking JDK...

[1] Oracle JDK 1.8 + Java Cryptography Extension (JCE) Policy Files 8

[2] Oracle JDK 1.7 + Java Cryptography Extension (JCE) Policy Files 7

[3] Custom JDK

===========================================================================

Enter choice (1): 3

WARNING: JDK must be installed on all hosts and JAVA_HOME must be valid on all hosts.

WARNING: JCE Policy files are required for configuring Kerberos security. If you plan to use Kerberos,please make sure JCE Unlimited Strength Jurisdiction Policy Files are valid on all hosts.

Path to JAVA_HOME: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.77-0.b03.el7_2.x86_64/jre/

Validating JDK on Ambari Server...done.

Completing setup...

Configuring database...

Enter advanced database configuration [y/n] (n)?

Configuring database...

Default properties detected. Using built-in database.

Configuring ambari database...

Checking PostgreSQL...

Running initdb: This may take upto a minute.

Initializing database ... OK

About to start PostgreSQL

Configuring local database...

Connecting to local database...done.

Configuring PostgreSQL...

Restarting PostgreSQL

Extracting system views...

ambari-admin-2.2.0.0.1310.jar

......

Adjusting ambari-server permissions and ownership...

Ambari Server 'setup' completed successfully.

• 1)    检测SELinux2)    询问是否自定义用户，默认否-（可以安装完毕之后再进行用户管理。）3)    检测iptables选择JDK版本，默认Oracle JDK 1.8。如果你已经安装了jdk，可以选择自定义jdk。如果你是yum安装的openjdk，那么路径位于/usr/lib/jvm/java-1.8.0-openjdk-xxx.x86_64/jre/4)    目录下。5)    询问是否打开高级的数据库配置，默认-否

启动ambari-server

[root@linux-node1 ~]# ambari-server start

查看监听端口

[root@linux-node1 ~]# netstat -ntlp | grep 8080

tcp6       0      0 :::8080                 :::*                    LISTEN      24168/java

访问ambari server

现在可以在浏览器访问你的ambari server了。注意端口是8080。

http://192.168.56.11:8080/

默认的用户名和密码都是admin


创建Hadoop集群

登录 Ambari 之后，点击按钮“Launch Install Wizard”，就可以开始创建属于自己的大数据平台。


1.设置集群的名称


2.选择一个Stack，默认使用最新版本。


3.填写你环境的所有主机名，并上传验证的公钥。注意使用FQDN名称，并且主机名要能够解析。

4.选择需要安装的组件


5.角色分配


其它步骤均使用默认配置即可。 收起阅读 »

作者 陶文 发布于 2015年8月11日  转载自：http://www.infoq.com/cn/articles/database-timestamp-01

什么是时间序列数据？最简单的定义就是数据格式里包含timestamp字段的数据。比如股票市场的价格，环境中的温度，主机的CPU使用率等。但 是又有什么数据是不包含timestamp的呢？几乎所有的数据都可以打上一个timestamp字段。时间序列数据更重要的一个属性是如何去查询它。在 查询的时候，对于时间序列我们总是会带上一个时间范围去过滤数据。同时查询的结果里也总是会包含timestamp字段。

选择什么样的时间序列数据库

时间序列数据无处不在。而几乎任意数据库都可以存时间序列数据。但是不同的数据能支持的查询类型并不相同。按照能支持的查询类型，我们可以把时间序列数据库分为两类，第一类的数据库按照关系型数据库的说法，其表结构是这样的：

[metric_name] [timestamp] [value]

其优化的查询方式是：

SELECT value FROM metric WHERE metric_name=”A” AND timestamp >= B AND timestamp < C

也就说这类数据库是什么样子的数据存进去，就什么样子取出来。



在这种模式下，首先要知道你需要的图表是什么样子的。然后按照这个图表的数据，去把数据入库。查询的字段，就是数据库存储的字段。然后再按照数据库存储的 字段，去从原始数据里采集上报。存储什么字段，就上报什么字段。这种模式很容易优化，可以做到非常快。但是这种模式有两个弊端。

1. 无法快速响应变化：如果需要的图表有变更，需要从上报的源头重新来一遍。而且要等新数据过来之后，才能查看这些新数据。
2. 存储膨胀：总有一些数据是需要从不同维度查询的要求。比如广告点击流数据，需要按省份聚合，按运营商聚合，按点击人的喜好聚合等。这些维度的交叉组合会产生非常巨大的组合数量，要预先把所有的维度组合都变成数据库里的表存储起来会很浪费空间。

这类时间序列数据库最多，使用也最广泛。一般人们谈论时间序列数据库的时候指代的就是这一类存储。按照底层技术不同可以划分为三类。

    直接基于文件的简单存储：RRD Tool，Graphite Whisper。这类工具附属于监控告警工具，底层没有一个正规的数据库引擎。只是简单的有一个二进制的文件结构。

    基于K/V数据库构建：opentsdb（基于hbase），blueflood，kairosDB（基于cassandra），influxdb，prometheus（基于leveldb）

    基于关系型数据库构建：mysql，postgresql 都可以用来保存时间序列数据

另外一类数据库其表结构是：

[timestamp] [d1] [d2] .. [dn] [v1] [v2] .. [vn]

其优化的查询方式不限于查询原始数据，而是可以组合查询条件并且做聚合计算，比如：

SELECT d2, sum(v1) / sum(v2) FROM metric WHERE d1 =

 “A” AND timestamp >= B AND timestamp < C GROUP BY d2

我们希望时间序列数据库不仅仅可以提供原始数据的查询，而且要支持对原始数据的聚合能力。这种聚合可以是在入库阶段完成的，所谓物化视图。也可以是在查询阶段完成，所谓实时聚合。根据实际情况，可以在这两种方式中进行取舍。

想要在在查询阶段做数据的聚合和转换，需要能够支持以下三点。

• 用索引检索出行号：能够从上亿条数据中快速过滤出几百万的数据。


• 从主存储按行号加载：能够快速加载这过滤出的几百万条数据到内存里。


• 分布式计算：能够把这些数据按照GROUP BY 和 SELECT 的要求计算出最终的结果集。

要想尽可能快的完成整个查询过程，需要在三个环节上都有绝招。传统上说，这三个步骤是三个不同的技术领域。

• 检索：这是搜索引擎最擅长的领域。代表产品是Lucene。其核心技术是基于高效率数据结构和算法的倒排索引。


• 加载：这是分析型数据库最擅长的领域。代表产品是C-store和Monetdb。其核心技术是按列组织的磁盘存储结构。


• 分布式计算：这是大数据计算引擎最擅长的领域。代表产品是Hadoop和spark。其核心技术是sharding 和 map/reduce等等。

前面提到的时间序列库（比如opentsdb）有不少从功能上来说是没有问题。它们都支持过滤，也支持过滤之后的聚合计算。在数据量小的时候勉强是可用的。但是如果要实时从十亿条里取百万记录出来，再做聚合运算，对于这样的数据量可能就勉为其难了。满足海量数据实时聚合要求的数据库不多，比较常见的有这么几种：

• 基于Lucene构建的“搜索引擎”：Elasticsearch, Crate.io（虽然是基于Elasticsearch，但是聚合逻辑是自己实现的），Solr；


• 列式存储数据库：Vertica（C-store的后裔）Actian（Monetdb的后裔）等；


• Druid.io。

其中Elasticsearch是目前市场上比较很少有的，能够在检索加载和分布式计算三个方面都做得一流的数据库。而且是开源并且免费的。它使用了很多技术来达到飞一般的速度。这些主要的优化措施可以列举如下。

• Lucene的inverted index可以比mysql的b-tree检索更快。


• 在 Mysql中给两个字段独立建立的索引无法联合起来使用，必须对联合查询的场景建立复合索引。而lucene可以任何AND或者OR组合使用索引进行检索。


• Elasticsearch支持nested document，可以把一批数据点嵌套存储为一个document block，减少需要索引的文档数。


• Opentsdb不支持二级索引，只有一个基于hbase rowkey的主索引，可以按行的排序顺序scan。这使得Opentsdb的tag实现从检索效率上来说很慢。


• Mysql 如果经过索引过滤之后仍然要加载很多行的话，出于效率考虑query planner经常会选择进行全表扫描。所以Mysql的存储时间序列的最佳实践是不使用二级索引，只使用clustered index扫描主表。类似于Opentsdb。


• Lucene 从 4.0 开始支持 DocValues，极大降低了内存的占用，减少了磁盘上的尺寸并且提高了加载数据到内存计算的吞吐能力。


• Lucene支持分segment，Elasticsearch支持分index。Elasticsearch可以把分开的数据当成一张表来查询和聚合。相比之下Mysql如果自己做分库分表的时候，联合查询不方便。


• Elasticsearch 从1.0开始支持aggregation，基本上有了普通SQL的聚合能力。从 2.0 开始支持 pipeline aggregation，可以支持类似SQL sub query的嵌套聚合的能力。这种聚合能力相比Crate.io，Solr等同门师兄弟要强大得多。

最后，再次推荐下INFOQ，作为运维工程师，要时刻关注，上面有很多好文章。 收起阅读 »

本文转载自：https://segmentfault.com/a/1190000000444617

InfluxDB 是一个开源分布式时序、事件和指标数据库。使用 Go 语言编写，无需外部依赖。其设计目标是实现分布式和水平伸缩扩展。

特点：

1. schemaless(无结构)，可以是任意数量的列
2. Scalable
3. min, max, sum, count, mean, median 一系列函数，方便统计
4. Native HTTP API, 内置http支持，使用http读写
5. Powerful Query Language 类似sql
6. Built-in Explorer 自带管理工具

管理界面:



API

InfluxDB 支持两种api方式

1. HTTP API
2. Protobuf API

Protobuf 还未开发完成, 官网文档都没有

如何使用 http api 进行操作？

比如对于foo_production这个数据库，插入一系列数据，可以发现POST 请求到 /db/foo_production/series?u=some_user&p=some_password, 数据放到body里。

数据看起来是这样的:

下面的"name": "events", 其中"events"就是一个series,类似关系型数据库的表table

[

  {

    "name": "events",

    "columns": ["state", "email", "type"],

    "points": [

      ["ny", "paul@influxdb.org", "follow"],

      ["ny", "todd@influxdb.org", "open"]

    ]

  },

  {

    "name": "errors",

    "columns": ["class", "file", "user", "severity"],

    "points": [

      ["DivideByZero", "example.py", "someguy@influxdb.org", "fatal"]

    ]

  }

]

格式是json，可以在一个POST请求发送多个 series, 每个 series 里的 points 可以是多个，但索引要和columns对应。

上面的数据里没有包含time 列，InfluxDB会自己加上，不过也可以指定time,比如：

[

  {

    "name": "response_times",

    "columns": ["time", "value"],

    "points": [

      [1382819388, 234.3],

      [1382819389, 120.1],

      [1382819380, 340.9]

    ]

  }

]

time 在InfluxDB里是很重要的，毕竟InfluxDB是time series database
在InfluxDB里还有个sequence_number字段是数据库维护的，类似于mysql的 主键概念

InfluxDB 增删更查都是用http api来完成，甚至支持使用正则表达式删除数据，还有计划任务。

比如:

发送POST请求到 /db/:name/scheduled_deletes， body如下，

{

  "regex": "stats\..*",

  "olderThan": "14d",

  "runAt": 3

}

这个查询会删除大于14天的数据，并且任何以stats开头的数据，并且每天3:00 AM运行。

更加详细查看官方文档: http://influxdb.org/docs/api/http.html

查询语言

InfluxDB 提供了类似sql的查询语言

看起来是这样的：

select * from events where state == 'NY';



select * from log_lines where line =~ /error/i;



select * from events where customer_id == 23 and type == 'click';



select * from response_times where value > 500;



select * from events where email !~ /.*gmail.*/;



select * from nagios_checks where status != 0;



select * from events 

where (email =~ /.*gmail.* or email =~ /.*yahoo.*/) and state == 'ny';



delete from response_times where time > now() - 1h

非常容易上手, 还支持Group By, Merging Series, Joining Series， 并内置常用统计函数，比如max, min, mean 等

文档： http://influxdb.org/docs/query_language/

库

常用语言的库都有，因为api简单，也很容易自己封装。

InfluxdDB作为很多监控软件的后端，这样监控数据就可以直接存储在InfluxDB
StatsD, CollectD, FluentD

还有其它的可视化工具支持InfluxDB, 这样就可以基于InfluxDB很方便的搭建监控平台

InfluxDB 数据可视化工具

InfluxDB 用于存储基于时间的数据，比如监控数据，因为InfluxDB本身提供了Http API，所以可以使用InfluxDB很方便的搭建了个监控数据存储中心。

对于InfluxDB中的数据展示，官方admin有非常简单的图表, 看起来是这样的

除了自己写程序展示数据还可以选择：

tasseo https://github.com/obfuscurity/tasseo/
grafana https://github.com/torkelo/grafana

tasseo

tasseo,为Graphite写的Live dashboard，现在也支持InfluxDB,tasseo 比较简单, 可以配置的选项很少。



Grafana

Grafana是一个纯粹的html/js应用，访问InfluxDB时不会有跨域访问的限制。只要配置好数据源为InfluxDB之后就可以，剩 下的工作就是配置图表。Grafana 功能非常强大。使用ElasticsSearch保存DashBoard的定义文件，也可以Export出JSON文件(Save ->Advanced->Export Schema)，然后上传回它的/app/dashboards目录。

配置数据源：

datasources: {      

      influx: {

        default: true,

        type: 'influxdb',

        url: 'http://:8086/db/',

        username: 'test',

        password: 'test',

      }

    },

  收起阅读 »

郑重声明：本文转载自郎格科技系列博客，原文地址：http://www.samecity.com/blog/Article.asp?ItemID=84
      LevelDb是针对大规模Key/Value数据的单机存储库，从应用的角度来看，LevelDb就是一个存储工具。而作为称职的存储工具，常见 的调用接口无非是新增KV，删除KV，读取KV，更新Key对应的Value值这么几种操作。LevelDb的接口没有直接支持更新操作的接口，如果需要 更新某个Key的Value,你可以选择直接生猛地插入新的KV，保持Key相同，这样系统内的key对应的value就会被更新；或者你可以先删除旧的 KV，之后再插入新的KV，这样比较委婉地完成KV的更新操作。     假设应用提交一个Key值，下面我们看看LevelDb是如何从存储的数据中读出其对应的Value值的。图7-1是LevelDb读取过程的整体示意图。



LevelDb首先会去查看内存中的Memtable，如果Memtable中包含key及其对应的value，则返回value值即可；如果在 Memtable没有读到key，则接下来到同样处于内存中的Immutable Memtable中去读取，类似地，如果读到就返回，若是没有读到,那么只能万般无奈下从磁盘中的大量SSTable文件中查找。因为SSTable数量 较多，而且分成多个Level，所以在SSTable中读数据是相当蜿蜒曲折的一段旅程。总的读取原则是这样的：首先从属于level 0的文件中查找，如果找到则返回对应的value值，如果没有找到那么到level 1中的文件中去找，如此循环往复，直到在某层SSTable文件中找到这个key对应的value为止（或者查到最高level，查找失败，说明整个系统 中不存在这个Key)。    那么为什么是从Memtable到Immutable Memtable，再从Immutable Memtable到文件，而文件中为何是从低level到高level这么一个查询路径呢？道理何在？之所以选择这么个查询路径，是因为从信息的更新时间 来说，很明显Memtable存储的是最新鲜的KV对；Immutable Memtable中存储的KV数据对的新鲜程度次之；而所有SSTable文件中的KV数据新鲜程度一定不如内存中的Memtable和 Immutable Memtable的。对于SSTable文件来说，如果同时在level L和Level L+1找到同一个key，level L的信息一定比level L+1的要新。也就是说，上面列出的查找路径就是按照数据新鲜程度排列出来的，越新鲜的越先查找。

     为啥要优先查找新鲜的数据呢？这个道理不言而喻，举个例子。比如我们先往levelDb里面插入一条数据 {key="www.samecity.com"  value="朗格科技"},过了几天，samecity网站改名为：69同城，此时我们插入数据{key="www.samecity.com"  value="69同城"}，同样的key,不同的value；逻辑上理解好像levelDb中只有一个存储记录，即第二个记录，但是在levelDb中 很可能存在两条记录，即上面的两个记录都在levelDb中存储了，此时如果用户查询key="www.samecity.com",我们当然希望找到最 新的更新记录，也就是第二个记录返回，这就是为何要优先查找新鲜数据的原因。

    前文有讲：对于SSTable文件来说，如果同时在level L和Level L+1找到同一个key，level L的信息一定比level L+1的要新。这是一个结论，理论上需要一个证明过程，否则会招致如下的问题：为神马呢？从道理上讲呢，很明白：因为Level L+1的数据不是从石头缝里蹦出来的，也不是做梦梦到的，那它是从哪里来的？Level L+1的数据是从Level L 经过Compaction后得到的（如果您不知道什么是Compaction，那么........也许以后会知道的），也就是说，您看到的现在的 Level L+1层的SSTable数据是从原来的Level L中来的，现在的Level L比原来的Level L数据要新鲜，所以可证，现在的Level L比现在的Level L+1的数据要新鲜。

   证毕。

   如果您没看明白上面的证明过程，那么请记得往您的IQ卡内充值。

    SSTable文件很多，如何快速地找到key对应的value值？在LevelDb中，level 0一直都爱搞特殊化，在level 0和其它level中查找某个key的过程是不一样的。因为level 0下的不同文件可能key的范围有重叠，某个要查询的key有可能多个文件都包含，这样的话LevelDb的策略是先找出level 0中哪些文件包含这个key（manifest文件中记载了level和对应的文件及文件里key的范围信息，LevelDb在内存中保留这种映射表）， 之后按照文件的新鲜程度排序，新的文件排在前面，之后依次查找，读出key对应的value。而如果是非level 0的话，因为这个level的文件之间key是不重叠的，所以只从一个文件就可以找到key对应的value。

    最后一个问题,如果给定一个要查询的key和某个key range包含这个key的SSTable文件，那么levelDb是如何进行具体查找过程的呢？levelDb一般会先在内存中的Cache中查找是否 包含这个文件的缓存记录，如果包含，则从缓存中读取；如果不包含，则打开SSTable文件，同时将这个文件的索引部分加载到内存中并放入Cache中。 这样Cache里面就有了这个SSTable的缓存项，但是只有索引部分在内存中，之后levelDb根据索引可以定位到哪个内容Block会包含这条 key，从文件中读出这个Block的内容，在根据记录一一比较，如果找到则返回结果，如果没有找到，那么说明这个level的SSTable文件并不包 含这个key，所以到下一级别的SSTable中去查找。

    从之前介绍的LevelDb的写操作和这里介绍的读操作可以看出，相对写操作，读操作处理起来要复杂很多，所以写的速度必然要远远高于读数据的速度，也就 是说，LevelDb比较适合写操作多于读操作的应用场合。而如果应用是很多读操作类型的，那么顺序读取效率会比较高，因为这样大部分内容都会在缓存中找 到，尽可能避免大量的随机读取操作。

  收起阅读 »

郑重声明：本文转载自郎格科技系列博客，原文地址：http://www.samecity.com/blog/Article.asp?ItemID=84

在之前的五节LevelDb日知录中，朗格科技介绍了LevelDb的一些静态文件及其详细布局，从本节开始，我们看看LevelDb的一些动态操作，比如读写记录，Compaction，错误恢复等操作。       本节介绍levelDb的记录更新操作，即插入一条KV记录或者删除一条KV记录。levelDb的更新操作速度是非常快的，源于其内部机制决定了这种更新操作的简单性。



图6.1是levelDb如何更新KV数据的示意图，从图中可以看出，对于一个插入操作Put(Key,Value)来说，完成插入操作包含两个具 体步骤：首先是将这条KV记录以顺序写的方式追加到之前介绍过的log文件末尾，因为尽管这是一个磁盘读写操作，但是文件的顺序追加写入效率是很高的，所 以并不会导致写入速度的降低；第二个步骤是:如果写入log文件成功，那么将这条KV记录插入内存中的Memtable中，前面介绍过，Memtable 只是一层封装，其内部其实是一个Key有序的SkipList列表，插入一条新记录的过程也很简单，即先查找合适的插入位置，然后修改相应的链接指针将新 记录插入即可。完成这一步，写入记录就算完成了，所以一个插入记录操作涉及一次磁盘文件追加写和内存SkipList插入操作，这是为何levelDb写 入速度如此高效的根本原因。        从上面的介绍过程中也可以看出：log文件内是key无序的，而Memtable中是key有序的。

那么如果是删除一条KV记录呢？对于levelDb来说，并不存在立即删除的操作，而是与插入操作相同的，区别是，插入操作插入的是Key:Value 值，而删除操作插入的是“Key:删除标记”，并不真正去删除记录，而是后台Compaction的时候才去做真正的删除操作。

        levelDb的写入操作就是如此简单。真正的麻烦在后面将要介绍的读取操作中。
  收起阅读 »

郑重声明：本文转载自郎格科技系列博客，原文地址：http://www.samecity.com/blog/Article.asp?ItemID=84
 LevelDb日知录前述小节大致讲述了磁盘文件相关的重要静态结构，本小节讲述内存中的数据结构Memtable，Memtable在整个体系 中的重要地位也不言而喻。总体而言，所有KV数据都是存储在Memtable，Immutable Memtable和SSTable中的，Immutable Memtable从结构上讲和Memtable是完全一样的，区别仅仅在于其是只读的，不允许写入操作，而Memtable则是允许写入和读取的。当 Memtable写入的数据占用内存到达指定数量，则自动转换为Immutable Memtable，等待Dump到磁盘中，系统会自动生成新的Memtable供写操作写入新数据，理解了Memtable，那么Immutable Memtable自然不在话下。     LevelDb的MemTable提供了将KV数据写入，删除以及读取KV记录的操作接口，但是事实上Memtable并不存在真正的删除操作,删除某 个Key的Value在Memtable内是作为插入一条记录实施的，但是会打上一个Key的删除标记，真正的删除操作是Lazy的，会在以后的 Compaction过程中去掉这个KV。

     需要注意的是，LevelDb的Memtable中KV对是根据Key大小有序存储的，在系统插入新的KV时，LevelDb要把这个KV插到合适的 位置上以保持这种Key有序性。其实，LevelDb的Memtable类只是一个接口类，真正的操作是通过背后的SkipList来做的，包括插入操作 和读取操作等，所以Memtable的核心数据结构是一个SkipList。

     SkipList是由William Pugh发明。他在Communications of the ACM June 1990, 33(6) 668-676 发表了Skip lists: a probabilistic alternative to balanced trees，在该论文中详细解释了SkipList的数据结构和插入删除操作。

SkipList是平衡树的一种替代数据结构，但是和红黑树不相同的是，SkipList对于树的平衡的实现是基于一种随机化的算法的，这样也就是说SkipList的插入和删除的工作是比较简单的。

关于SkipList的详细介绍可以参考这篇文章：http://www.cnblogs.com/xuqiang/archive/2011/05/22/2053516.html，讲述的很清楚，LevelDb的SkipList基本上是一个具体实现，并无特殊之处。

SkipList不仅是维护有序数据的一个简单实现，而且相比较平衡树来说，在插入数据的时候可以避免频繁的树节点调整操作，所以写入效率是很高 的，LevelDb整体而言是个高写入系统，SkipList在其中应该也起到了很重要的作用。Redis为了加快插入操作，也使用了SkipList来 作为内部实现数据结构。 收起阅读 »

郑重声明：本文转载自郎格科技系列博客，原文地址：http://www.samecity.com/blog/Article.asp?ItemID=84
SSTable是Bigtable中至关重要的一块，对于LevelDb来说也是如此，对LevelDb的SSTable实现细节的了解也有助于了解Bigtable中一些实现细节。本节内容主要讲述SSTable的静态布局结构，朗格科技曾在“LevelDb日知录之二：整体架构”中说过，SSTable文件形成了不同Level的 层级结构，至于这个层级结构是如何形成的我们放在后面Compaction一节细说。本节主要介绍SSTable某个文件的物理布局和逻辑布局结构，这对 了解LevelDb的运行过程很有帮助。

LevelDb不同层级有很多SSTable文件（以后缀.sst为特征），所有.sst文件内部布局都是一样的。上节介绍Log文件是物理分块 的，SSTable也一样会将文件划分为固定大小的物理存储块，但是两者逻辑布局大不相同，根本原因是：Log文件中的记录是Key无序的，即先后记录的 key大小没有明确大小关系，而.sst文件内部则是根据记录的Key由小到大排列的，从下面介绍的SSTable布局可以体会到Key有序是为何如此设 计.sst文件结构的关键。




上图展示了一个.sst文件的物理划分结构，同Log文件一样，也是划分为固定大小的存储块，每个Block分为三个部分，红色部分是数据存储区，蓝色 的Type区用于标识数据存储区是否采用了数据压缩算法（Snappy压缩或者无压缩两种），CRC部分则是数据校验码，用于判别数据是否在生成和传输中 出错。    以上是.sst的物理布局，下面介绍.sst文件的逻辑布局，所谓逻辑布局，就是说尽管大家都是物理块，但是每一块存储什么内容，内部又有什么结构等。图4.2展示了.sst文件的内部逻辑解释。




从图4.2可以看出，从大的方面，可以将.sst文件划分为数据存储区和数据管理区，数据存储区存放实际的Key:Value数据，数据管理区则提供一些 索引指针等管理数据，目的是更快速便捷的查找相应的记录。两个区域都是在上述的分块基础上的，就是说文件的前面若干块实际存储KV数据，后面数据管理区存 储管理数据。管理数据又分为四种不同类型：紫色的Meta Block，红色的MetaBlock 索引和蓝色的数据索引块以及一个文件尾部块。

    LevelDb 1.2版对于Meta Block尚无实际使用，只是保留了一个接口，估计会在后续版本中加入内容，下面我们看看数据索引区和文件尾部Footer的内部结构。



图4.3是数据索引的内部结构示意图。再次强调一下，Data Block内的KV记录是按照Key由小到大排列的，数据索引区的每条记录是对某个Data Block建立的索引信息，每条索引信息包含三个内容，以图4.3所示的数据块i的索引Index i来说：红色部分的第一个字段记载大于等于数据块i中最大的Key值的那个Key，第二个字段指出数据块i在.sst文件中的起始位置，第三个字段指出 Data Block i的大小（有时候是有数据压缩的）。后面两个字段好理解，是用于定位数据块在文件中的位置的，第一个字段需要详细解释一下，在索引里保存的这个Key值未 必一定是某条记录的Key,以图4.3的例子来说，假设数据块i 的最小Key=“samecity”，最大Key=“the best”;数据块i+1的最小Key=“the fox”,最大Key=“zoo”,那么对于数据块i的索引Index i来说，其第一个字段记载大于等于数据块i的最大Key(“the best”)同时要小于数据块i+1的最小Key(“the fox”)，所以例子中Index i的第一个字段是：“the c”，这个是满足要求的；而Index i+1的第一个字段则是“zoo”，即数据块i+1的最大Key。

 文件末尾Footer块的内部结构见图4.4，metaindex_handle指出了metaindex block的起始位置和大小；inex_handle指出了index Block的起始地址和大小；这两个字段可以理解为索引的索引，是为了正确读出索引值而设立的，后面跟着一个填充区和魔数。




上面主要介绍的是数据管理区的内部结构，下面我们看看数据区的一个Block的数据部分内部是如何布局的（图4.1中的红色部分），图4.5是其内部布局示意图。




从图中可以看出，其内部也分为两个部分，前面是一个个KV记录，其顺序是根据Key值由小到大排列的，在Block尾部则是一些“重启点”（Restart Point）,其实是一些指针，指出Block内容中的一些记录位置。

“重启点”是干什么的呢？我们一再强调，Block内容里的KV记录是按照Key大小有序的，这样的话，相邻的两条记录很可能Key部分存在重叠，比如 key i=“the Car”，Key i+1=“the color”,那么两者存在重叠部分“the c”，为了减少Key的存储量，Key i+1可以只存储和上一条Key不同的部分“olor”，两者的共同部分从Key i中可以获得。记录的Key在Block内容部分就是这么存储的，主要目的是减少存储开销。“重启点”的意思是：在这条记录开始，不再采取只记载不同的 Key部分，而是重新记录所有的Key值，假设Key i+1是一个重启点，那么Key里面会完整存储“the color”，而不是采用简略的“olor”方式。Block尾部就是指出哪些记录是这些重启点的。




在Block内容区，每个KV记录的内部结构是怎样的？图4.6给出了其详细结构，每个记录包含5个字段：key共享长度，比如上面的“olor”记录， 其key和上一条记录共享的Key部分长度是“the c”的长度，即5；key非共享长度，对于“olor”来说，是4；value长度指出Key:Value中Value的长度，在后面的Value内容字 段中存储实际的Value值；而key非共享内容则实际存储“olor”这个Key字符串。

上面讲的这些就是.sst文件的全部内部奥秘。
  收起阅读 »