后使用快捷导航没有帐号？
查看: 234|回复: 2
ES(elasticsearch) 有谁工作中用吗?
金牌会员, 积分 1147, 距离下一级还需 1853 积分
论坛徽章:13
ES(elasticsearch) 有谁工作中用吗?
推荐一本书籍,
2.0 出来后网上的例子都1.0的
两个区别大吗?
中级会员, 积分 217, 距离下一级还需 283 积分
论坛徽章:0
我用过，区别有一点，但不是很大，近期准备升级到2
注册会员, 积分 121, 距离下一级还需 79 积分
论坛徽章:0
可以看他的release信息，都有的，变动不是特别大Elasticsearch数据架构及基本特点 - 推酷
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处理许多节点。集群的状态由时光之门控制。默认情况下，每个节点都在本地存储这些信息，并且在节点中同步。
相关图书推荐
一本书全面掌握Wikimedia、Stack Overflow、GitHub使用的新一代分布式全文搜索引擎
Elasticsearch是一个基于Lucene构建的开源、分布式、RESTful风格的搜索引擎。它被设计用于云计算中，具有实时搜索、稳定、快速、安装使用方便等优点。本书是关于Elasticsearch的百科全书式著作，介绍了Elasticsearch这个优秀的全文检索和分析引擎从安装和配置到集群管理的各方面知识。
点击左下角查看更多内容
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
没有分页内容
图片无法显示
视频无法显示
与原文不一致每日产生 1440 万条数据，如何做到查询效率在百毫秒内体验？ - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
每日产生 1440 万条数据，如何做到查询效率在百毫秒内体验？
· 307 天前 · 3774 次点击
现行需求分析
每隔十秒产生1万条数据，每一条数据约260字节。
数据产生时间9:30－11:30；13:00 －15:00。在这个时间段内一天数据量约为：$1万*6*60*4 = 1440万条，约3.5GB数据$。长期预估1-3年内产生：3.7TB数据。
已产生数据非常小量更新操作，可以任务数据库无更新操作（如update ，delete），只有插入、查询操作（insert 、select）
无复杂查询。如：group by ，join
查询操作并发度不高，但查询效率严格控制在十毫秒到几百毫秒内。
对写数据库操作要求高，达到10秒内完成插入1万条数据
每条数据字段都是数字或段文字，没有复杂字段。
选择什么样物理服务器＋数据库＋数据架构？如dell r730+mysql＋分库分表？
40 回复 &| &直到
17:34:39 +08:00
& &307 天前
mysql按日期分表比较好，建好索引，查询还是很快的。插入没测过。
& &307 天前
撸主是自己计算XX指数么 还是数据分析的高频交易
& &307 天前
读写分离，分库分表，上搜索引擎.
elasticsearch号称支持pb级的搜索。
& &307 天前
数据产生时间9:30－11:30；13:00 －15:00
周六周日不产生?
& &307 天前 via Android
每个写入时间段，创建一个新表来接受输入，尽量少的索引，来保证插入效率。如果觉得效率还不够，就每一天的每一个小时都创建一个表接受插入。
每天15点开始执行数据汇总操作，将当天的每个表数据汇入总表，加尽量多且必要的索引。
如果存在大量重复记录，可以去重，然后建立一个计数器表，统计每一种记录的次数即可
数据库不建议自己服务器搭建，用阿里云RDS，性能超强
& &307 天前
我的做法时，根据时间创建新表，我当时是一天一个表，加必要的索引
搜索时，如果搜索某一天的话，就搜索那天的表，
如果搜索两天以上，就根据时间范围，把那几天的表的组合起来建立临时表，再去搜索
没有你的数据这么多，所以没法给你具体的结果
& &307 天前
考虑自己有多大的带宽，如果1000MB/s的带宽，可以直接考虑同步到服务器上，然后让云去烦恼。
如果是自有服务器，考虑服务器群来处理，其实就是分表。
& &307 天前
@ 每天都会产生数据。everyday，不放假。哈哈
& &307 天前
@ 你就是每天产生的数据，最终都会汇总到一个大表中，这样日积月累这个表会很大很大，我想这个总表是不是在逻辑看作一个表，在实际物理存储的时候是分成小表存储，其实就是一个分表操作。但是做成一个总表，在以后查询效率控制在百毫秒内，我觉效率会不好。但是每天建一个表，就是每天产生的表数据量为1440万，以后查询时候，按照时间查询，找到对应的表，再到对应的字段，这样效率应该可以控制在百毫秒内。在全局上看，我还不太清楚这两种方案好与坏
& &307 天前
@ 我们想存到我们自己物理服务器，出于数据安全性考虑
& &307 天前
@ 你的做法，和我一开始是一样的。你的单表数据量是多少，查询效率如何，参考下。谢谢哦
& &307 天前
无复杂查询尽量别用RDMS
& &307 天前
@ 不知道你目标是50~100ms还是100~300ms，这两个数量级是两个坑
定个目标咯，我觉得我没有对50ms内的数量级做任何建议，这个太挑战我能力了。
你现在是做架构方案，还是改造？
& &307 天前
卤煮要自己存L1还是L2的行情数据啊？
& &307 天前
& &307 天前
如果你存的是时间序列之类，直接append文件，每条记录固定长度，查询的时候自己去算offset，然后读出来。
& &307 天前
@ 计算机永远是时间换空间,空间换时间的游戏,要想查找快,就需要占更大的空间,最有效的加快查找办法是做反向索引,google上千亿页面怎么做的几十毫秒查询的呢,他是先把所有可能的关键词都做了预先的计算,把关键词对应的搜索结果已经缓存下来了,查找的时候就直接调用结果,不需要再去遍历总表了.
你是否可以提前预判到可能被查询的关键词,利用15点到第二天9点这段时间全部穷举,缓存下来.写到一个表里.
& &307 天前
@ 我估计楼主应该是要存股市之类的tick data
& &307 天前
稍微计算了一下，每秒大约是250kb的数据写入，这个对大部分提供数据库云服务商来说，都不是什么难度。
除非你自己能handle，不然不是很建议自建数据库。
查询的效率 依赖你的sql语句以及索引，这个只能具体分析了。例如如果你写个select *想100ms以内返回当日的所有数据，神仙都帮你不了。
& &307 天前
& &307 天前
嗯！你说的反向索引是不错的方案。谢谢
& &307 天前
@ 我准备收拾收拾东西 ，跳楼了。。。。不要拦我
& &307 天前 via iPhone
mongodb无压力
& &307 天前
我们这边一天产生4g的数据量，按日分表建立索引。数据进入时采用缓存，每隔15秒插入一次。
& &307 天前
后端elasticsearch存储，调优后单台2W/S写入速度，可水平扩展集群系统，前面可以在加个mogodb之类的数据库来持久化一下，elasticsearch丢起数据来集群恢复起来很慢
& &307 天前 via Android
taowen.gitbooks.io
用elasticsearch设计好mapping
& &307 天前
一看就知道是l2数据，别问我为什么知道
& &307 天前
@ 看时间都知道了
& &307 天前
elasticsearch
& &307 天前
elasticsearch，solr，sphinx
& &307 天前
NoSQL的解决方案就可以满足你的需求，比如HBase
& &307 天前
1,可以不更新，就插入和查询
2,无复杂查询
3 写数据库操作要求高
4 没有复杂字段
我知道可能不行，以前也就实习的时候用过，但是dynamoDB和cassandra怎么样？
理论上，可能，好像，没问题，但是似乎有人告诫我NoSQL是坑不要入。
& &307 天前
& &307 天前
@ 我是在设计架构。查询效率在500ms都是可以接受的。
& &307 天前
@ Mongo 显然不行，访问量高了丢数据。
& &306 天前
@ 我是你的百分之一的量，效率方面也就没有参考价值了！我的问题还要面对很多数据去组合，group by 的问题。
@ 讲的最好了，想要速度，就得需要更大的空间去做索引或缓存
& &306 天前
& &306 天前
这个时间段像是A股交易
& &306 天前
数据库的话试试Hbase吧,性能的话可以根据需求来部署HDFS集群
& · & 1673 人在线 & 最高记录 1847 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.7.3 · 55ms · UTC 03:12 · PVG 11:12 · LAX 20:12 · JFK 23:12? Do have faith in what you're doing.