首页 文章 精选 留言 我的

精选列表

搜索[全基因组选择]，共10000篇文章
优秀的个人博客,低调大师

搜索引擎选择：Elasticsearch与Solr

Elasticsearch简介 Elasticsearch是一个实时的分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。 它可以用于全文搜索，结构化搜索以及分析，当然你也可以将这三者进行组合。 Elasticsearch是一个建立在全文搜索引擎 Apache Lucene? 基础上的搜索引擎，可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。 但是Lucene只是一个框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的学习了解，才能明白它是如何运行的，Lucene确实非常复杂。 Elasticsearch使用Lucene作为内部引擎，但是在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。 当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作： 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 这么多的功能被集成到一台服务器上，你可以轻松地通过客户端或者任何你喜欢的程序语言与ES的RESTful API进行交流。 Elasticsearch的上手是非常简单的。它附带了很多非常合理的默认值，这让初学者很好地避免一上手就要面对复杂的理论，它安装好了就可以使用了，用很小的学习成本就可以变得很有生产力。 随着越学越深入，还可以利用Elasticsearch更多高级的功能，整个引擎可以很灵活地进行配置。可以根据自身需求来定制属于自己的Elasticsearch。 使用案例： 维基百科使用Elasticsearch来进行全文搜做并高亮显示关键词，以及提供search-as-you-type、did-you-mean等搜索建议功能。 英国卫报使用Elasticsearch来处理访客日志，以便能将公众对不同文章的反应实时地反馈给各位编辑。 StackOverflow将全文搜索与地理位置和相关信息进行结合，以提供more-like-this相关问题的展现。 GitHub使用Elasticsearch来检索超过1300亿行代码。 每天，Goldman Sachs使用它来处理5TB数据的索引，还有很多投行使用它来分析股票市场的变动。 但是Elasticsearch并不只是面向大型企业的，它还帮助了很多类似DataDog以及Klout的创业公司进行了功能的扩展。 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有一个插件架构，以支持更多的高级定制。 因为2010年 Apache Lucene 和 Apache Solr 项目合并，两个项目是由同一个Apache软件基金会开发团队制作实现的。提到技术或产品时，Lucene/Solr或Solr/Lucene是一样的。 Solr的优缺点 优点 Solr有一个更大、更成熟的用户、开发和贡献者社区。 支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。 Solr比较成熟、稳定。 不考虑建索引的同时进行搜索，速度更快。 缺点 建立索引时，搜索效率下降，实时索引搜索效率不高。 Elasticsearch与Solr的比较 当单纯的对已有数据进行搜索时，Solr更快。 当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。 随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。 综上所述，Solr的架构不适合实时搜索的应用。 实际生产环境测试 下图为将搜索引擎从Solr转到Elasticsearch以后的平均查询速度有了50倍的提升。 Elasticsearch 与 Solr 的比较总结 二者安装都很简单； Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能； Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式； Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供； Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。 Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。 其他基于Lucene的开源搜索引擎解决方案 直接使用Lucene 说明：Lucene 是一个 JAVA 搜索类库，它本身并不是一个完整的解决方案，需要额外的开发工作。 优点：成熟的解决方案，有很多的成功案例。apache 顶级项目，正在持续快速的进步。庞大而活跃的开发社区，大量的开发人员。它只是一个类库，有足够的定制和优化空间：经过简单定制，就可以满足绝大部分常见的需求；经过优化，可以支持 10亿+ 量级的搜索。 缺点：需要额外的开发工作。所有的扩展，分布式，可靠性等都需要自己实现；非实时，从建索引到可以搜索中间有一个时间延迟，而当前的“近实时”(Lucene Near Real Time search)搜索方案的可扩展性有待进一步完善 Katta 说明：基于 Lucene 的，支持分布式，可扩展，具有容错功能，准实时的搜索方案。 优点：开箱即用，可以与 Hadoop 配合实现分布式。具备扩展和容错机制。 缺点：只是搜索方案，建索引部分还是需要自己实现。在搜索功能上，只实现了最基本的需求。成功案例较少，项目的成熟度稍微差一些。因为需要支持分布式，对于一些复杂的查询需求，定制的难度会比较大。 Hadoop contrib/index 说明：Map/Reduce 模式的，分布式建索引方案，可以跟 Katta 配合使用。 优点：分布式建索引，具备可扩展性。 缺点：只是建索引方案，不包括搜索实现。工作在批处理模式，对实时搜索的支持不佳。 LinkedIn 的开源方案 说明：基于 Lucene 的一系列解决方案，包括 准实时搜索 zoie ，facet 搜索实现 bobo ，机器学习算法 decomposer ，摘要存储库 krati ，数据库模式包装 sensei 等等。 优点：经过验证的解决方案，支持分布式，可扩展，丰富的功能实现。 缺点：与 linkedin 公司的联系太紧密，可定制性比较差。 Lucandra 说明：基于 Lucene，索引存在 cassandra 数据库中。 优点：参考 cassandra 的优点。 缺点：参考 cassandra 的缺点。另外，这只是一个 demo，没有经过大量验证。 HBasene 说明：基于 Lucene，索引存在 HBase 数据库中。 优点：参考 HBase 的优点。 缺点：参考 HBase 的缺点。另外，在实现中，lucene terms 是存成行，但每个 term 对应的 posting lists 是以列的方式存储的。随着单个 term 的 posting lists 的增大，查询时的速度受到的影响会非常大。 本文转自UltraSQL51CTO博客，原文链接：http://blog.51cto.com/ultrasql/1695743，如需转载请自行联系原作者
2017-11-08
优秀的个人博客,低调大师

【IaaS&PaaS】为什么选择PaaS？

何为PaaS 地球人都知道PaaS就是Platform as a Service的缩写，但到底什么是PaaS呢? 假如我们现在需要一个业务，提供一个很简单的"hello world"服务，那么需要的资源有哪些呢，看下图： IaaS&PaaS覆盖图 从最底层的IDC、机房、网络、服务器，到服务器上的操作系统，操作系统上的服务软件(主要包括WebServices、数据库、缓存等)，当然最终在WebServices里运行的是我们的业务代码。如果我们生活在互联网的初始阶段，那么这些元素都是需要我们关心的，我们不得不为带宽机架跟运营商打交道，为域名备案跟通管局打交道，为服务器跟服务器供应商打交道，最后还得雇佣管理一个运维团队，帮助维护自己的IT资源。这会使人疯掉! 现在幸福的事情，IaaS(Infrastructure as a Service)，来了，IaaS帮我们节省了红线所涉及的部分，包括IDC、网络、服务器、甚至包括部分操作系统，为什么说部分操作系统呢?因为我们还是要关心操作系统挂掉、机器宕机等因素，如果我们不关心，或者说我们从业务的架构上不考虑这些因素，是很难保证业务稳定的。 而PaaS呢?PaaS帮我们节省了蓝色涉及的部分，也就是说除了IaaS节省的部分外，还节省了服务软件和代码的部分，换句话说，PaaS提供了一个完整的业务开发、运行环境，我们无需关心怎么安装Apache、怎么配置缓存、怎么配置数据库读写分离，所有这些已经以服务的方式(注意：不是以机器的方式)提供好了，我们需要做的，只是把业务代码放上来就好了。 总之，IaaS提供的还是虚拟机资源，而PaaS提供的是实际业务的开发、运行环境，正如SAE对自己的定位：“Web应用/业务的分布式开发、运行平台”。 PaaS和IaaS的区别 刚才说了IaaS主要是虚拟机资源，而PaaS提供的是业务的开发、运行环境，那么PaaS和IaaS的区别就是这些吗? 云计算追求的就是通过共享从而降低成本，并且利用技术提供更好的服务。我们来看一个生活中的例子： 我们去饭店吃饭，菜很好吃，但有一个事比较烦心：“到底点多少菜”，点的多了怕浪费，点的少了怕不够吃，快吃完了再点又怕上菜慢，现在我们利用云计算的思路解决这个问题=》 IaaS的办法：将菜“虚拟化”，将一份菜切分为半份菜、1/3份菜，甚至1/4菜，用户可以点小份。 这种办法很有效，可以有效降低我们吃饭的成本，但仍不是特别方便，A，我们无法准确预估需要点多少份;B，吃着吃着饭，突然来了一个朋友，又要现点份菜，这需要上菜时间，耽误工夫。 那么怎么才能做的更好呢?人类吃饭的单位都是一口，没有人能吃“半口饭”，能不能按照口供应呢?我们来看： PaaS的办法：通过一种技术，将菜按口供应，每个顾客只要张嘴就可以吃菜，不张嘴就不吃了，停止计费，来了一个新朋友，也是通过同样的方式，只要张嘴就有菜吃。 IaaS&PaaS解决问题对比 从这张图可以看出，PaaS对比IaaS虚拟化的粒度更细，更贴近用户的实际需要，因为用户真正需要的并不是虚拟机，而是满足业务运行需求。下面我们来仔细讨论一下PaaS和IaaS的区别吧： PaaS的计费粒度更细 从计费粒度上，PaaS比IaaS更细，IaaS普遍以 虚拟机的实例数*运行时间 计费，即使IaaS标榜他们的计费单元可以精确到秒级，但如果用户业务某个时间段没有任何请求，用户仍然需要为这部分虚拟机使用时间付费，因为用户无法预知下一次请求什么时候到来，所以用户无法关闭所有虚拟机。 而PaaS是以请求消耗的资源为单元计费的。 这样，如果用户的业务暂时没有任何请求，则用户无需支付任何费用，做到了真正的“所付即所用”。 从SAE上用户的实际使用情况来看，几乎所有用户对比之前的使用IaaS时都会有不同程度的成本节约，以某创业为例，日均15万PV， PaaS比IaaS更可靠 IaaS用户容易高估自己的服务可靠性，这里面有两个原因： - IaaS服务厂商往往夸大自己的服务可靠性，实际从目前看任何一个IaaS厂商都时不时有重大故障报出来 - IaaS用户迷信厂商提供的SLA，自己不进行高可靠架构部署 我见过在IaaS只用2台虚拟机，然后标榜自己的服务可靠性有多高的用户，殊不知当物理机宕机时，虚拟机一定会收到影响，目前IaaS服务商能提供热迁移的只是少数，即使能提供也是需要提前准备的，无法做到故障时实时切换 PaaS隐藏了服务器、虚拟机的概念，把一切功能服务化，而这些服务都是基于高可靠架构的，以SAE提供的Cron定时服务为例，这套Cron服务是基于分布式环境，任何一台机器宕机都不会影响定时任务的准确触发。 PaaS是真正的“高可扩展” 要明白这个问题，我们先来看什么叫“可扩展”，可扩展有两个层面： 1，用户可以自行扩展资源，通过手工的方式(包括页面点击、API调用等) 2，随着用户的业务扩张，自动扩展 几乎所有的IaaS厂商都可以实现层面1，但层面1的问题是，用户不知道什么时候扩展。用户真正需要的是层面2的扩展，即随着业务增长，资源自动扩展，整个过程用户可以完全不感知，目前这种层面的“高可扩展”没有任何一家IaaS厂商提供。 而SAE恰恰提供这种层面2的高可扩展，SAE会自动判断用户的业务是否存在等待队列，一旦请求出现等待，将自动将请求分配新的计算节点，通过这种机制，用户从PV 100/天涨到PV 1亿/天，可以做到瞬间实现而无需用户做任何操作。 PaaS是免运维的云计算 “免运维”是PaaS的最大魅力，因为用户把代码放上来，就可以完全不管了，无论业务凋零还是业务暴涨，都无需人工干预，当然SAE提供完整的图表展现用户的各种请求曲线，了解业务情况还是必须的。在SAE上的很多用户团队里都是0运维，也就是一个运维人员都没有，这在传统业务团队中是不可想象的。 PaaS的缺点 虽然PaaS有免运维、高可靠、自动扩展、更加节约成本等优点，但是PaaS也有缺点，PaaS的最大缺点就是因为用户无法看见服务器，感受不到虚拟机，这样限制了用户的自主性和灵活性，比如用户想部署一个自己的C程序，或者用户想直接开一个FTP管理文件，这些需求都无法在PaaS中满足，因为PaaS 提供的是一个业务的开发、运行环境，而不是用户能够登陆的云主机。 那么既然PaaS有优点也有缺点，那么什么情况适合使用PaaS呢? PaaS的适用场景 其实，PaaS和IaaS各有各的适用场景，主要由以下一些规律： 非HTTP业务(如游戏服务端、数据分析服务)适合用IaaS，HTTP业务(网站、RESTfulAPI服务端)适合用PaaS; 大型团队(拥有丰富的系统、网络、运维能力和经验)适合用IaaS，创业团队/小型团队(团队规模小，全部聚焦在业务)适合用PaaS; 技术团队(喜欢定制化、喜欢掌控一切)适合用IaaS，产品团队(聚焦在产品开发)适合用PaaS; 资金充裕(能够雇佣昂贵的系统工程师、能够支付没有流量的虚机费用)的团队适合用IaaS，资金紧张(对成本比较care的用户)的适合用PaaS; PaaS是真正的云计算平台 总之，在桌面时代，我们需要的不是IBM ThinkPad、甚至不是Windows，而是上面成千上万的应用、游戏;到了云时代，我们需要的既不是几core的虚拟机、也不是什么EBS存储，而是一个能让我们的业务稳定可靠省心运行的环境，如果有这样的环境，除了技术Geek，我想没有人想管服务器。。。 PaaS尽管有种种问题，但它确实是从诞生就想提供给用户一个省心、稳定的业务运行环境，用户一旦部署，不需要关心扩容，不需要关心架构，不需要关心宕机，不需要关心配置，不需要关心优化，就可以随着业务的发展时时满足各种需要，所以PaaS是真正的云计算平台。 本文作者：sae_kobe 来源：51CTO
2017-08-01

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册