4 倍的性能提升
大幅降低 IT 支出
减少维护时间
从 FAST ESP 切换到 Elastic Cloud 后,Candid 的 Guidestar 从每天管理集群转变为每月检查一次集群运行状况。
通过 Elastic 支持满足客户 SLA
无论是架构指导还是验证想法,Elastic 支持都可以帮助 Candid 的 Guidestar 的 Elastic Cloud 部署保持同步。
公司概述:更好的数据。更好的决策。更美好的世界。
非营利组织员工构成了美国第三大劳动力。他们每天都在影响数百万人的生活,他们正在努力使世界变得更美好。
Candid 的 Guidestar 是一个 501(c)(3) 公共慈善机构,其使命是提供更好的数据,以帮助人们做出更好的决策,从而创建一个更美好的世界。他们汇总了 200 多万个非营利组织的信息,例如他们的使命、合法性、影响、声誉、财务、项目、透明度和治理,并将其免费提供,作为他们对公共服务承诺的一部分。他们还为希望进一步利用其丰富的非营利组织数据集的用户和组织提供各种付费产品和服务。
为更具慈善精神的世界提供搜索支持
Candid 的 Guidestar 的目标是使世界变得更美好。他们是世界上最大的非营利组织信息来源,汇总了来自 200 多万个非营利组织的数据,以帮助 700 多万捐助者和资助者就他们支持的非营利组织做出明智的决定。
Candid 旗下的 Guidestar 最初依赖 FAST ESP 作为其搜索引擎,但当 FAST 于 2014 年成为 SharePoint 的一部分后,他们意识到需要做出改变。他们首先将其 API 切换到 Elasticsearch,并看到了积极的结果。因此,当他们决定开始将其基础设施迁移到云端时,他们选择了 AWS 上的 Elastic Cloud,以继续将其其他搜索服务从 FAST 迁移出来。
一旦他们切换到 Elastic Cloud,他们不仅看到了更快的加载时间、用户参与度的提高和巨大的成本节省,他们的工程师也更快乐、更高效。
2008 年:实施 FAST ESP
数据是 Candid 旗下 Guidestar 业务的核心,他们需要让用户可以随时随地轻松访问这些数据。早期,Candid 旗下的 Guidestar 得出结论,快速且相关的搜索结果是连接用户、捐助者、资助者和非营利组织管理者与他们做出明智决策所需信息的桥梁。因此,它成为他们最重要的组织优先事项之一。
数据是我们业务的核心,让用户更容易获得数据是我们的全部目标。
2008 年,他们实施了 FAST ESP 作为其企业搜索解决方案,该解决方案运行良好,直到……
2014 年 5 月:SharePoint 还是其他?
收购了 FAST ESP 的微软宣布他们将停止支持 FAST 作为独立产品,并且只通过 SharePoint 提供它。FAST ESP 还只支持 XML,Candid 旗下的 Guidestar 发现 XML 的计算量过大,无法实现他们所期望的性能基准。最终,经过六年,Candid 旗下的 Guidestar 需要刷新其软件和数据架构。
软件和数据架构不是您购买然后随着时间推移贬值的固定资产。您需要不断地再投资。现在是时候再投资我们的架构了,无论 FAST 是否会消失。
Candid 旗下的 Guidestar 开始研究替代方案,这些替代方案是开源的,具有原生 JSON 支持,可水平扩展,具有用户社区参与,以及用于管理任务的 RESTful API 端点。
他们开始研究 Lucene。在尝试使用它之后,他们意识到他们需要更多功能以及支持,以确保他们能够满足客户 SLA。接下来,他们研究了基于 Lucene 构建的技术,并发现了 Elasticsearch。
2014 年 9 月:Elasticsearch 的首次测试
大约在 Candid 旗下的 Guidestar 发现 Lucene 和 Elasticsearch 的时候,他们即将发布下一代 API,这些 API 被 200 多个慈善网站和应用程序使用,包括美国运通、BlackBaud、CrowdRise、JustGive 和 NetworkForGood。他们没有立即删除 FAST,而是认为这将是一个尝试新的搜索解决方案并观察情况的好测试平台。
使用 Lucene 需要 GuideStar 的 API 用户构建复杂的搜索查询才能产生相关的结果。Candid 旗下的 Guidestar 认为 Elasticsearch 可以做得更好,而无需花费太多时间构建搜索查询。为了正确测试此假设,Candid 旗下的 Guidestar 决定推出其 Search API 的测试版本,并测试“单框”搜索功能。
此时,他们还决定购买 Elastic 订阅,以帮助他们从一开始就正确地构建软件,并确保他们能够在出现任何问题时遵守客户 SLA。
当您投入生产并需要满足 SLA 时,您不能孤身一人。此外,当您拥有一个不受支持的平台并且无人可问时,这会感到孤独。如果您是最了解它的人,而您不知道答案,并且无人可谈——那就像身处孤岛,没有人喜欢那样。
2015 年 1 月,Candid 旗下的 Guidestar 发布了由 Elasticsearch 提供支持的 Search API 的测试版。结果非常积极,以至于 GuideStar 决定从其 API 转向并专注于 Guidestar.org 的搜索功能。
2015 年中期:Candid 旗下 Guidestar 的硬件租赁和托管服务即将到期
到 2015 年中期,Candid 旗下的 Guidestar 正在考虑是否续签其硬件租赁合同并与托管设施签订另一份合同。当时,他们做出了战略决策,将两份合同都续签两年,并开始将工作负载转移到公共云产品,特别是 AWS。
Candid 旗下 Guidestar 的技术高级总监 Shane Ward 参加了 Elastic 的首届用户大会 Elastic{ON} 2015,并记得听说了 Elastic Cloud,这是 Elasticsearch 的托管版本,可以自动执行安装、配置、维护、备份以及 Elasticsearch 集群的高可用性等关键流程。他联系了他的 Elastic 客户经理,看看他们是否可以试用 AWS 上的 Elastic Cloud。Elastic 很高兴为 Shane 和他的团队提供了一个免费的完整生产实例进行测试,在一周内,他们看到了惊人的结果。
我们在 Elastic Cloud 上测试的查询速度和索引速度比我们在自己的硬件上运行 FAST 时快了三倍。
这些结果让 Shane 和他的团队有信心完全从 FAST 迁移到 Elastic Cloud。此外,保持他们的应用程序托管与他们的数据源和云平台一致,意味着 AWS 上的 Elastic Cloud 非常适合。
2015 年 10 月:迁移到 Elastic Cloud
Shane 和他的团队决定从他们最受欢迎的两个搜索产品开始迁移到 Elastic Cloud:组织搜索(让人们可以按原因查找非营利组织)和人员搜索(允许用户获取有关非营利组织领导者和董事会成员的信息)。
由于他们使用 FAST 建立的搜索抽象层,过渡本身相对容易。他们首先需要弄清楚的事情之一是他们的集群大小——他们与 Elastic 支持工程师合作解决了这个问题:一个主节点,两个数据节点,每个索引有两个副本。
Elastic 支持查看了我们的文档大小,并对要使用的主节点和数据节点的数量给出了很好的估计。从第一天起,这个数字就完全正确,并且一直为我们完美工作。
他们还实施了 X-Pack,这是他们 Elastic 订阅的一部分,以使用 SSL 加密保护他们的集群。这使他们可以防止在与云中的集群通信时拦截他们的数据。
他们的数据库管理员 Rich(Candid 旗下的 Guidestar 将其称为 Elasticsearch 的“大人物”)利用 Elasticsearch 的 搜索模板来隔离地工作,而不会影响实时搜索应用程序。
Candid 旗下 Guidestar 的产品团队利用这个机会来增强搜索 UI。他们做出的重大改进之一是通过利用 Elasticsearch 的 聚合来预览有多少结果符合某些过滤器(例如原因领域、位置和财务信息),这些聚合会实时更新。他们使用 FAST 时没有此功能,用户的搜索通常会导致没有匹配项,因为他们无法在完全执行搜索的情况下了解预期结果。
在他们投入生产之前,对新搜索体验的用户测试表明,搜索结果更加相关——而且速度更快。Candid 旗下的 Guidestar 还进行了一些自动化负载测试,发现他们的 Elastic Cloud 集群可以处理的负载是他们在本地运行 FAST 时的 4 倍。
2016 年 8 月,Candid 旗下的 Guidestar 使用 AWS 上的 Elastic Cloud 投入生产,并向世界推出了他们的新搜索产品。
结果:更低的成本,更高的参与度
以下是 Candid 旗下的 Guidestar 迁移到 Elastic Cloud 后迄今为止的体验
加载时间快 4 倍
与 FAST ESP 相比,Candid 旗下的 Guidestar 使用 Elastic Cloud 的加载时间快了 2.5-4 倍。
大幅降低 IT 支出
当 Candid 旗下的 Guidestar 使用 FAST ESP 时,他们有 19 个虚拟机专门用于搜索,这占他们整个托管基础设施的 18%。使用 Elastic Cloud,他们能够通过一个双节点集群满足相同的需求,这最终为他们在基础设施、许可、支持和人工成本方面节省了数十万美元。他们也不再像他们的内部 CRM 或 Exchange 电子邮件服务器那样与组织中的其他系统争夺资源。
用户参与度提高 34%
由于 Elasticsearch 聚合的实时性,Candid 旗下的 Guidestar 增强了其搜索过滤器的交互性,并看到用户参与度提高了 34%。用户参与度是流失的主要指标。如果您的客户不使用您的产品,他们将不会续订订阅。
利用 Elastic 支持的协助
每当他们有问题时,Candid 旗下的 Guidestar 都会毫不犹豫地与 Elastic 支持部门联系——在架构指导、验证想法以及就他们做出的各种其他决策进行咨询——所有这些都归功于 Elastic 的专用支持模式。专用支持意味着 Candid 旗下 Guidestar 的每个人每次有问题或需要帮助时都与同一位 Elastic 支持工程师互动。在合作一段时间后,这位工程师基本上成为客户团队的延伸部分。
我们非常感谢分配给我们的专用支持工程师——这节省了很多浪费的时间。甚至只是知道另一端帮助您的人的名字也是非常棒的。与不同的支持合同相比,这是一个重大改进,在不同的支持合同中,您每次打开工单都必须让另一端的人了解最新情况。
升级轻而易举
Elastic 会相当频繁地发布产品,以便尽快将最新功能提供给用户。为了升级到最新版本的 FAST,Candid 旗下的 Guidestar 必须建立另一个集群、测试所有内容,然后安排一个晚上或周末来切换所有内容。使用 Elastic Cloud,只需单击 Cloud 用户控制台上的一个按钮即可完成升级。这将自动使用最新版本的 Elasticsearch 启动新集群,根据其填充和配置所有内容,复制数据并切换流量。没有晚上,没有周末。就这么简单。
更少的维护,更多的时间用于核心业务(和睡眠!)
在使用 FAST 时,Candid 旗下的 Guidestar 必须每天与他们的集群进行交互,以进行管理和性能监控。使用 Elastic Cloud,他们每月只需检查一次,以确保集群运行良好——他们不再需要花费时间进行硬件维护,或者在半夜处理警报以修复生产环境中的中断。
我们不是搜索引擎公司。我们是致力于非营利软件的机构。现在,我们可以更专注于核心业务和为我们的应用程序添加功能,而不是担心我们的搜索引擎在半夜出现故障。
更高的敏捷性
Candid 的 Guidestar 不再害怕尝试,因为 Elastic Cloud 比 FAST 更灵活,而且他们知道不会出现任何故障。当产品团队想要测试一组新功能时,Candid 的 Guidestar 可以建立一个全新的集群,并在 60-90 分钟内将其完全填充他们拥有的 1600 万份文档。而使用 FAST 则需要一天半的时间。
最终,Candid 的 Guidestar 希望与 Elastic 合作,是因为我们有共同的价值观:我们也希望使数据更具洞察力。我们也希望以最佳方式支持我们的客户。我们也都对我们所做的事情充满热情,日复一日。现在,我们可以共同努力实现共同的目标,这感觉非常棒。
了解更多关于 Elastic 可观测性 和 我们与 AWS 的合作。立即开始并免费试用 AWS 上的 Elastic 可观测性。
Candid 的 Guidestar 集群
- 集群1
- 索引2
- 节点3
- 查询速率每秒 8 次
- 托管环境AWS 上的 Elastic Cloud
- 副本1
- 文档1600 万
- 基于时间的索引实时索引
- 总数据大小35 GB
- 节点规格64GB RAM,2 个数据中心,1.5TB SSD 存储
- 每日摄取率250,000