Pergunta Base de dados: mudança simples tabelas relacionais para não-relacional?

Question

Eu tenho uma aplicação web que funciona sobre um banco de dados MySQL (em desenvolvimento). Estou pensando em migrar meu aplicativo para o Google App Engine, e gostaria de entender melhor como o meu modelo de banco de dados relacional simples pode ser transformado para a abordagem não-relacional.

Eu sou uma pessoa do banco de dados relacional muito tempo, e eu não tenho nenhuma experiência com bancos de dados baseados em colunas como BigTable. Apenas no caso de Google também suporta implementações pequenas de bancos de dados relacionais, gostaria de afirmar que a minha pergunta é geral e não específico para o Google -. Eu gostaria de entender como os modelos relacionais simples pode ser representado em bancos de dados não relacionais

O meu banco de dados (simplificado) é a seguinte:

Items Table
------------

ItemID  ItemName  ItemPriority
1       "Car"     7
2       "Table"   2
3       "Desk"    7

ItemProperties Table
---------------------

ItemID  Property        Importance 
1       "Blue"          1
1       "Four Wheels"   2
1       "Sedan"         0
2       "Rectangular"   1
2       "One Leg"       1

Eu tenho muitos artigos, cada um com um nome e ID. Cada item tem várias propriedades, cada propriedade tem vários parâmetros (eu só disse o nome e "importância" de cada propriedade, mas existem mais). Eu tenho dezenas de milhões de itens, cada um tem centenas de propriedades.

O cenário de uso: receber uma ItemName como entrada, procure seu ID na tabela de itens e buscar todas as propriedades por que id. Eu, então, realizar algumas análises sobre a lista de propriedades (em memória), e retornar um resultado.

90% do trabalho é a pesquisa com base em um parâmetro, que (se eu entendi corretamente) é o ponto de dor de bancos de dados não relacionais.

O que é a abordagem recomendada?

Answer 1

De alguém que tem vindo a trabalhar com não-relacional db de por um tempo suas duas tabelas devem ser realmente fácil de traduzir para uma db não-relacional.

Leve as duas tabelas e transformá-los em um único objeto.

Item: - Eu iria - Nome - Propriedades - prop1 - prop2

Guarde a coisa toda em suas colunas de dados de lojas (Big-Table), documentos (CouchDB), ou qualquer outra coisa que ele usa.

Você pode procurar itens por qualquer dos IDs, nomes ou propriedades. Não há nenhum junta-se que é um dos maiores pontos de dor de dbs não-relacionais. pesquisas de parâmetros não são realmente um ponto de dor, a menos que eu não estou entendendo o que você quer dizer com isso. Você pode ter que fazer várias pesquisas, mas na maioria das vezes isso não é um problema e ele escalas muito melhor do que um RDBMS faz.

No seu exemplo eu realmente considerar o modelo não-relacional para ser mais simples e mais fácil de implementar e entender.

Cada armazenamento de dados não-relacional tem diferentes convenções e restrições embora por isso é orientação dar duro no sentido geral. CouchDB pode criar um índice em qualquer parte do objeto com a sua vista, por exemplo. Com BigTable você pode ter que armazenar várias cópias dos dados desnormalizada para obter pesquisas rápido indexados. Outros terão coisas diferentes a considerar quando você decidir como armazenar os dados. Há um monte de diferenciação lá fora, uma vez que você deixar o mundo da SQL.

Answer 2

GQL não suporta junta. Você pode contornar isso de duas maneiras:

• Faça o mesmo juntar-se

Apenas buscar o Item, verificar a sua ItemID e consulta para ItemProperties com que ItemID. Suas tabelas ficariam exatamente como você especificou eles. Claro, este é duas consultas, mas as duas consultas são simples.

• Use Expando Models

Em um modelo Expando, você pode criar novos campos em tempo de execução. Eles não serão indexados, por isso, se você quiser pesquisar sobre eles pode ser mais lento, mas simplesmente buscá-los é apenas multa. Você pode usar tipos complexos como ListProperty também. Com este tipo de flexibilidade, você pode ser capaz de pensar em uma maneira de colocar tudo na tabela de ItemProperties na tabela de itens, e salve-se uma consulta. Seja criativo.

Answer 3

Eu tenho uma estrutura de banco de dados muito semelhante (os nossos "registros" e "recordEntries" tabelas espelhar seus "itens" e "ItemProperties") e estou considerando uma migração semelhante a um banco de dados não-relacional. Nós provavelmente vamos ir para CouchDB ou memcachedb ou algo parecido, ao invés de Google.

Como você eu não tenho nenhuma experiência em trabalhar com bancos de dados não relacionais (nem meus desenvolvedores). No entanto, temos jogado um par de ideias ao redor. Nossos pensamentos atuais são (usando o esquema):

• Primeiro: Recolher cada item mais suas propriedades de itens em um objeto com campos (essencialmente um documento XML) e enchê-lo no banco de dados introduzidos pelo identificador. Toda vez que você recuperar um item que você voltar todos os ItemProperties também.

Observe a diferença que temos é que o índice que nosso conteúdo fora do banco de dados (com Solr), e, portanto, não precisa fazer pesquisas no próprio banco de dados usando o "nome" da propriedade, assim YMMV.

• Em segundo lugar: Nós estamos fazendo uma lista off todas as operações "relacional" que estamos fazendo que não pode ser suportada pelo modelo acima. Isto inclui um par de operações de "agrupamento" onde nós consulta itens com base num campo especial na tabela de item, e uma consulta em que tentam detectar todos os itens que foram recentemente modificados (anteriormente realizado por uma consulta em uma coluna de data em tabela de item). Estamos inventando implementações alternativas para cada um desses casos (há apenas uns poucos, felizmente).

Se isto prova muito difícil, vamos tentar o mesmo exercício com outro modelo. Felizmente, temos tempo para planejar.

Um ponto chave para nós é que estamos fazendo todo o nosso indexação externamente com Solr, por isso (por exemplo) que não precisamos fazer pesquisas de banco de dados sobre os valores nos valores ItemProperties, ou para fazer pesquisas por nome na item de mesa.

De qualquer forma, isso provavelmente não é muita ajuda, mas eu vou estar ansiosos para ver que tipo de soluções pessoas mais experientes podem vir acima com.

PS: Eu inferir sua mesa propriedades deve ter bilhões de linhas. Quantos exatamente, e que hardware que você está executando o servidor MySQL em? Você está tendo problemas de escalabilidade ainda com MySQL?

Answer 4

Você precisa achatar tudo isso, eu acho que AppEngine permite que estruturas como

ID = 1, ItemName = Carro, ItemPriority = 7, Propriedade = (azul, 1), Propriedade = (Quatro Rodas, 2), Propriedade = (Sedan, 0) ID = 2, ItemName = Tabela, ItemPriority = 2, Propriedade = (retangular, 1), Propriedade = (um pé, 1) ID = 3, ItemName = Desk, ItemPriority = 7

Observe que o mesmo "campo" pode ter vários valores, e que você pode usar vários itens nele.

Seus dados da amostra seria de 3 linhas em uma tabela.