resultSet.next(): извлекает ли данные из буфера или из базы данных?

Question

У меня есть код, как это ниже,

try (Connection connection = this.getDataSource().getConnection(); 
     PreparedStatement statement = connection.prepareStatement(sqlQuery);) { 


     try { 
      statement.setFetchSize(10000); // Set fetch size 
      resultSet = statement.executeQuery(); 

      while (true) { 
       resultSet.setFetchSize(10000); 
       boolean more = resultSet.next(); 
       if (! more) { 
        break; 
       } 
       // populating an arraylist from the value from resultSet 
      } 
     } 
     catch (Exception e) { 
      LOGGER.error("Exception : "+e); 
     } 
    } catch (SQLException e) { 
     LOGGER.error("Exception : "+e); 
    } 

Мое понимание заключается в следующем,

Оператор размер выборки 10000. когда statement.executeQuery() выполняется, она возвращает ResultSet курсор. Он будет иметь 10000 строк в памяти. Когда вызывается resultSet.next, он получает одну строку из буфера памяти. (одна строка за вызов). Когда в памяти больше нет строк, запрос снова запускается, и 10000 строк снова извлекаются из базы данных и сохраняются в буфере. Это продолжается до тех пор, пока ни одна строка будет выбираемые из БД

Так что, если я правильно понимаю, сколько реальных БД вызывает будет там для полных строк 210000? Это 21? (210000/10000)

Также, когда и кто вызывает БД (когда строки в буфере все прочитаны), чтобы получить больше строк (10000, в моем случае) и сохранить в буфере. Также когда очищается буфер?

Пожалуйста, исправьте меня, если я ошибаюсь в своем понимании.

Мне нужно работать с миллионами данных в Oracle Database.

Спасибо за любые советы/Информация

С уважением,

SD

Answer 1

Единственные люди, которые могут ответить на ваш вопрос, являются авторами драйвера Oracle JDBC.

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

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

Об очистке буфера, в основном это область сбора мусора, после того, как вы потеряете ссылку на набор результатов.

Просто убедитесь, что ваше заявление FORWARD ONLY, как по соображениям производительности, так и по памяти.

connection.createStatement(ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);

Answer 2

Извините, но ваше понимание является неправильным. Нет такой вещи, как «запрос увольняется снова».

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

Таким образом, насколько клиент может сказать, как только он отправил запрос на сервер, задержка сервера пока задумывается, после чего строки становятся доступными со скоростью, которая обычно равна быстро, поскольку провод может нести их. Таким образом, клиент начинает читать эти строки с resultSet.next().

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

С буферизацией первый звонок resultSet.next() запросит кучу строк с сервера. Это наложит штраф на время получения первой строки, потому что вам придется ждать 100 строк, которые будут отправляться по проводу, но в конечном итоге это значительно сократит общие сетевые издержки, потому что будет только один раунд между клиентом и сервером на каждую строку.

Идеальная стратегия для resultSet.setFetchSize() заключается в том, чтобы оставить ее такой, какой она есть, и не слишком беспокоиться об этом.

Но если вы параноик в отношении производительности, то хорошей стратегией было бы начать с довольно небольшого размера выборки (скажем, 10), чтобы быстро получить свой первый ряд, а затем удвоить его до тех пор, пока он не достигнет определенный максимум (скажем, 100), за которым нет никакого улучшения.