@florgas

Добрый день.
Бэк java+spring.
БД hbase через apache phoenix.
В базе 10млн записей.
С фронта приходит 10.000 идентификаторов записей (только для примера, по факту может быть 100.000 или больше).
Надо проверить есть ли запись в базе.
Сейчас реализация такова, что сначала в лист джавы вытаскиваются все записи, и потом идет проверка по листу. Это занимает огромное количество времени из-за работы с hbase через phoenix. По факту больше 10 минут ( только чтобы вытащить все записи в лист).
Подскажите пожалуйста как подобную работу оптимизировать. Спасибо.

0

@iSmokeJC

Зачем все вытаскивать? У JpaRepository есть метод boolean existsBy...

0

@korvin_

Насколько я знаю про HBase и подобные БД, они медленно работают с такими операциям как «вытащить все записи», поэтому может оказаться эффективней вытаскивать записи по имеющимся идентификаторам. Наверняка это можно делать не по одному запросу на каждую запись, а пачками (batch get), по несколько идентификаторов за раз. Или, если идентификаторы упорядочены, использовать scan.

Добавлено через 5 минут
Ты же не будешь вытаскивать все записи, когда в базе их будет не 10млн, а 10млрд или 10трлн?

0

@xoraxax

select ... where id in (лист, который приходит)

0

@florgas

Ну одно сделать один объемный запрос к базе, а другое сделать 10.000 запросов к базе.
Каковы результаты с точки зрения оптимизации?

0

@korvin_

Да, это разные дела. HBase и Cassandra, например, плохо и медленно делают «один объёмный запрос», но хорошо много маленьких.

Результаты таковы: пишешь бенчмарки и меряешь.

Добавлено через 5 минут
Ну или попробуй так (обрати внимание на комментарий про setCaching), т.е., делаешь из своего списка ID'шников Set, потом проходишь по таблице, как описано по ссылке, и проверяешь, есть ли ключ из таблицы в твоём Set'е.

0

@KEKCoGEN

Нет смысла вытаскивать все данные если интересует только факт наличия.

Самая простая оптимизация это вытаскивать только ids и затем сравнивать.

Если пойти дальше, можно подумать что в большинстве случаев записи скорее всего будут в БД чем будут отсутствовать, то есть при входных данных размера N, если разделить его на части N/M то с высокой вероятностью каждая часть из N/M будет полностью присутствовать в БД. Таким образом можно делать запрос на count(id) where id in(part_list) и сравнивать счетчик с размером листа. Если он одинаковый, проходим дальше, если нет, запускаем либо бинарный поиск (само собой должна быть сортировка по id) либо селектим все ids (тут можно померять что быстрее).


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

0