Чи можна було б мати кілька пулів підключення до бази даних в рейках для перемикання між ними?

Трохи фону

Я вже багато років використовую дорогоцінний камінь для запуску програми для багаторічної оренди. Зараз нещодавно з'явилася необхідність масштабувати базу даних на окремих хостах, сервер db просто більше не може йти в ногу (і читання, і запис стає занадто багато) - і так, я розширив обладнання до максимуму (присвячений апаратне забезпечення, 64 ядра, 12 Nvm-e накопичувачів у рейді 10, 384 Гбіт та ін.).

Я розглядав можливість зробити це для кожного орендаря (1 орендар = 1 конфігурація / пул підключення до бази даних), як це було б "простим" та ефективним способом отримати до- number-of-tenantsраз більше можливостей, не роблячи навантажень змін коду програми.

Зараз я бігаю по рейках 4,2 атм., Скоро переходжу до 5.2. Я можу бачити, що рейки 6 додають підтримку визначень підключення для кожної моделі, однак це насправді не те, що мені потрібно, оскільки у мене є повністю дзеркальна схема бази даних для кожного з моїх 20 орендарів. Як правило, я перемикаю "базу даних" за запитом (в середньому програмному забезпеченні) або за фоновим завданням (додаткове програмне забезпечення sidekiq), однак це в даний час банально і обробляється між дорогоцінним каменем, оскільки він просто встановлює значення search_pathPostgresql і насправді не змінює фактичне з'єднання. При переході на стратегію хостингу для орендарів мені потрібно буде переключити все з'єднання за запитом.

Запитання:

1. Я розумію, що я можу виконати ActiveRecord::Base.establish_connection(config)запит / фонову роботу - однак, як я також розумію, це запускає абсолютно нове рукостискання з підключенням до бази даних і новий пул db для нерестування в рейках - так? Я думаю, що це було б самогубство, яке зробило б таке накладне на кожен запит на мою заяву.
2. Тому мені цікаво, чи може хтось побачити варіант з рейками, наприклад, попередньо встановивши декілька (всього 20) підключень / пулів до бази даних (спочатку під час завантаження програми), а потім просто переключитися між цими пулами за запитом? Так що з'єднання db вже зроблені та готові до використання.
3. Чи все це лише погана погана ідея, і чи варто замість цього шукати інший підхід? Наприклад, 1 екземпляр програми = одне конкретне підключення до одного конкретного орендаря. Або щось інше.

Як я розумію, для додатків для багаторічних найменувань існує 4 схеми:

1. Виділена модель / Кілька виробничих середовищ

У кожному екземплярі або екземплярі бази даних повністю розміщені різні програми орендарів, і нічого не ділиться між орендарями.

Це додаток на 1 екземпляр та 1 базу даних для 1 орендаря. Розробка була б легкою, як якщо б ви обслуговували лише 1 орендаря. Але буде кошмаром для коханих, якщо у вас, скажімо, 100 орендарів.

2. Фізична сегрегація орендарів

Додаток 1 екземпляра для всіх орендарів, крім 1 бази даних для 1 орендаря. Це те, що ви шукаєте. Ви можете використовувати ActiveRecord::Base.establish_connection(config)або використовувати дорогоцінні камені, або оновлювати до Rails 6, як інші пропозиції. Дивіться відповідь (2) нижче.

3. Ізольована модель схеми / Логічні розділення

В Ізольованій схемі таблиці орендарів або компоненти бази даних є груповими під логічною схемою або простором імен і відокремлені від інших схем орендаря, однак схема розміщується в одному екземплярі бази даних.

Додаток на 1 примірник та 1 базу даних для всіх орендарів, як ви робите з дорогоцінним каменем.

4. Частково ізольований компонент

У цій моделі компоненти, які мають загальні функціональні можливості, поділяються між орендарями, тоді як компоненти з унікальними або непов'язаними функціями є ізольованими. На рівні даних загальні дані, такі як дані, що ідентифікують орендарів, групуються або зберігаються в одній таблиці, тоді як конкретні дані орендаря ізольовані на рівні таблиці чи екземпляра.

Що стосується (1), ActiveRecord::Base.establish_connection(config)не рукостискання до db за запит, якщо ви правильно його використовуєте. Ви можете перевірити тут і прочитати весь коментар тут .

Що стосується (2), якщо ви не хочете використовувати establish_connection, ви можете використовувати дорогоцінний камінь мультивселенной (він працює на рейки 4.2), або інші дорогоцінні камені. Або, як передбачають інші, ви можете оновити до Rails 6.

Редагувати: Використовується мультисерверний самоцвіт establish_connection. Він додастьdatabase.yml і створить базовий клас, щоб кожен підклас поділяв однакове з'єднання / пул. В основному, це зменшує наші зусилля для використання establish_connection.

Щодо (3), відповідь:

Якщо у вас не так багато орендарів, і ваша заявка є досить складною, пропоную скористатися схемою виділеної моделі. Таким чином, ви використовуєте один екземпляр програми = одне конкретне підключення до одного конкретного орендаря. Не потрібно робити додатки складнішими, додаючи кілька підключень до бази даних.

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

У будь-якому випадку вам потрібно оновити / переписати свою програму, щоб відповідати новій архітектурі.

Як я розумію, (2) має бути можливим з ручним перемиканням підключення в рейках 6.

Буквально пару днів тому було додано горизонтальне заточування до Ruby на masterгілці Rails на GitHub. Наразі ця функція офіційно не випущена, але залежно від версії програми Rails у вашій програмі ви можете розглянути можливість використання Rails master, додавши це до свого Gemfile:

gem "rails", github: "rails/rails", branch: "master"

Завдяки цій новій функції ви можете скористатися пулом підключення до бази даних Rails та переключити базу даних на основі умов.

Я не використовував цю нову функцію, але це здається досить прямим:

# in your config/database.yml
production:
  primary:
    database: my_database
    # other config: user, password, etc
  primary_tenant_1:
    database: tenant_1_database
    # other config: user, password, etc

# in your controller for example when updating a tenant
ActiveRecord::Base.connected_to(shard: "primary_tenant_#{tenant.database_shard_number}") do
  tenant.save
end

Ви не додали багато деталей про те, як визначити номер орендаря або як проводиться авторизація у вашій заяві. Але я б спробував якомога швидше визначити кількість орендаря application_controllerв приміщенні around_action. Щось подібне може бути відправною точкою:

around_filter :determine_database_connection

private

def determine_database_connection
  # assuming you have a method to determine the current_tenant and that tenant
  # has a method that returns the number of the shard to use or even the 
  # full shard identifier
  shard = current_tenant.database_shard # returns for example `:primary_tenant_1` 

  ActiveRecord::Base.connected_to(shard: shard) do
    yield
  end
end