后使用快捷导航没有帐号？
查看: 1238|回复: 15
Elasticsearch 能够存储的数据量一般有多大？
金牌会员, 积分 1605, 距离下一级还需 1395 积分
论坛徽章:8
Elasticsearch 能够存储的数据量一般有多大？
金牌会员, 积分 1605, 距离下一级还需 1395 积分
论坛徽章:8
自己先灌水，为了万恶的作业
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
看集群了 我们单位集群20台& &每天数据1亿多条 每条处理18s
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
忘了补充一句 每条记录都是几百k
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
所以其实主要是你集群的大小 和整个集群的配置和优化&&原来我们用mongo现在准备用es
金牌会员, 积分 1771, 距离下一级还需 1229 积分
论坛徽章:16
兄弟，分布式存储，你想存多少就存多少，关键在于你的shards分配是不是
金牌会员, 积分 1771, 距离下一级还需 1229 积分
论坛徽章:16
兄弟，分布式存储，你想存多少就存多少，关键在于你的shards分配是不是
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
注册会员, 积分 187, 距离下一级还需 13 积分
论坛徽章:10
能存多少数据根据应用来看吧，如果服务器资源足够的情况下存几十T上百T都不是问题
注册会员, 积分 150, 距离下一级还需 50 积分
论坛徽章:5
估计至少图片G的量 分布式的 达到PB级
高级会员, 积分 624, 距离下一级还需 376 积分
论坛徽章:4
@齐慧强，看集群了 我们单位集群20台& &每天数据1亿多条 每条处理18s。
这个速度怎么这样慢啊，按道理一般查询速度在3秒之内才可以接受啊。你们是查询什么样的数据了。
扫一扫加入本版微信群ES即简单又复杂，你可以快速的实现全文检索，又需要了解复杂的REST API。本篇就通过一些简单的搜索命令，帮助你理解ES的相关应用。虽然不能让你理解ES的原理设计，但是可以帮助你理解ES，探寻更多的特性。
其他相关的内容参考：
为了更好的使用和理解ES，没有点样例数据还是不好模拟的。这里提供了一份官网上的数据，。如果需要的话，也可以去这个网址玩玩，它可以。
首先开启你的ES，然后执行下面的命令，windows下需要自己安装curl、也可以使用cygwin模拟curl命令:
curl -XPOST 'localhost:9200/bank/account/_bulk?pretty' --data-binary
@accounts.json
1 需要在accounts.json所在的目录运行curl命令。
2 localhost:9200是ES得访问地址和端口
3 bank是索引的名称
4 account是类型的名称
5 索引和类型的名称在文件中如果有定义，可以省略；如果没有则必须要指定
6 _bulk是rest得命令，可以批量执行多个操作（操作是在json文件中定义的，原理可以参考之前的翻译）
7 pretty是将返回的信息以可读的JSON形式返回。
执行完上述的命令后，可以通过下面的命令查询：
curl 'localhost:9200/_cat/indices?v'
health index pri rep docs.count docs.deleted store.size pri.store.size
yellow bank
ES提供了两种搜索的方式：请求参数方式 和 请求体方式。
请求参数方式
curl 'localhost:9200/bank/_search?q=*&pretty'
其中bank是查询的索引名称，q后面跟着搜索的条件：q=*表示查询所有的内容
请求体方式（推荐这种方式）
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match_all": {} }
这种方式会把查询的内容放入body中，会造成一定的开销，但是易于理解。在平时的练习中，推荐这种方式。
返回的内容
"took" : 26,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
"hits" : {
"total" : 1000,
"max_score" : 1.0,
"hits" : [ {
"_index" : "bank",
"_type" : "account",
"_id" : "1",
"_score" : 1.0, "_source" : {"account_number":1,"balance":39225,"firstname":"Amber","lastname":"Duke","age":32,"gender":"M","address":"880 Holmes Lane","employer":"Pyrami","email":"","city":"Brogan","state":"IL"}
"_index" : "bank",
"_type" : "account",
"_id" : "6",
"_score" : 1.0, "_source" : {"account_number":6,"balance":5686,"firstname":"Hattie","lastname":"Bond","age":36,"gender":"M","address":"671 Bristol Street","employer":"Netagy","email":"","city":"Dante","state":"TN"}
"_index" : "bank",
"_type" : "account",
"_id" : "13",
返回的内容大致可以如下讲解：
took：是查询花费的时间，毫秒单位
time_out：标识查询是否超时
_shards：描述了查询分片的信息，查询了多少个分片、成功的分片数量、失败的分片数量等
hits：搜索的结果，total是全部的满足的文档数目，hits是返回的实际数目（默认是10）
_score是文档的分数信息，与排名相关度有关，参考各大搜索引擎的搜索结果，就容易理解。&
由于ES是一次性返回所有的数据，因此理解返回的内容是很必要的。它不像传统的SQL是先返回数据的一个子集，再通过数据库端的游标不断的返回数据（由于对传统的数据库理解的不深，这里有错还望指正）。
查询语言DSL
ES支持一种JSON格式的查询，叫做DSL，domain specific language。这门语言刚开始比较难理解，因此通过几个简单的例子开始：
下面的命令，可以搜索全部的文档：
"query": { "match_all": {} }
query定义了查询，match_all声明了查询的类型。还有其他的参数可以控制返回的结果：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match_all": {} },
上面的命令返回了所有文档数据中的第一条文档。如果size不指定，那么默认返回10条。
下面的命令请求了第10-20的文档。
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match_all": {} },
"from": 10,
"size": 10
下面的命令指定了文档返回的排序方式：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match_all": {} },
"sort": { "balance": { "order": "desc" } }
上面了解了基本的搜索语句，下面就开始深入一些常用的DSL了。
之前的返回数据都是返回文档的所有内容，这种对于网络的开销肯定是有影响的，下面的例子就指定了返回特定的字段：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match_all": {} },
"_source": ["account_number", "balance"]
再回到query，之前的查询都是查询所有的文档，并不能称之为搜索引擎。下面就通过match方式查询特定字段的特定内容，比如查询余额为20的账户信息：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match": { "account_number": 20 } }
查询地址为mill的信息：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match": { "address": "mill" } }
查询地址为mill或者lane的信息：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match": { "address": "mill lane" } }
如果我们想要返回同时包含mill和lane的，可以通过match_phrase查询：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": { "match_phrase": { "address": "mill lane" } }
ES提供了bool查询，可以把很多小的查询组成一个更为复杂的查询，比如查询同时包含mill和lane的文档：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": {
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
修改bool参数，可以改为查询包含mill或者lane的文档：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": {
"should": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
也可以改写为must_not，排除包含mill和lane的文档：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": {
"must_not": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
bool查询可以同时使用must, should, must_not组成一个复杂的查询：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": {
{ "match": { "age": "40" } }
"must_not": [
{ "match": { "state": "ID" } }
之前说过score字段指定了文档的分数，使用查询会计算文档的分数，最后通过分数确定哪些文档更相关，返回哪些文档。
有的时候我们可能对分数不感兴趣，就可以使用filter进行过滤，它不会去计算分值，因此效率也就更高一些。
filter过滤可以嵌套在bool查询内部使用，比如想要查询在范围内的所有文档，可以执行下面的命令：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"query": {
"must": { "match_all": {} },
"filter": {
"range": {
"balance": {
"gte": 20000,
"lte": 30000
ES除了上面介绍过的范围查询range、match_all、match、bool、filter还有很多其他的查询方式，这里就先不一一说明了。
聚合提供了用户进行分组和数理统计的能力，可以把聚合理解成SQL中的GROUP BY和分组函数。在ES中，你可以在一次搜索查询的时间内，即完成搜索操作也完成聚合操作，这样就降低了多次使用REST API造成的网络开销。
下面就是通过terms聚合的简单样例：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"size": 0,
"group_by_state": {
"terms": {
"field": "state"
它类似于SQL中的下面的语句：
SELECT state, COUNT(*) FROM bank GROUP BY state ORDER BY COUNT(*) DESC
返回的数据：
"hits" : {
"total" : 1000,
"max_score" : 0.0,
"hits" : [ ]
"aggregations" : {
"group_by_state" : {
"buckets" : [ {
"key" : "al",
"doc_count" : 21
"key" : "tx",
"doc_count" : 17
"key" : "id",
"doc_count" : 15
"key" : "ma",
"doc_count" : 15
"key" : "md",
"doc_count" : 15
"key" : "pa",
"doc_count" : 15
"key" : "dc",
"doc_count" : 14
"key" : "me",
"doc_count" : 14
"key" : "mo",
"doc_count" : 14
"key" : "nd",
"doc_count" : 14
由于size设置为0，它并没有返回文档的信息，只是返回了聚合的结果。
比如统计不同账户状态下的平均余额：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"size": 0,
"group_by_state": {
"terms": {
"field": "state"
"average_balance": {
"field": "balance"
聚合支持嵌套，举个例子，先按范围分组，在统计不同性别的账户余额：
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
"size": 0,
"group_by_age": {
"range": {
"field": "age",
"ranges": [
"from": 20,
"from": 30,
"from": 40,
"group_by_gender": {
"terms": {
"field": "gender"
"average_balance": {
"field": "balance"
聚合可以实现很多复杂的功能，而且ES也提供了很多复杂的聚合，这里作为引导篇，也不过多介绍了。
对于基本的数据搜索大致就是上面讲述的样子，熟悉了一些常用的API，入门还是很简单的，倒是要熟练使用ES，还是需要掌握各种搜索查询的命令，以及ES内部的原理。
阅读(...) 评论()　　ElasticSearch是现在技术前沿的大数据引擎，常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统，其中Logstash是ETL工具，Kibana是数据分析展示平台。ES让人惊艳的是他强大的搜索相关能力和灾备策略，ES开放了一些接口供开发者研发自己的插件，ES结合中文分词的插件会给ES的搜索和分析起到很大的推动作用。ElasticSearch是使用开源全文检索库ApacheLucene进行索引和搜索的，说架构必须和Lucene的一些东西打交道。
关于Lucene：
　　ApacheLucene将写入索引的所有信息组织成一种倒排索引（Inverted Index）的结构之中，该结构是种将词项映射到文档的数据结构。其工作方式与传统的关系数据库不同，大致来说倒排索引是面向词项而不是面向文档的。且Lucene索引之中还存储了很多其他的信息，如词向量等等，每个Lucene都是由多个段构成的，每个段只会被创建一次但会被查询多次，段一旦创建就不会再被修改。多个段会在段合并的阶段合并在一起，何时合并由Lucene的内在机制决定，段合并后数量会变少，但是相应的段本身会变大。段合并的过程是非常消耗I/O的，且与之同时会有些不再使用的信息被清理掉。在Lucene中，将数据转化为倒排索引，将完整串转化为可用于搜索的词项的过程叫做分析。文本分析由分析器（Analyzer）来执行，分析其由分词器（Tokenizer），过滤器（Filter）和字符映射器（Character Mapper）组成，其各个功能显而易见。除此之外，Lucene有自己的一套完整的查询语言来帮助我们进行搜索和读写。
&　　[注]ES中的索引指的是查询/寻址时URI中的一个字段如：[host]：[port（9200）]/[index]/[type]/[ID]?[option]，而Lucene中的索引更多地和ES中的分片的概念相对应。
回到ElasticSearch，ES的架构遵循的设计理念有以下几个特征：
1.&合理的默认配置：只需修改节点中的Yaml配置文件，就可以迅捷配置。这和Spring4中对配置的简化有相似的地方。
2.&分布式工作模式：ES强大的Zen发现机制不仅支持组广播也支持点单播，且有&知一点即知天下&之妙。
3.&对等架构：节点之间自动备份分片，且使分片本身和样本之间尽量&远离&，可以避免单点故障。且Master节点和Data节点几乎完全等价。
4.&易于向集群扩充新节点：大大简化研发或运维将新节点加入集群所需的工作。
5.&不对索引中的数据结构增加任何限制：ES支持在一个索引之中存在多种数据类型。
6.&准实时：搜索和版本同步，由于ES是分布式应用，一个重大的挑战就是一致性问题，无论索引还是文档数据，然而事实证明ES表现优秀。
（一）分片策略
　　选择合适的分片数和副本数。ES的分片分为两种，主分片（Primary Shard）和副本（Replicas）。默认情况下，ES会为每个索引创建5个分片，即使是在单机环境下，这种冗余被称作过度分配（Over Allocation），目前看来这么做完全没有必要，仅在散布文档到分片和处理查询的过程中就增加了更多的复杂性，好在ES的优秀性能掩盖了这一点。假设一个索引由一个分片构成，那么当索引的大小超过单个节点的容量的时候，ES不能将索引分割成多份，因此必须在创建索引的时候就指定好需要的分片数量。此时我们所能做的就是创建一个新的索引，并在初始设定之中指定这个索引拥有更多的分片。反之如果过度分配，就增大了Lucene在合并分片查询结果时的复杂度，从而增大了耗时，所以我们得到了以下结论：
　　我们应该使用最少的分片！
　　主分片，副本和节点最大数之间数量存在以下关系：
　　节点数&=主分片数*（副本数+1）
&　 &控制分片分配行为。以上是在创建每个索引的时候需要考虑的优化方法，然而在索引已创建好的前提下，是否就是没有办法从分片的角度提高了性能了呢？当然不是，首先能做的是调整分片分配器的类型，具体是在elasticsearch.yml中设置cluster.routing.allocation.type属性，共有两种分片器even_shard,balanced（默认）。even_shard是尽量保证每个节点都具有相同数量的分片，balanced是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。
　　每次ES的分片调整都是在ES上的数据分布发生了变化的时候进行的，最有代表性的就是有新的数据节点加入了集群的时候。当然调整分片的时机并不是由某个阈值触发的，ES内置十一个裁决者来决定是否触发分片调整，这里暂不赘述。另外，这些分配部署策略都是可以在运行时更新的，更多配置分片的属性也请大家自行Google。
（二）路由优化
　　ES中所谓的路由和IP网络不同，是一个类似于Tag的东西。在创建文档的时候，可以通过字段为文档增加一个路由属性的Tag。ES内在机制决定了拥有相同路由属性的文档，一定会被分配到同一个分片上，无论是主分片还是副本。那么，在查询的过程中，一旦指定了感兴趣的路由属性，ES就可以直接到相应的分片所在的机器上进行搜索，而避免了复杂的分布式协同的一些工作，从而提升了ES的性能。于此同时，假设机器1上存有路由属性A的文档，机器2上存有路由属性为B的文档，那么我在查询的时候一旦指定目标路由属性为A，即使机器2故障瘫痪，对机器1构不成很大影响，所以这么做对灾况下的查询也提出了解决方案。所谓的路由，本质上是一个分桶（Bucketing）操作。当然，查询中也可以指定多个路由属性，机制大同小异。
（三）ES上的GC调优
　　ElasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也是一个很有意义的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发致命的OutOfMemoryException。这意味着要么内存不足，要么出现了内存泄露。处理GC问题，首先要确定问题的源头，一般有两种方案：
　　1. 开启ElasticSearch上的GC日志
　　2. 使用jstat命令
　　3. 生成内存Dump
　　第一条:在ES的配置文件elasticsearch.yml中有相关的属性可以配置，关于每个属性的用途这里当然说不完。
　　第二条:jstat命令可以帮助我们查看JVM堆中各个区的使用情况和GC的耗时情况。
　　第三条:最后的办法就是将JVM的堆空间转储到文件中去，实质上是对JVM堆空间的一个快照。
　　想了解更多关于JVM本身GC调优方法请参考：/technetwork/java/javase/gc-tuning-6-140523.html
　　另外，通过修改ES节点的启动参数，也可以调整GC的方式，但是实质上和上述方法是等同的。
（四）避免内存交换
　　这一点很简单，由于操作系统的虚拟内存页交换机制，会给性能带来障碍，如数据写满内存会写入Linux中的Swap分区。
　　可以通过在elasticsearch.yml文件中的bootstrap.mlockall设置为true来实现，但是需要管理员权限，需要修改操作系统的相关配置文件。
（五）控制索引合并
　　上文提到过，ES中的分片和副本本质上都是Lucene索引，而Lucene索引又基于多个索引段构建（至少一个），索引文件中的绝大多数都是只被写一次，读多次，在Lucene内在机制控制下，当满足某种条件的时候多个索引段会被合并到一个更大的索引段，而那些旧的索引段会被抛弃并移除磁盘，这个操作叫做段合并。&
　　Lucene要执行段合并的理由很简单充分：索引段粒度越小，查询性能越低且耗费的内存越多。频繁的文档更改操作会导致大量的小索引段，从而导致文件句柄打开过多的问题，如修改系统配置，增大系统允许的最大文件打开数。总的来讲，当索引段由多一个合并为一个的时候，会减少索引段的数量从而提高ES性能。对于研发者来讲，我们所能做的就是选择合适的合并策略，尽管段合并完全是Lucene的任务，但随着Lucene开放更多配置借口，新版本的ES还是提供了三种合并的策略tiered，log_byte_size，log_doc。另外，ES也提供了两种Lucene索引段合并的调度器：concurrent和serial。其中各者具体区别，这里暂不赘述，只是抛砖引玉。
阅读(...) 评论()