Обработка связи mysql db

Question

Я работаю над высокопроизводительным приложением реального времени, с node.js и mysql в качестве backend.

Чтобы увеличить производительность, у меня есть отдельное обновление процесса node.js, лежащее в основе mysql bd. Запросы обновления отправляются в очередь для гарантии выполнения последовательности (обязательно).

Я думаю о постоянном открытии соединения db в этом процессе, чтобы не терять время при его открытии по каждому запросу.

Другие DB-запросы (обновления или чтения) обслуживаются непосредственно из экземпляра узла-сервера web-сервера, возможно, параллельно. Эти db-соединения, конечно, создаются/освобождаются в каждом запросе.

Вы видите некоторые минусы этого подхода?

UPDATE:

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

логика, которая должна быть выполнена до того, как каждое обновление будет относительно сложным и зависит от структуры данных в базе данных. Перед каждым обновлением потребуется несколько дополнительных запросов. Этот автономный процесс имеет полную структуру данных в памяти и может выполнять эти проверки очень быстро и без доступа к db (повышение производительности).

Answer 1

Другой подход к вашему подходу.

MySQL известен тем, что закрывает соединения, которые были открыты в течение длительного времени на основе тайм-аутов.

Lost connection to MySQL server during query

@duffymo правильно: с помощью коротких долгоживущих соединений из пула гораздо более вероятно, продолжать работать в течение сотен часов, чем давно открыл соединение.

node.js + mysql connection pooling

Интересно: вы говорите, что последовательное выполнение является обязательным. Крупномасштабные СУБД (в том числе MySQL на большом сервере) очень компетентны при обработке одновременных запросов из нескольких соединений без искажения данных. Вероятно, ваша система будет более надежной, если вы сможете точно определить, что является обязательным в отношении последовательности ваших обновлений. Если вы можете реализовать эту последовательность в самом SQL или, возможно, в некоторых транзакциях, у вас будет более отказоустойчивая система, чем если бы вы настаивали на том, чтобы только один процесс выполнял обновления. Одноцелевые процессы, подобные тем, которые вы упоминаете, нелегко отлаживать в системном тесте: они известны тем, что после нескольких сотен часов по всем причинам.Когда они терпят неудачу в производстве, все вскакивают, чтобы восстановить их, поэтому никто не успевает их устранить.

Answer 2

Я вижу минусы.

Сделки являются крупнейшими. Что произойдет, если UPDATE завершится с ошибкой? Вы откатываетесь и повторите попытку? Вернуть сообщение в очередь?

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

Я бы рекомендовал посмотреть на vert.x вместо node.js. Это node.js для JVM. Он использует неблокирующий ввод-вывод и кольцевую буферную шину для обеспечения последовательных и быстрых операций.