Каков наилучший способ сделать мультитенант с помощью узла / экспресс / mysql? - PullRequest
0 голосов
/ 19 апреля 2020

Я хотел бы создать приложение SaaS с мультитенантным сервером следующим образом:

  • 1 база данных для всех клиентов
  • 1 узел / express сервер для все клиенты
  • разделяют данные клиентов, используя поле tenant_id во всех соответствующих таблицах

Прочитав различные обсуждения / форумы / статьи, я думаю, что у меня есть только 2 варианта:

  1. найти какой-то ORM, который гарантирует, что во всех моих запросах всегда есть предложение tenant_id=XXX WHERE, без риска его забыть.
  2. найти способ использовать MySQL view для каждого table, который выполняет эту фильтрацию.

Однако у меня есть проблемы для обоих вариантов ...

  1. Я пробовал Sequelize и сталкиваются с проблемами со сложными запросами, которые ведут себя плохо. Я также посмотрел на Objection.js и Knex, но не смог определить, смогли ли они систематически добавлять предложение WHERE для фильтрации на tenant_id.
  2. . Я хотел бы найти способ дать параметр арендатора при запросе представлений, но это кажется невозможным, за исключением глобальных MySQL переменных. Таким образом, я думаю, что вещи могут быть ошибочными, если 2 запроса для 2 разных клиентов происходят одновременно. Другой вариант - создать представление для каждой таблицы И для каждого клиента, но я нахожу это довольно тяжелым и сложным в обслуживании. Особенно, если мне нужно добавить поле в таблицу, мне придется перестроить все представления, связанные с этой таблицей. Кроме того, я не знаю, как сохранить 100 подключений к базам данных на сервере, если одновременно открыто 100 клиентских сессий (рекомендуется ли это делать?)

Может ли пожалуйста, помогите мне с рекомендациями и / или инструментами?

И, между прочим, я также пытаюсь добиться контроля версий моей базы данных MySQL, как и для моего кода JavaScript, но я Пока что не удалось найти что-то замечательное, так как это может быть связано с некоторыми функциями ORM, пожалуйста, дайте мне знать! Моя основная цель заключается в том, чтобы убедиться, что я изменяю производственную базу данных точно так же, как база данных разработки (и не забудьте, например, добавить поле в производство).

Редактировать: решение, указанное в Могу ли я создать представление с параметром в MySQL? здесь не работает, потому что переменная p1 впоследствии сохраняет свое значение. Поэтому я должен подумать о том, чтобы сбрасывать его после каждого запроса, но риск, который я забыл, велик. И если я забуду, последствия будут даже хуже, чем бездействие: один клиент увидит данные другого клиента.

1 Ответ

0 голосов
/ 19 апреля 2020

Каждый многопользовательский веб-сайт в мире использует свой вариант идентификатора клиента. Нет магий c, чтобы предотвратить ошибочный доступ пользователей к данным друг друга.

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

A Стратегия тестирования и валидации: зарезервируйте некоторые значения идентификаторов и заполните ваши таблицы ложными строками с этими зарезервированными значениями. Затем добавьте утверждения в свой код доступа к данным, которые заставят ваши программы громко жаловаться, если они когда-либо сталкиваются с этими зарезервированными значениями. Не просто зарезервируйте значения 0 и 1.

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

Проблема с контролем исходного кода для определений СУБД заключается в следующем: вы создадите свое производство столы только один раз. Они могут длиться несколько десятилетий. А если их воссоздать с нуля по ошибке, вы отключите вас, пока вы восстановите резервные копии.

pro tip выяснит, как вы будете обрабатывать часовые пояса, прежде чем начинать помещать данные в таблицы. Я застрял с данными, где все время на востоке США. Если бы они были в UT C, жизнь была бы проще.

...