从两个方面比较ElasticSearch和Solr，比较从关系数据库导入的速度和模糊查询的速度。
独立比较1
1. Solr发布了4.0-阿尔法。 试了一下，我发现架构需要自己修改。 好处是附带了数据导入器。 用自己的计算机测试，导入的性能约14分钟为3092730条记录，约3682条/秒。
对于2. 3万条记录，模糊搜索和排序基本上在1秒内返回
3 .刚才的测试是针对每个field分别保存的，现在我们修改了配置文件，添加了复制字段。 所有字段都将复制到名为text的字段中。 导入性能为19分钟3092730条记录，约2713条记录/秒
对于4. 3万条记录，对text的模糊查询基本上在1秒钟内返回，但对所有记录的排序大约需要2到3秒钟
使用elasticsearch 0.19.8，以默认配置、单任务部署，部署性能为20分钟部署3092730条记录，约2577条记录/秒
对于6. 3百万记录，查询基本上在1秒钟内返回，但模糊查询较慢，第一次需要10秒钟，然后大约需要1-3秒钟。 排序大约需要5秒钟，整体排序基本上为100ms
查询和排序命令： {
' query':{
' query_string':{
' query':'*999* '
}
(，
' sort':[
{
' TIME_UP':{
' order':'asc '
}
}
]
}
7. Es0.19.8在两个任务中引入，部署性能为13分钟3092730条记录，约3965条/秒
8. Solr索引所有磁盘后，占用的磁盘空间为1.2G，es占用的磁盘空间为4G
独立比较2
在inteli 7，32g内存的计算机上重新运行这两个比较。 但是，有很大的不同。 Solr在这款性能良好的机器上运行，而es的部署过程在英特尔四核2.5G、4G内存的机器上运行。 可能有性能的差异。 ES版本0.19.8、Solr版本4.0-阿尔法。
1. Solr部署性能： 3400万条记录，使用时间62分钟，平均9140瓶/秒，占用空间12.75G
使用类似*999*的模糊查询，在3秒内返回。 稍长的查询条件*00100014*也在2~3秒内返回
3. Es部署性能(Xmx为10G ) 3400万条记录，40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。
使用类似*999*的模糊查询，9秒返回，稍长的查询条件*00100014*，11.8秒返回
5 .针对特定字段(例如SAM_CODE: *00100014* )而不是针对所有字段，也会在一秒钟内返回。
6 .结论： es查询效率也可以很高，但还不能使用。
7 .结论2:es有将所有字段合并在一起的设置。 默认值集中在一起，但我不知道为什么没有发挥本来的作用。
评论：
1. Solr最初的那个内存使用了默认设定，但是这次变更为10G的结果是导入性能反而变差了。 400万件的记录，8分钟，平均花了8333件/秒。 为什么？
2 .即使恢复默认内存配置，导入速度也很慢。
重新启动Linux，以10G内存配置导入。 5030万条记录，使用时间92分钟，约9112条/秒，表示导入速度和内存配置没有大的差异
4.10G配置时，搜索速度也相差不大。
为了说明lucene4.0和solr4.0的进步大小，我下载了solr3.6.1。 幸运的是，4.0的配置文件在3.6.1中也可以使用，所以我们很快进行了组合测试。 部署性能为3400万条记录，使用时间为55分钟，约10303条/秒。 查询性能： *999*第一次11.6s，*00100014* 27.3s比4.0阿尔法的结果(5000万个结果中的*999*第一次2.6s，*00100014*第一次2.5s )慢很多，而且
集群比较：
使用4台由相同结构(inteli 7，32g内存)的Centos 6.3构成的集群进行了比较。
1 .首先是es。 轻松创建集群，在前面的3400万个索引全部平衡负载后进行测试，然后部署到另一个索引。
2 .部署性能： 8500万条记录，使用时间72分钟，约19676条/秒。 引进前5千万唱片时速度在2万/瓶以上，初期速度为2.2万/瓶。 占用空间78.6G (由于具有冗馀，实际占用空间为157.2G )。
3 .查询性能：
*999*第13.5秒、第2次19.5秒、第3次7.4秒、第4次7.1秒、第5次7.1秒
p>*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒
SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s
SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s
4. Solr4.0-ALPHA，SolrCloud的配置还算简单，启动一个ZooKeeper，然后其他三台机器访问这个地址，就可以组成一个Cloud：
机器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &
其他机器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &
但是在执行 data import 的时候，频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料，把Linux的ulimit当中的nproc改成10240，把Xss改成256K，都解决不了问题。暂时没有办法进行。
结论如下：
1. 导入性能，es更强
2. 查询性能，solr 4.0最好，es与solr 3.6持平，可以乐观的认为，等es采用了lucene4之后，性能会有质的提升
3. Es采用SAM_CODE这样的查询性能很好，但是用_all性能就很差，而且差别非常大，因此，个人认为在目前的es情况下，仍然有性能提升的空间，只是现在还没找到方法。