Подключение к нескольким базам данных

Question

Я пытаюсь понять, как лучше подключиться к моим базам данных.

На данный момент у меня есть метод, который анализирует URL-адрес (в зависимости от URL-адреса, вызываемого приложением для подключения к другой базе данных, например, customer1.example.com будет подключаться к базе данных customer1) и вызывает

ActiveRecord::Base.establish_connection(conn_string)

где conn_string содержит имя базы данных.

Этот метод (set_db) вызывается с

before_filter :set_db

в моем контроллере приложения, поэтому в основном для каждого полученного запроса URL-адрес анализируется, и приложение пытается выполнить установление соединения.

Мне было интересно, могу ли я где-нибудь иметь пул соединений ... У вас есть какие-либо предложения по этому поводу? Разве лучше иметь Синглтон, который сохраняет все сделанные соединения и возвращает правильное?

Спасибо! Roberto

Answer 1

Базы данных находятся на одном сервере?

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

class xx < ActiveRecord.base

def self.table_name
  "otherdatabase.table"
end

Похоже, что пул баз данных уже готовится к выпуску новой версии rails.

Что нового в Edge Rails

Answer 2

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

Метод анализа URL-адресов реализован вне Rails в конфигурации Apache Rewrite, поскольку несколько хостов могут быть сопоставлены одному клиенту. Также я использую «ключ» клиента для доступа к кэшированным файлам на диске веб-сервера. Переписать конфигурацию выглядит примерно так:

RewriteMap accounts prg:domain_mapper.rb
RewriteMap lowercase int:tolower

RewriteCond %{HTTP_HOST} ^(.*)$
RewriteCond ${accounts:${lowercase:%1}} ^(.+)$
RewriteRule . - [E=ACCOUNT:%1]
RequestHeader set Customer-Key %{ACCOUNT}e

И ключ клиента будет привязан непосредственно к имени базы данных, которое будет подключено в методе before_filter.

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

Я уверен, что вы рассматривали проблемы миграции. В начале не было проблем со схемами баз данных <2000. Сейчас существует> 15 000 клиентских баз данных (и их число растет), поэтому мы объединяем их в небольшое количество сегментированных баз данных.

Answer 3

Сначала касаемо комментария к первому сообщению: ничего не имеет , связанного с ruby. это имеет отношение к дизайну рельсов.

с учетом вышесказанного, вы, вероятно, можете перехватить поведение ActiveRecord :: Base, чтобы сохранить хэш соединений, проиндексированный по ключу (в вашем случае ключом будет имя пользователя), а затем перехватить Estab_connection, чтобы проверить в пуле соединение уже открыт

, что потребует повторного открытия базы ActiveRecord, что делает ваши изменения зависимыми от внутренних компонентов AR.

Answer 4

Я не программист на Ruby, но вообще говоря, пул соединений - хорошая идея. Вы можете сделать этот пул соединений одноэлементным и передавать / возвращать соединения. После восстановления соединения пул может проверить, все ли еще в порядке.

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

Будьте осторожны с временными таблицами, поскольку они принадлежат одному сеансу базы данных. У нас была ошибка, при которой в ситуациях высокой нагрузки мы сталкивались со странными ошибками. Наконец мы вспомнили, что в нашем приложении мы использовали временные таблицы. В ситуации высокой нагрузки соединения с базой данных прерываются и автоматически восстанавливаются объектом соединения, когда код приложения не знает об этом (мы осуществили повторное соединение, но забыли, что в такой ситуации это было проблемой). Временная таблица, которую мы хотели прочитать, исчезла.