Цель
Этот вопрос больше об ограничениях / подводных камнях использования ExecuteSQLRecord для больших таблиц.
У меня есть таблицы из десятков миллионов строк, которые должны быть загружены за один прогон, они могут взять около 5-6 ГБ в бинарном формате Nifi. Мне нужно их прочитать и загрузить в облачное хранилище как CSV. Мне также нужно регистрировать количество загруженных строк.
Вопрос
До какого размера набора результатов можно безопасно использовать ExecuteSQLRecord? Есть ли какая-то причина использовать GenerateTableFetch вместо ExecuteSQLRecord + «Размер выходного пакета», кроме параллелизации нагрузки больших таблиц между процессорами?
ExecuteSQLRecord
В одних руках процессор ExecuteSQLRecord и простота. Я могу загрузить набор результатов размером 5-6 ГБ одним блоком, но я боюсь OutOfMemory при чтении и загрузке в облачное хранилище. Особенно при наличии 1-2 ГБ кучи JVM на процессор.
С другой стороны, я могу указать «Размер выходного пакета», но это вызовет другую проблему - вычисление количества строк уже не будет таким тривиальным. . Это немного проще, чем следующий вариант:
GenerateTableFetch + ExecuteSQLRecord
Более сложный вариант. По сравнению с ExecuteSQLRecord + "Размер выходного пакета" он позволяет немного ускорить работу, загружая большие таблицы параллельно между несколькими процессорами. Тем не менее, это вносит дополнительную сложность.