floppa322, извини а какие в бенмарке ты видишь ПУТИ исследования оптимизаций? Просто играться с типами и дождаться что вдруг на каком-то из них будет щастье? Мне кажется что это не инженерный путь.
Мне задача напоминает научпоп. В котором не хватает исходных данных. Это как помните популярную задачу о взлетающем самолёте. Тоесть ее решать на основе знаний физики - бесполезно. Это парадокс. Можно фантазировать и придумывать миры или системы отсчета где эта задача решается и где не решается.
Возможно Армянское Радио прав. И здесь мы просто не можем расплющивать планеты не оперируя сравнением бесконечностей. Это как теория пределов. Или как игры Кантора с бесконечностями. Счетными и не-счетными.
Вот. А чтоб эти бесконечности сравнивать - у нас не хватает исходных данных.
Этот вопрос идет очень глубоко. Слабая контроль над типами в Java был одним из мотиваторов например создания языка Scala. По крайней мере Мартин Одерский в своих лекциях неоднократно ссылается на сравнение контроля типов при создании коллекций.
Википедия цитирует буквально следующее
many of Scala's design decisions are aimed to address criticisms of Java.
Поэтому тема это глубокая. Я советую автору ее не трогать. Просто забить. Воспринимать Java как есть. Есть некоторая видимость контроля типов при использовании Generics. Когда компиллятор видит неверный кастинг - он предупреждает. Вот такой вариант существует на данный момент.
Сама идея создания массива списков - не очень умная идея. Если ты пошел в коллекции - то делай тогда единообразно. Делай List<List<....>>
Такое решение по крайней мере не вызывает вопросов на code-review.
Если ты используешь микс из объектов уровня language и объектов уровня jdk то ты должен
обосновать зачем. Не по причине детского любопытства.
kiddle, что у тебя в тексте? Не вижу... Там надо analyze table [table name]... А для запроса - explain select...
Это первое. И второе. Что меня смущает. Ты уверен что мы воюем именно с select?
У тебя 2 конфигурации на одной из них процесс ETL идет 20 минут а в другой - более суток.
Я здесь вижу что проблемой может быть также insert. Он зависит от многих параметров но
главное - от того destincation куда ты вставляешь 2 млн строк. Всяко тут может быть.
Проверяй эту версию.
И помни что любой SQL запрос select имеет 2 фазы. Первая фаза - это execution. Это пока висят
песочные часы. И второе это fetch - когда БД уже начинает выдавать строки на экран. Новички
часто этого не понимают и считают что им интересен только execution. А в твоей задаче
в миграции строк важны обе фазы. Поэтому твои эксперименты по select должны включать
не визуальную оценку (как только получил 1 page). А ПОЛНЫЙ подсчет всех 2 млн строк.
Это если ты хочешь играться с оптимизацией select.
Ping между New-York и Los-Angelos составляет примерно 70мс. Тоесть у вас еще очень даже неплохие показатели времени. У вас работала база внутри докера. Вот и пускай там работает всегда. У вас архитектура такая. Вы разрабатывали и тестировали исходя из таких вот условий.
Возвращайте все взад как было.
И вам надо думать над архитектурой. Что у вас в запросах. Подумайте над когерентными запросами. Например с одной страницы с одно пользователя будет прилетать все время 3 типа запроса. В одном и том-же порядке. Попробуйте их объединить в батч. Оформить как хранимую функцию и получать сразу все 3 ответа за 1 раз. Тоесть у вас вместо трёх блокирующих TTFB будет один TTFB.
Попробуйте кешировать данные через nginx. В большинстве случаев кеширование является спасением для таких вот нагруженных систем. Кеширование - это компромисс. Какие-то данные будут стареть в кеше. Это расплата.
