Pull to refresh

Comments 6

Если честно, не очень понятна цель статьи. Мы пытаемся сделать реальный поиск, который будет лучше современных решений по полнотекстовому поиску, или мы играемся со Спарком на примере этой задачи? Если второе — то ок, если первое — ну, такое: перебить в одиночку современные индустриальные разработки вряд ли получится.
Спасибо за комментарий. Свои цели я описывал в предыдущей статье, в ваших терминах это «поиграться со спарком». Конечно же я не планирую в одиночку перебить индустриальные разработки, а на примере задачи продемонстрировать разные технологии и алгоритмы.
Мне кажется, автор слегка жульничает :) всю работу по распараллеливанию запросов за вас сделает aerospike, причем вы даже не задумываетесь, что у него внутри. И фактически вы сделали работу только по построению индекса. И да, попытка добавить сюда например исправление опечаток (любой нечеткий поиск) весьма вероятно приведет к изменению всей архитектуры.
Я сделал работу только по построению индекса, так как в этом была цель этого шага:) Aerospike тут выполняет роль которую может любое другое key-value хранилище построенное на этих принципах, например dynamodb. Работа key-value хранилищ это интересная область, но для моей задачи это просто инструмент (так же как например spark).

По поводу исправления ошибок и например обработки синонимов — на самом деле архитектура не меняется от этого. Просто в момент извлечения данных из индекса необходимо будет извлечь большее количество документов, а уже потом правильным образом их отсортировать (об этом в следующей статье)
Понятно, что в одном посте всего не рассказать, так что это не претензия.

>любое другое key-value хранилище

На каких «этих»? Тут в моем понимании дело в том, что с ростом объема данных и индексов вы просто обязаны их распределять, и данные, и работу, по узлам кластера. И я не знаю универсального автоматического способа это сделать, не вникая в то, что у нас за данные. Ну то есть — хранилище распределяет данные по кластеру на основе ключа, а ключ строите вы. Я не особо большой спец в этом вопросе, но мне кажется, что такого хранилища, которое позволяло бы ни о чем не думать на реально больших объемах не существует.

И еще я имел в виду, что для нечеткого поиска обычно приходится что-то делать при построении индекса, а не только при поиске по нему. Так что если не архитектура в целом, что вид индекса или индексов вполне может поменяться. И если у вас не было изначально скажем N-грамм, то при поиске им взяться негде, и о дополнительных индексах нужно очевидно подумать заранее.
Принцип — это в первую очередь Distributed Hash Table. Примеры других технологий — Apache Cassandra, Amazon Dynamo Db и так далее.

По поводу N-Gram — возможно что-то и понадобится поменять при построении индекса, однако предусмотреть все невозможно. Архитектурно и идейно получится все равно то же самое: обратный индекс построенный при помощши технологий больших данных.
Sign up to leave a comment.

Articles