Как правильно организовать архитектуру веб-сервера?

Question

[loly]

На данный момент я являюсь джуниором и, к сожалению, должен прибегнуть к помощи более опытных специалистов (к сожалению по тому что не люблю беспокоить других людей). Проект на данный момент не является коммерческим, целью на данном этапе ставится его разработка. Основная цель - детальный поиск по базе. В базе хранятся объекты с максимум 20 различными характеристиками. Поиск возможен по каждой характеристике. Должна присутствовать регистрации и входа пользователей.

Источники пополнения базы:
1) Каждые 5-10 секунд JSON объемом в среднем 5.5 МБ. Информация может быть как абсолютно новая, так и заменяющая старую. На данный момент подробная статистика не известна, однако приблизительно половина информации должна будет заменить старую. После набора определенной базы новой информации поступать почти не будет. Сборщик первого источника будет написан в течении следующего дня (скажем, 24 часа). Как только будет известен приблизительный вес всей информации - добавлю его комментарием.
2) Парсер определенной страницы каждую минуту (нужной информации в объеме ~0.2 МБ).

Пример поиска (абсолютно вымышленного, тематика другая):
[Скорость > 90 и Скорость < 150 и Срок службы < 5 и [Тип "A" или Тип "C"] и ... и Стоимость < 10 и Сумма([чего-нибудь]) > 72] или [аналогичный фильтр со своими параметрами] и сортировка по [параметр]

Пример объекта (абсолютно вымышленного, тематика другая):
[Скорость = 134, Срок службы = 2, Тип = "A", ..., Стоимость = 80]

Собственно вопросы, что бы хотя бы в самом начале разработки не ошибиться при выборе инструментов:
1) Как лучше организовать структуру? Например, парсеры явно стоит выделить в отдельное приложение, но я пока не знаю как.
2) Какой веб-сервер лучше использовать? Node.js или django?
3) Самое важное. Какую базу данных использовать? Результат необходим мгновенно, т.е. без ожидания, а не через 5 минут и даже не через 10 секунд. Чем быстрее - тем лучше.

Answer 1

[Дмитрий Энтелис]

Ох. Ну давайте подряд. Начнем с конца :-p
3) Мгновенного поиска не бывает. Так что нужно сразу понимать необходимой быстродействие. Кому то и 1500ms "мгновенно", а кто то хочет за 10ms данные получить.
Критические вопросы:
- какой объем данных в базе всего
- какое количество поисков случается в секунду
- насколько поисковые запросы избирательны (ответ на поисковый запрос это единицы записей или десятки тысяч)
- насколько консистентна и релевантна должна быть поисковая выдача с учетом постоянных апдейтов.
- сколько есть денег на сервера ;-)

Если данных мало (< 1gb плюс минус) я бы не парился и записал это все в обычный mysql навешав на него 100500 индексов. Дальше нужно померять производительность на запись-чтение, если все устраивает - на этом и остановиться.

Если данных больше и хочется освоить что то новое - я бы посмотрел в сторону Elastic Search.
Ребята из 2gis как раз пару лет назад его внедряли https://habrahabr.ru/company/2gis/blog/213765/ документации по нему море. Из минусов - выдача всегда будет отставать от горячих данных.

Если нужен поиск по горячим данным и при этом быстродействие mysql не устраивает - у меня нет хорошего ответа :) Можно какую нибудь кассандру посмотреть, можно свой велосипед напилить, но тут советовать лично мне - сложно.

2) Нода, питон, руби, пхп - дело вкуса абсолютно. Основная нагрузка (если речь не идет про велосипеды) будет все равно на БД идти. А велосипеды лучше на C++ писать такие.

1) По Вашему посту у меня больше вопросов чем ответов если честно. Что за json, откуда они берутся, как будут разрешаться конфликты если новые json приходят быстрее чем обрабатываются старые, итд.
В целом это более тривиальный вопрос чем задача быстрого поиска.

Comments

[loly]

Мне казалось в подобном сообществе нет необходимости уточнять, что подразумевалось под мгновенным поиском, но раз уж на то пошло...

[Дмитрий Энтелис]

loly: "чем быстрее тем лучше" - это не постановка задачи. Постановка это: есть XXXXX mb данных, XXXX$ в месяц на железо, XXX запросов в секунду, нужно уложить ответ в XX ms. Тогда уже можно думать.

[Дмитрий Энтелис]

loly: только прочитал "Проект на данный момент не является коммерческим, целью на данном этапе ставится его разработка." - тогда сразу Elastic Search

[loly]

Дмитрий Энтелис: К сожалению, у меня ничего этого нет) У меня нет заказчика, железа (разве что домашнее) или каких то больших (а тем более XXXX$) средств. XXX запросов в секунду точно не будет, максимум моих ожиданий - XXXX уникальных посетителей в сутки (которые, правда, могут достигнуть XXX запросов в секунду, но только если у них будет возможность получения "горячей информации", т.е. какой нибудь встроенный функционал, обновляющий каждую секунду).

[loly]

Дмитрий Энтелис: PS Мне бы совесть не позволила взять подобный проект на данном этапе развития)

Answer 2

[ThunderCat]

Если известно конечное число характеристик - делать одну таблицу, в идеале - поля должны быть уже известны. Тогда проще работать с индексами и не нужно подключать связи таблиц. Это серьезно ускорит работу бд.

1. Структура будет зависеть от среды, нода джанго или пых - все они будут по разному подходить к задаче в силу ограничений/преимуществ среды. По пыху - взять ченть полуготовое, например ларавел, хотя из задачи торчат уши хайлоада, тут в идеале нужно писать свой шустрый велосипед. Но мвц - без сомнений. По остальным - не в курсе что сейчас модно.
2. Нода и джанга - не сервера, а фреймворки.
3. Я бы смотрел на мускуль. При правильной настройке скорость работы современных рбд практически идентична, а информации по настройке/работе с мускулом просто через край. Комюнити широкое и достаточно отзывчивое, спецов на рынке есть. Если нужно надежно/быстро/поддерживаемо то в экзотику типа мемористораж баз я бы не кидался. Результат мгновенно - это только у пургена, любая программная компонента имеет задержку, на поиск, индексацию, внутреннюю передачу данных, структурирование и прочую накладную фигню.

PS: кто такая логинация???

Comments

[sim3x]

лог + пагинация = мутант логинация

[loly]

Исправил логинацию.