планы смотрел - все по индексам. Одно дело короткий запрос с одним in условием по одному полю, а другое дело 100 блоков where по трем полям. Наверное поэтому хэш быстрее жука соответственно
Можно было бы решить через теорию графов, но тогда нужно держать в согласованном виде граф и БД. А это дополнительная точка отказа. Как мне кажется одна из основных задач enterprise разработки - чтоб было все как можно проще и понятнее. Как молоток =) Взял в руку и понятно что делать.
Спасибо за крутые вопросы. Надеюсь статья теперь стала понятнее)
Не одним запросом. Входные параметры бьются на батчи. А то в постгре есть лимит на входящие параметры, да и на саму длину sql запроса. В одном сценарии может происходить работа по 100 тыс. направлений. И в случае Хеша полезем в БД несколько раз (зависит от размера батча направлений).
Дичь не дичь, но Нумерология в данный момент и работает по стране)
Так как: Хеш реализовывать не быстро; с Жуком поймал проблему на тестовой нагрузке. Видать что-то другое стрельнуло, а я подумал на бедного жука.
Мы превращаем не три буквы в три хеша, а каждое направление в хэш. То есть для 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>) лишние записи отсутствуют. Табличка в пункте "Практика — критерий истины". Метод жук не имеет лишних данных. А вот хэш как раз имеет, но очень немного.
Спасибо за комментарии! Постараюсь учесть в следующих статьях)
да
все подряд =) чуть ли не на каждое поле
Значительно уменьшает лишние данные, но полностью проблему не убирает. Остаются коллизии. Так как хэш это число с ограниченной разрядностью. И кстати 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 направлениями. Иначе памяти не хватит
планы смотрел - все по индексам. Одно дело короткий запрос с одним in условием по одному полю, а другое дело 100 блоков where по трем полям. Наверное поэтому хэш быстрее жука соответственно
главное не хацкнуть самолет во время полета. А то окажется как в фильме "Черный ящик")
Можно было бы решить через теорию графов, но тогда нужно держать в согласованном виде граф и БД. А это дополнительная точка отказа. Как мне кажется одна из основных задач enterprise разработки - чтоб было все как можно проще и понятнее. Как молоток =) Взял в руку и понятно что делать.
А я сам с НГТУ, получается заказали =)
С пачечной обработкой все ок. Но как показал тест - метод с хешом намного быстрее, чем через множественный where блок (Жук метод).
индекс есть
Спасибо за крутые вопросы. Надеюсь статья теперь стала понятнее)
Не одним запросом. Входные параметры бьются на батчи. А то в постгре есть лимит на входящие параметры, да и на саму длину sql запроса. В одном сценарии может происходить работа по 100 тыс. направлений. И в случае Хеша полезем в БД несколько раз (зависит от размера батча направлений).
Дичь не дичь, но Нумерология в данный момент и работает по стране)
Так как:
Хеш реализовывать не быстро;
с Жуком поймал проблему на тестовой нагрузке. Видать что-то другое стрельнуло, а я подумал на бедного жука.
В итоге, все равно, ускорение хорошее получили.
Мы превращаем не три буквы в три хеша, а каждое направление в хэш. То есть для 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>) лишние записи отсутствуют. Табличка в пункте "Практика — критерий истины". Метод жук не имеет лишних данных. А вот хэш как раз имеет, но очень немного.
+
Спасибо за комментарии! Постараюсь учесть в следующих статьях)
да
все подряд =) чуть ли не на каждое поле
Значительно уменьшает лишние данные, но полностью проблему не убирает. Остаются коллизии. Так как хэш это число с ограниченной разрядностью. И кстати 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 направлениями. Иначе памяти не хватит
да