Мудрость слияния 100 с экземпляров Oracle в один экземпляр
Наше выполнение приложения в сети, главным образом инструмент запроса, делает некоторые транзакции. Мы размещаем базу данных Oracle. Приложение всегда имело другой экземпляр Oracle для каждого клиента. Клиент является компанией, которая платит нам для предоставления нашей услуги сотрудникам компании, обычно 10 000-25 000 сотрудникам на клиента. Мы намереваемся иметь несколько сотен клиентов. Мы делаем главную версию каждые несколько лет, и мигрирующий, к которому новый выпуск сложен: у нас могла бы быть команда на сайте для клиентов в течение пары недель, объясняя новую функциональность и настраивая ведущие данные для удовлетворения тому клиенту.
Мы рассматриваем идущий мультиклиент, помещая всех наших клиентов в единственный общий экземпляр 11 г Oracle на большом гудящем' сервере Windows Server 2008 - для сокращения затрат. Я задаюсь вопросом, желательно ли это.
Существуют некоторые преимущества для наличия отдельных экземпляров для каждого клиента. Скажите мне, если они являются поддельными. В моем приблизительном подсчете об уменьшающейся важности:
Наши клиенты MyCorp и YourCo могут быть перемещены отдельно при повреждении изменений, сделаны к схеме. (С мультиклиентом мы мигрировали бы 300 + клиенты в течение ночи!?!)
Данные MyCorp могут быть легко сохранены и (!!!) восстановленный, не влияя на других клиентов.
Данные MyCorp надежно разделяются от их данных YourCo конкурента, без в зависимости от разработчиков для разбираний в коде и/или DBAs разбирающийся в конфигурации.
Несколько экземпляров являются более низким риском, потому что авария с одним клиентом (кто-то случайно удваивает общую зарплату и ошибку, обнаружена после дня платы), не влияет на других клиентов. Авария, которая влияла на ВСЕХ наших клиентов (возгласы, новый DBA, и внезапно у каждого участника есть тот же SSN!?!) мог бы поместить нашу компанию под.
Наличие одного экземпляра на одном сервере представляет единую точку отказа с нашей всей клиентской базой из бизнеса, если ураган сваливает здание. Несколько экземпляров на нескольких серверах разрешают географическую дисперсию: никакая катастрофа не будет влиять на слишком большую пропорцию наших клиентов, и незатронутые серверы в других регионах могут взять загрузку неудавшихся серверов.
Производительность лучше, потому что база данных меньше (10,000 по сравнению с 2 000 000 строк в ~50 таблицах).
Если офисы MyCorp находятся (главным образом) во всего одном регионе, то экземпляр MyCorp может быть географически соразмещен там, таким образом, сетевая задержка не повреждает производительность. Мы можем предоставить лучшую услугу глобальным клиентам по той же причине.
В MyCorp хочет взять их внутреннюю базу данных, затем мы можем легко экспортировать их экземпляр, для получения MyCorp их данные.
Выравнивание нагрузки легче, потому что экземпляры могут быть помещены в различные серверы (это с веб-фермой).
Когда экземпляр DEV или QA необходим, легче клонировать реальный экземпляр и анонимизировать данные, потому что существует намного меньше данных.
Поскольку они являются достаточно маленькими, у разработчиков может быть свой собственный экземпляр, работающий локально, таким образом, они могут работать над кодом при ожидании в аэропорту и, в то время как в полете, не борясь со стычками VPN.
Q1: Каковы другие преимущества отдельных экземпляров?
Мы собираемся изменять схему базы данных и объединять всех наших клиентов в один экземпляр Oracle, работая на одном значительном сервере.
Вот преимущества мультиклиентского подхода экземпляра, самого важного первые (мой ВЗМАХ). Стреляйте из укрытия, если они являются поддельными:
Меньше работы для DBAs, так как они только должны поддержать один экземпляр вместо сотен. Меньше работы DBA переводит в более дешевый, наш основной повод для этого изменения.
Со всего одним экземпляром DBAs может сделать лучшее задание оптимизации производительности. У них будет время, чтобы добавить соответствующие индексы и рассмотреть наш SQL.
Для разработчиков будет легче отладить и улучшить приложение, потому что существует только одна схема и одно приложение (могли бы быть десятки версий схемы, если существуют сотни экземпляров с другой версией приложения для каждой версии схемы). Это уменьшает затраты также. Альтернатива должна запустить каждый сеанс отладки с (1) Какая версия является этим клиентом, работающим и (2) Позволяют нам изо всех сил пытаться воссоздать соответствующую среду разработки, код и базу данных. (Нам нужна Виртуальная машина, которая включает код И экземпляр базы данных для каждого патча и выпуска!)
Лицензирование Oracle является более дешевым, потому что это оценено на сервер независимо от, поднимают (или что-то - я ничего не знаю о предмете).
База данных становится жизнеспособным персистентным хранилищем для веб-данных сессии, потому что существует всего один экземпляр.
Некоторые операции базы данных легче с одним мультиклиентским экземпляром, как нахождение участника, когда они являются туманными, о котором клиенте они (или их супруг, возможно) работают на: все имена находятся в одной таблице. Создание отчетов через клиентов просто.
Q2: Каковы другие преимущества наличия нескольких клиентов в одном экземпляре?
Q3: То, какой подход делают Вы думаете, лучше (почему)? Экземпляр на клиента или всех клиентов в одном экземпляре?
Я обеспокоен, что наличие одного мультиклиентского экземпляра делает миграцию почти невозможной, и это - уничтожитель соглашения...
... если нет компромиссное решение как наличие двух мультиклиентских экземпляров, старого и нового. В этом случае случай, мы разработали бы решения перекрестного экземпляра для нахождения участников, создания отчетов, и т.д. таким образом, клиенты могли пойти от одного мультиклиентского экземпляра до следующего ни с чем повреждение.
6 ответов
Если вы не используете Oracle XE (ограниченная бесплатная версия), наличие одной базы данных на сервере очень быстро станет очень дорогим, даже если вы покупаете одноядерные блоки с одним процессором. . Наличие нескольких баз данных на сервере неэффективно, поскольку каждая база данных требует дополнительных затрат на использование ЦП и ОЗУ. Настроить сложнее, потому что разногласия сложнее диагностировать.
Таким образом, помимо простоты администрирования, один большой сервер должен работать дешевле, чем множество отдельных маленьких серверов (без гарантий, без возврата денег!). Убедитесь, что вы покупаете самые большие и быстрые чипы и столько оперативной памяти, сколько у вас есть свободных слотов. Это то, что дает вам лучшую производительность, не влияя на ваши затраты на лицензирование.
Рассмотрите вариант разбиения на разделы, если вы можете себе это позволить. Это решит ваши проблемы, связанные с резервным копированием и восстановлением, поскольку каждый раздел может иметь собственное табличное пространство. Таким образом (с учетом разделения по client_id) становится возможным резервное копирование или восстановление данных отдельного клиента, не затрагивая других клиентов. Мы даже можем экспортировать и импортировать отдельные перегородки. Меня удивило наблюдение Дэвида о том, что сокращение разделов не работает с VPD. Но я не пробовал эту комбинацию, так что верю ему на слово.
Единственное, что вы можете потерять при консолидации, - это возможность поддерживать разных клиентов в разных версиях вашего приложения.Однако это не обязательно плохо. Как вы заметили, поддерживать несколько сотен клиентов будет намного проще, если вы откажетесь от индивидуальных версий приложения. Если вам действительно нужно предложить какие-то специальные функции - даже если вы просто хотите провести бета-тестирование некоторых функций с отдельным клиентом - то взгляните на Переопределение на основе редакции в 11gR2 : это действительно отличная функция. Также он доступен для всех лицензий Oracle, а не только для Enterprise.
Хороший вопрос, рад видеть, что вы рассматриваете все альтернативы. Много хороших моментов, но я остановлюсь только на одном.
Я был администратором баз данных для размещенного приложения, и разработчики решили использовать для этого функцию Oracle Virtual Private Database.
Приложение было создано с намерением, чтобы клиенты совместно использовали пул серверов приложений для балансировки нагрузки и единую схему базы данных на внутренней стороне.
До VPD у нас был класс Java, в котором говорилось, что «where customer_id =?» или "and customer_id =?" по каждому запросу прямо перед отправкой в базу данных, чтобы клиент мог видеть только свои данные. Чтобы реализовать это в VPD при входе в БД, нам нужно, чтобы приложение установило переменную в контексте приложения, которая будет использоваться политиками VPD, чтобы позволить сеансу видеть только их записи. Так что да, вы должны правильно кодировать и назначать политики VPD для таблиц, а также верить, что Oracle выполняет свою часть сделки.
Так это было хорошо для нас? Теоретически было приятно переложить обработку предикатов SQL на что-то за пределами нашего приложения, но на практике преимущества не перевешивали недостатки.
Когда у нас были десятки клиентов в одной базе данных, и когда мы обновляли их, все они должны были быть обновлены одновременно. У нас было много конфликтов с клиентами, которые не хотели обновляться по какой-либо причине или хотели проводить собственный контроль качества новых версий.
Мы использовали вариант «Старый экземпляр / Новый» для обновлений, но перенос данных был рискованным, а связанные с этим простои не порадовали клиентов.Мы разработали нашу собственную процедуру, которая будет проходить по таблицам и экспортировать данные ... Но, конечно, не так просто, как быстрый экспорт или задание Data Pump.
У нас также были проблемы с анализом предикатов VPD, когда дело касалось секционирования. Как и многие функции Oracle, они могут работать нормально сами по себе, но как только вы объедините их с другими функциями, все станет непредсказуемо. Для нас разделы, не связанные с текущим customer_id, не удалялись, потому что анализ предикатов затягивался с обработкой оператора SQL. Мы обошли это, изменив статические политики VPD на динамические, но время, потраченное на синтаксический анализ, резко возросло.
Итак, как я к этому отношусь? Я бы потратил время на то, чтобы убедиться, что наше приложение эффективно использует переменные связывания, и продолжил бы старый механизм, добавляющий customer_id в оператор SQL.
Oracle создан для обработки такой нагрузки.
Мой вопрос - Что вы делаете, когда у вас тысяча клиентов и вы говорите десять тысяч?
Вы по-прежнему храните отдельные экземпляры / схемы?
Я сомневаюсь, что кто-то будет это делать. Раньше я работал в месте, где у каждого клиента была отдельная база данных, а также копия в центральном месте.
Управление изменениями становится головной болью, вам нужно будет хранить очень точную информацию о том, какой клиент / компания использует какую версию базы данных, схему, версию приложения и все такое. Это само по себе превратилось бы в программное обеспечение.
Я бы предложил создать программное обеспечение / дизайн на основе модели SaaS, что позволит вам легко обслуживать и использовать одну и ту же базу данных / схему для всех пользователей.
Для надежности вы все еще можете использовать кластеризацию - Oracle RAC .
Мне приходилось обдумывать одно и то же решение несколько раз. В нашем случае мы используем MySQL, поэтому нет затрат, связанных с запуском всех клиентов в отдельной базе данных.
Запуск всех наших клиентов в отдельной базе данных огромен. У нас есть сценарий, который позволяет нам переместить весь экземпляр клиента на любой сервер для балансировки нагрузки. Сценарий просто копирует базу данных, копирует любые пользовательские файлы, запускает приложение и настраивает нашу систему маршрутизации для отправки пользователей в новый экземпляр. Весь процесс занимает всего несколько минут.
В больших базах данных mysql изменение базы данных может занять очень много времени. Поскольку у всех наших клиентов есть собственная база данных, мы можем сохранить все наши наборы данных небольшими. Резервное копирование также выполняется очень быстро.
Наши экземпляры для разработки ведут себя одинаково, поэтому этот метод позволяет нам одновременно запускать различные схемы базы данных по мере разработки и тестирования новых функций. Мы часто работаем с клиентами, чтобы они опробовали новую функцию, прежде чем мы развернем ее на остальных наших экземплярах. Единственное правило, которого мы придерживаемся (чтобы избежать некоторых из упомянутых вами недостатков), заключается в том, что все клиенты должны находиться в пределах одной версии друг друга. Поддержание более чем пары версий для клиентов потребовало бы огромных накладных расходов.
Facebook применил тот же подход, когда основал свою компанию. Каждая школа, в которой они открывали, имела отдельную базу данных, и они могли очень быстро создавать новые экземпляры. Основная причина, по которой они наконец объединили свою базу данных, заключалась в том, что они хотели дать пользователям возможность общаться между школами.
Если бы не потенциальные проблемы с затратами, я определенно рекомендовал бы вам придерживаться подхода отдельной базы данных.
Возможно, стоит изучить salesforce, и модное слово, которое вы ищете, это «мультитенантная архитектура»
Это хорошо читается:
http://blog.dayspring-tech.com/2009/02/forcecom-multitenant-architecture-under-the-covers/
Это хороший пример, потому что Salesforce использует базу данных Oracle под обложками.
Когда вы говорите «отдельные экземпляры», вы имеете в виду один экземпляр с несколькими схемами? Или вы действительно имеете в виду несколько экземпляров, работающих на одной машине? Нет особых причин запускать несколько экземпляров на одном компьютере, в отличие от запуска нескольких схем на одном экземпляре - каждая схема по-прежнему будет иметь свой собственный набор таблиц, индексов и т. Д.
В любом случае, у меня нет Полный ответ, но нужно иметь в виду стоимость лицензирования Oracle и то, как это может повлиять на оптимальное решение.
По данным магазина Oracle,
- стандартная версия Oracle стоит 5 800 долларов США за процессор (где на x86 процессор представляет собой сокет, и вы можете использовать до двух сокетов)
- Стандартная версия Oracle стоит 17 500 долларов США за процессор. (где на x86 процессор - это сокет, и вы можете использовать до 4 сокетов)
- Корпоративная версия Oracle стоит 47 500 долларов США за процессор (где на x86 процессор - это 2 ЯДРА, поэтому вам нужно эффективно удвоить эту цену за четырехъядерные процессоры)
Так что, если, например, вам нужно 8 четырехъядерных процессоров для обслуживания 100 клиентов, лицензирование одной базы данных ОЧЕНЬ дороже, чем наличие 4 отдельных баз данных, каждая из которых имеет 2 четырехъядерных процессора, каждая из которых работает по 25 клиенты.
Для 8 четырехъядерных процессоров требуется корпоративная версия, и их прейскурантная цена составляет 16 x 47 500 долларов США = 760 000 долларов США. 4 машины, на каждой из которых установлена одна стандартная версия, и каждая с двумя четырехъядерными процессорами CPUS, будут иметь прейскурантную цену 8 x 5800,00 долларов США = 46 400 долларов США - разница в 16 раз. Теперь имейте в виду, что никто не платит прейскурантную цену за корпоративную версию, но все же есть огромная разница, которую следует учитывать.
Если у вас нет огромной потребности в операциях с базой данных на разных клиентах, и вам не нужны функции корпоративной версии, и вам нужен этот уровень мощности процессора (или вы ожидаете роста до этого уровня мощности процессора), Затраты на лицензирование станут огромным недостатком подхода с использованием одного экземпляра.