Os bancos de dados multilocatário têm vários bancos de dados ou tabelas compartilhadas?

É um banco de dados multilocatário:

Um servidor de banco de dados que possui um banco de dados / esquema (idêntico) diferente para cada cliente / inquilino ?; ou
Um servidor de banco de dados que possui um banco de dados / esquema em que clientes / inquilinos compartilham registros dentro das mesmas tabelas?

Por exemplo, na Opção # 1 acima, eu posso ter um servidor MySQL em, digamos mydb01.example.com, e ele pode ter um customer1banco de dados dentro dele. Esse customer1banco de dados pode ter, digamos, 10 tabelas que alimentam meu aplicativo para esse cliente em particular (cliente nº 1). Também pode ter um customer2banco de dados com exatamente as mesmas 10 tabelas, mas contendo apenas os dados do Cliente 2. Pode ter um customer3banco de dados, um customer4banco de dados e assim por diante.

Na Opção nº 2 acima, haveria apenas um único banco de dados / esquema, digamos myapp_db, novamente com 10 tabelas (as mesmas que acima). Mas aqui, os dados de todos os clientes existem nessas 10 tabelas e, portanto, "compartilham" as tabelas. E na camada do aplicativo, controle lógico e de segurança a que os clientes têm acesso a quais registros nessas 10 tabelas, e é tomado muito cuidado para garantir que o Cliente nº 1 nunca efetue login no aplicativo e veja os dados do Cliente nº 3, etc.

Qual desses paradigmas constitui um banco de dados "multilocatário" tradicional? E se não, alguém pode me fornecer um exemplo (usando os cenários descritos acima) do que é um banco de dados de vários inquilinos?

database-design multitenancy

— smeeb
fonte

"multi-inquilino" implica em segurança forte - implementada em algum lugar - para que um inquilino não possa ver os dados de outros, não possa modificá-los, não possa negar acesso a eles, etc. Essa segurança deve ser implementada de alguma forma. As opções 1 e 2 do OP funcionam, mas a análise de segurança e o trabalho necessário para implementar a segurança são diferentes. Pelo que vale, trabalhei em uma startup que implementou a multilocação via opção 2, onde as tabelas - com linhas pertencentes a vários inquilinos - estavam ocultas (por meio de permissões) de todos os usuários finais e a segurança foi implementada inteiramente nos procedimentos armazenados.

— Davidbak

Possível duplicata da multilocação - banco de dados único vs banco de dados múltiplo

— JeffO

Se isso acabar sendo fechado como duplicado, acho que deveríamos sinalizar para mesclá-lo com o alvo idiota, porque ambas as perguntas têm respostas realmente boas.

Respostas:

Qual desses paradigmas constitui um banco de dados "multilocatário" tradicional

Ambos os conceitos são chamados de multilocação, pois é apenas um conceito lógico "no qual uma única instância de software é executada em um servidor e atende a vários inquilinos" (da Wikipedia ). Mas como você implementa esse conceito "fisicamente" é com você.

Obviamente, o aplicativo precisa de um conceito de banco de dados que permita separar os dados de diferentes inquilinos, e a idéia da multilocação é compartilhar alguns recursos do servidor (pelo menos o hardware) para melhor utilização dos recursos e administração mais fácil. Portanto, um "banco de dados multi-inquilino" é aquele que suporta isso diretamente , onde partes do modelo ou tabelas do banco de dados são compartilhadas.

Para ser preciso, é possível criar um aplicativo multilocatário com um banco de dados não multilocatário, fornecendo uma instância de banco de dados individual por cliente. No entanto, isso impede o compartilhamento de quaisquer recursos de banco de dados diretamente entre os inquilinos, e a camada de aplicativo deve garantir a conexão do inquilino certo ao banco de dados correto.

— Doc Brown
fonte

Obrigado @Doc Brown (+1), mas como você poderia ter algum banco de dados que não fosse multi-inquilino?!?

— smeeb

@smeeb: multilocação é uma propriedade do aplicativo usado por diferentes inquilinos, não do banco de dados "por trás" do aplicativo. Obviamente, o conceito db precisa oferecer suporte à multilocação para tornar isso possível.

— Doc Brown

@smeeb: bem, suponha que você tenha uma tabela de usuário com uma restrição de que o nome de usuário seja único, agora algum funcionário de um inquilino não pode mais usar um nome de usuário apenas porque outra pessoa que trabalha em outro inquilino já o está usando.

— RemcoGerlich

@smeeb: se a única maneira de atender a dois inquilinos é instalar e executar um aplicativo duas vezes, em dois servidores diferentes, com dois bancos de dados separados, acho que não chamaríamos isso de multilocação.

— Doc Brown)

Fui a uma apresentação no Azure há algum tempo atrás, dizendo que o MYOB executava sua solução de nuvem no Azure e cada inquilino obtém seu próprio banco de dados (e presumivelmente servidores da Web também); eles apenas têm ótimas ferramentas de automação para gerenciar as centenas de instâncias de banco de dados necessárias. Por outro lado, a organização em que trabalho atualmente executa centenas de clientes em um único banco de dados, há bastante trabalho no software para impor o isolamento dos dados dos clientes. Também consideramos um híbrido, onde nossos maiores clientes obtinham seu próprio banco de dados, enquanto outros compartilhavam o original.

— David Keaveny

Segundo a Microsoft, o termo tem três significados em potencial (um banco de dados para todos os inquilinos ou um banco de dados por inquilino).

Para usar seu exemplo, cada cliente seria seu próprio inquilino.

Um banco de dados por inquilino (cliente)
- Cada inquilino é isolado dos outros (sem acesso acidental aos dados de outros inquilinos)
- O isolamento também facilita o gerenciamento da restauração de dados, bem como a personalização das necessidades de armazenamento para as necessidades dos inquilinos.
Um banco de dados compartilhado, esquema separado.
- Cada inquilino tem seu próprio esquema e seus dados estão em suas próprias tabelas.
- A restauração pode ser mais demorada, já que todos estão no mesmo banco de dados, você não pode simplesmente restaurar o banco de dados em um backup anterior (isso reverteria os dados de todos os inquilinos). Uma opção é restaurar para um novo banco de dados e mesclar / copiar apenas os dados dos 1 inquilinos.
Um banco de dados compartilhado, esquema compartilhado.
- Os dados de todos os inquilinos estão nas mesmas tabelas. Se você rastrear pedidos, por exemplo, todos os pedidos de inquilinos estariam localizados em "dbo.Orders".
- Os dados dos inquilinos são separados por uma coluna em cada tabela (pode ser TenantId), que mostra o proprietário da linha.

Há prós e contras para cada um, bem explicados neste artigo: https://msdn.microsoft.com/en-us/library/aa479086.aspx

Bônus: você pode pensar nisso como um alojamento (simplificado).

Todo inquilino tem sua própria casa. Eles podem fazer o que quiserem e, se queimar, realmente não afeta ninguém.
Cada inquilino está no mesmo prédio, mas tem apartamento próprio.
Todo mundo mora no mesmo apartamento, e todas as coisas são marcadas com um lembrete para mostrar quem é o dono.

— lmms90
fonte

Obrigado pela sua resposta. Poderia, por favor, elaborar sua resposta um pouco. Isso criaria uma resposta melhor.

— Thomas Junk

seu exemplo de bônus é incrível @ imms90

— Aravin

A Microsoft retirou a página que você vinculou do MSDN. A máquina wayback ainda tem uma cópia.

— Mike Sherrill 'Cat Recall'

Artigo semelhante de MS (talvez o mesmo que se moveu): docs.microsoft.com/en-us/azure/sql-database/...

— Pierre Henry