Chave-Valor Stores vs. RDBMs vs. “nuvem” DBS (SDB) [fechado]

Question

Sinto-me confortável no espaço MySQL tendo projetado vários aplicativos ao longo dos últimos anos e, em seguida, refinando continuamente os aspectos de desempenho e escalabilidade. Eu também tenho algum trabalho experiência com memcached para fornecer colaterais aplicação speed-ups em conjuntos de resultados frequentemente consultados. E, recentemente, eu implementei a Amazon SDB como meu "banco de dados" principal para uma experiência de comércio eletrônico.

Para simplificar, uma justificação rápida que eu passei na minha mente para usar o serviço SDB era que o uso de uma estrutura de banco de dados sem esquema me permita focar o problema lógico do meu projeto e conteúdo rapidamente se acumulam em meus dados-store . Ou seja, não se preocupe sobre como configurar e normalizar todas as permutações possíveis de atributos de um produto antes da mão; simplesmente começar a carregar nos produtos eo SDB simplesmente se lembrar de tudo que está disponível.

Agora que eu consegui obter através das primeiras iterações do meu projeto e eu preciso interfaces de configuração simples para os dados, eu estou correndo para questões que eu tinha tomado para concedido trabalhar com o MySQL. Ex: agrupamento em instruções select e sintaxe limite para consulta "itens 50 a 100". A vantagem facilidade ganhei usando a arquitetura livre esquema de SDB, perdi a uma batida de consulta performance / looping um conjunto de resultados com apenas mais de 1800 itens.

Agora estou lendo sobre projetos como Tokyo Cabinet que estão estendendo o conceito de lojas de valor-chave na memória para fornecer funcionalidade pseudo-relacional na ridiculamente velocidades mais rápidas (14x eu li em algum lugar).

A minha pergunta: Existem algumas diretrizes rudimentares ou heurísticas que eu como designer application / desenvolvedor pode percorrer para avaliar qual DB tecnologia é a mais adequada em cada fase do meu projeto.

Ex: Numa fase de prototipagem, onde lógicas incógnitas / técnicos da aplicação make estrutura de dados fluido: uso SDB. Numa fase mais madura, onde as entregas de usuários são uma prioridade, usar ferramentas tradicionais, onde você não tem que gastar dev tempo escrevendo ordenação, agrupamento ou a lógica de paginação.

A experiência prática com essas ferramentas seria muito apreciado.

Graças SO!

Shaheeb R.

Answer 1

As novas soluções não são balas de prata.

Em comparação com RDBMS tradicional, estes sistemas fazer melhorias em alguns aspectos (escalabilidade, disponibilidade ou simplicidade) por outros aspectos comerciais-off (capacidade consulta reduzida, consistência eventual, desempenho horrível para certas operações).

Pense destes não como substitutos do banco de dados tradicional, mas eles são ferramentas para um conhecido, necessidade específica especializada.

Tome Amazon DB simples por exemplo, SDB é basicamente uma enorme planilha, se é isso que a sua aparência de dados gosta, então provavelmente funciona bem e a escalabilidade excelente e simplicidade que você vai economizar muito tempo e dinheiro.

Se o seu sistema requer consultas muito estruturados e complexos, mas você insistir com um desses nova solução legal, você vai encontrar-se no meio da um amador implementação de re-, RDBMS mal concebidos, com toda a sua problemas inerentes.

A este respeito, se você não sabe se estes irão atender sua necessidade, eu acho que é realmente melhor para fazer suas primeiras iterações em um RDBMS tradicional, porque eles dão-lhe a melhor flexibilidade e capacidade especialmente em uma implantação de servidor único e sob carga modesto. (Veja CAP Teorema ).

Uma vez que você tem uma idéia melhor sobre o que seus dados se parecem e como eles serão usados, então você pode combinar sua necessidade com uma solução alternativa.

Se você quiser a simplicidade de uma solução de nuvem hospedado, mas precisa de um banco de dados relacional, você poderá verificar: Amazon Serviço de Banco de Dados relacional

Answer 2

Os problemas que você está encontrando são por isso que especialistas RDBMS ver alguns dos sistemas alternativos com um olho invejoso. Sim, os sistemas alternativos de lidar com certos requisitos específicos extremamente rápido, mas assim que você quer fazer alguma coisa com os mesmos dados, o mais velozes de repente se torna o retardatário. Em contraste, um RDBMS tipicamente controla as variações com maior aprumo; pode não ser tão rápido como o mais velozes para a carga de trabalho especializado que o mais velozes é micro-otimizado para lidar com, mas raramente se deteriora tão rapidamente quando chamado para lidar com outras consultas.