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

Question

Наше приложение работает в Интернете, в основном это инструмент запросов, выполняет некоторые транзакции. Мы размещаем базу данных Oracle. В приложении всегда был свой экземпляр Oracle для каждого клиента. клиент - это компания, которая платит нам за предоставление наших услуг сотрудникам компании, обычно от 10 000 до 25 000 сотрудников на клиента. Мы намерены иметь несколько сотен клиентов. Мы выпускаем основной выпуск каждые несколько лет, и переход на этот новый выпуск сопряжен с трудностями: у нас может быть команда на сайте клиента в течение пары недель, объясняющая новые функциональные возможности и настраивающая движущие данные для удовлетворения этого клиента.

Мы рассматриваем возможность использования нескольких клиентов, объединяя всех наших клиентов в единый общий экземпляр Oracle 11g на большом сервере Windows Server 2008, чтобы сократить расходы. Мне интересно, если это желательно.

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

• Наши клиенты MyCorp и YourCo могут переноситься отдельно, если в схему вносятся критические изменения. (С помощью мультиклиента мы будем мигрировать более 300 клиентов за одну ночь!?!)

• Данные MyCorp могут быть легко скопированы и (!!!) восстановлены, не затрагивая других клиентов.

• Данные MyCorp надежно отделены от данных вашего конкурента YourCo, при этом разработчики не могут получить правильный код и / или администраторы баз данных получают правильную конфигурацию.

• Несколько экземпляров имеют меньший риск, потому что авария с одним клиентом (кто-то случайно удваивает зарплату каждого, и ошибка обнаруживается после дня оплаты) не влияет на других клиентов. Бедствие, которое затронуло ВСЕХ наших клиентов (упс, новый администратор БД, и внезапно у каждого участника был такой же SSN!?!), Может поставить нашу компанию под угрозу.

• Наличие одного экземпляра на одном сервере представляет собой единую точку отказа, и вся наша клиентская база не работает, если ураган обрушит здание. Несколько экземпляров на нескольких серверах допускают географическое рассредоточение: никакая катастрофа не затронет слишком большую долю наших клиентов, а незатронутые серверы в других регионах могут взять на себя нагрузку отказавших серверов.

• Производительность лучше, потому что база данных меньше (10 000 против 2 000 000 строк в ~ 50 таблицах).

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

• В MyCorp хочет взять их базу данных внутри себя, тогда мы можем легко экспортировать их экземпляр, чтобы получить MyCorp их данные.

• Балансировка нагрузки проще, поскольку экземпляры можно размещать на разных серверах (это относится к веб-ферме).

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

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

Q1: Каковы другие преимущества отдельных экземпляров?

Мы планируем изменить схему базы данных и объединить всех наших клиентов в один экземпляр Oracle, работающий на одном здоровенном сервере.

Вот преимущества подхода, основанного на нескольких клиентах, в первую очередь (мой WAG). Пожалуйста, отрежьте, если это фальшивка:

• Меньше работы для администраторов баз данных, поскольку им нужно поддерживать только один экземпляр вместо сотен. Меньше работы DBA переводит на более дешевый, наш главный мотив для этого изменения.

• Имея всего один экземпляр, администраторы баз данных могут лучше оптимизировать производительность. У них будет время, чтобы добавить соответствующие индексы и просмотреть наш SQL.

• Разработчикам будет легче отлаживать и улучшать приложение, потому что существует только одна схема и одно приложение (могут быть десятки версий схемы, если есть сотни экземпляров, с другой версией приложения). для каждой версии схемы). Это также снижает затраты. Альтернативой является запуск каждого сеанса отладки с (1) какой версией работает этот клиент и (2) давайте изо всех сил попытаемся воссоздать соответствующую среду разработки, код и базу данных. (Нам нужна виртуальная машина, которая включает код и экземпляр базы данных для каждого исправления и выпуска!)

• Лицензирование Oracle обходится дешевле, потому что он платится за сервер независимо от кражи (или чего-то еще - я ничего не знаю по этому вопросу).

• База данных становится жизнеспособным постоянным хранилищем данных веб-сеанса, поскольку существует только один экземпляр.

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

Q2: Каковы другие преимущества наличия нескольких клиентов в одном экземпляре?

Q3: Какой подход, по вашему мнению, лучше (почему)? Экземпляр на одного клиента или всех клиентов в одном экземпляре?

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

... если не существует компромиссного решения, такого как наличие двух мультиклиентских экземпляров, старого и нового. В этом случае мы разработали бы решения для нескольких экземпляров для поиска участников, создания отчетов и т. Д., Чтобы клиенты могли переходить от одного экземпляра с несколькими клиентами к другому без каких-либо проблем.

Answer 1

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

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

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

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

Answer 2

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

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

http://blog.dayspring -tech.com / 2009/02 / forcecom-Многоквартирный-архитектуры из-под крышки /

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

Answer 3

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

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

По данным магазина Oracle,

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

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

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