Какая архитектура нужна для телеграм бота с функцией full-text поиска?

Question

[WiredPulp]

Сейчас я продумываю план/архитектуру (idk как правильно назвать) тг бота и не могу разобраться
Главная фишка моего бота – full-text поиск.



1. Мне нужно место, где я буду хранить данные 10 000 элементов, у каждого элемента будут:
- Тэги (~200 символов)
- Описание (1000 символов)
- Фото (1 МБ)
- Геолокация
2. К этому хранилищу мне нужен full-text поиск по таким параметрам как:
-Геолокация
-Тэги
-Описание
3. Затем результаты поиска будут форматироваться в инлайн кнопки (и в запросах, которые выводятся юзеру будут сокращенные версии информации об объектах, чтобы это помещалось в инлайн кнопки) и отправляться юзеру

4. И затем пользователь уже запрашивает полную версию информации об обьекте (т.к. нажимая на инлайн кнопки, он выбирает id из БД с полной информацией), и соотвественно её получает

> Инфраструктура должна поддерживать 1000 одновременных полнотекстовых запросов по показателям указанным выше

Моя проблема:
**Как стоит продумать архитектуру проекта? Какие инструменты лучше использовать? Использовать один сервер или несколько?**
Мои варианты:
Инструмент для full-text поиска, который мне понравился больше всего – ElasticSearch, но я полагаю, что лучше не надо использовать его как основную базу данных.
Значит в качестве основной базы данных нужна какая-то другая БД. Мой главный критерий – возможность иметь базовую статистику по данным (насколько нагружена БД, когда и сколько объектов появилось в системе) а также максимальную быстродейственность, т. к. ресурсы ограничены и хотелось бы иметь лучшее решение. И тут я не могу выбрать: PostgresQL или MongoDB. Не будет ли SQL база слишком требовательна к ресурсам? Может стоит выбрать sphinx а не elasticsearch? Или я мыслю совершенно в неправильном русле?

Comments

[rPman]

данные 10 000 элементов

Использовать один сервер, эти объемы минимальны, конечно если у тебя будут десятки-сотни тысяч активных пользователей, возможно нагрузка станет неподъемной для одной машины, но что то мне говорит что на старте тебе хватит 10$-vps

full-text поиск используй то что нравится и на чем лучше всего пишешь, хотя современные sql базы отлично и с этим справляются, многим нравятся некоторые фичи эластика

sql база данных идеальна для случаев, когда нужна будет аналитика но еще непонятно какая, никаких json и других document-oreiented подходов, все разбивай на элементы и храни в полях и таблицах, сем меньше у тебя будет универсальных данных, тем легче тебе будет. Данные должны быть машиночитаемыми.

Совет стороннюю базу для full-text поиска используй как довесок для основной sql базы данных, а не как основное хранилище, пусть оно дублирует его.

Answer 1

[mayton2019]

Да. Elastic можно использовать. Но только до того как принимать решение - попробуй смоделируй рандомных 10 000 документов и наполни их рандомными атрибутами. И загрузи в эластик и посмотри как быстро работает поиск. Эластик масштабируется по количеству нод. Тоесть надо будет платить провайдеру пропорционально твоим потребностям. Хочешь чтоб поиск работал быстрее - плати за большее число нод.

Comments

[LXSTVAYNE]

А самому в докере поднять, зачем провайдеру то платить ?

[mayton2019]

LXSTVAYNE, попробуйте.

[LXSTVAYNE]

Dr. Bacon, ну про одну ноду ничего не знаю, ведь автор задаётся вопросом

Использовать один сервер или несколько?

Но прорыв был бы действительно гарантирован, если бы так работало)

[mayton2019]

Масштабирование поисковых систем текста обеспечивается за счет распределенных дисковых систем. Так работает Google например.

Тоесть сам по себе совет поднимать TextSearch в докерах - это правда но не вся. Нужно так-же динамически докидывать в систему диски.