Настройка производительности JDBC - setFetchSize

Question

Я пытаюсь разработать микросервис Scala для управления данными для базы данных Oracle. Я использую драйверы JDBC для подключения к нему.

Читая ответы на вопросы о производительности драйвера JDBC по сравнению с .NET, я понял, что одним из наиболее эффективных способов настройки производительности чтения JDBC является установка размера выборки с помощью метода ResultSet.setFetchSize.

Я попытался подключиться к базе данных Oracle, чтобы получить реальные данные для реального бизнес-случая с фиксированным числом записей, возвращаемых БД, и я измерил экспоненциальное поведение прошедшего времени. В частности, выборка 10000 строк из базы данных без установки размера выборки, что приводит к невероятно большому количеству времени выборки, но с указанием размера выборки, превышающего 1000, что приводит к небольшому выигранному времени (примерно 100 мс за 1 с).

Вот мои вопросы по этой теме:

1. Я полагаю, что слишком большое увеличение размера выборки потребовало бы ресурсы для получения небольшого выигрыша, поэтому существует ли даже грубый метод для оценки размера ResultSet до его фактической выборки? Я читал о следующей технике:

   result.last(); result.getRow();

   но это будет означать прокрутку всего ResultSet, и мне было интересно, есть ли хотя бы грубая точная методика для подсчета количества;

2. Я подсчитал, что хороший размер выборки будет составлять 1/10 от количества выбранных записей, но есть ли документированное правило, позволяющее автоматически оценить правильный размер выборки для наибольшего числа случаев?

Answer 1

Пожалуйста, не устанавливайте размер выборки слишком большим, если у вас нет узких мест в сети между приложением и базой данных. Чем больше размер выборки, тем больше памяти используется.

По моему опыту, 1024 - 2048 приведут к лучшей производительности в большинстве случаев. Увидеть https://docs.oracle.com/javase/tutorial/jdbc/basics/retrieving.html обсуждаются некоторые детали, но по умолчанию обычно лучше.

Не пытайтесь получить общее количество строк в наборе результатов, это не лучшая практика.

И, наконец, я хочу отметить, что, основываясь на сотнях тысяч раз оптимизации JVM и jit, узкое место, кажется, никогда не возникает при размере выборки JDBC после того, как вы установили его с 1000-2000, но на производительность SQL , приложения или лимит ресурсов и т. д.