Сергей Соловьев

1) Что будет с запросом UPDATE, если исполнение кода ещё не дошло до этого запроса, оно получается будет ещё доступна для запросов из другого кода?

Не понял, что имеется ввиду. Но если это про то - "будут ли видны изменения, которые сделаны до вызова этого UPDATE в транзакции", то это зависит от уровня изоляции других транзакций.
В случае SERIALIZABLE - нет, не увидят.

2) А если функцию sameFunc запустят много юзеров? Получается КАЖДЫЙ юзер будет ждать завершения предыдущих транзакций от всех остальных юзеров?

Так как указана SERIALIZABLE, то да:
- Если конфликтов не будет, т.е. никто не обновлял те же самые записи, то будут ждать
- Если кто-то одновременно обновил одни и те же данные, то будет конфликт транзакции

Стоит еще учесть, что если одна и та же запись обновлена одновременно разными транзакциями, то поздняя транзакция просто заблокируется и будет ждать: либо когда первая закоммит - тогда конфликт транзакции, либо первая выполнит откат и ты продолжишь выполнение
P.S. еще есть таймаут ожидания транзакции

3) А если все запросы в транзакции взаимодействуют только с полями конкретного юзера, то как это нужно реализовать в транзакциях? Вроде как объект транзакции один — сам node.js, который единожды подключается к БД.

А вот тут надо разобраться. Зависит от того как ты работаешь с БД.
Судя по названию ты используешь пул соединений (переменная pool) и каждый раз выполняешь запрос на нем. Я не знаю node.js и фреймворк для БД, который ты используешь, но что-то подсказывает, что на каждый такой .query создается отдельное подключение и выполняется запрос.
Если да, то этот код работать не будет, т.к. ты постоянно открываешь новое соединение, начинаешь транзакцию или запрос и закрываешь соединение. В этом случае, все начавшиеся транзакции завершатся сразу, а запросы, которые должны работать в транзакции будут выполняться сразу.
Чтобы все работало корректно - на каждом вызове этого метода открывай новое соединение и работай с ним. Тогда гонки в коде не будет. (Можно еще использовать пул соединений).

Дополнительно я бы еще реализовал логику повторных попыток выполнения, если был обнаружен конфликт транзакций (проверяй исключение)

1. Для тестирования выделения памяти нужно использовать dotMemory. У него есть отдельный плагин для всяких unit фреймвоков - https://blog.jetbrains.com/dotnet/2018/10/04/unit-...
Единственная проблема - она платная, а других аналогов мне не известно.
2. Нашел репозиторий с кодом для профилирования Unity, но последнее обновление 5 лет назад - https://github.com/donaldwuid/unitymemoryprofilert...
3. У самого Unity есть документация по профилированию памяти, но это не для юнит тестов, а для всего приложения - https://unity.com/how-to/analyze-memory-usage-memo...

Лично я не советую тестировать выделение памяти в юнит тестах. Память надо профилировать в рабочем приложении, когда запущено, собрать данные за несколько часов работы и только тогда станет понятно, какие места надо оптимизировать.
А так - уйдешь в микрооптимизации для кода, запускающегося раз за всю жизнь

Короткий ответ - да.
Длинный -
NoSQL - это обощенное название для всех НЕРЕЛЯЦИОННЫХ БД - ключ-значение (Redis), документо-ориентированные (MongoDB), графовые (Neo4J), семейство столбцов (Cassandra).
Каждая имеет свой язык запросов. Какие-то похожи на SQL (Cassandra имеет схожий синтаксис), какие-то можно превраить в SQL (у Mongo очень похож на SQL, можно сконвертировать простые запросы, как представленный например), другие вообще не похожи (Redis - это просто 1 строка команды в plain text).
Все что нужно - найти способ как транслировать этот SQL запрос в язык для целевой NoSQL.

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

Моя проблема заключалась в изначально неправильном проектировании файловой структуры - было только 2 файла: снапшот и лог.
Спустя время нашел следующее решение:
- Файл снапшота 1 - для его обновления создается временный файл снапшота, который атомарно переименовывается (системный вызов rename атомарный - так прописано в документации)
- Вместо единого файла лога используется сегментированный лог - весь лог хранится в нескольких меньших файлах. Т.е. теперь я работаю с логическим файлом лога, который состоит из нескольких физических сегментов. Сегменты лога не удаляются при создании снапшота - этим может заниматься фоновый поток, который удаляет те сегменты все записи которых по индексу меньше индекса примененной записи в снапшоте.

Так как я использую RAFT, то необходимость в UNDO логе при записи в лог отпадает:
- запись append only, т.е. закоммиченные записи перезаписываться не будут
- лог может быть в несогласованном состоянии только если не до конца будут перезаписаны незакоммиченные записи, но это можно понять по чек-суммам, которые идут после каждой записи (можем откатить лог)

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

В итоге работа со снапшотами будет примерно следующей:
- Добавляем (при необходимости перезаписываем) записи в лог
- Если размер сегмента превысил максимальный, то создаем новый и закрываем старый (работа будет вестить с новым файлом)
- Новый снапшот создаем во временном файле
- Когда снапшот готов, то атомарно вызовом rename перемещаем его в целевой файл (замена)
- Фоновый поток в один момент обнаружит, что есть файлы лога с неактуальными записями и тогда их (старые сегменты лога) удалит

Похожие идеи я нашел в:
- etcd - создание новых файлов сегментов через атомарный rename
- kafka - все записи хранит в xxxxxxx.log файле, где xxxxxxx означает офсет первой записи