Рекомендации по внедрению системы поиска данных для веб-сайта stati c с инфраструктурой AWS - PullRequest
2 голосов
/ 21 января 2020

У меня есть веб-сайт c, который мне нужен для поиска отдельного набора данных; В настоящее время я размещаю сайт с использованием технологии без сервера на AWS, включая S3, Cloudfront, Lambda и API-шлюз для некоторых серверных логи c.

У меня есть несколько 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 для бэкэнд-системы, которая запрашивает базу данных или отдельную программную службу, которая может соответствовать строке в поле «search_name»; а затем верните все совпадения. Мой интерфейс будет отображать записи с «источником» и «другим именем» в качестве метаданных в результате, а не в отдельных результатах.

Новый набор файлов CSV будет предоставляться каждые 3 месяца, который будет содержать то же самое, и дополнительные записи, но поле «количество» может иметь новое значение.

Поскольку я работал с бессерверными технологиями, моей первоначальной мыслью было попытаться сохранить файлы в корзине s3, использовать клей AWS, чтобы обработать их и сделать доступными для AWS Афины для запросов. Мне нравится эта настройка, так как не так много компонентов, которые нужно обслуживать, а расходы на хостинг будут низкими Мои две проблемы с этой настройкой - время, которое я потрачу, пытаясь разработать хороший алгоритм поиска, который может сортировать результаты в соответствии с тем, как закрыть матч они. Например, если имя для поиска AB C, оно должно быть первым результатом, в отличие от других элементов, в которых AB C является частью их имени. Во-вторых скорость исполнения; Я выполнил несколько простых запросов, таких как:

SELECT id, search_name, source
FROM data
WHERE search_name like '%lorem%'; 

Просто с помощью редактора запросов в Афине GUI, и время выполнения может варьироваться от 0,5 до 3 секунд. Это те 3 секунды казни, которые меня беспокоят. Мне интересно, насколько хорошо это можно оптимизировать. Я также прочитал: «Пользователи могут отправлять только один запрос за раз и могут выполнять только до пяти одновременных запросов для каждой учетной записи», если только у меня нет некоторой оговорки, похоже, это как бы убивает меня.

В качестве второго варианта я думал об использовании AWS ElasticSearch. Я не очень много знаю об этом, но я подумал, что использование системы, разработанной для поиска, может сделать мой конечный продукт намного лучше. Я не знаю много о его реализации, но мои проблемы здесь, опять же, моя способность расставить приоритеты для определенных результатов поиска и насколько легко будет выполнить этот процесс ввода данных, например, когда новый набор данных прибывает, он нуждается обновлять записи, а не просто укладывать их поверх. Я написал первоначальный сценарий для загрузки записей CSV, чтобы проверить запрос.

Я только начал смотреть на AWS CloudSearch, который на самом деле выглядит немного проще, чем ElasticSearch, поэтому начинаю склоняться таким образом.

Поэтому совет, который я ищу, - это рекомендации о том, какие продукты или услуги мне следует использовать, будь то Athena, ElasticSearch или что-то еще, и любые рекомендации высшего уровня о том, как мне следует внедрять эти службы.

Спасибо.

Ответы [ 2 ]

1 голос
/ 21 января 2020

Просто используйте редактор запросов в Athena GUI, и время выполнения может варьироваться от 0,5 до 3 секунд. Это те 3 секунды казни, которые меня беспокоят. Мне интересно, насколько хорошо это можно оптимизировать. Я также прочитал: «Пользователи могут отправлять только один запрос за раз и могут выполнять только до пяти одновременных запросов для каждой учетной записи», если только у меня нет некоторой оговорки, похоже, это как бы убивает меня.

Один момент, который вам следует беспокоить больше всего: кто будет использовать ваше приложение? Если бы это был только я, у меня не было бы проблем с несколькими запросами Athena и медленным временем ответа. Однако, если ваше приложение publi c -facing , серьезно подумайте о трафике c и сумме денег, которую вы собираетесь заплатить за Athena, чтобы сканировать ваш набор данных снова и снова.

Быстрая разбивка

  • Афина: Быстро ознакомьтесь с данными CSV там, где они находятся (S3). Нет необходимости в сложных ETL / проглатывании или индексации. "Поиск" не особенно силен
  • CloudSearch: проверьте, поддерживается ли он до сих пор / обновляется. У меня есть чувство, что это больше не так. Используйте его на свой страх и риск!
  • ElasticSearch. Сильный в поиске. Особенно "поиск на основе языка природы". Вы можете настроить вес ранжирования , и тому подобное может соответствовать вашему требованию

Я бы порекомендовал вам go для самостоятельного ElasticSearch

0 голосов
/ 24 января 2020

Я решил потратить свое время на ElasticSearch вместо CloudSearch после прочтения этой статьи ; автор реализовал аналогичную систему с CloudSearch и заявил, что они использовали бы ElasticSearch вместо этого, если бы они начали заново.

Афина не подходила для поиска, учитывая работу, которую мне нужно было сделать, чтобы попытаться оптимизировать ее, а также ее ограничения не подходили для общедоступного c веб-сайта.

Я не мог избежать написания сценариев для процесса импорта моих данных, поэтому я закончил писать сценарии для извлечения файлов из корзины s3, их проверки, деномарлизации данных и отправки их в ElasticSearch под новый индекс. Эти скрипты будут в конечном итоге в лямбда-функциях, которые облегчат полностью автоматизированный процесс обновления набора данных.

Одна из приятных вещей, которые я обнаружил в ElasticSearch - это возможность создавать псевдонимы для индекса. Поскольку CSV, которые я получаю периодически, являются полным источником правды для моих данных; Я могу автоматизировать импорт в новое уникальное имя индекса на основе метки времени. После завершения импорта я написал запрос API, чтобы переместить псевдоним со старого индекса на новый, а затем удалить старый индекс. Таким образом, я могу заменить весь набор данных в ElasticSearch и затем запустить его без простоев или смешанных наборов данных. Прежде чем я узнал о псевдонимах, я подумал, что мне нужно будет выполнить обновление существующего индекса или создать новый, а затем обновить веб-сайт для ссылки на URL нового поискового индекса.

...