‘壹’ 如何查看IT大数据中ElasticSearch组件的数据存储路径
如果是默认配置的话，就是放在ES目录下的data文件夹下
如果是默认配置的话，就是放在ES目录下的data文件夹下
-
‘贰’ elasticsearch document 怎么存
本文翻译自Elasticsearch官方指南的distributed document store一章。
分布式文档存储
在上一章中，我们一直在介绍索引数据和获取数据的方法。但是我们省略了很多关于数据是如何在集群中被分布(Distributed)和获取(Fetched)的技术细节。这实际上是有意为之 - 你真的不需要了解数据在ES中是如何被分布的。它能工作就足够了。
在本章中，我们将会深入到这些内部技术细节中，来帮助你了解你的数据是如何被存储在一个分布式系统中的。
路由一份文档(Document)到一个分片(Shard)
当你索引一份文档时，它会被保存到一个主要分片(Primary Shard)上。那么ES是如何知道该文档应该被保存到哪个分片上呢？当我们创建了一份新文档，ES是如何知道它究竟应该保存到分片1或者分片2上的呢？
这个过程不能是随机的，因为将来我们或许还需要获取该文档。实际上，这个过程是通过一个非常简单的公式决定的：
shard = hash(routing) % number_of_primary_shards
以上的routing的值是一个任意的字符串，它默认被设置成文档的_id字段，但是也可以被设置成其他指定的值。这个routing字符串会被传入到一个哈希函数(Hash Function)来得到一个数字，然后该数字会和索引中的主要分片数进行模运算来得到余数。这个余数的范围应该总是在0和number_of_primary_shards - 1之间，它就是一份文档被存储到的分片的号码。
这就解释了为什么索引中的主要分片数量只能在索引创建时被指定，并且将来都不能在被更改：如果主要分片数量在索引创建后改变了，那么之前的所有路由结果都会变的不正确，从而导致文档不能被正确地获取。
用户有时会认为将主要分片数量固定下来会让将来对索引的水平扩展(Scale Out)变的困难。实际上，有些技术能够让你根据需要方便地进行水平扩展。我们会在Designing for scale中介绍这些技术。
所有的文档API(get, index, delete, buli, update和mget)都接受一个routing参数，它用来定制从文档到分片的映射。一个特定的routing值能够确保所有相关文档 - 比如属于相同用户的所有文档 - 都会被存储在相同的分片上。我们会在Designing for scale中详细介绍为什么你可能会这样做。
‘叁’ Elasticsearch的架构是什么样的
Elasticsearch是由Shay Banon发起的一个开源搜索服务器项目，2010年2月发布。迄今，该项目已发展成为搜索和数据分析解决方案领域的主要一员，广泛应用于声名卓着或鲜为人知的搜索应用程序。此外，由于其分布式性质和实时功能，许多人把它作为文档数据库。
Elasticsearch架构简单介绍如下。
索引
索引（index）是Elasticsearch对逻辑数据的逻辑存储，所以它可以分为更小的部分。你可以把索引看成关系型数据库的表。然而，索引的结构是为快速有效的全文索引准备的，特别是它不存储原始值。如果你知道MongoDB，可以把Elasticsearch的索引看成MongoDB里的一个集合。如果你熟悉CouchDB，可以把索引看成CouchDB数据库索引。Elasticsearch可以把索引存放在一台机器或者分散在多台服务器上，每个索引有一或多个分片（shard），每个分片可以有多个副本（replica）。
文档
存储在Elasticsearch中的主要实体叫文档（document）。用关系型数据库来类比的话，一个文档相当于数据库表中的一行记录。当比较Elasticsearch中的文档和MongoDB中的文档，你会发现两者都可以有不同的结构，但Elasticsearch的文档中，相同字段必须有相同类型。这意味着，所有包含title字段的文档，title字段类型都必须一样，比如string。
文档由多个字段组成，每个字段可能多次出现在一个文档里，这样的字段叫多值字段（multivalued）。每个字段有类型，如文本、数值、日期等。字段类型也可以是复杂类型，一个字段包含其他子文档或者数组。字段类型在Elasticsearch中很重要，因为它给出了各种操作（如分析或排序）如何被执行的信息。幸好，这可以自动确定，然而，我们仍然建议使用映射。与关系型数据库不同，文档不需要有固定的结构，每个文档可以有不同的字段，此外，在程序开发期间，不必确定有哪些字段。当然，可以用模式强行规定文档结构。从客户端的角度看，文档是一个JSON对象（关于JSON格式的更多内容，参见http://en.wikipedia.org/wiki/JSON）。每个文档存储在一个索引中并有一个Elasticsearch自动生成的唯一标识符和文档类型。文档需要有对应文档类型的唯一标识符，这意味着在一个索引中，两个不同类型的文档可以有相同的唯一标识符。
文档类型
在Elasticsearch中，一个索引对象可以存储很多不同用途的对象。例如，一个博客应用程序可以保存文章和评论。文档类型让我们轻易地区分单个索引中的不同对象。每个文档可以有不同的结构，但在实际部署中，将文件按类型区分对数据操作有很大帮助。当然，需要记住一个限制，不同的文档类型不能为相同的属性设置不同的类型。例如，在同一索引中的所有文档类型中，一个叫title的字段必须具有相同的类型。
映射
在有关全文搜索基础知识部分，我们提到了分析的过程：为建索引和搜索准备输入文本。文档中的每个字段都必须根据不同类型做相应的分析。举例来说，对数值字段和从网页抓取的文本字段有不同的分析，比如前者的数字不应该按字母顺序排序，后者的第一步是忽略HTML标签，因为它们是无用的信息噪音。Elasticsearch在映射中存储有关字段的信息。每一个文档类型都有自己的映射，即使我们没有明确定义。
现在，我们已经知道Elasticsearch把数据存储在一个或多个索引上，每个索引包含各种类型的文档。我们也知道了每个文档有很多字段，映射定义了Elasticsearch如何对待这些字段。但还有更多，从一开始，Elasticsearch就被设计为能处理数以亿计的文档和每秒数以百计的搜索请求的分布式解决方案。这归功于几个重要的概念，我们现在将更详细地描述。
节点和集群
Elasticsearch可以作为一个独立的单个搜索服务器。不过，为了能够处理大型数据集，实现容错和高可用性，Elasticsearch可以运行在许多互相合作的服务器上。这些服务器称为集群（cluster），形成集群的每个服务器称为节点（node）。
分片
当有大量的文档时，由于内存的限制、硬盘能力、处理能力不足、无法足够快地响应客户端请求等，一个节点可能不够。在这种情况下，数据可以分为较小的称为分片（shard）的部分（其中每个分片都是一个独立的Apache Lucene索引）。每个分片可以放在不同的服务器上，因此，数据可以在集群的节点中传播。当你查询的索引分布在多个分片上时，Elasticsearch会把查询发送给每个相关的分片，并将结果合并在一起，而应用程序并不知道分片的存在。此外，多个分片可以加快索引。
副本
为了提高查询吞吐量或实现高可用性，可以使用分片副本。副本（replica）只是一个分片的精确复制，每个分片可以有零个或多个副本。换句话说，Elasticsearch可以有许多相同的分片，其中之一被自动选择去更改索引操作。这种特殊的分片称为主分片（primary shard），其余称为副本分片（replica shard）。在主分片丢失时，例如该分片数据所在服务器不可用，集群将副本提升为新的主分片。
‘肆’ elasticsearch数据存储目录data会存哪些信息
elasticsearch数据存储目录data会存哪些信息
如果是默认配置的话,就是放在ES目录下的data文件夹下如果是默认配置的话,就是放在ES目录下的d
‘伍’ elasticsearch integer 和 string存储的区别
在Es中，字段的类型很关键：
在索引的时候，如果字段第一次出现，会自动识别某个类型，这种规则之前已经讲过了。
那么如果一个字段已经存在了，并且设置为某个类型。再来一条数据，字段的数据不与当前的类型相符，就会出现字段冲突的问题。如果发生了冲突，在2.x版本会自动拒绝。
如果自动映射无法满足需求，就需要使用者自己来设置映射类型，因此，就需要使用者了解ES中的类型。
下面就步入正题吧！
‘陆’ elasticsearch 怎么更新数据的
我们经常有这样的需求，在对 Elasticsearch 数据进行操作的时候，要及时返回刚刚操作完毕的数据，或者数据列表。
比如加入存储一条数据后，我马上要返回数据的总条数，这个时候，会出问题，Elasticsearch会返回操作之前的数据，也就是假如开始有500条数据，我Insert了一条进去，按道理来说应该是501条，但是这个时候查询会发现，只有500条数据，再次请求又得到501条数据，这个是怎么回事呢？
这个问题因为 Elasticsearch 有延迟的关系（好像记得是3秒还是1秒来着）。有的人的做法比如有以下方法解决的。
Thread.sleep(3000L);
还有再请求一次的。但这些都不是解决方案，当你知道有方法的时候，你会自己笑自己。
其实我看过这个网站的博客里有用到，但是群主没提到这个方法的作用。
在：http://www.sojson.com/blog/88.html里有一句代码，如下：
BulkRequestBuilder bulkRequest = ESTools.client.prepareBulk().setRefresh(true);
这里的setRefresh(true);
就是自动刷新的用处。所以在我们CRUD的时候，如果对数据增删改操作的时候，如果要及时返回最新数据，那么我们就需要加这个方法，及时刷新数据。
当然 Elasticsearch 也是可以配置刷新时间的，但是没必要，频繁的刷新会造成压力过大。
‘柒’ elasticsearch，solr对比各自有哪些优缺点
从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。
单机对比
1. Solr 发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data importer。在自己的计算机上测试了一下，导入的性能大概是：14分钟导入 3092730 条记录，约合 3682条/秒。
2. 3百万条记录的情况下，模糊查询和排序基本都在1秒内返回
3. 刚才的测试，是每个field单独存储，现在修改了一下配置文件，增加了一个Field，所有的field都拷贝一份到text这个field里面去，导入的性能大概是：19分钟导入了3092730 条记录，约合 2713条/秒
4. 3百万条记录的情况下，针对text的模糊查询基本在1秒内返回，但是针对所有记录的排序，大概要2~3秒
5. 使用 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
在一台Intel i7，32G内存的机器上，重新跑这两个的对比。不过有个重大的区别在于，Solr是在这台性能很好的机器上跑，而es的导入进程则是在一台Intel 四核 2.5G，4G内存的机器上跑的，也许会有性能的差异。ES版本0.19.8，Solr版本4.0-ALPHA。
1. Solr的导入性能：3400万条记录，用时62分钟，平均9140条/秒，占用空间12.75G
2. 使用 *999* 这样的模糊查询，3秒以内返回，稍长一点的查询条件 *00100014*，也是2~3秒返回
3. Es的导入性能（设置Xmx为10G）：3400万条记录，用时40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。
4. 使用 *999* 这样的模糊查询，9秒返回，稍长一点的查询条件 *00100014*，11.8秒返回
5. 如果不是针对所有字段查询，而是针对某个特定字段，比如 SAM_CODE: *00100014*，那么也是1秒以内返回。
6. 结论：es的查询效率也可以很高，只是我们还不会用。
7. 结论2：es有个设置是把所有字段放一块的那个，缺省是放一起，但是不知道为什么没起到应有的作用。
备注：
1. Solr第一次的那个内存使用的是缺省设置，这次改为10G，结果导入性能反而变差了，400万条记录，用了8分钟，平均8333条/秒，不知道为什么。
2. 改回缺省的内存配置，导入速度仍然慢。
3. 重启Linux，用10G的内存配置，再导入，5030万条记录，用时92分，约9112条/秒，说明导入速度和内存配置没有大差别
4. 在10G配置的情况下，检索速度也差别不大。
5. 为了搞清楚lucene4.0和solr4.0的进步有多大，下载了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起来进行测试，导入性能为：3400万条记录，用时55分钟，约10303条/秒，占用空间13.85G。查询性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的结果（5000万结果当中，*999*第一次2.6s，*00100014*第一次2.5s）来说，慢了很多，与es的性能差不多，因此，也许lucene4.0真的对性能有大幅提升？
集群对比：
采用4台同样配置（Intel i7，32G内存）的Centos 6.3组成的集群，进行对比。
1. 首先是es，很方便的就组成了一个Cluster，等上一个3400万条的Index全部均衡负载之后进行测试，导入到另外一个Index当中。
2. 导入性能：8500万条记录，用时72分钟，约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上，初始的速度在2.2万/条。占用空间78.6G（由于有冗余，实际占用空间为157.2G）
3. 查询性能：
*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒
*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情况下，仍然有性能提升的空间，只是现在还没找到方法。
‘捌’ elasticsearch如何搭建在hadoop上
配置elasticsearch的存储路径为hdfs需要两步，安装插件elasticsearch-hadoop，在联网的情况下在命令窗口运行：plugin -install elasticsearch/elasticsearch-hadoop/1.2.0即可。
如果没有联网解压插件到plugins中即可，目录为/hadoop。。。。。
在配置文件elasticsearch.yml中要配置如下：
gateway:
type: hdfs
gateway:
hdfs:
uri: hdfs://localhost:9000
‘玖’ 如何搭建elasticsearch
配置elasticsearch的存储路径为hdfs需要两步，安装插件elasticsearch-hadoop，在联网的情况下在命令窗口运行：plugin -install elasticsearch/elasticsearch-hadoop/1.2.0即可。如果没有联网解压插件到plugins中即可，目录为/hadoop。。。。。在配置文件elasticsearch.yml中要配置如下：gateway:type: hdfsgateway:hdfs:uri: hdfs://localhost:9000