关于ElasticSearch与MySql的数据存储测试！

8870188

　　一直好奇存储大小相同的记录，es和mysql谁占用存储空间更大呢。虽然按道理来看应该是mysql，但一直没有亲自尝试，总还是心里感觉不那么踏实。
　　所以今天做一个测试，看看到底实际情况怎么样？
　　关于在二者的数据存储，有下面一个大概的说明，可能不够准确，但我只知道这么多:
　　1、ES先将数据存到内存，再通过队列的形式写到磁盘；虽然mysql也有内存模式，但是在大多数实际应用中我们仍然使用的传统模式，所以在并发写入方面，es要优于mysql。
　　2、ES存储的数据是经过压缩的。在实际测试中笔者发现6千条记录并不比5千条记录所占用的磁盘空间大。
　　3、关于mysql，每条索引的长度是和你创建列的时候制定的长度相同的。比如你创建varchar(100)，当你在该列上创建索引，那么索引的长度则是102字节，因为长度超过64字节则会额外增加2字节记录索引的长度。
　　4、在这个测试中es未做分词，仅用于数据存储。
　　测试机硬件配置：
　　CPU
　　I7 8核心
　　内存
　　12G
　　硬盘
　　320G
　　网络
　　局域网
　　ES索引配置：5个主分片，未添加复制分片。Type结构如下：

字段

类型

分词

备注

　　id
　　string

否

　　createTimeYmd
　　date

否

　　创建日期yyyy-mm-dd格式
　　createTime
　　date

否

　　创建时间yyyy-mm-dd hh:mi:ss格式
　　createName
　　string

否

　　xmlContent
　　string

否

　　申报表xml报文，本次测试中使用的xml报文为30kb的xml结构体。约等于2.8w个字符长度。
　　refKey
　　string

否

　　业务关联字段（模拟）
　　mysql数据表的结构与es中type的结构相同，详细如下：

字段

类型

主键

备注

　　id
　　long

是

　　自增
　　createTimeYmd
　　date

　　创建日期yyyy-mm-dd格式
　　createTime
　　date

　　创建时间yyyy-mm-dd hh:mi:ss格式
　　createName
　　varchar(10)

　　xmlContent
　　text

　　申报表xml报文，本次测试中使用的xml报文为30kb的xml结构体。约等于2.8w个字符长度。
　　refKey
　　varchar(10)

　　业务关联字段（模拟）
　　以下为es记录数与物理文件列表：

记录条数 单位：行

es数据文件(物理存储空间)

mysql数据文件(物理存储空间)

　　5000
　　21.8M
　　183.51M
　　15000
　　47.9M
　　550.51M
　　65000
　　257M
　　2386M
　　18w
　　4.02GB
　　对比鲜明，不忍继续
　　26.8w
　　7.85GB
　　677621
　　27.5GB
　　从以上数据指标可以看出，ES在做存储的时候针对数据是做了压缩的。根据其规律可以推测出1000W行这样的记录，其存储空间约为500GB。1亿条记录，其主分片存储空间约为5T。
　　在5000至6.5w行数据的写入过程中，es与mysql完成写入的时间都在可接受的范围内，耗时并不长。（ps:mysql使用单线程for循环的方式插入数据;es前6.5w行记录使用单线程循环插入，后面数据过多，使用8个线程，循环插入。）
　　由于对比过于鲜明，相同数据量的情况下mysql占用的空间明显比es大很多，在插入6.5W行数据后就没再继续做插入测试。
　　在添加数据过程中，笔者尝试边写入边查询。使用refKey做为条件进行随机查询，值得一提的是在6.5万行记录中查询一条记录所耗时间不足3秒；而mysql，在边写入边查询的时候(特别是循环暴力写入)，其查询几乎处于停滞状态。
　　在添加操作结束后，笔者随机做了一下查询操作，如果使用主键mysql查询能够很快得到结果，如果使用非主键----refKey做查询，mysql要在7,8秒左右才能返回结果，而es查询相同条件的数据，仅需要2秒不足，且es里面的总数据量在60w+,比mysql的数据总量要大很多。
　　做此对比的目的不是说es就比mysql好用。二者各有所长，要按使用场景，按需选用。
　　以上为es与mysql存储数据的对比结果。测试过程中使数据在附件中列出。如果没有，可能是我忘了， 如果有人需要，可提醒我上传。