@nobodywithbody

Где было бы корректно обрабатывать данные, на стороне БД или ЯП?

Приветствую!

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

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

Вопрос заключается в следующем, где было бы правильно реализовать подобный сложный поиск? Можно вынести в монгу, сделать mapReduce, а скорость подтянуть исключительно кол-вом машин, обрабатывающий этот запрос. Например, на каком уровне решают задачу коммивояжера, в бд или в коде? Но в том же php можем упереться в ограничение памяти, т.к. нам нужно получить все данные, коих довольно много.

Решение алгоритма не требуется, требуется просто совет, где было бы корректней реализовать подобное, как делают поиск крупные компании. Всем добра!
  • Вопрос задан
  • 208 просмотров
Решения вопроса 1
@Stqs
senior software developer
nobodywithbody,

я бы делал всю логику в коде и начал бы со следующих шагов

В базу:
- берем выборку самых тормозных запросов
далее EXPLAIN в руки и выясняем где что тупит)
- делаем индексы (с умом) если нужно
- делаем вьюшки (если нужно) в базе что б не работать с совсем сырыми данными
- даты на стороне базы не конвертируем - это тоже очень медленно будет

В коде:
- профайлер в руки и профилировать, профилировать, профилировать
- используем методы динамического программирования (у вас задача практически классическая)
- если все равно тормозит как вариант наколбасить что-нить типа сишной либы для этой конкретной задачи и дергать ее из хпх
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
daager
@daager
Возможно мне не хватит квалификации, но:
Посмотрите, сколько времени занимает запрос, частота запросов и обновление данных, возможно есть смысл кэшировать результат и самому инвалидировать его. Изучите код внимательнее, там могут быть места для локального кэша из серии, когда значение некой переменной уже рассчитывалось и можно его заново не узнавать. Для PHP timestamp не так уж и сложно, загоните его в DateTime и может вам станет проще. В больших циклах можно использовать yeild, вроде как это несколько решает вопрос с памятью, почитайте об этом. Также, конечно же сделайте профилирование своего кода и узнайте, где самые тяжелые места и пляшите от этого.
Ответ написан
Therapyx
@Therapyx
Data Science
А о каком кол-ве данных идет речь? Чтобы сделать алгоритм работащий для таких задачь я так понимаю данных должно быть много. Чтобы работать в бекенде быстро и еффективно придется очень и очень сильно оптимизировать этот потом с запросами и обработкой, при условии, что нету возможности просто взять все нужные данных и работать с ними уже в оперативке.
Если же все таки такой возможности нету, то или как уже написал оптимизация запросов - обработок. Или же вообще все сделать на основе триггеров или сторедпроцедур.
Ну и про поддержку верно, есть ли у вас или являетесь вы сами таким специалистом, который в sql чувствует себя как дома?
Трудно конечно ответить на такое без тестов) я тоже не гуру, но в моем случае я бы писал 2 варианта и тестил наилучший из них. Да это в 2 раза больше времени, но если важен качественный результат, то приходится и таким жертвовать )
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы