Всем привет. У меня есть вопрос касательно MsSQL и миграции, буду

рад услышать ваше мнение.

Допустим, в базе у меня лежат какие-то данные (2 миллиона записей). И в NoSql базе (Redis) лежит 3,5 миллионов записей, причем из них 2 миллиона записей так же деблируются с базой.

Я хочу написать джобу, которая будет переводить остаток (1,5 миллиона записей) в MsSql. Но так как для меня MsSql - зверь неизвестный, я решил обратиться сюда.

Важно отметить, что в редис данные уже не записываются, они могут только удаляться и читаться. А в базу удаляться, читаться и добавляться.

Особенности выборки в MsSql состоит в том, что по дефолту там ставится блокировка (shared lock, если не ошибаюсь). Потому с такими вещами нужно быть осторожным.

Примерный сценарий, по которому хочу построить миграцию:
1. Получить все данные из Redis, замапить их в map’у (это необходимо сделать потому, что без ключей я не смогу дополнить данные для переноса в базу, так они были изначально туда записаны) - ключ по которому данные лежат и сами значения

2. После чего я хочу взять и пройтись итеративно по этой мапке, чтобы собрать нужные INSERT’ы для mssql.

3. Используя jdbc template я хочу выполнить все эти INSERT’ы

Концепция достаточно простая, но кажется, что она не особо рабочая. Во-первым, на втором шаге мне придётся проверять базу (условно говоря выполнять некий database.findAllByParams(…), чтобф вообще понять, есть ли эти данные в базе или нет. Ну и да, сами данные могут удаляться как из Redis’а, так и из базы. Плюс ко всему, если разом попытаться это всё дело мигрировать, то можно просто потерять новые данные, ведь блокировка может усилить контеншон, а значит нужно делать таймауты.

Короче, как вы думаете, есть ли смысл как-то двигаться в эту сторону? Или проще завести третью таблицу в базе и не рисковать? Ну и да, для третьей таблицы там нужно будет лишь выполнить следующее:
redis data - database data

А какой размер одной записи? Я бы закинул всё из редиса в отдельную табличку/базу на том же экземпляре и сливал все уже внутри SQL server. Shared lock можно убрать с помощью read committed snapshot в свойствах бд - но стоит протестировать, т.к. меняется логика и нагрузка на tempdb возрастает.