使用 AWS 基础设施为静态网站实施数据搜索系统的建议
Advice for implementation of a data search system for a static website with AWS infrastructure
我有一个静态网站，我需要实现对单独数据集的搜索；我目前在 AWS 上使用无服务器技术托管网站，包括 S3、Cloudfront、Lambda 和 API 网关用于某些服务器端逻辑。
我有几个 csv 文件，其中包含大约 120,000 条记录，其结构如下：
ID search_name name source quantity
10002 Lorem Ipsum Dolor sit amet primary_name 10
10002 Lorem Ipsum Consectetur amet other_name 10
10002 Lorem Ipsum Donec a erat other_name 10
10003 Ultricies pretium Inceptos primary_name 100
10003 Ultricies pretium Himenaeos other_name 100
所以最终结果将是我前端的一个搜索表单，该表单将对后端系统进行 API 调用，查询数据库或能够与 [= 字符串匹配的独立软件服务33=]字段；然后 return 所有比赛。我的前端会将带有 'source' 和 'other_name' 的记录显示为结果中的元数据，而不是单独的结果。
每 3 个月将提供一组新的 CSV 文件，其中包含相同的和额外的记录，但 'quantity' 字段可能具有新值。
由于我一直在使用无服务器技术，所以我最初的想法是尝试将文件存储在
一个 s3 桶，使用 AWS glue 处理它们并使它们可供 AWS Athena 进行查询。我很喜欢这个设置，因为没有太多的组件需要维护，而且托管成本会很低 我对这个设置的两个担忧是我会花时间尝试设计一个很好的搜索算法，该算法可以根据如何对结果进行排序他们结束了一场比赛。例如。如果搜索名称是 ABC，它应该是第一个结果，而不是其他仅包含 ABC 作为其名称一部分的项目。
其次执行速度；我有 运行 一些像这样的简单查询：
SELECT id, search_name, source
FROM data
WHERE search_name like '%lorem%';
只需使用 Athena GUI 中的查询编辑器，执行时间可以 运行从 0.5 秒增加到 3 秒。我关心的是那些 3 秒处决。我想知道这可以优化到什么程度。我也读过 "Users can only submit one query at a time and can only run up to five simultaneous queries for each account."，除非对我的理解有一些警告，否则听起来对我来说有点杀了它。
作为第二个选择，我正在考虑使用 AWS ElasticSearch。我不太了解它，但我认为使用专为执行搜索而设计的系统可能会使我的最终产品更好。我对实现它不太了解，但我担心的是，我对某些搜索结果进行优先排序的能力，以及执行该数据注入过程的难易程度，例如当一组新数据到达时，它需要更新记录，而不是仅仅堆叠在它们之上。我写了一个初始脚本来加载那里的 csv 记录来测试查询。
我现在刚刚开始研究 AWS CloudSearch，它实际上看起来比 ElasticSearch 简单一些，所以开始倾向于这种方式。
所以我正在寻找的建议是关于我应该使用哪些产品或服务的建议，无论是 Athena、ElasticSearch 还是其他东西，以及关于我应该如何实施这些服务的任何顶级建议。
谢谢。
Just using the Query editor in the Athena GUI, and the execution time can range from 0.5 to 3 seconds. It's those 3 second executions that concern me. I'm wondering how well this can be optimized. I've also read "Users can only submit one query at a time and can only run up to five simultaneous queries for each account.", unless there's some caveat to my understanding of that, sounds like it kind of kills it for me.
您最应该关心的一点是：谁将使用您的应用程序？如果只有我自己，我不会对一些 Athena 查询和缓慢的响应时间有任何问题。但是，如果您的应用程序是 public-facing，请认真考虑您要为 Athena 一遍又一遍地扫描您的数据集支付的流量和金额。
快速分解
- Athena：快速概览您的 CSV 数据所在的位置 (S3)。不需要复杂的 ETL / 摄取或索引。在"Searching"
时不是特别强
- CloudSearch：检查它是否仍在维护/更新。我有一种感觉，不再是这样了。使用它需要您自担风险！
- 弹性搜索。搜索能力强。特别是 "nature language based" 搜索。您可以 customize the ranking weight 和类似的东西可能符合您的要求
我建议您使用自托管的 ElasticSearch
阅读这篇文章后，我决定将时间投入到 ElasticSearch 而不是 CloudSearch article；作者使用 CloudSearch 实现了一个类似的系统，并表示如果他们重新开始，他们会使用 ElasticSearch。
Athena 不适合搜索，因为我需要做一些工作来尝试优化它，而且它的限制也不适合面向 public 的网站。
我无法避免为我的数据编写导入过程的脚本，所以我最终编写了脚本来从 s3 存储桶中获取文件，验证它们，对数据进行反命名，然后将其发送到新的 ElasticSearch指数。这些脚本最终将出现在 Lambda 函数中，这将促进一个完全自动化的过程来更新数据集。
我发现 ElasticSearch 的优点之一是可以为索引设置别名。由于我定期收到的 CSV 是我数据的完整真实来源；我可以根据时间戳自动导入新的唯一索引名称。导入完成后，我编写了一个 API 请求以将别名从旧索引转移到新索引，然后删除旧索引。所以我可以替换 ElasticSearch 中的整个数据集，然后将其设置为实时，无需停机或混合数据集。在我发现别名之前，我想我必须对现有索引执行更新或创建一个新索引，然后更新网站以引用新搜索索引的 url。
我有一个静态网站，我需要实现对单独数据集的搜索；我目前在 AWS 上使用无服务器技术托管网站，包括 S3、Cloudfront、Lambda 和 API 网关用于某些服务器端逻辑。
我有几个 csv 文件，其中包含大约 120,000 条记录，其结构如下：
ID search_name name source quantity
10002 Lorem Ipsum Dolor sit amet primary_name 10
10002 Lorem Ipsum Consectetur amet other_name 10
10002 Lorem Ipsum Donec a erat other_name 10
10003 Ultricies pretium Inceptos primary_name 100
10003 Ultricies pretium Himenaeos other_name 100
所以最终结果将是我前端的一个搜索表单，该表单将对后端系统进行 API 调用，查询数据库或能够与 [= 字符串匹配的独立软件服务33=]字段；然后 return 所有比赛。我的前端会将带有 'source' 和 'other_name' 的记录显示为结果中的元数据，而不是单独的结果。
每 3 个月将提供一组新的 CSV 文件，其中包含相同的和额外的记录，但 'quantity' 字段可能具有新值。
由于我一直在使用无服务器技术，所以我最初的想法是尝试将文件存储在 一个 s3 桶，使用 AWS glue 处理它们并使它们可供 AWS Athena 进行查询。我很喜欢这个设置，因为没有太多的组件需要维护，而且托管成本会很低 我对这个设置的两个担忧是我会花时间尝试设计一个很好的搜索算法，该算法可以根据如何对结果进行排序他们结束了一场比赛。例如。如果搜索名称是 ABC，它应该是第一个结果，而不是其他仅包含 ABC 作为其名称一部分的项目。 其次执行速度；我有 运行 一些像这样的简单查询：
SELECT id, search_name, source
FROM data
WHERE search_name like '%lorem%';
只需使用 Athena GUI 中的查询编辑器，执行时间可以 运行从 0.5 秒增加到 3 秒。我关心的是那些 3 秒处决。我想知道这可以优化到什么程度。我也读过 "Users can only submit one query at a time and can only run up to five simultaneous queries for each account."，除非对我的理解有一些警告，否则听起来对我来说有点杀了它。
作为第二个选择，我正在考虑使用 AWS ElasticSearch。我不太了解它，但我认为使用专为执行搜索而设计的系统可能会使我的最终产品更好。我对实现它不太了解，但我担心的是，我对某些搜索结果进行优先排序的能力，以及执行该数据注入过程的难易程度，例如当一组新数据到达时，它需要更新记录，而不是仅仅堆叠在它们之上。我写了一个初始脚本来加载那里的 csv 记录来测试查询。
我现在刚刚开始研究 AWS CloudSearch，它实际上看起来比 ElasticSearch 简单一些，所以开始倾向于这种方式。
所以我正在寻找的建议是关于我应该使用哪些产品或服务的建议，无论是 Athena、ElasticSearch 还是其他东西，以及关于我应该如何实施这些服务的任何顶级建议。
谢谢。
Just using the Query editor in the Athena GUI, and the execution time can range from 0.5 to 3 seconds. It's those 3 second executions that concern me. I'm wondering how well this can be optimized. I've also read "Users can only submit one query at a time and can only run up to five simultaneous queries for each account.", unless there's some caveat to my understanding of that, sounds like it kind of kills it for me.
您最应该关心的一点是：谁将使用您的应用程序？如果只有我自己，我不会对一些 Athena 查询和缓慢的响应时间有任何问题。但是，如果您的应用程序是 public-facing，请认真考虑您要为 Athena 一遍又一遍地扫描您的数据集支付的流量和金额。
快速分解
- Athena：快速概览您的 CSV 数据所在的位置 (S3)。不需要复杂的 ETL / 摄取或索引。在"Searching" 时不是特别强
- CloudSearch：检查它是否仍在维护/更新。我有一种感觉，不再是这样了。使用它需要您自担风险！
- 弹性搜索。搜索能力强。特别是 "nature language based" 搜索。您可以 customize the ranking weight 和类似的东西可能符合您的要求
我建议您使用自托管的 ElasticSearch
阅读这篇文章后，我决定将时间投入到 ElasticSearch 而不是 CloudSearch article；作者使用 CloudSearch 实现了一个类似的系统，并表示如果他们重新开始，他们会使用 ElasticSearch。
Athena 不适合搜索，因为我需要做一些工作来尝试优化它，而且它的限制也不适合面向 public 的网站。
我无法避免为我的数据编写导入过程的脚本，所以我最终编写了脚本来从 s3 存储桶中获取文件，验证它们，对数据进行反命名，然后将其发送到新的 ElasticSearch指数。这些脚本最终将出现在 Lambda 函数中，这将促进一个完全自动化的过程来更新数据集。
我发现 ElasticSearch 的优点之一是可以为索引设置别名。由于我定期收到的 CSV 是我数据的完整真实来源；我可以根据时间戳自动导入新的唯一索引名称。导入完成后，我编写了一个 API 请求以将别名从旧索引转移到新索引，然后删除旧索引。所以我可以替换 ElasticSearch 中的整个数据集，然后将其设置为实时，无需停机或混合数据集。在我发现别名之前，我想我必须对现有索引执行更新或创建一个新索引，然后更新网站以引用新搜索索引的 url。