Sabedoria de fusão 100s de instâncias do Oracle em uma instância

Question

Nosso aplicativo é executado na web, é principalmente uma ferramenta de investigação, faz algumas transações. Nós hospedar o banco de dados Oracle. O aplicativo sempre teve uma instância diferente do Oracle para cada cliente. Um cliente é uma empresa que nos paga para prestar nossos serviços para os funcionários da empresa, tipicamente 10,000-25,000 funcionários por cliente. Pretendemos ter várias centenas de clientes. Fazemos um grande lançamento a cada poucos anos, e migrar para esse novo lançamento é um desafio: nós poderíamos ter uma equipe no local do cliente por algumas semanas, explicando a nova funcionalidade e configurar os dados de condução às esse cliente.

Estamos pensando em ir multi-cliente, colocando todos os nossos clientes em uma única instância Oracle 11g compartilhada em um grande Honkin' servidor Windows Server 2008 - a fim de reduzir custos. Eu estou querendo saber se isso é aconselhável.

Existem algumas vantagens em ter instâncias separadas para cada cliente. Diga-me se estes são falsos, por favor. Na minha estimativa aproximada sobre a importância decrescente:

• Nossos clientes MyCorp e SuaEmpresa podem ser migrados separadamente quando alterações significativas são feitas para o esquema. (Com multi-cliente, que estaria migrando mais de 300 clientes durante a noite!?!)

• Os dados de mycorp podem ser facilmente copiados e (!!!) restaurado, sem afetar outros clientes.

• Os dados de MyCorp está bem separada do seu concorrente de dados do SuaEmpresa, sem depender de desenvolvedores para obter o direito de código e / ou DBAs recebendo o direito de configuração.

• Várias instâncias são menor risco, porque um desastre com um cliente (alguém acidentalmente duplica o salário de todos e o erro é descoberto após dia de pagamento) não afeta outros clientes. Um desastre que afetou todos os nossos clientes (whoops, nova DBA, e de repente, cada participante tem a mesma SSN!?!) Pode colocar a nossa empresa abaixo.

• Ter uma instância em um servidor apresenta um ponto único de falha, com toda a nossa base de clientes fora do negócio se um furacão bate a construção de mais. Várias instâncias em múltiplos servidores permite dispersão geográfica:. Nenhuma catástrofe vai afetar uma proporção muito grande de nossos clientes, e os servidores não afetados de outras regiões podem assumir a carga dos servidores falharam

• O desempenho é melhor porque o banco de dados é menor (10.000 vs 2.000.000 linhas em ~ 50 mesas).

• Se os escritórios da mycorp são (principalmente) em apenas uma região, então instância do MyCorp pode ser geograficamente co-localizado lá, então lag rede não desempenho ferido. Nós podemos fornecer um melhor serviço aos clientes globais, pela mesma razão.

• Em MyCorp quer levar seu banco de dados in-house, então podemos facilmente exportar seu exemplo, para obter mycorp seus dados.

• o balanceamento de carga é mais fácil porque instâncias podem ser colocados em servidores diferentes (isso é com uma fazenda web).

• Quando é necessário um DEV ou instância QA, é mais fácil de clonar o exemplo real e anônimos os dados, porque há muito menos dados.

• Porque eles são pequenos o suficiente, os desenvolvedores podem ter sua própria instância em execução localmente, para que eles possam trabalhar em código enquanto espera no aeroporto e durante o vôo, sem lutar aborrecimentos VPN.

Q1:? Quais são as outras vantagens de instâncias separadas

Estamos contemplando alterar o esquema de banco de dados e fundindo todos os nossos clientes em uma instância Oracle, rodando em um servidor robusto.

Aqui estão as vantagens da abordagem instância multi-cliente, mais importante primeiro (meu WAG) Por favor, snipe se estes são falsos:.

• Menos trabalho para os DBAs, uma vez que só precisa manter uma instância em vez de centenas. Menos DBA trabalho se traduz em mais barato, o nosso principal motivo para esta mudança.

• Com apenas um exemplo, os DBAs podem fazer um trabalho melhor de optimizidesempenho ng. Eles vão ter tempo para adicionar índices apropriados e rever o nosso SQL.

• Será mais fácil para os desenvolvedores a depurar e melhorar a aplicação, porque há apenas um esquema e um aplicativo (pode haver dezenas de versões de esquema se existem centenas de casos, com uma versão diferente do aplicativo para cada versão do esquema). Isso reduz os custos também. A alternativa é ter que começar cada sessão de depuração com (1) Qual versão é este cliente em execução e (2) Vamos luta para recriar o correspondente ambiente de desenvolvimento, código e banco de dados. (Nós precisamos de uma máquina virtual que inclui a instância de código e banco de dados para cada patch e lançamento!)

• Licenciamento Oracle é mais barato porque é fixado o preço por servidor, independentemente do peso (ou algo - Eu não sei nada sobre o assunto).

• O banco de dados torna-se um armazenamento persistente viável para os dados da sessão web, porque não é apenas um exemplo.

• Algumas operações de banco de dados são mais fáceis com uma instância multi-cliente, como encontrar um participante quando eles estão nebuloso sobre qual cliente que eles (ou seu cônjuge, talvez) trabalha para: todos os nomes estão em uma tabela. Relatórios em clientes é simples.

Q2:? Quais são as outras vantagens de ter múltiplos clientes em uma instância

Q3: Que abordagem você acha que é melhor (porque)? Instância por cliente, ou todos os clientes em um exemplo?

Estou preocupado que ter uma instância multi-cliente faz a migração quase impossível, e isso é um assassino do negócio ...

... a menos que haja uma solução de compromisso como ter dois casos multi-cliente, o velho eo novo. Nesse caso caso, gostaríamos de projetar soluções de cross-instância para encontrar participantes, relatórios, etc. para que os clientes podem ir de uma instância multi-cliente para o outro sem quebrar nada.

Answer 1

A menos que você estiver usando o Oracle XE (a edição limitada, livre) que possui um banco de dados por servidor vai ficar muito caro muito rapidamente, mesmo se você está comprando de núcleo único, caixas de CPU individuais. Tendo vários bancos de dados por servidor é ineficiente, porque cada banco de dados incorre em uma sobrecarga de CPU e RAM. Sintonia é mais difícil, porque a disputa é mais difícil de diagnosticar.

Assim, além de ser mais fácil de administrar, uma única grande servidor deve trabalhar para fora mais barato do que muitos servidores pequenos discretas (sem garantias, sem dinheiro de volta!). Certifique-se de comprar os maiores chips, mais rápido que puder e mais memória RAM quanto você tem slots livres. Essas são as coisas que lhe dão um melhor desempenho sem afetar seus custos de licenciamento.

Considere a opção de particionamento, se você pode pagar. Isto irá resolver as suas preocupações sobre backup e recuperação, porque cada partição pode ter o seu próprio espaço de tabela. Então (dado particionamento por client_id) torna-se possível fazer backup ou restaurar dados de um cliente individual sem afetar os outros clientes. Podemos até mesmo exportar e importar partições individuais. Estou surpreso com a observação de David que Partition poda não trabalhar com VPD. Mas eu não tentei esta combinação, então eu vou levar sua palavra para ela.

A única coisa que você pode perder de consolidação é a capacidade de suportar diferentes clientes em diferentes versões do seu aplicativo. No entanto, isso não é necessariamente uma coisa ruim. Como você observar, a manutenção de várias centenas de clientes será muito mais fácil se você abrir mão de versões individualizadas da aplicação. Se você precisa oferecer alguma bespoke recursos - mesmo se você só quer testar a versão beta algumas funcionalidades com um cliente individual - em seguida, ter um olhar para Edição Baseada Redefinition em 11gR2 : é um recurso muito bacana. Também está disponível para todas as licenças da Oracle, e não apenas da empresa.

Answer 2

Quando você diz 'instâncias separadas', você está falando uma instância com vários esquemas sobre ele? Ou você realmente várias instâncias médias em execução em uma única máquina? Há pouca razão para executar várias instâncias em uma única máquina, ao invés de executar vários esquemas em uma única instância - cada esquema ainda teria seu próprio conjunto de tabelas, índices, etc

.

De qualquer forma, eu não tenho uma resposta completa, mas uma coisa a ter em mente é os custos de licenciamento da Oracle, e como isso pode afetar o que a melhor solução é.

De acordo com a loja Oracle,

• A Oracle Standard Edition é $ 5.800,00 / Processor (onde em x86, um processador é um socket, e você pode ir para cima 2 soquetes)
• A Oracle Standard Edition é de R $ 17.500,00 / Processor (onde em x86, um processador é um socket, e você pode ir para cima 4 sockets)
• edição Oracle Enterprise é de US $ 47,500.00 / Processor (onde em x86, um processador é 2 núcleos - então você tem que dobrar efetivamente esse preço para quad core CPUs)

Assim, se, por exemplo, você precisa de 8 CPUs quad core para lidar com 100 clientes, licenciamento que em um único banco de dados é muito mais caro do que ter 4 bancos de dados separados, cada um com 2 Quad core, cada um rodando 25 clientes.

núcleo 8 quad CPUs requer edição de empresa, e teria um preço de tabela de 16 x $ 47.500 = $ 760.000. 4 máquinas, cada um executando uma edição padrão, e cada um com 2 CPUs Quad-Core, teria um preço de lista de 8 x $ 5.800,00 = $ 46.400 - um fator de 16 diferença. Agora, tenha em mente que ninguém paga preço de lista para edição de empresa, mas ainda há uma enorme diferença a considerar.

Se você não tem uma enorme necessidade de operações de banco de dados em clientes, e você não precisa de recursos Enterprise Edition, e você precisa este nível de potência da CPU (ou esperar crescer precisar desse nível de energia da CPU), os custos de licenciamento vai ser uma enorme desvantagem da abordagem de uma instância.

Answer 3

Pode valer a pena Salesforce pesquisa, e a palavra da moda que você está procurando "Multi arquitetura inquilino"

Isto faz uma boa leitura:

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

É um bom exemplo porque Salesforce fazer usar um db Oracle sob as cobertas.

Answer 4

Boa pergunta, contente de ver que você está considerando todas as alternativas. Lotes de bons pontos, mas vou ater-se apenas abordar um.

Eu era o DBA para um aplicativo hospedado e os desenvolvedores decidiram usar o recurso de banco de dados virtual privada Oracle para isso.

O aplicativo foi construído com a intenção de clientes que compartilham um pool de servidores de aplicativos para balanceamento de carga e um esquema de banco de dados único no back-end.

Antes de VPD tivemos uma classe Java que pregado "onde customer_id =?" ou "e customer_id =?" em cada consulta à direita antes que ela foi para o banco de dados para que o cliente só iria ver os seus dados. Para implementar isso em VPD após o login ot o DB teríamos o aplicativo definir uma variável no contexto aplicativo que seria usado pelas políticas VPD para permitir que a sessão para ver apenas seus registros. Então, sim, você tem que código-lo políticas corretas e atribuir VPD a tabelas, e também a confiança que a Oracle detém a sua parte no trato.

Então, foi bom para nós? Na teoria foi bom para descarregar a manipulação SQL predicado para algo fora da nossa aplicação, mas na prática as vantagens não sobrelevar as desvantagens.

• Quando tivemos dezenas de clientes em um banco de dados e quando nós atualizamos tudo o que tinham para se atualizado ao mesmo tempo. Tivemos muitos cabo-de-guerra com os clientes que não desejam atualizar por qualquer motivo ou queria fazer seu próprio QA nas novas versões.

• Nós entreter o / New coisa instância instância Velho para atualizações, mas os dados que migram era arriscado e tempo de inatividade associado não fazer os clientes felizes. Fizemos rolo de nosso próprio procedimento que percorrer tabelas e dados de exportação ... Mas certamente não é tão fácil como um Export ou Data Pump trabalho rapidinha.

• Nós também teve problemas com análise de predicado VPD quando se tratava de particionamento. Tal como acontece com um monte de recursos do Oracle que podem funcionar bem por conta própria, mas uma vez que você combinar com outras características as coisas ficam imprevisível. Para nós não partições relacionada com a customer_id atual não estavam sendo eliminado porque a análise predicado estava chegando muito tarde no processamento da instrução SQL. Nós trabalhamos em torno dele, alterando de estático para políticas VPD dinâmicos, mas o nosso tempo gasto analisar disparou.

Então, depois de tudo o que o que é a minha opinião sobre isso? Gostaria de ter passado o tempo certificando-se de nosso aplicativo fez bom uso de variáveis ??de ligação e continuou com o antigo mecanismo que customer_id adicionado à instrução SQL.

Answer 5

A Oracle é feito para lidar com esse tipo de carga.

A minha pergunta -? O que você faz quando você tem mil clientes e dizer dez mil
Você ainda manter instâncias separadas / esquema?
Eu duvido que alguém vai fazer isso. Eu tenho trabalhado anteriormente em um lugar onde cada cliente tinha banco de dados separado, bem como uma cópia em um lugar central.
A gestão da mudança torna-se uma dor de cabeça, você tem que manter uma muito boa informações sobre qual cliente / empresa está em qual revisão banco de dados, esquemas, versão do aplicativo e todas essas coisas. This'd tornar-se um software em si.
Eu sugiro para criar software / Projeto baseado em torno do modelo SaaS, que vai permitir que você fácil manutenção e mesmo banco de dados / esquema para todos os usuários.

Para confiabilidade você ainda pode usar o agrupamento - Oracle RAC .

Answer 6

Eu tive a considerar a mesma decisão algumas vezes. No nosso caso, usamos o MySQL, por isso não há custos associados com o funcionamento de todos os clientes em um banco de dados separado.

Os benefícios para a execução de todos os nossos clientes em um banco de dados separado ter sido grande. Nós temos um script que nos permite mover toda instância de um cliente para qualquer servidor a carga de equilíbrio. O script apenas cópias sobre o banco de dados, cópias mais quaisquer arquivos personalizados, gira-se a aplicação, e configura o nosso sistema de roteamento para enviar os usuários para a nova instância. Todo o processo leva apenas alguns minutos.

mudanças de banco de dados pode levar um tempo muito longo em grandes bancos de dados mysql. Uma vez que todos os nossos clientes têm a sua própria base de dados, somos capazes de manter todos os nossos conjuntos de dados de pequeno porte. Backups são também muito rápido.

Os nossos casos de desenvolvimento comportam da mesma maneira, de modo que este método nos permite executar uma variedade de esquemas de banco de dados simultaneamente como desenvolver e testar novos recursos. Nós muitas vezes trabalham com os clientes para tê-los experimentar um novo recurso, antes de implantá-lo para o resto de nossas instâncias. A única regra que nos ater ao (a fim de evitar algumas das desvantagens que você menciona), é que todos os clientes devem estar dentro de uma versão de outro. Manter mais de algumas versões em clientes teria um enorme sobrecarga.

Facebook tomou a mesma abordagem quando eles começaram a sua empresa. Cada escola que eles lançado no tinha um banco de dados separado e eles foram capazes de criar novas instâncias muito rapidamente. A principal razão que eles finalmente consolidou seu banco de dados foi que eles queriam permitir que os usuários se comuniquem entre as escolas.

Se não fosse por questões de custo potenciais Eu definitivamente encorajá-lo a ficar com a abordagem de banco de dados separado.