На каком языке программирования чаще всего пишется метапоиск?

Question

[MSAFT]

Делаю проект для туроператора.
По своей сути напоминает чем-то aviasales, hotellook, chip.travel.
Разница только в том, что помимо порядка 130 партнеров этого туроператора есть еще свой продукт.

Мысль проста, взять цены всех партнеров по запросу пользователя и выдать ему лучшую. Если запрос пользователя есть в своем продукте - выдать свой продукт не сканируя партнеров.

Сканировать всех и сразу не имеет смысла, запрос фильтруется по критериям(откуда вылет, куда летим). По любому запросу, обычно нужно отсканировать 5-6 партнеров. Поэтому нагрузка иная, если бы сканировать надо было 130 партнеров сразу.

Думал, что обычно такие проекты целиком и полностью пишутся на одном языке. Чаще всего на PHP.
Покурив данную тему, в частности изучив немного проект aviasales, понял что сайт и его функции у них написаны на PHP, а сам метапоиск реализован на RUBY.

Касаемо PHP есть неплохая база и некоторые знания. А вот с RUBY не сталкивался ниразу.

Вертска готова полностью. Проектирование, как мне кажется, тоже. Вот часть моих мыслей касаемо самого метапоиска:


Но остались вопросы по серверной части и по RUBY.

Вопросы:

1. Действительно ли метапоиск чаще всего реализуется на RUBY?
2. Можно ли выполнить основной функционал сайта на PHP, а сам поиск на RUBY?
3. Пришел к мысли, что под определенные функции нужны свои, отдельные БАЗЫ ДАННЫХ. Имел дело только с MySQL. Под такие высоконагруженные проекты какие БД лучше всего использовать?
4. Где подобрать грамотную команду специалистов(fl.ru ; upwork?) и как вести данный проект(Github?)? Какие решения лучшие? Что это за система управления проектом - https://www.youtube.com/watch?v=DCg-LGiWrKk (видео "Как писали aviasales")
5. Серверная часть. Наверняка под такие проекты нужно покупать свои машины. Есть ли смысл? Или есть хостинг решения под такие задачи? Насколько крутой сервер-специалист нужен для настройки всего этого дела?

Спасибо за внимание.

Comments

[MSAFT]

У меня уже готовое ТЗ по back-end'у на 29 страниц. Предполагаемую нагрузку трудно рассчитать, т.к. на рынке в стране где этот сервис планирует запускаться просто нет аналогов. У aviasales 13ГБ в секунду, но в данном проекте пока сложно представить такие нагрузки.

Answer 1

[Макс]

Купался я в этой нише.

1, 2. Поиск можно делать и на PHP
3. Базы можно и SQL. PostgreSQL вполне потянет такое. В зависимости от функционала может понадобиться MemCached, Redis
4. Мало сайтов с вакансиями?) тот же hh, например. Использоваться можно тот же GIT или SVN. Кому что удобнее
5. Не только наверняка, а 100% придется. Уровень крутости специалиста определяется поставленными вами задачами.

Вы учитывайте еще то, что если вы собираете выводить услуги партнеров, то вам их надо парсить. И вы же не будете их парсить при каждом запросе пользователя, а это значит, что вам надо сохранять эти данные где-то у себя. На примере 6-10 не скажу, но на примере >200 скажу точно, что там огромное кол-во слоев кеширования должно быть, по куче параметров. Парсер в этом случае может выступать вообще как отдельный проект. Плюс динамические фильтры с зависимыми параметрами и т.д.

Потянете конкуренцию со стороны TourIndex? :)))

Comments

[MSAFT]

Благодарю за ответ.
1.2. Изначально так и планировал, но покурив данную тему, понял что все таки такого рода поиск лучше на PHP не делать. Осталось понять для себя почему :)

Да, я абсолютно учитываю, что услуги партнеров надо парсить. Причем вы меня сбили с толку, потому что я рассчитываю их парсить при каждом запросе пользователя :)
Конкретно цену, сама отельная база естественно должна быть своя. Цена ведь динамическая и может меняться каждые 5 минут.

Так и планирую. Функционал сайта по типа "кабинет пользователя", статичные(информационные) страницы и т.д. планирую таки реализовать на PHP. А сам метапоиск как отдельный проект. Т.е. пользователь дал данные, эти данные зашли в отдельный сервис метапоиска где есть куча подключенных gate(партнеров) и выдали цену по запросу. Далее сервис сканирует лучшее предложение и показывает цену уже с % нашего сервиса пользователю.

TourIndex, я так понял, российский сайт. А этот сервис планируется на рынке страны, где пока еще просто нет аналогов.

[Макс]

MSAFT:
На ТИ например реализовано несколько способов получения актуальной цены:
1. Туры выводятся из кеша и в каждом туре есть кнопка для получения актуальной цены.
2. В фильтре есть галка 100% актуальность. Если она стоит, то туры будут парситься сразу с контрагентов.

Если вы хотите парсить при каждом поиске, то вам стоит учесть то, что контрагент может долго не отвечать (10 - 20 - 30 сек), или вообще не ответить. Естественно пользователь столько ждать не захочет. Вам уже через максимум 5-7 сек надо ему что-то показать. А как быть в таком случае, если у запоздалого контрагента цена самая низкая? Поставите его самым последним? Это лишь 1 из тех подводных камней которые ожидают вас на этом пути) А их там огого сколько)

[MSAFT]

Я все таки рассчитываю до 1 мин загрузки. Даже сверстал страницу с такой надписью, под это дело.


Как раз таки об этом камне я подумал, а там уже по фидбеку юзеров будем думать, что к чему. Подскажите какие еще могут быть?

Еще вы сказали, что купались в этой нише. Тоже хотелось бы подробностей, если Вас не затруднит конечно.

Я сейчас как губка, пока подбираю команду стараюсь впитать максимально много полезной информации.

[Макс]

MSAFT: 1 минуты? Ужас какой.... Мы на ТИ боролись (уверен они и сейчас это делают) за каждые 100мс, а уж как это сделать выбирайте сами, есть множество способов. Если скорость загрузки хоть немного падает, то в фидбек сразу падают жалобы, что поиск стал очень долгим.

Думаю вы понимаете, что под каждого контрагента должен быть свой парсер, в том числе если у них AJAX загрузка результатов поиска. И если у одного контрагента разметка поменяется, то у вас не должно все упасть и завалить юзера нотисами, варнингами т.д.

В тур как правило входит отель, у которого куча параметров (румсайзы, вид из номера, питание и т.д.) и вот у некоторых контрагентов одна и та же аббревиатура может подразумевать слегка различные понятия, либо называться такой же аббревиатурой, но уже с какой-то приставкой. Вам придется их как-то группировать по смыслу.

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

[MSAFT]

Макс: Вы знаете, я хочу вам сказать ОГРОМНОЕ спасибо. Вы поменяли мое мнение касаемо PHP. Поиск ТИ целиком написан на PHP? Я сравнил ТИ и продукт AviaSales, у них цена подгружается ГОРАЗДО быстрее чем у Hotellook от Aviasales. Aviasales билеты ищет так же порядка 40-45 секунд. Ну тут дело наверное не в самом PHP, а в методе исполнения. Но если можно исполнить тоже самое на PHP лучше, чем то, что исполнено на Python у продуктов Aviasales. Вопрос, зачем тогда морочить себе голову и лезть в те дебри в которых особо не разбираешься, если сделать можно тоже самое но идти по тому пути в котором есть понимание и представление того что ты делаешь.

С вами можно как-то связаться и пообщаться лично?

[Макс]

MSAFT: Пишите, контакт в профиле

Answer 2

[Dimonchik]

1) neo4j
2) sphinxsearch + facet

P.S. на Руби свет клином не сошелся

Answer 3

[Pavel Ivanov]

1. В Aviasales метапоиск переписали на Python/Tornado Отказоустойчивость на примере aviasales
В случае метапоиска я бы смотрел на инструменты с хорошей поддержкой concurrency, например golang.
2. Конечно можно, просто выделяете метапоиск в отдельный сервис.
3. Реляционные базы данных вполне подойдут.
4. Там используется git.
5. Сервера возьмите на digitalocean.com или его аналогах - vscale.io, flops.ru