Comments 17
Было интересно, спасибо. Особенно нумерология и волшебное число 1000!
Кто в теме, накидайте семерок
Одному мне кажется что "смешные" картинки в статьях/презентациях это что-то из середины десятых? Конкретно в вашей статье они не добавляют ничего.
Тяжело воспринимается для читателя не в теме. Пришлось перечитывать местами, но всё равно вопросы остались, т.к. подробностей в статье нет:
Маршруты A->B и B->A - это разные маршруты?
Какие индексы есть в БД для таблиц с маршрутами?
Каким образом использования хэша спасает от декартового произведения? A->B и B->A на одинаковом тарифе имеют одинаковый хэш?
Upd:
UUID - это прям UUID или цифра?
Добавлю ещё:
Откуда берутся лишние данные для решения с батчами?
У вас же в БД хранятся все возможные маршруты из-в?
Короче, вместо "смешных" картинок стоило нагляднее описать задачу и решение.
Спасибо за комментарии! Постараюсь учесть в следующих статьях)
да
все подряд =) чуть ли не на каждое поле
Значительно уменьшает лишние данные, но полностью проблему не убирает. Остаются коллизии. Так как хэш это число с ограниченной разрядностью. И кстати A->B и B->A на одинаковом тарифе имеют разные хэши (см. реализацию 17/37 https://www.baeldung.com/java-equals-hashcode-contracts)
uuid - это прям uuid, но выглядит внутри как цифры 123e4567-e89b-12d3-a456-426655440000
картинка в пункте (Собственно, проблема). Запрашиваем 3 направления, а из БД достается 9. Батчи просто ограничивают входящую выборку. Например, если всего 27 направлений, а размер батча 3, то выполним 9 итераций. При том, что на каждой будем доставать лишние данные. Просто не лезем сразу за всеми 27 направлениями. Иначе памяти не хватит
да
Мне на 10к фантазии не хватает. Вот есть 26 мест A-Z. Итого в БД 26х26 записей. Нам дали буквы A, B, C. Нужно вытащить 6 записей: AB, AC, BA, BC, CA, CB.
Каким образом вы 3 буквы превращаете в 3 хэша, делаете с ними запрос, а потом получаете искомые 6 записей?
Как у вас получаются лишние записи? У вас в запросе AND.
Вы подробностей задачи не написали - приходится додумывать.
Мы превращаем не три буквы в три хеша, а каждое направление в хэш. То есть для 6 записей-направлений: AB, AC, BA, BC, CA, CB мы сформируем 6 хэшей: (например) 1, 2, 3, 128, 18, 2. Как видими здесь есть повторения AC и CB имеют в моем примере одинаковый хэш. Имхо в БД еще несколько направлений имеют хеш 2. Например DZ. Соответственно по 6 хэшам запрашиваем строки. БД вернет, скажем, 9 из 6 нужных. Далее пробегаемся по полученным данным и выбрасываем ненужные (DZ).
Вообще сценарий следующий: пользователь знает только направления и тариф, а мы по ним должны достать полноценный объект (там намного больше полей: на каком складе будет выгрузка, едем или летим и тд). И уже над объектом провести какие-то действия.
На множественные where блоки (NODE_FROM,NODE_TO) = (<UUID1>, <UUID2>) AND (NODE_FROM,NODE_TO) = (<UUID3>, <UUID4>) лишние записи отсутствуют. Табличка в пункте "Практика — критерий истины". Метод жук не имеет лишних данных. А вот хэш как раз имеет, но очень немного.
Вот теперь картина сложилась.
"Жук" (как и "Хэш") всё тянет одним запросом? Если да, то почему не разбили "Жук" на батчи? Это самый очевидный вариант, как по мне.
Остальные два способа - вообще какая-то дичь. Так и не понял зачем вообще их пробовать.
Спасибо за крутые вопросы. Надеюсь статья теперь стала понятнее)
Не одним запросом. Входные параметры бьются на батчи. А то в постгре есть лимит на входящие параметры, да и на саму длину sql запроса. В одном сценарии может происходить работа по 100 тыс. направлений. И в случае Хеша полезем в БД несколько раз (зависит от размера батча направлений).
Дичь не дичь, но Нумерология в данный момент и работает по стране)
Так как:
Хеш реализовывать не быстро;
с Жуком поймал проблему на тестовой нагрузке. Видать что-то другое стрельнуло, а я подумал на бедного жука.
В итоге, все равно, ускорение хорошее получили.
Вот видите сколько важных деталей вы в статье не рассказали.
Не могу понять что может быть не так с пачечной обработкой заданных направлений - это же не отличается от хешей, по сути. Разве что меньше данных передаётся в запросе, но не думаю, что это так критично. Индекс (from, to) есть а базе? Может в этом дело.
Блок с комментариями и нужен чтобы задавать вопросы.
Читаю, тема понятна, картинки не мешают. Автору лайк за труд
Ни о чем. Познавательно, но не несет никакой практической пользы. Задача решается теорией графов немного сложнее институтской программы. Всегда можно заказать решение на кафедре НГТУ, если не хватает своих знаний.
Можно было бы решить через теорию графов, но тогда нужно держать в согласованном виде граф и БД. А это дополнительная точка отказа. Как мне кажется одна из основных задач enterprise разработки - чтоб было все как можно проще и понятнее. Как молоток =) Взял в руку и понятно что делать.
А я сам с НГТУ, получается заказали =)
Жук, нумерология, хеш или ничо? Оптимизация работы с путями