继续OneCoder之前提出的要验证的问题，为了方便测试MySQL Cluster的数据分片功能，我们设置集群节点配置如下：

NoOfReplicas=1   
DataMemory=50M  
IndexMemory=10M

初始化重启节点：

开始写入80w数据。观察写入过程，可以看到数据是大致均匀写入两个节点之中：

跟之前不同的事，这次不会双节点都保持完全 一样的内存占用了。这说明，这不是由于数据复制造成的，而是正常的数据分片导致。最终80w数据成功写入了容量均为50m的两个数据节点中。这说明MySQL Cluster是可以自动将数据分片保存的。

Begin to prepare statement.
It's up to batch count: 100000
Batch data commit finished. Time cost: 90128
It's up to batch count: 100000
Batch data commit finished. Time cost: 87141
It's up to batch count: 100000
Batch data commit finished. Time cost: 86353
It's up to batch count: 100000
Batch data commit finished. Time cost: 86775
It's up to batch count: 100000
Batch data commit finished. Time cost: 89635
It's up to batch count: 100000
Batch data commit finished. Time cost: 87782
It's up to batch count: 100000
Batch data commit finished. Time cost: 89180
It's up to batch count: 100000
Batch data commit finished. Time cost: 89021
All data insert finished. Total time cost: 706041

那么，如果是在集群已有存储容量不足的情况下，扩充新节点进来，会是怎样的情况呢。我们再测试一下。先去掉一个节点，将容量再调小。然后写入数据直到写满，再加入第二个节点，继续写入数据。看是否可以成功，并且观察数据的分配情况。

在写入的过程，也观察到另外一个现象，就是在一次批量写入没有提交的情况下，内存的占用大于存储需要的空间容量，在提交以后，这部分内存会释放，内存的占用量会降低。因此调整每批次写入的数据量，可在现有的空间中存入更多的数据。这里采用单批次1w输入写入。

注：在单批次20w的情况下。根本无法成功写入任何数据，10w的时候只能写入20w数据。

加入新节点：

目前数据并没有自动调配。我们先继续写入数据测试，看看集群容量是否真的扩容了，并观察后续空间使用状况。数据库现有数据23w。直接继续写入数据，仍然提示空间不足。

观察到，新加入的节点是no nodegroup 状态。所以我们通过：

ndb_mgm>create nodegroup 3;

来创建nodegroup。然后再调整分区数据：

mysql> alter online table data_house reorganize partition;

发现分区果然有变化了。再次继续写入数据，成功！

新加入的节点已经可以写入数据了。

通过工具也可看到，数据库里已经有42w数据了。最终两个节点共写入50w数据。查询效率仍然是20ms左右。至此，MySQL Cluster的一些基本的功能特性，都验证完成了。不过想用于生产环境还需要更多的考量，目前网上也有很多改造过的开源和商业版本，如果有需要可以具体考察一下。

承接之前的初测，题目本来想叫深入测试的，不过想想太大了，就还叫使用的一个小结吧。

在扩充数据节点之前，OneCoder向数据库中又写入900w的数据，总量达到1kw。每批次写入20w的数据，写入时间大致如下：

……
It's up to batch count: 200000
Batch data commit finished. Time cost: 202634
It's up to batch count: 200000
Batch data commit finished. Time cost: 168834
It's up to batch count: 200000
Batch data commit finished. Time cost: 181764
It's up to batch count: 200000
Batch data commit finished. Time cost: 156975
It's up to batch count: 200000
Batch data commit finished. Time cost: 184845
It's up to batch count: 200000
Batch data commit finished. Time cost: 202010
It's up to batch count: 200000
Batch data commit finished. Time cost: 177443
It's up to batch count: 200000
Batch data commit finished. Time cost: 203957
It's up to batch count: 200000
Batch data commit finished. Time cost: 159565
All data insert finished. Total time cost: 10476439

1kw数据执行Select，查询10条结果效率如下：

Query ten rows from table [data_house] cost time: 27

可见效率还是很快。当前数据分布情况如下：

现在，再添加一个数据节点。步骤略，主要就是修改配置文件，按顺序重启即可。不过在重启Data Node时候需要耐心等待成功。

通过

ndb_mgm>all report memory

查看内存占用：

发现数据并没有均匀分配。此时再通过代码查询记录，看看耗时情况。耗时还是24ms左右。没有明显变化。不过，这里我们还是想让数据均匀分配的。先测试再写入100w数据。会不会分别存储。测试显示，数据还是集中在原来的节点保存。插入效率基本与原来一致。

将NoOfReplicas的值从1改为2， 重新启动，发现一直报错：

Node 2: Forced node shutdown completed. Occured during startphase 1. Caused by error 2350: 'Invalid configuration received from Management Server(Configuration error). Permanent error, external action needed'

这个问题确实有由于修改了值引起的，但是找了半天一直没有正常的解决。考虑到现在data存储都是测试数据，所以考虑在data节点采用：

shell>ndbd --initial-start --foreground

的方式重启节点，并通过foreground的方式查看启动日志。最后，倒是正常启动成功了，只是数据确实被"initial"干净了。重新灌数据吧。还拿100w试验。数据灌入效率差不多，只是数据在两个节点上被复制两份了

查询效率还是20ms左右。

继续测试，在执行之前的1kw数据，20w一组批量写入数据灌入测试中，却出现：

Lock wait timeout exceeded; try restarting transaction

的错误。有人说需要调整

TransactionDeadLockDetectionTimeOut=10000

参数的值，默认是1200。不过我并没有采用，因为重启挺坎坷，根据网上的一些讨论分析，减少了每次写入的数量，到10w。目前来看，稳定许多，尚未出现错误。
关闭一个节点，验证集群的高可用性。

再次调用查询接口。正常返回数据。

目前为止，我们还差最关心的数据自动分片，分节点保存的问题没有验证清楚。随后，我们将针对此问题再进行进一步的验证。

基于上篇搭建的环境，验证一些基本功能和性能需求。这里先说一下功能使用的问题。OneCoder也是第一次用。摸索着来，仅做一个记录。

从部署图就可知道，对数据库的请求操作发生在SQL节点上。为了达到试验效果，这里又追加了一个sql节点。现在集群环境如下：

在追加的过程中，发现MySQL Cluster对启动顺序要求严格，在没考虑热部署方案的情况下，必须停止了所有节点，重新按照management->data->sql的顺序启动节点。

现在测试对表的创建和修改的自动同步：

在任意SQL节点执行：（这里选择44.200节点）

create table bigdata_cluster(id int primary key, name varchar(20)) engine=ndbcluster default charset utf8;

创建表，注意表的引擎一定要指定ndbcluster，在201节点查看

show tables;

发现已经可以同步查询了。其实本来底层data节点对上层就是透明的，自然可以查到。多sql节点，就可以起到负载均衡的效果。

调整表和数据插入，都跟传统的MySQL方式相同，不再赘述，同样也是可以做到实时同步的，这里也测过了。下面通过JDBC代码测试下API操作的效果，同时也想灌入100w的数据，进行一下效率测试和对比。

在测试前，OneCoder先用SQLyog工具，测试了一下数据库远端访问权限，发现果然没有。在一个节点grant all了一下以后，却发现另一个节点仍然无法访问，搜索才知，原来MySQL Cluster的用户权限默认不是共享的，进行如下设置，在mysql终端执行：

mysql> SOURCE /usr/local/mysql/share/ndb_dist_priv.sql;
mysql> CALL mysql.mysql_cluster_move_privileges();

即可完成权限共享，现在在一个终端设置的权限就是集群共享的了。在用SQLYog测试，果然均可以链接了。下面开始开发JDBC链接MySQL的代码：</p>

/**
  * 向数据库中插入数据
  *
  * @param conn
  * @param totalRowCount
  * @param perRowCount
  * @param tableName
  * @author lihzh(OneCoder)
  * @throws SQLException
  * @date 2013-1-17 下午1:57:10
  */
private void insertDataToTable(Connection conn, String tableName,
long totalRowCount, long perRowCount) throws SQLException {
conn.setAutoCommit(false);
long start = System.currentTimeMillis();
String sql = "insert into " + tableName + " VALUES(?,?,?)";
System.out.println("Begin to prepare statement.");
PreparedStatement statement = conn.prepareStatement(sql);
for (int j = 0; j < TOTAL_ROW_COUNT / BATCH_ROW_COUNT; j++) {
long batchStart = System.currentTimeMillis();
for (int i = 0; i < BATCH_ROW_COUNT; i++) {
long id = j * BATCH_ROW_COUNT + i;
String name_pre = String.valueOf(id);
statement.setLong(1, id);
statement.setString(2, name_pre);
statement.setString(3, name_pre);
statement.addBatch();
}
System.out.println("It's up to batch count: " + BATCH_ROW_COUNT);
statement.executeBatch();
conn.commit();
long batchEnd = System.currentTimeMillis();
System.out.println("Batch data commit finished. Time cost: " + (batchEnd - batchStart));
}
long end = System.currentTimeMillis();
System.out.println("All data insert finished. Total time cost: " + (end - start));
}

开始设置BATCH_ROW_COUNT为5w，结果报错：

java.sql.BatchUpdateException: Got temporary error 233 'Out of operation records in transaction coordinator (increase MaxNoOfConcurrentOperations)' from NDBCLUSTER

意思比较明显，超过了MaxNoOfConcurrentOperations设置的值。该值默认为：32768。你可以通过修改config.ini里的配置改变默认值。不过有人提到，修改该值的同事，你也需要修改

MaxNoOfLocalOperations的值，并且建议后者的值超过前者值10%左右（1.1倍）。

这里为了避免麻烦，我们直接将代码的里预设值调小到2w，再运行代码。

Begin to prepare statement.
It's up to batch count: 20000
Batch data commit finished. Time cost: 20483
It's up to batch count: 20000
Batch data commit finished. Time cost: 19768
It's up to batch count: 20000
Batch data commit finished. Time cost: 20136
It's up to batch count: 20000
Batch data commit finished. Time cost: 19958
…….
java.sql.BatchUpdateException: The table 'bigdata_cluster' is full

无语……表满了。共写入了88w条数据。每次batch写入时间稳定。再测试条件查询耗时：

/**
  * 查询特定的一个或者一组数据，打印查询耗时
  *
  * @param conn
  * @param tableName
  * @author lihzh
  * @throws SQLException
  * @date 2013-1-17 下午4:46:20
  */
private void searchData(Connection conn, String tableName) throws SQLException {
long start = System.currentTimeMillis();
String sql = "select * from " + tableName + " where name = ?";
PreparedStatement statement = conn.prepareStatement(sql);
statement.setString(1, "300");
ResultSet resultSet = statement.executeQuery();
resultSet.first();
System.out.println("Name is: " + resultSet.getObject("name"));
long end = System.currentTimeMillis();
System.out.println("Query one row from 88w record cost time: " + (end - start));
}

通过另一个sql节点，根据没有索引的name字段查询耗时约1.4s，有索引的id查询耗时20ms左右。

再新建一个表，发现什么数据再也无法写入，看来是数据节点全局容量限制导致的。修改config.ini文件中的

DataMemory=80M    # How much memory to allocate for data storage
IndexMemory=18M   # How much memory to allocate for index storage
                  # For DataMemory and IndexMemory, we have used the
                  # default values. Since the "world" database takes up
                  # only about 500KB, this should be more than enough for
                  # this example Cluster setup.

分别改为1400和384M。重启集群。再通过

ndb_mgm> all report memoryusage

命令查看使用情况，

似乎恢复了正常。再向新表写入数据，成功。

测试删除数据，又遇到提示：

ERROR 1297 (HY000): Got temporary error 233 'Out of operation records in transaction coordinator (increase MaxNoOfConcurrentOperations)' from NDBCLUSTER

看来真的得调整MaxNoOfConcurrentOperations参数的大小了。根据虚拟机内存情况（据说1约需要1kb内存。因此10w，大约100m内存），调整如下：

MaxNoOfConcurrentOperations=300000
MaxNoOfLocalOperations=330000

重启，测试删除11w数据，通过。同时，再次测试向新表写入100w条数据，以20w为一组，也顺利通过了。

It's up to batch count: 200000
Batch data commit finished. Time cost: 268642
It's up to batch count: 200000
Batch data commit finished. Time cost: 241301
It's up to batch count: 200000
Batch data commit finished. Time cost: 209329
It's up to batch count: 200000
Batch data commit finished. Time cost: 207634
It's up to batch count: 200000
Batch data commit finished. Time cost: 241746
All data insert finished. Total time cost: 1168703

目前的使用情况大致如此，接下来OneCoder打算测试一下集群节点添加和数据自动分区读写情况。等有了结论在与大家分享。

实验需要，OneCoder打算亲自部署一下MySQL Cluster环境。VMware环境中，虚拟化三台CentOS5.4 x64虚拟机。

10.4.44.201 SQL
10.4.44.202 Data
10.4.44.203 Manager

用于部署。

官方文档自然是最好的部署手册，先简单了解一下。

MySQL Cluster构成

Each MySQL Cluster host computer must have the correct executable programs installed. A host running an SQL node must have installed on it a MySQL Server binary (mysqld). Management nodes require the management server daemon (ndb_mgmd); data nodes require the data node daemon (ndbd or ndbmtd). It is not necessary to install the MySQL Server binary on management node hosts and data node hosts. It is recommended that you also install the management client (ndb_mgm) on the management server host.

SQL节点，必须部署MySQL Server binary(mysqld)；管理(Management) 节点，需要部署management server daemon(ndb_mgmd)；数据(data)节点，需要部署data node daemon(ndbd 或者 ndbmtd)。无需在管理和数据节点上部署MySQL Server binary。推荐在管理节点上，也部署management client(ndb_mgm)。

MySQL Cluster配置（翻译自官方文档）

每个data和SQL节点都需要一个my.cnf文件，其中包含了两条重要的信息：一个链接串指明management节点位置，一条针对data节点，告诉MySQL服务器开启NDBCLUSTER存储引擎。
management节点需要config.ini配置文件，里面保存着它需要管理的集群节点的信息、保存数据和各data节点数据索引所需的内存信息，data节点的位置信息，
有了这些理论基础，下面我们来动手操作一下

先部署data和SQL节点， 下载MysQL Cluster压缩包 ，通过putty自带的pscp工具，拷贝到各个节点linux虚拟机中。

解压。

先配置SQL和Data节点。在/etc下放置my.cnf配置文件。内容如下：

[ndbcluster]
ndb-connectstring=10.4.44.203
[mysql_cluster]
ndb-connectstring=10.4.44.203

再配置Manager

同样先将压缩包拷贝，然后在/var/lib/mysql-cluster/config.ini 配置：[ndbd default]

# Options affecting ndbd processes on all data nodes:
NoOfReplicas=1    # Number of replicas
DataMemory=80M    # How much memory to allocate for data storage
IndexMemory=18M   # How much memory to allocate for index storage
                  # For DataMemory and IndexMemory, we have used the
                  # default values. Since the "world" database takes up
                  # only about 500KB, this should be more than enough for
                  # this example Cluster setup.

[ndb_mgmd]
# Management process options:
hostname=10.4.44.203           # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster  # Directory for MGM node log files

[ndbd]
# Options for data node "A":
                                # (one [ndbd] section per data node)
hostname=10.4.44.202          # Hostname or IP address
datadir=/usr/local/mysql/data   # Directory for this data node's data files

[mysqld]
# SQL node options:
hostname=10.4.44.201          # Hostname or IP address
                                            # (additional mysqld connections can be
                                        # specified for this node for various
                                                # purposes such as running ndb_restore)

启动MySQL Cluster：

先启动Management节点:

shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini

再启动data

shell>ndbd

和SQL节点shell> groupadd mysql

shell> useradd -r -g mysql mysql
shell> cd /usr/local
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
shell> ln -s full-path-to-mysql-VERSION-OS mysql
shell> cd mysql
shell> chown -R mysql .
shell> chgrp -R mysql .
shell> scripts/mysql_install_db
shell> bin>mysqld

成功。在management节点，利用./ndb_mgm查看状态。

ndb_mgm>show.

部署成功。

OneCoder注：这里一开始有一个误区，就是我根据文档误以为SQL节点部署的MySQL Server版本而不是Cluster版本，导致耽误了很多时间。今天看一个错误出神的时候，才突然醒悟，我是不是搞错了。连忙替换了版本，这才成功。

OneCoder最近入手一台Mac Pro。其实这个话题本来没什么可写的。但是考虑确实自己开始是不知道的，哪怕是一丁点的收获，也应该记录下来。

其实Java开发环境无非就是安装JDK，安装IDE，配置环境变量。JDK自然从官网下载Mac版的，IDE，OneCoder也从Eclipse的官网下载了。安装也是一键安装和解压即可。而且发现JDK安装后，在命令行运行java -version和javac -version直接会识别出你刚才安装的版本是无需配置的。

直接通过eclpse.app启动Eclipse Juno(4.2) 居然报错，寻找Java6版本。但是通过“替身”eclipse启动是可以启动的。虽然可用，不过OneCoder还是想解决这个问题。

若要打开“Eclipse”，您需要 Java SE 6 运行时。您想现在安装一个吗？

OneCoder点击安装后，即可正常使用了。不过网上有人说他点了安装后也无效。这个OneCoder就不知道到底是什么原因了。至少那个没有图标样式的替身eclipse是可用的吧。也可以考虑尝试打开Eclipse.app这个项目，编辑里面的eclipse.ini文件，指定vm路径来解决这个问题，不过OneCoder并没有亲自验证可行性。只是修改了里面的启动参数，增加了一些内存而已。

    有一段时间没来了，日子不论是忙是闲，过的都飞快。OneCoder的心态也起伏不定，让您见笑。

这也是OneCoder在数据测试过程中遇到的问题，不一定有多少普试性，但是也许可以解决你的问题。

海量数据测试，数据导入一般是非常耗时的过程。OneCoder这里面对大约2T左右数据的导入问题，头疼不已，时间有限。本来准备的方式是将事先生成好的数据文件导入HBase中，这里有两个比较耗时的过程，put到hdfs和import到HBase中，昨天测试5G数据导入到HBase中，居然用了20min。如此估算，不能忍。

交流中，获知可以考虑先导入部分数据，然后利用这部分数据，在数据库中查询出来，然后修改比如时间字段的值，然后在合并入表中。这样，利用一天的数据，就可以构造出2、4，8，16天的数据。效率会高出很多。

当然，如果你的测试是基于真实的业务数据的，那么这种方式不适合你。如果你是构造的数据，那么可以尝试一下这种方式。OneCoder基于MySQL写了一个自动化的代码，作为参考。真实海量数据的一般可能是基于Hive的，只要修改链接串和可能少量的SQL语句即可。

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

/**
 * 用于在MySQL中数据翻倍复制
 * 
 * @author OneCoder(OneCoder)
 * @date 2012-11-27 下午3:28:16
 * @Blog http://www.coderli.com
 */
public class MySQLDataCopy {

	private static final int COPY_COUNT = 9;
	private static final long ONE_DAY_MILLISECOND = 3600 *24 *1000L;
	private static final String SQL_CREATE_TABLE_ONE = "CREATE TABLE metric_t1 AS SELECT * FROM metric;";
	private static final String SQL_CREATE_TABLE_TWO = "CREATE TABLE metric_t2 AS SELECT * FROM metric LIMIT 1;";
	private static final String SQL_DELETE_DATA_TABLE_TWO = "DELETE FROM metric_t2;";
	private static final String SQL_INSERT_DATA_TABLE_TWO_PREFIX = "INSERT INTO metric_t2 SELECT cpu, id, recordtime + ";
	private static final String SQL_INSERT_DATA_TABLE_TWO_MIDDLE = " AS recordtime, CONCAT(id,\"_\",recordtime + ";
	private static final String SQL_INSERT_DATA_TABLE_TWO_PRSTFIX = ") AS rowkey FROM metric;";
	private static final String SQL_DELETE_DATA = "DELETE FROM metric;";
	private static final String SQL_INSERT_DATA = "INSERT INTO metric SELECT * FROM (SELECT * FROM metric_t1 UNION ALL SELECT * FROM metric_t2) tmp;";
	private static final String SQL_DROP_TABLE_ONE = "DROP TABLE metric_t1;";
	private static final String SQL_DROP_TABLE_TWO = "DROP TABLE metric_t2;";
	
	

	static {
		try {
			Class.forName("com.mysql.jdbc.Driver");
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		}
	}

	/**
	 * @param args
	 * @author OneCoder(OneCoder)
	 * @throws SQLException
	 * @date 2012-11-27 下午3:28:16
	 */
	public static void main(String[] args) throws SQLException {
		Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root",
				"root");
		int times = 1;
		for (int i = 1; i <= COPY_COUNT; i++) {
			System.out.println("Begin to copy: " + i +" time");
			conn.createStatement().execute(SQL_CREATE_TABLE_ONE);
			System.out.println("Create table t1 finished");
			conn.createStatement().execute(SQL_CREATE_TABLE_TWO);
			System.out.println("Create table t2 finished");
			conn.createStatement().execute(SQL_DELETE_DATA_TABLE_TWO);
			System.out.println("Delete table t2 data");
			conn.createStatement().execute(createInsertDataToTableTwoSQL(times));
			System.out.println("Insert into table t2 new data.");
			conn.createStatement().execute(SQL_DELETE_DATA);
			System.out.println("Delete table metric data");
			conn.createStatement().execute(SQL_INSERT_DATA);
			System.out.println("Insert new data into metric");
			conn.createStatement().execute(SQL_DROP_TABLE_ONE);
			System.out.println("Drop table t1");
			conn.createStatement().execute(SQL_DROP_TABLE_TWO);
			System.out.println("Drop table t1");
			times *= 2;
		}
	}

	private static String createInsertDataToTableTwoSQL(int count) {
		long addNum = count * ONE_DAY_MILLISECOND;
		StringBuilder sbuilder = new StringBuilder();
		sbuilder.append(SQL_INSERT_DATA_TABLE_TWO_PREFIX).append(addNum)
				.append(SQL_INSERT_DATA_TABLE_TWO_MIDDLE).append(addNum)
				.append(SQL_INSERT_DATA_TABLE_TWO_PRSTFIX);
		return sbuilder.toString();
	}

}

初学者，请勿见笑，多多指教：）

其实这个本来没什么可写的，只是OneCoder恰巧用到又不会，在网上查了一下找到了答案，所以记录一下，也做分享。

很简单，一句话，执行：

mvn dependency:copy-dependencies -DoutputDirectory=lib   -DincludeScope=compile

会将依赖的包拷贝到工程的lib目录下。

OneCoder只是一个初学者，记录的只是自己的一个过程。不足之处还望指导。

看网上说导入大量数据，用bulk load的方式效率比较高。bulk load可以将固定格式的数据文件转换为HFile文件导入，当然也可以直接导入HFile文件。所以OneCoder最开始考虑的生成HFile文件供HBase导入，不过由于手太新，一直没有搞定。参考了很多网上的代码也没跑通。暂时搁浅。

后来OneCoder采用了，生成普通的数据格式文件，然后用过imporsttsv命令导入的方式成功。生成数据文件代码如下：

private static final String PATH = "F:/data.txt";

	/**
	 * @param args
	 * @author lihzh
    * @alia OneCoder
    * @blog http://www.coderli.com
	 * @throws IOException 
	 * @date 2012-11-14 下午4:51:22
	 */
	public static void main(String[] args) throws IOException {
		long startTime = System.currentTimeMillis();
		File dataFile = getFile();
		FileWriter writer = null;
		try {
			writer = new FileWriter(dataFile);
			int timeCount = 1;
			int resourceCount = 1;
			for (int j = 0; j < timeCount; j++) {
				long timeStamp = System.currentTimeMillis();
				for (int i = 0; i < resourceCount; i++) {
					UUID uuid = UUID.randomUUID();
					String rowKey = uuid.toString() + "_" + timeStamp;
					Random random = new Random();
					String cpuLoad = String.valueOf(random.nextDouble())
							.substring(0, 4);
					String memory = String.valueOf(random.nextDouble())
							.substring(0, 4);
					StringBuilder builder = new StringBuilder();
					builder.append(rowKey).append("\t").append(cpuLoad)
							.append("\t").append(memory).append("\t").append(uuid.toString()).append("\t").append(timeStamp);
					writer.append(builder.toString());
					if ((i +  1) * (j + 1) < timeCount * resourceCount) {
						writer.append("\r");
					}
				}
			}
			long endTime = System.currentTimeMillis();
			System.out.println("Cost Time: " + (endTime - startTime));
		} catch (IOException e) {
			e.printStackTrace();
		} finally {
			writer.close();
		}
	}

	/**
	 * 得到一个新文件
	 * 
	 * @return
	 * @author lihzh
	 * @date 2012-11-14 下午4:53:31
	 */
	private static File getFile() {
		File file = new File(PATH);
		if (!file.exists()) {
			try {
				file.createNewFile();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}
		return file;
	}

文件格式大致如下：

29611690-69cb-4749-8bd5-be75793d6611_1352968490061 0.41 0.34 29611690-69cb-4749-8bd5-be75793d6611 1352968490061

然后将文件上传到HDFS中，

hadoop fs -put /home/admin/Desktop/data.txt /test<

转换成HFile格式存储

hadoop jar hbase-version.jar importtsv -Dimporttsv.columns=HBASE_ROW_KEY,c1,c2 -Dimporttsv.bulk.output=tmp hbase_table hdfs_file  

生成HFile文件。其中c1,c2是列名，格式为:列族：列名

然后，导入到HBase中：

hadoop jar hbase-version.jar completebulkload /user/hadoop/tmp/cf hbase_table

这里的路径都是hdfs的路径。

在一个下雨的夜晚，我在思考Java中内存管理的问题，以及Java集合对内存使用的效率情况。我做了一个简单的实验，测试在16G内存条件下，Java的Map可以插入多少对象。

这个试验的目的是为了得出集合的内部上限。所以，我决定使用很小的key和value。所有的测试，都是在64w位linux环境下进行的，操作系统是ubuntu12.04。JVM版本为Oracle Java 1.7.0_09-bo5 (HotSpot 23.5-b02)。在这个JVM中，压缩指针(compressed pointers(-XX:+UseCompressedOops))的选项是默认打开的。

首先是简单的针对java.util.TreeMap的测试。不停向其中插入数字，直到其抛出内存溢出异常。JVM的设置是-xmx15G

import java.util.*; 
Map m = new TreeMap();
for(long counter=0;;counter++){
  m.put(counter,"");
  if(counter%1000000==0) System.out.println(""+counter);
}

这个用例插入了1 7200 0000条数据。在接近结束的时候，由于高负荷的GC插入效率开始降低。第二次，我用HashMap代替TreeMap，这次插入了182 000 000条数据。

Java默认的集合并不是最高效利用内存的。所以，这回我们尝试最后化内存的测试。我选择了MapDB中的LongHashMap，其使用原始的long key并且对封装的内存占用进行了优化。JVM的设置仍然是-Xmx15G。

import org.mapdb.*
LongMap m = new LongHashMap();    
for(long counter=0;;counter++){
  m.put(counter,"");
  if(counter%1000000==0) System.out.println(""+counter);
}

这次，计数器停止在了276 000 000。同样，在插入接近结束的时候，速度开始减慢。看起来这是基于堆的结合的限制所在。垃圾回收带来了瓶颈 。

现在是时候祭出杀手锏了:-)。我们可以采用非基于堆的方式存储，这样GC就不会发现我们的数据。我来介绍一下MapDB，它提供了基于数据库引擎的并发同步的TreeMap和HashMap。它提供了多样化的存储方式，其中一个就是非堆内存的方式。(声明：我是MapDB的作者)。

现在，让我们再跑一下之前的用例，这次采用的是非堆的Map。首先是配置并打开数据库，它打开的直接基于内存存储并且关闭事物的模式。接下来的代码是在这个db中创建一个新的map。

import org.mapdb.*

DB db = DBMaker
   .newDirectMemoryDB()
   .transactionDisable()
   .make();

Map m = db.getTreeMap("test");
for(long counter=0;;counter++){
  m.put(counter,"");
  if(counter%1000000==0) System.out.println(""+counter);
}

这是非堆的Map，所以我们需要不同的JVM配置： -XX:MaxDirectMemorySize=15G -Xmx128M。这次测试在达到980 000 000条记录的时候出现内存溢出。

但是，MapDB还可以优化。之前样例的问题在于记录的破碎分散，b-tree的节点每次插入都要调整它的容量。变通的方案是，将b-tree的节点在其插入前短暂的缓存起来。这使得记录的分散降到最低。所以，我们来改变一下DB的配置：

DB db = DBMaker
     .newDirectMemoryDB()
     .transactionDisable()
     .asyncFlushDelay(100)
     .make();

Map m = db.getTreeMap("test");   

这次记录数达到了 1 738 000 000。速度也是达到了惊人的31分钟完成了17亿数据的插入。

MapDB还能继续优化。我们把b-tree的节点容量从32提升到120并且打开透明(OneCoder理解为对用户不可见的)压缩：

DB db = DBMaker
            .newDirectMemoryDB()
            .transactionDisable()
            .asyncFlushDelay(100)
            .compressionEnable()
            .make();

   Map m = db.createTreeMap("test",120, false, null, null, null);

这个用例在大约3 315 000 000条记录时出现内存溢出。由于压缩，他的速度 有所降低，不过还是在几个小时内完成。我还可以进行一些优化(自定义序列化等等) ，使得数据量达到大约40亿。

也许你好奇所有这些记录是怎么存储的。答案就是，delta-key压缩。(OneCoder注：不知如何翻译)。当然，向B-Tree插入已经排好序的递增key是最佳的使用场景，并且MapDB也对此进行了一些小小的 优化。最差的情形就是key是随机的.

后续更新：很多朋友对压缩有一些困惑。在这些用例中，Delta-key 压缩默认都是启用的。在下面的用例中，我又额外开启了zlib方式的压缩：

DB db = DBMaker
            .newDirectMemoryDB()
            .transactionDisable()
            .asyncFlushDelay(100)
            .make();

    Map m = db.getTreeMap("test");

    Random r = new Random();
    for(long counter=0;;counter++){
        m.put(r.nextLong(),"");
        if(counter%1000000==0) System.out.println(""+counter);
    }

即使在随机序列情况下，MapDB也可以存储652 000 000条记录，大概4倍于基于堆的集合。

这个简单的试验没有太多的目的。这仅仅是我对MapDB的一种优化。也许，更多的惊喜在于插入效率确实不错并且MapDB可以抗衡基于内存的集合。

原文地址：http://kotek.net/blog/3G_map

OneCoder注：OneCoder仅做翻译，顺便了解一下知识，关于本文，下面的评论中也存在一定的争议，大家可以自行关注。此文，权当开阔视野，不是也很好么。