Андрей

Сконвертировать XLS посредством скрипта в SQL пакетами по 50к строк и пулять в базу из консоли.

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

храним в базе, кешируем в редис и основная нагрузка ложится на редис...

Вообще принято в подобных случаях показывать код.

Если через постман все уходит, а из браузера нет, значит проблема в клиентской части. Например, если адрес (урл) клиентской части хоть как-то отличается от серверной части, например порт другой, то будет срабатывать CORS, и нужно сервером слать соответствующие заголовки, чтобы запросы проходили, либо проксировать запросы вебпаком.

Это смотря на чем сервер. Если на Node.JS, то коннектится он при запуске скрипта, а когда получает запрос, то через уже существующий коннект просто сходит в базу, причем, скорее всего, асинхронно, так-что, тут даже лучше будет если не по аяксу данные запрашивать с сервера, а через вебсокеты. Запросил, через какое-то время сервер сам данные пришлет и отработает событие.

Не надо никаких джойнов в данном случае.

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

https://www.youtube.com/watch?v=39e1vAGD3hg
https://www.youtube.com/watch?v=-7sCE6ob70U

ну и т.п.

Я много лет пользуюсь DBSimple Дмитрия Котерова dklab.ru/lib/DbSimple/manual.html
Очень доволен.

А зачем в коде такие конские отступы?

М.б. сессии как-то попробовать использовать для эмуляции сохранения состояния?

ORDER BY на обычных autoincrement ID замечательно работают при наличии индексов даже на миллионах записей... Не вижу причин отказываться от ORDER BY id DESC LIMIT 20

Текстовый файл 2 мб это не так много. Я бы спарсил текстовый файл в отдельную временную таблицу (даже можно in-memory), а потом от нее делал OUTER JOIN на основную, и в тех строках, которые есть в файле, но нет в основной таблице получил бы NULL, по которому и отбирал бы то, что надо дозалить в основную таблицу.

Это более-мене адекватный и производительный способ на мой взгляд.

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

Если же в строках что-то плавает, например регистр символов, то перед вычислением хэша строки надо приводить к единому виду. Причем в таблицах помимо хэшей хранить можно и оригинальные строки, тут вопрос только о вариантах сравнения.

Я бы тоже делал онлайн приложение, сегодня для этого существуют все необходимые возможности.