es数据库详解？

一、es数据库详解？

es数据库是一个基于Lucene的搜索服务器。

es数据库提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。

es数据库是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。

设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

官方客户端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。

根据DB-Engines的排名显示，es数据库是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。

二、ES是什么数据库？

ElasticSearch简称ES，是一个高拓展和开源的全文搜索和分析引擎，可以准实时地存储、搜索、分析海量的数据。

它和MongoDB、redis等一样是非关系型数据。

业应用定位：采用Restful API标准的可扩展和高可用的实时数据分析的全文搜索工具

三、es数据库优缺点？

ElasticSearch最广泛的使用场景，是提供垂直搜索功能。什么是垂直搜索呢？

垂直搜索引擎是针对某一个行业的专业搜索引擎，是搜索引擎的细分和延伸，是对网页库中的某类专门的信息进行一次整合，定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。垂直搜索是相对通用搜索引擎的信息量大、查询不准确、深度不够等提出来的新的搜索引擎服务模式，通过针对某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。其特点就是“专、精、深”，且具有行业色彩，相比较通用搜索引擎的海量信息无序化，垂直搜索引擎则显得更加专注、具体和深入。

其实说白了就一句话，垂直搜索是在企业内部使用的搜索引擎。这种搜索引擎的特点是，内容可能是一些结构化的数据，而不像大搜索那样都是杂乱的内容。

一般被拿来解决一些什么样的问题？

数据库字段太多，查询太慢，索引没有办法再做优化；

数据库一个count就拖死全表；

MySQL的limit翻到几十几百万页后实在是太慢；

数据库like实在太慢，每次like整个服务器cpu内存飙高，拖慢整个线上服务；

想要对外/内提供db里的数据的全文检索服务；

提供日志(程序运行)查询功能；

下面来针对上面几方面的问题逐一进行说明。

数据库方面

MySQL对于一些较为固定，字段较少的查询方式，可以通过简单的增加索引来完成优化。在大多数公司，即使对索引优化不熟悉，也有专门的dba来帮忙完成一些简单的优化。甚至有些公司要求程序中不允许出现orm，必须用纯sql来完成业务逻辑，这样dba可以直接介入到代码中来。

不过到字段太多的时候，这种方法就失灵了。字段越多，查询自然就越慢（比如单条记录可能都超过了4k）。

MySQL表在普通查询过程中，比如select * from xxx limit 100w, 100;这种，数据量小的时候随便写sql，可能不会体会到翻页的痛。但在一个单表3000w的系统中写了limit 100w, 10。那数据库服务器就哭了。因为实际上数据库为了取出想要的那几条数据，需要把所有的数据也就是10000010条都取到内存中，复杂一点的select再加上order by则可能会同时涉及到多次磁盘读取和文件排序，慢上加慢。

除此之外，现在最流行的innodb之类的存储引擎在计算count的时候非常的慢。当然了，网络上会有人从乱七八糟的文章里看到换myisam应该就会更快的结论，但这其实是错的。如果在select语句的where条件中也有表达式时，这两种存储引擎本质上都是一样的，都会很慢很慢。

还有MySQL的like，其实没什么玄幻的，每次做like本质还是查询内容去和数据库字段做字符串匹配。非常地慢。

现在一般的互联网系统都是普遍的写少读多的系统，写/读搞不好会有1/5以上。但因为数据量庞大，为了读取效率而去做拆表或者拆库的话，有时候实在是有点得不偿失。而且拆表拆库对业务代码来说也并不透明，还可能会对本来支持的功能造成额外的影响。只是为了查询而去拆分的话，不是很合适。

上面这些问题，ES都可以解决。企业里对数据的查询一般可以分为三种：列表查询、详情查询和统计查询。列表一般就是列表页对应的查询，详情查询一般就是具体id对应的详情查询，而统计查询一般都是在看一些数值之类的报表，也就是一堆count值。

这三种查询里，MySQL做起来最困难的是1和3，即列表查询和统计查询。列表查询这种场景也会对应各种各样的查询条件，例如字段等于/小于/大于/不等判断，或者像字符串的严格匹配/前后缀模糊查询，时间字段的范围查询，in查询等等。这些查询都可以翻译为ES中的bool查询，举一个简单的例子：

例如上面这个es中的bool查询，就是从这种sql翻译过来的：

对应到业务里，常用的查询其实大多数都是这些很简单的条件并列，A && B && C && D。所以翻译起来也比较简单。

单表的count放在ES里做也非常的快，为什么呢？因为ES本身会把单个字段的一种值当作一个term，然后会记录这个term出现的所有文档和出现次数。举个例子，我们公司的业务，可能会去查询某个业务线下的所有工单。那么查询条件就类似于where business_type is 6这样。可能只需要一毫秒就返回了结果。很费解是不是？其实ES也只是去读了一下这个business_type是6的term出现的文档数，逻辑上是很简单的。

这是不是说明ES就是万能的了？

并不是。

首先是翻页的问题，ES里有上亿数据，翻到最后一页的时候还是会比较慢，并且会影响到整个系统的load，然后系统响应变慢。因为其原理还是拿一堆数据来做merge。

从传统的sql思维翻译到es的dsl过程也稍微有点痛苦。因为ES毕竟是从搜索引擎的角度去做这些事情，所以如果当DB来用的话，其DSL设计就显得很别扭。虽然有了上面的转换规则，但实际上业务转换起来并没有这么方便，比如在通常的查询里还可能会有where a = 1 or b = 2。显然想转成DSL就没有这么方便了。

ES不是数据库，所以如果想要实现联表查询也会变得很麻烦。如果还想实现事务，那么还是放弃吧。

在企业里用ES提供查询服务的话，一般都会做一层查询封装。直接提供sql接口。

但插件支持的功能也是有限的，并不是所以的特性都能很好的支持，比如join。所以也有一些公司的人会用druid之类的东西做一个sql parser层，然后来支持这些需求。

不过即使是直接用这种插件，也不能认为它就能一劳永逸，还是需要对ES内部的机制(例如mapping)和通常的查询方式(term/query_string/wild_card等)很了解才行。

比如必须知道wildcard查询必须对字符串字段设置为not_analyzed。还得知道term什么时候代表的是分词后的词，什么时候代表的是整个字段的值。

在了解了这些之后才会了解到ES的高性能like，其实也还是有一些限制。例如输入的字符串会被分词，这也就是说，想要高性能的时候只能用ES默认提供的基于词的字符串like，而且一旦分词，就没办法实现类似sql里的 x= "Hello world"这种准确匹配的逻辑。也就是说，在ES里查询hello world，hello world fuck也会出现在结果当中。不过这个对于大多数的业务来说实际上是无所谓的。

检索服务方面

搜索是人类的自然需求。如果不是的话，那Google和百度就不会诞生了。

而检索/搜索的基本原理就是对语句进行分词，然后再形成倒排索引，再根据词项出现次数对文档进行打分，最终按分数倒序展示给用户。

对于海量数据的公司来说，一个单机的方案很快就会遇到瓶颈，而去寻求或自行开发更好的解决方案。在ES之前solr更流行一些吧，不过solr的配置还是稍微麻烦，而es的集群搭建只要改改yml就好了。

有了ES以后，集群便可以非常方便地进行动态扩展。只要加硬盘加机器改配置就好，因为本身的副本分布策略比较科学。所以只要别一半以上的节点都挂掉，数据就不会丢失。而且还会在某些结点挂掉的时候自动进行分片relocate。

由于ES本身带的分词不是很科学，这样的话对doc打分可能会有一些影响。比如中国人可能不正确地分成了中/国人之类的。现在很多人会选择以插件的形式把ik分词器之类的插件挂载到es上来改善分词效果。这些插件的本质其实还是一个非常庞大的中文词库。内部设计有链接可以直接查看语句的分词结果，可以方便地直接查看效果。

所以要是有几亿的文档需要做些检索，那五六台配置不错的ES机器就足够了，甚至都不用ssd。

日志方面

企业里的系统一般都是分布式系统，所以无论是接入，还是api，还是db，都不太可能在一台机器上完成需求。

对于某一个服务模块来说，多台机器最麻烦的就是去查问题。在没有日志系统的时代，程序员大概只能登陆到机器去一台一台寻找可能的错误日志，然而因为负载均衡算法(比如可能是一致性哈希望/随机/RR/WR)的问题，可能一个用户在一次访问会话(session)中的请求都不是一台而是多台机器完成的响应。

所以日志系统的工作就是把日志汇集到一起，并提供统一的查询入口。

要收集日志一般会自行搭建一个elk平台，elasticsearch/logstash/kibana必不可少。

不过拿来的东西总会有那么一些问题，比如kibana里的按地图出数据默认用的是googlemap，在墙内使会有些问题，这个问题github上也有人已经解决了。再比如logstash这个程序可能只考虑了简单的收集 ，如果是大公司的业务讲究一个严谨。例如想要对日志收集端的资源使用做一些限制，不能随便占用系统资源而影响到业务系统。再比如还希望日志不要因为网络闪断之类的问题导致日志丢失什么的，所以还可能会在logstash后面再加一个kafka/redis。不管怎么说，工作基础还是elk。

日志系统还存在一个问题，因为海量的数据和海量的访问，日志的数据量一般都非常地庞大。所以一般数据都会有一个过期时间，一般来说，日志数据其实一般也就一周或者一个月。毕竟即使是一个边缘部门，一周的日志也都已经几个亿(100+GB)了。

查询起来也不希望太慢，所以还是尽量把日志索引的大小控制在一个范围内。当然，也有按照日期来生成索引的。每一天在一个独立的索引下，这样查询性能也会好一些。

同时又是因为这海量的数据，在写入到ES的时候必须使用bulk端口，相信使用过ES的人都知道使用和不使用分别意味着什么。

四、es数据库是什么？

ElasticSearch （es）数据库是一个分布式、高扩展、高实时的搜索与数据分析引擎。

它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用ElasticSearch的水平伸缩性，能使数据在生产环境变得更有价值。ElasticSearch 的实现原理主要分为以下几个步骤，首先用户将数据提交到Elastic Search 数据库中，再通过分词控制器去将对应的语句分词，将其权重和分词结果一并存入数据，当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户。

Elasticsearch是与名为Logstash的数据收集和日志解析引擎以及名为Kibana的分析和可视化平台一起开发的。这三个产品被设计成一个集成解决方案，称为“Elastic Stack”（以前称为“ELK stack”）。

Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索，具有接近实时的搜索，并支持多租户。”Elasticsearch是分布式的，这意味着索引可以被分成分片，每个分片可以有0个或多个副本。每个节点托管一个或多个分片，并充当协调器将操作委托给正确的分片。再平衡和路由是自动完成的。“相关数据通常存储在同一个索引中，该索引由一个或多个主分片和零个或多个复制分片组成。一旦创建了索引，就不能更改主分片的数量。

Elasticsearch使用Lucene，并试图通过JSON和Java API提供其所有特性。它支持facetting和percolating，如果新文档与注册查询匹配，这对于通知非常有用。

另一个特性称为“网关”，处理索引的长期持久性；例如，在服务器崩溃的情况下，可以从网关恢复索引。Elasticsearch支持实时GET请求，适合作为NoSQL数据存储，但缺少分布式事务

五、十大舆情监测工具？

一、识微商情监测系统

以大数据思维监测和分析海量互联网公开数据，方便客户监测关注全网信息，支持全网舆情数据监测，覆盖新闻媒体、社交媒体、主流门户网站、论坛、博客、微信公众号等多个平台；支持7*24小时自动告警提醒，提前预知风险，快速处置突发舆情危机；支持海量数据语义分析，分析网民媒体正负面情绪，为企业处置舆情危机提供参考意见；支持统计图表分类整合，自动生成日报周报和竞品分析报。

二、鹰眼速读网系统

旨在解决各级政府客户的舆情监测、预警、分析、报告需求，在舆情分析上具体又包括舆情话题的分析、舆情热点的分析、重大事件的分析、民生热点的分析等等，可支持剪辑文章段落和图表，导出关键数据，自动生成舆情剪报，分析内容项有舆情的传播声量、传播来源、传播媒体类型、转载情况以及情感态度等。

三、慧科智能舆情洞察

实现舆情监测与洞察分析，配合公关经典职能，满足企业基础需求；挖掘数据背后深层次价值，提供媒体和营销洞察，辅助企业科学决策依据，全力为公关从业者赋能。

四、新浪舆情通

用户只需设置关键词，即可实现对全互联网的信息进行监测。提供邮件、短信、微信、APP、PC弹窗等5种舆情预警方式。包含全网事件、微博事件、微博传播效果、竞品、评论分析、热度指数等6种分析类型。既可自行快速生成简报，也可向舆情分析师提出需求，定制专业报告。可视化数据大屏，为舆情热点发现、应对提供便利化方案。

五、清博舆情

以大数据为核心技术支撑，可实时监测采集全网舆情信息，通过数据挖掘、可视化分析技术，提供舆情监测、分析报告、危机预警等一站式服务。

六、融文舆情

通过海量真实数据，实时对中国新闻及社交媒体进行全网舆情监测，满足品牌对全网舆情监测的需求，高效追踪品牌媒体曝光，提供一站式全网舆情监测与商情洞察服务。

七、人民网舆情数据中心

中国最早从事互联网舆情监测、研究的专业机构，与人民在线一体化运作，已经走过了十年历程。一直致力于以互联网为圆心，以先进的大数据技术为手段，系统分析，全面、立体，准确地反映舆论态势，在舆情研究、平台服务、智库咨询领域处于领先地位。

八、新华网舆情在线

国内最早从事网络舆情监测分析服务的机构之一，2003年以来一直在为中央有关部门专供舆情报告。包括全国乃至全球网络舆情、电视舆情监测研判服务，危机公关和舆论引导服务等等。旨在依托新华网权威媒体平台和先进技术手段和阵容庞大的专家队伍，以网络舆情研判为基础，提供智库类综合信息服务，帮助各级党政机关和企事业单位领导干部探索利用互联网倾听民意呼声，改进工作方式。

九、乐思舆情监测系统

针对向互联网这一新兴媒体，通过对海量网络舆论信息进行实时的自动采集，分析，汇总，监视，并识别其中的关键信息，及时通知到相关人员，从而第一时间应急响应，为正确舆论导向及收集群众意见提供帮助的一套信息化系统。

十、舆情秘书

面向政府和企业客户，提供互联网舆情监测及智能分析的大数据服务平台。平台提供监测、预警、分析、报告等全方位舆情服务，具有媒体覆盖最全、预警最快、分析最智能等特点，在小视频监测、电视监测、图片识别、溯源分析、智能报告等方面具有突出优势。

六、es和数据库的区别？

1.结构名称不同

一个ES集群可以包含多个索引（数据库），每个索引又包含了很多类型（表），类型中包含了很多文档（行），每个文档使用 JSON 格式存储数据，包含了很多字段（列）。

关系型数2.ES分布式搜索，传统数据库遍历式搜索

2.ES支持分片和复制，从而方便水平分割和扩展，复制保证了es的高可用与高吞吐。

在ES中，当你创建一个索引（数据库）的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的索引（数据库），索引可以被放置到集群中的任何节点上。

七、国内五大舆情监测公司？

1.湖南识微科技有限公司

简称识微科技，基于大数据服务云——蚁工厂（Antfact），专注于为企业提供互联网信息挖掘服务，旗下产品包括识微商情监测系统、识微商情报告，旨在为广大企业用户提供舆情监测、舆情分析、舆情预警、竞品监测、行业监测、营销监测、舆情分析报告服务。

2.湖南蚁坊软件股份有限公司

简称蚁坊软件，专业从事互联网大数据分析，专注于大数据信息的挖掘和价值传递，在舆情领域颇具影响力的数据分析产品有“鹰击早发现”、“鹰眼速读网”、“鹰领舆情态势系统”。

3.中国舆情网 PALAS

由复旦大学舆情研究实验室共同主办的国内最大的专业化舆情研究与舆情监测数据平台，涵盖日常舆情监测、舆情专题、地方舆情、舆情研究频道、舆情报告免费下载、舆情搜索等多个栏目。

4.北京清博大数据科技有限公司

主要产品和服务有清博指数(前称新媒体指数)、清博舆情、清博助手、清博广告、清博学院，提供各类数据、榜单、分析报告、舆情监测、品牌推广、精准营销和论坛、培训、新媒体运营、APP建设，媒体融合、大数据建设等。

5.上海蜜度信息技术有限公司

旗下的代表产品主要指的是新浪舆情通，是一个专业的政企舆情大数据服务网站，从舆情信息发现、热度监测、预警到详细分析，全程监控舆情信息路径，提高舆情管理工作效率。

6.中科点击(北京)科技有限公司

面向政府、企业提供网络舆情监测和决策参考服务，其产品军犬舆情被广泛地用于舆情监控监测、竞争情报以及风险预警等领域。

八、国内十大舆情监测系统？

十大舆情监测系统：

1：人民网舆情监测室

2：中新社新媒体中心

3：腾讯新闻

4：新华网

5：新浪

6：网易

7：搜狐

8：凤凰网

9：百度

10：今日头条

九、es可以替代数据库吗？

es更侧重近实时搜索。数据库更关注的是数据的存储查询。二者使用场景不一祥，不能说谁替代谁。

十、媒体舆情三大效应是什么？

1、晕轮效应

晕轮效应又称“光环效应”、“成见效应”，是指在人际互动中形成的一种夸大的社会印象，正如日、月的光辉，在云雾的作用下扩大到四周，形成一种光环作用。简言之，晕轮效应是指以对象的某种特征推及对象的总体特征，从而产生美化或丑化对象的心理定式。比如，在舆情传播中，某些媒体常常以偏概全，过度地对事件或当事人进行“标签化”，以至于模糊了事件的本质。舆情管理工作应该谨防由于晕轮效应而导致的舆情偏差。

2、破窗效应

破窗效应是指环境中的不良现象被放任存在，会诱使人们效仿甚至变本加厉。比如一幢有少许破窗的建筑，如果那些窗不被修理好，可能会有人破坏更多的窗户，甚至闯入建筑内定居、纵火。

从发展的观点看，“破窗效应”对网络舆情管理存在如下借鉴意义：一是要有风险意识，重视舆情苗头和风险隐患；二是要防微杜渐，及时将问题消灭在萌芽状态；三是要加强道德建设，净化滋生不良现象的环境，降低问题发生的几率。

3、长尾效应

长尾效应最初被《连线》的总编辑克里斯·安德森用来描述亚马逊、Netflix等网站的商业和经济模式。是指那些原来不受到重视的销量小但种类多的产品或服务，由于总量巨大，累积起来的总收益超过主流产品的现象。“涓涓细流，汇聚成河”，长尾效应体现了事物的发展从量变到质变的过程。