良好的逻辑设计和物理设计是高性能的基石，应该根据系统将要执行的查询语句来设计 schema，这往往需要权衡各种因素。

人生就是如此，你以为已经从一个漩涡逃离，其实另外一个漩涡就在你的脚下。用力蹬一脚，就进去了。所以，不需要对生活太用力，心会带着我们去该去的地方。 ——龙应台《目送》

R.I.P. If they say Who cares if one more light goes out In the sky of a million stars It flickers, flickers Who cares when someone’s time runs out If a moment is all we are Or quicker, quicker

最近把博客从 Hexo 迁移到了 Ghost 上，简单聊一下用了两年的 Hexo 和只用了两天的 Ghost。 我对博客系统的要求，只有一个：能用 Markdown 渲染。其实能满足我要求的博客系统的还是蛮多，除了 Hexo 和 Ghost 这两个，还有比如 FarBox、Jekyll、Octopress 这些都是可以的，甚至还有直接注册个账号就能用的简书。

Ghost 1.0.0 已经 RC1 了，我用着比之前的版本舒服多了。不过嘛，既然是候选版本，问题肯定还是有的（主要是新版 Casper 主题样式上的），结合我目前体验发现的一些 BUG 做个汇总。

测试环境中用三台 Linux 服务器来部署 HBase 与 Hadoop，详细信息如下： hostname ip role hadoop hbase yibo-0 10.10.5.215 master ResourceManager/NameNode/SecondaryNameNode HMaster yibo-1 10.10.5.207 slave1 Node

公司项目最近要增加一个搜索的模块，虽然之前已经在项目中广泛的使用了 Lucene，但是这次这个模块再直接使用 Lucene 的话还得担心以后的扩展问题，所以就决定尝试用 ElasticSearch 来解决。（为什么不用 Solr 呢？其实 Solr 和 ES 的差别不大，它俩的对比评测网上也是一搜一大把，我主要是之前使用过 ELK 技术栈，所以还是更倾向于 ES） 这篇文章就简单的对我在使用 ES

前言众所周知， 现在的 Spring 框架已经成为构建企业级 Java 应用事实上的标准了，众多的企业项目都构建在 Spring 项目及其子项目之上，特别是 Java Web 项目。 Spring 的两个核心概念是 IoC（控制反转）和 AOP（面向切面编程）。想了解 Spring 的工作原理，毫无疑问，首先要从这两个概念的 Spring 实现入手。但是 Spring 源码浩如烟海，里面掺杂了太多

Java 语言，开发者不能直接控制程序运行内存，对象的创建都是由类加载器一步步解析，执行与生成与内存区域中的；并且 jvm 有自己的垃圾回收器对内存区域管理、回收；但是我们已经可以通过一些工具来在程序运行时查看对应的 jvm 内存使用情况，帮助更好的分析与优化我们的代码。

Introductionhg flow  是一种开发模式，采用生产（Production）、发布（Release）、开发（Develop）完全分离的分支模型支撑多人团队的开发模式。hg flow 的开发模型借鉴自  git flow。 git flow 的流程图如下：（hg flow 的流程同理，只不过大家习惯的分支名略有不同而已）

平时都是用 Hg（Mercurial），Git 用得不是很熟练，老是遗忘，特此记录一下。其实都是根据 GitHub 官方 help 整理的（Syncing a fork、Configuring a remote for a fork）。

引子介绍 Java 中 Integer 缓存的相关知识前，我们先来看一段代码，猜猜输出结果， 1234567891011121314151617181920212223242526package com.codingon.java;public class JavaIntegerCache { public static void main(String[] args) {

一般大家在安装完 Hadoop 后运行相关的命令，都会看到这样一个警告 1WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable 意思也就是加载不了 Hadoop 的本地库，这个问题不解决也不影

在 Java 中对一个 Map 按 Key 排序是很简单的一件事（TreeMap）。但是按 Value 排序的话，却略显麻烦。 在 Java 8 之前，对 Map 按 Value 排序一般有两种方法： 123456789101112131415161718192021222324252627282930313233343536// 1. TreeMappublic class Testing &#

ELK 是 Elasticsearch、Logstash、Kibana 三个开源软件的组合。在实时数据检索和分析场合，三者通常是配合共用，而且又都先后归于 Elastic.co 公司名下，故有此简称。 ELK 在最近两年迅速崛起，成为机器数据分析，或者说实时日志处理领域，开源界的第一选择。和传统的日志处理方案相比，ELK 具有如下几个优点： 处理方式灵活。Elasticsearch 是实时全文索

项目中涉及到生成二维码（像微信那种的），就用 ZXing 并混合 Java 的图形库搞了一个工具类。 奉上效果图一张 废话不多说，直接上代码：

项目后台要加一个统计，产品只要求能看到数据就行了，但是做完后我发现只有文本不够直观，就想着用图表的形式的展现一下（顺便温习一下曾经用过的 JFreeChart XD）。JFreeChat 虽好，但也有些年头了，就去网上搜了搜有没有什么更好的图表生成的类库。 当在8 个华丽而实用的 Java 图表应用看到 ECharts 的时候，发现 JFreeChart 跟它比就不是一个级别的呀！至于开头说的温习

Let’s Encrypt 简介Let’s Encrypt 是一个新的数字证书认证机构，它通过自动化的过程消除创建和安装证书的复杂性，为网站提供免费的 SSL/TLS 证书。Let’s Encrypt 项目获得了 Mozilla、思科、Akamai、IdenTrust 和 EFF 等组织的支持，由 Linux 基金会托管。它在 9 月中旬颁发了第一个证书，已经从 12 月 3 日起开放了

Java 中哪个 JSON 库的解析速度是最快的？JSON 已经成为当前服务器与 WEB 应用之间数据传输的公认标准，不过正如许多我们所习以为常的事情一样，你会觉得这是理所当然的便不再深入思考了。我们很少会去想用到的这些 JSON 库到底有什么不同，但事实上它们的确是不太一样的。因此，我们运行了一个基准测试来对常用的几个 JSON 库进行了测试，看看在解析不同大小的文件时哪个库的速度是最快的。下面

继前两篇文章（Supervisor 基础、监控并报警）后，用 Supervisor 管理单个机器上的进程没啥问题了。但是 A 机器上的 Supervisor 只能管理 A 机器上的进程，管理不了 B 上边的。在当今这个云的时代，大家都玩集群了，如果用其管理的话，需要打开 N 个网页去各各机器上的进程显然是不现实的（OP 们要哭晕在厕所了）。其实之前仔细看配置文件的话，应该会想到一种解决的办法——通