后使用快捷导航没有帐号？
查看: 4660|回复: 17
Elasticsearch 能够存储的数据量一般有多大？
金牌会员, 积分 1605, 距离下一级还需 1395 积分
论坛徽章:8
Elasticsearch 能够存储的数据量一般有多大？
金牌会员, 积分 1605, 距离下一级还需 1395 积分
论坛徽章:8
自己先灌水，为了万恶的作业
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
看集群了 我们单位集群20台& &每天数据1亿多条 每条处理18s
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
忘了补充一句 每条记录都是几百k
注册会员, 积分 146, 距离下一级还需 54 积分
论坛徽章:4
所以其实主要是你集群的大小 和整个集群的配置和优化&&原来我们用mongo现在准备用es
金牌会员, 积分 1823, 距离下一级还需 1177 积分
论坛徽章:17
兄弟，分布式存储，你想存多少就存多少，关键在于你的shards分配是不是
金牌会员, 积分 1823, 距离下一级还需 1177 积分
论坛徽章:17
兄弟，分布式存储，你想存多少就存多少，关键在于你的shards分配是不是
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
中级会员, 积分 259, 距离下一级还需 241 积分
论坛徽章:10
能存多少数据根据应用来看吧，如果服务器资源足够的情况下存几十T上百T都不是问题
注册会员, 积分 164, 距离下一级还需 36 积分
论坛徽章:5
估计至少图片G的量 分布式的 达到PB级
高级会员, 积分 624, 距离下一级还需 376 积分
论坛徽章:5
@齐慧强，看集群了 我们单位集群20台& &每天数据1亿多条 每条处理18s。
这个速度怎么这样慢啊，按道理一般查询速度在3秒之内才可以接受啊。你们是查询什么样的数据了。
扫一扫加入本版微信群ElasticSearch与大数据的不解情缘
你好，游客
ElasticSearch与大数据的不解情缘
来源：大讲台&
　　一、ElasticSearch 产生背景
　　1. 海量数据组合条件查询
　　2. 毫秒级或者秒级返回数据
　　Lucene 定义
　　lucene是一个开放源代码的全文检索引擎工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎。
　　ElasticSearch 定义
　　ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
　　二、ElasticSearch vs Lucene
　　1. 成品与半成品的关系
　　2. Lucene专注于搜索底层的建设，而ElasticSearch专注于企业应用。
　　三、ElasticSearch vs Solr
　　Solr 定义：Solr是Apache 下的一个开源项目，使用Java基于Lucene开发的全文检索服务是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引;也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。
　　ElasticSearch vs Solr 优缺点
　　ElasticSearch vs Solr 检索速度
　　当单纯的对已有数据进行搜索时，Solr更快。
　　当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。
　　随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。
　　大型互联网公司，实际生产环境测试，将搜索引擎从Solr转到Elasticsearch以后的平均查询速度有了50倍的提升。
　　ElasticSearch vs Solr 热度
　　ElasticSearch vs Solr 总结
　　1. 二者安装都很简单。
　　2. Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能。
　　3. Solr 支持更多格式的数据，比如JSON、XML、CSV，而 Elasticsearch 仅支持json文件格式。
　　4. Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供
　　5. Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。
　　6. Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。
　　四、ElasticSearch vs 关系型数据库
　　五、ElasticSearch 架构
　　六、ElasticSearch 在Hadoop生态圈的位置
　　七、ElasticSearch 应用场景
　　1. 站内搜索：主要和 Solr 竞争，属于后起之秀
　　2. NoSQL Json文档数据库：主要抢占 Mongo 的市场，它在读写性能上优于 Mongo ，同时也支持地理位置查询，还方便地理位置和文本混合查询。
　　3. 监控：统计、日志类时间序的数据存储和分析、可视化，这方面是引领者
　　4. 国外：Wikipedia(维基百科)使用 ES 提供全文搜索并高亮关键字、Stack Overflow(IT问答网站)结合全文搜索与地理位置查询、Github使用Elasticsearch检索1300亿行的代码
　　5. 国内：百度(在云分析、网盟、预测、文库、钱包、风控等业务上都应用了ES，单集群每天导入30TB+数据，总共每天60TB+)、新浪 、阿里巴巴、腾讯等公司均有对ES的使用
　　6. 使用比较广泛的平台ELK(ElasticSearch, Logstash, Kibana)
相关新闻 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款　　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。其中各者具体区别，这里暂不赘述，只是抛砖引玉。
阅读(...) 评论()1. 多线程程序插入，可以根据服务器情况开启多个线程index
速度可以提高n倍, n&=2
2. 如果有多台机器，可以以每台设置n个shards的方式，根据业务情况，可以考虑取消replias
curl -XPUT &http://10.1.*.*:9200/dw-search/& -d &{
&settings& : {
&number_of_shards& : 20,
&number_of_replicas& : 0
这里设置20个shards, 复制为0，如果需要replicas，可以完成index后再修改为replicas&=1
原文：http://www.elasticsearch.org/guide/reference/api/admin-indices-create-index.html
3. 提高ES占用内存
内存适当调大，初始是256M, 最大1G，
调大后，最小和最大一样，避免GC, 并根据机器情况，设置内存大小，
$ bin/elasticsearch -f -Xmx4g -Xms4g -Des.index.storage.type=memory
原文：http://www.elasticsearch.org/guide/reference/setup/installation.html
4. 减少shard刷新间隔
curl -XPUT &http://10.1.*.*:9200/dw-search/_settings& -d &{
&index& : {
&refresh_interval& : &-1&
完成bulk插入后再修改为初始值
curl -XPUT &http://10.1.*.*:9200/dw-search/_settings& -d &{
&index& : {
&refresh_interval& : &1s&
5. 设置一个shard的段segment最大数
可以减少段文件数，提高查询速度
curl -XPOST &http://10.1.*.*:9200/dw-search/_optimize?max_num_segments=5&
注意：有时候可能需要多次执行
原文：http://www.elasticsearch.org/guide/reference/api/admin-indices-update-settings.html
原文：http://www.elasticsearch.org/guide/reference/index-modules/merge.html
6. 去掉mapping中_all域
Index中默认会有_all的域，这个会给查询带来方便，但是会增加索引时间和索引尺寸
&_all& : {&enabled& : false}
原文：http://www.elasticsearch.org/guide/reference/mapping/all-field.html
curl -XPOST &http://10.1.*.*:9200/dw-search/pt_normal/_mapping& --data-binary @pt_normal_properties.mapping
7. 设置source为压缩模式或者disable
compress=true这个能大大减少index的尺寸
disable将直接没有_source域
8. 增加merge.policy.merge_factor数
设置merge.policy.merge_factor到30，初始是10
增加这个数需要更多的内存，bulk index可以调大这个值.
如果是即时索引，应该调小这个值
原文：http://www.elasticsearch.org/guide/reference/index-modules/merge.html
9. 修改Client获得方式为
Node node = nodeBuilder().client(true).node();
Client client = node.client()
相比transport client更快
测试效果，速度提高不明朗，且报错。去除
相关 [elasticsearch 优化 方法] 推荐：
- 互联网 - ITeye博客
多线程程序插入，可以根据服务器情况开启多个线程index. 速度可以提高n倍, n&=2. 如果有多台机器，可以以每台设置n个shards的方式，根据业务情况，可以考虑取消replias. 这里设置20个shards, 复制为0，如果需要replicas，可以完成index后再修改为replicas&=1.
- 行业应用 - ITeye博客
ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展，而这ES主要是用tranlog进行各节点之间的数据平衡. 所以从上我可以通过索引的settings进行第一优化：. 这两个参数第一是到tranlog数据达到多少条进行平衡，默认为5000，而这个过程相对而言是比较浪费时间和资源的. 所以我们可以将这个值调大一些还是设为-1关闭，进而手动进行tranlog平衡.
- ITeye博客
欢迎发送邮件至
. 本博文为
Elasticsearch Server2nd的部分第7章部分章节的翻译，版权归原作者. 设置Filter cache. 缓存是提高性能的很重要的手段，es中的filter cache能够把搜索时的filter条件的结果进行缓存，当进行相同的filter搜索时（query不同，filter条件相同）,es能够很快的返回结果.
- 数据库 - ITeye博客
ElasticSearch性能优化主要分为4个方面的优化. 1、增加1-2台服务器，用于负载均衡节点. elasticSearch的配置文件中有2个参数：node.master和node.data. 数搭配使用时，能够帮助提供服务器性能.
该node服务器只作为一个数据节点，只用于存储索引数据.
- 开源软件 - ITeye博客
本次分享主要包含两个方面的实战经验：索引性能和查询性能. 索引性能（Index Performance）. 首先要考虑的是，索引性能是否有必要做优化. 主要是看瓶颈在什么地方，若是 Read DB（产生DOC）的速度比较慢，那瓶颈不在 ElasticSearch 时，优化就没那么大的动力. 实际上 Elasticsearch 的索引速度还是非常快的.
- 开源软件 - ITeye博客
在bin/elasticsearch.in.sh中进行配置. 修改配置项为尽量大的内存：. 两者最好改成一样的，否则容易引发长时间GC（stop-the-world）. elasticsearch默认使用的GC是CMS GC. 如果你的内存大小超过6G，CMS是不给力的，容易出现stop-the-world.
- ScienJus's Blog
在使用 Elasticsearch 进行全文搜索时，搜索结果默认会以文档的相关度进行排序，如果想要改变默认的排序规则，也可以通过
sort指定一个或多个排序字段. 但是使用
sort排序过于绝对，它会直接忽略掉文档本身的相关度（根本不会去计算）. 在很多时候这样做的效果并不好，这时候就需要对多个字段进行综合评估，得出一个最终的排序.
- 行业应用 - ITeye博客
因为gc时会使jvm停止工作，如果某个节点gc时间过长，master ping3次（zen discovery默认ping失败重试3次）不通后就会把该节点剔除出集群，从而导致索引进行重新分配. （1）优化gc，减少gc时间. （2）调大zen discovery的重试次数（es参数：ping_retries）和超时时间（es参数：ping_timeout）.
- an74520的专栏
es的mapping设置很关键，mapping设置不到位可能导致索引重建. 请看下面各个类型介绍^_^. 每一个JSON字段可以被映射到一个特定的核心类型. JSON本身已经为我们提供了一些输入,支持
【北京上地】滴滴出行基础平台部招聘 Elasticsearch 与 Mysql binlog databus 开发工程师. 内推简历投递给： . 推销Elasticsearch. 时间序列数据库的秘密（1）—— 介绍. 时间序列数据库的秘密（2）——索引.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。