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

Ответ 1

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

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

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

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

Ответ 2

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

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

В соответствии с хранилищем Oracle

• Стандартная версия Oracle - $5,800.00/Процессор (где на x86 процессор - это сокет, и вы можете перейти в 2 сокета).
• Стандартная версия Oracle составляет 17 500 долларов США/процессор (где на x86 процессор - это сокет, и вы можете перейти в 4 сокета).
• Корпоративная версия Oracle составляет 47 500 долл. США/Процессор (где на x86 процессор равен 2 CORES - поэтому вам нужно удвоить эту цену для четырехъядерных процессоров).

Итак, если, например, вам нужно 8 четырехъядерных процессоров для обработки 100 клиентов, лицензирование того, что в одной базе данных VASTLY дороже, чем наличие 4 отдельных баз данных, каждая из которых имеет 2 четырехъядерных процессора, каждый из которых работает 25 клиентов.

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

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

Ответ 3

Возможно, стоит исследовать salesforce, а слово buzz, которое вы ищете, - это архитектура с несколькими арендаторами.

Это хорошо читается:

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

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

Ответ 4

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

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

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

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

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

• Мы развлекали объект Old instance/New instance для обновлений, но перенос данных был рискованным, а связанный с ним простор не делал клиентов счастливыми. Мы выполнили собственную процедуру, которая будет проходить через таблицы и экспортировать данные... Но, конечно, это не так просто, как быстрое или экспортное задание.

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

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