Мудрость объединения сотен экземпляров Oracle в один экземпляр

Если вы не используете Oracle XE (ограниченную бесплатную версию), наличие одной базы данных на сервере очень быстро станет очень дорогим, даже если вы покупаете одноядерные однопроцессорные блоки. Наличие нескольких баз данных на сервере неэффективно, так как каждая база данных влечет за собой дополнительную нагрузку на ЦП и ОЗУ. Настройка более сложная, потому что конкуренцию труднее диагностировать.

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

Рассмотрите возможность создания разделов, если вы можете себе это позволить. Это решит ваши проблемы с резервным копированием и восстановлением, поскольку каждый раздел может иметь собственное табличное пространство. Таким образом (с учетом разделения по client_id) становится возможным резервное копирование или восстановление данных отдельного клиента, не затрагивая других клиентов. Мы даже можем экспортировать и импортировать отдельные разделы. Я удивлен наблюдением Дэвида о том, что обрезка разделов не работает с VPD. Но я не пробовал это сочетание, так что поверю ему на слово.

Единственное, что вы можете потерять в результате консолидации, — это возможность поддерживать разных клиентов в разных версиях вашего приложения. Однако это не обязательно плохо. Как вы заметили, поддерживать несколько сотен клиентов будет намного проще, если вы откажетесь от индивидуальных версий приложения. Если вам нужно предложить некоторые специальные функции — даже если вы просто хотите провести бета-тестирование некоторых функций с отдельным клиентом — загляните на Переопределение на основе редакции в 11gR2: это действительно отличная функция. Также он доступен для всех лицензий Oracle, а не только для Enterprise.

Когда вы говорите «отдельные экземпляры», вы говорите об одном экземпляре с несколькими схемами? Или вы действительно имеете в виду несколько экземпляров, работающих на одной машине? Нет особых причин запускать несколько экземпляров на одном компьютере, в отличие от запуска нескольких схем на одном экземпляре — каждая схема по-прежнему будет иметь свой собственный набор таблиц, индексов и т. д.

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

Согласно магазину Oracle,

• Одна стандартная версия Oracle стоит 5 800,00 долларов США за процессор (где на x86 процессор — это сокет, и вы можете использовать до 2 сокетов).
• Стандартная версия Oracle стоит 17 500,00 долларов США за процессор (где на x86 процессор — это сокет, и вы можете использовать до 4 сокетов).
• Корпоративная версия Oracle составляет 47 500,00 долларов США за процессор (где на x86 процессор составляет 2 ядра, поэтому вам нужно фактически удвоить эту цену для четырехъядерных процессоров).

Так что, если, например, вам нужно 8 четырехъядерных процессоров для обслуживания 100 клиентов, лицензирование для одной базы данных будет ЗНАЧИТЕЛЬНО дороже, чем иметь 4 отдельные базы данных, каждая из которых имеет 2 четырехъядерных процессора, каждая из которых работает с 25 клиентами.

Для 8 четырехъядерных процессоров требуется корпоративная версия, и их прейскурантная цена будет составлять 16 x 47 500 долларов США = 760 000 долларов США. 4 машины, каждая из которых работает со стандартной версией и каждая с 2 четырехъядерными процессорами, будут иметь прейскурантную цену 8 x 5 800,00 долларов США = 46 400 долларов США — разница в 16 раз. Теперь имейте в виду, что никто не платит за корпоративную версию по прейскуранту, но все же есть огромная разница, которую следует учитывать.

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

Возможно, стоит изучить отдел продаж, и модное слово, которое вы ищете, — «мультитенантная архитектура».

Это делает хорошее чтение:

http://blog.dayspring-tech.com/2009/02/forcecom-multitenant-architecture-under-the-covers/

Это хороший пример, потому что Salesforce негласно использует базу данных Oracle.

Хороший вопрос, рад видеть, что вы рассматриваете все альтернативы. Много хороших моментов, но я остановлюсь только на одном.

Я был администратором базы данных размещенного приложения, и разработчики решили использовать для этого функцию Oracle Virtual Private Database.

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

До VPD у нас был класс Java, который привязывал «where customer_id=?» или "и customer_id=?" по каждому запросу прямо перед тем, как он попадет в базу данных, чтобы клиент мог видеть только свои данные. Чтобы реализовать это в VPD при входе в БД, мы должны установить в приложении переменную в контексте приложения, которая будет использоваться политиками VPD, чтобы сеанс мог видеть только свои записи. Так что да, вы должны правильно запрограммировать его и назначить политики VPD для таблиц, а также верить, что Oracle выполнит свою часть сделки.

Так было ли это хорошо для нас? Теоретически было бы неплохо переложить обработку предикатов SQL на что-то вне нашего приложения, но на практике преимущества не перевесили недостатки.

• Когда у нас были десятки клиентов в одной базе данных, и при обновлении все они должны были обновляться одновременно. У нас было много перетягивания каната с клиентами, которые по какой-либо причине не хотели обновляться или хотели самостоятельно проводить контроль качества новых версий.

• Мы использовали старый экземпляр/новый экземпляр для обновлений, но миграция данных была рискованной, и связанное с этим время простоя не радовало клиентов. Мы развернули нашу собственную процедуру, которая пролистывала таблицы и экспортировала данные... Но, конечно, не так просто, как экспресс-экспорт или задание Data Pump.

• У нас также были проблемы с анализом предикатов VPD, когда дело дошло до секционирования. Как и многие функции Oracle, они могут нормально работать сами по себе, но когда вы объединяете их с другими функциями, все становится непредсказуемым. Для нас разделы, не связанные с текущим идентификатором customer_id, не удалялись, поскольку анализ предикатов выполнялся слишком поздно при обработке оператора SQL. Мы обошли эту проблему, заменив статические политики VPD на динамические, но время, потраченное на синтаксический анализ, увеличилось.

Итак, после всего этого, что я думаю об этом? Я бы потратил время на то, чтобы убедиться, что наше приложение правильно использует переменные связывания, и продолжил бы использовать старый механизм, который добавлял идентификатор клиента в оператор SQL.

Oracle создан для обработки такой нагрузки.

Мой вопрос: Что вы делаете, когда у вас тысяча клиентов, а вы говорите, что десять тысяч?
Вы все еще храните отдельные экземпляры/схемы?

Сомневаюсь, что кто-то будет это делать. Раньше я работал в месте, где у каждого клиента была отдельная база данных, а также копия в центральном месте.
Управление изменениями становится головной болью, вам нужно поддерживать очень хорошую информацию о том, какой клиент/компания находится на каком версия базы данных, схема, версия приложения и все такое. Это стало бы программным обеспечением само по себе.
Я бы предложил создать программное обеспечение/дизайн на основе модели SaaS, что позволит вам легко обслуживать и использовать одну и ту же базу данных/схему для всех пользователей.

Для надежности вы по-прежнему можете использовать кластеризацию — Oracle RAC.

Мне несколько раз приходилось обдумывать одно и то же решение. В нашем случае мы используем MySQL, поэтому размещение всех клиентов в отдельной базе данных не требует затрат.

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

Изменения базы данных могут занять очень много времени в больших базах данных mysql. Поскольку у всех наших клиентов есть собственная база данных, мы можем сохранять все наши наборы данных небольшими. Бэкапы тоже очень быстрые.

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

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

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