首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

搜索引擎选择 Elasticsearch与Solr

一、Elasticsearch简介 Elasticsearch是一个实时的分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。它可以用于全文搜索,结构化搜索以及分析,当然你也可以将这三者进行组合。Elasticsearch是一个建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎,可以说Lucene是当今最先进,最高效的全功能开源搜索引擎框架。但是Lucene只是一个框架,要充分利用它的功能,需要使用JAVA,并且在程序中集成Lucene。需要很多的学习了解,才能明白它是如何运行的,Lucene确实非常复杂。Elasticsearch使用Lucene作为内部引擎,但是在使用它做全文搜索时,只需要使用统一开发好的API即可,而不需要了解其背后复杂的Lucene的运行原理。 当然Elasticsearch并不仅仅是Lucene这么简单,它不但包括了全文搜索功能,还可以进行以下工作: (1)分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索。 (2)实时分析的分布式搜索引擎。 (3)可以扩展到上百台服务器,处理PB级别的结构化或非结构化数据。Elasticsearch的优缺点: 优点 Elasticsearch是分布式的。不需要其他组件,分发是实时的,被叫做”Push replication”。 Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。 处理多租户(multitenancy)不需要特殊配置,而Solr则需要更多的高级设置。 Elasticsearch 采用 Gateway 的概念,使得完备份更加简单。 各节点组成对等的网络结构,某些节点出现故障时会自动分配其他节点代替其进行工作。 缺点 只有一名开发者(当前Elasticsearch GitHub组织已经不只如此,已经有了相当活跃的维护者) 还不够自动(不适合当前新的Index Warmup API) 二、Solr简介 Solr(读作“solar”)是Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成,以及富文本(如Word、PDF)的处理。Solr是高度可扩展的,并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎,Solr4 还增加了NoSQL支持。 Solr是用Java编写、运行在Servlet容器(如 Apache Tomcat 或Jetty)的一个独立的全文搜索服务器。Solr采用了 Lucene Java 搜索库为核心的全文索引和搜索,并具有类似REST的HTTP/XML和JSON的API。Solr强大的外部配置功能使得无需进行Java编码,便可对其进行调整以适应多种类型的应用程序。Solr有一个插件架构,以支持更多的高级定制。 Solr的优缺点 优点 Solr有一个更大、更成熟的用户、开发和贡献者社区。 支持添加多种格式的索引,如:HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。 Solr比较成熟、稳定。 不考虑建索引的同时进行搜索,速度更快。 缺点 建立索引时,搜索效率下降,实时索引搜索效率不高。 三、Elasticsearch与Solr的比较 当单纯的对已有数据进行搜索时,Solr更快。

01

storm安装教程

Storm是Twitter开源的分布式实时大数据处理框架,被业界称为实时版Hadoop。按照storm作者的说法,Storm对于实时计算的意义类似于Hadoop对于批处理的意义。 应用场景包括推荐系统(实时推荐,根据下单或加入购物车推荐相关商品)、金融系统、预警系统、网站统计(实时销量、流量统计,如淘宝双11效果图)、交通路况实时系统等等。 storm一般从日志系统通过kafka收集数据,然后对数据进行处理运算(运算可以结合数据库以及hdfs的存量数据),不断将运算结果写入redis,然后需要展示这个运算结果的系统从redis读取数据。运算结果写入redis和读取展示运算结果是不断重复的(例如1秒一次),这样能实时观察数据的变化。例如双十一的销售额会不断增长,那么storm就要不断解析日志累加销售额,展示页面也要不断读取redis最新的销售额。 twitter和微博实时统计热搜也是一样,实时分析日志才能发现今天的高频词是哪个。 也可以用于埋点收集日志,用户做某个动作,会触发在日志里打印出某个关键字,通过对关键字的统计,可以实时分析用户行为特征。 本文演示安装单机storm系统,并运行内置的示例程序。分为四个步骤:

01

SQL(及存储过程)跑得太慢怎么办?

但遗憾的是,仍然有相当多情况无论怎样优化都不可能跑得更快。这里做 SQL 性能优化真是让人干瞪眼 介绍了一些,并做了相应的技术分析。由于其理论基础关系代数的局限,SQL缺乏离散性和有序集合等特性的支持使得SQL在表达某些高性能算法时异常困难,甚至完全写不出来,只能采用比较笨的低性能算法,眼睁睁地看着硬件资源被白白浪费。在 写着简单跑得又快的数据库语言 SPL 中有对SQL理论基础缺陷的通俗解释。也就是说,SQL的慢是理论性的,这种问题仅仅由数据库在工程层面优化只能局部改善(确实有不少商业数据库能够自动识别某些SQL并转换成高性能算法),而不能根本地解决问题(情况复杂时数据库优化引擎都会“晕”掉,只能按SQL的书写逻辑执行成低性能算法)。理论性的缺陷当然也不能寄希望于更换数据库而得到解决,只要还是用SQL,即使采用分布式数据库、内存数据库也还是这种情况,在消耗更大成本的资源后当然也能有一定的性能提升,但和硬件本应能够达到的性能仍然有巨大的差距。

02
领券