Casos de uso para NoSQL [fechado]

O NoSQL tem recebido muita atenção recentemente em nosso setor. Estou realmente interessado em saber o que as pessoas pensam sobre os melhores casos de uso para o uso em armazenamento relacional de banco de dados. O que deve levar um desenvolvedor a pensar que conjuntos de dados específicos são mais adequados para uma solução NoSQL. Estou particularmente interessado no MongoDB e no CouchDB, pois eles parecem estar obtendo a maior cobertura em relação ao desenvolvimento do PHP, e esse é o meu foco.

Apenas prometa a si mesmo que nunca tentará mapear um modelo de dados relacionais para um banco de dados NoSQL como MongoDB ou CouchDB ... Esse é o erro mais comum que os desenvolvedores cometem ao avaliar a tecnologia emergente.

Essa abordagem é análoga a pegar um carro e tentar usá-lo para puxar seu carrinho pela estrada como um cavalo.

É uma reação natural devido à experiência de todos, é claro, mas o valor real do uso de um banco de dados de documentos é ser capaz de simplificar seu modelo de dados e minimizar seu sofrimento como desenvolvedor. Sua base de código diminuirá, seus erros serão menos e mais fáceis de encontrar, o desempenho será incrível e a escala será muito mais simples.

Como fundador do Joomla, sou tendencioso :-) mas vindo do espaço do CMS, algo como o MongoDB é uma bala de prata, pois o conteúdo é mapeado muito naturalmente para os sistemas de documentos.

Outro ótimo argumento para o MongoDB é a análise em tempo real, pois o MongoDB tem desempenho e escala muito fortes, principalmente em relação à simultaneidade. Existem estudos de caso no site MongoDB.org que demonstram esses atributos.

Eu concordo com a noção de que cada banco de dados tem seus próprios objetivos e casos de uso; tome o objetivo de cada banco de dados para avaliação em conformidade.

Alguns ótimos casos de uso - para o MongoDB de qualquer maneira - são mencionados no site do MongoDB. Os exemplos dados são análise em tempo real, registro e pesquisa de texto completo. Vale a pena ler todos esses artigos http://www.mongodb.com/use-cases

Também há uma excelente descrição sobre qual banco de dados NoSQL é mais adequado para qual tipo de projeto: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Eu sugeriria este artigo de Rick Cattell sobre diversos armazenamentos de dados (também conhecido como NoSQL), suas diferenças e alguns de seus casos de uso: http://www.cattell.net/datastores/index.html

O que eu gosto no NoSQL não tem nada a ver com desempenho e tudo a ver com usabilidade. Os armazenamentos de documentos são mais fáceis de trabalhar quando suas unidades de dados atômicas são parecidas com documentos, porque é trivial serializar para e de objetos. É apenas mais divertido, e esse é um fator importante para projetos pessoais ou paralelos.

Estou usando os bancos de dados NoSQL há algum tempo e esta é minha contribuição para o tópico:

Um ótimo caso de uso para um banco de dados NoSQL é um aplicativo para geração de estatísticas e / ou relatórios , especialmente quando os dados são fornecidos por uma fonte de terceiros.

Em uma situação como essa, um banco de dados NoSQL pode ser uma ótima escolha

Vamos considerar, por exemplo, o MongoDB :

Depois que você tiver seus dados em JSON (eles podem vir de uma API de terceiros ou ser exportados de um aplicativo sql) no MongoDB, é bastante fácil importar e atualizar os dados JSON no banco de dados; por exemplo, usando o mongoimportutilitário de linha de comando

Nesse ponto, é muito simples criar consultas dinâmicas com filtragem e agrupamento, que se encaixam bem nesse tipo de aplicativo.

Por exemplo, usando a Estrutura de agregação :

$pipeline = [];

//filter by date
$pipeline[] = [ '$match' => [ 'created_at' => [ '$gte' => $starDate, '$lte' => $endDate ]  ]  ];

//if we want to filter by a specific field, we add the filter to the pipeline array
if( $filters->isFilterByField() )
    $pipeline[] = [ '$match' => [ 'field' => $fieldValue ] ];    

//group the results by date and get the count
$pipeline[] = [ '$group' => [ '_id' => '$created_at', 'num_elements' => [ '$sum' => 1 ] ] ];

return $collection->aggretate( $pipeline );

Gostaria de destacar a facilidade com que podemos adicionar / remover dinamicamente filtros usando estruturas de dados php e evitando a concatenação tediosa de strings para criar nossas consultas. Com essa abordagem, adicionar / remover filtros dinamicamente é tão fácil quanto adicionar / remover elementos de uma matriz

Outro grande benefício vem do fato de que uma solução como essa provavelmente será mais rápida do que o uso de um banco de dados relacional , onde precisamos fazer junções com tabelas diferentes para obter todos os dados de que precisamos

Além disso, este caso de uso é ideal porque evita todos os principais limites de um banco de dados NoSQL:

• Falta de transações: o aplicativo não realiza gravações, mas apenas lê, portanto, não precisamos de transações.

• Falta de junções entre tabelas: não precisamos de junções, pois podemos usar redundância para armazenar nossos dados desnormalizados nas coleções. Como apenas lemos dados, não precisamos nos preocupar em sincronizar dados desnormalizados entre as atualizações.

Dessa forma, podemos nos concentrar em armazenar os dados com redundância de uma maneira que se adapte bem às nossas consultas , que serão focadas em coleções únicas.

Estou escrevendo isso porque, se eu tivesse lido algo assim há algumas vezes, teria me poupado algum tempo para fazer pesquisas

Espero que seja útil para alguém

Eu recomendo fortemente essa palestra de Martin Fowler:

https://www.youtube.com/watch?v=qI_g07C_Q5I

RESUMO: Martin fornece uma rápida introdução aos bancos de dados NoSQL: de onde eles vieram, a natureza dos modelos de dados que eles usam e a maneira diferente de pensar em consistência. A partir disso, ele descreve quais tipos de circunstâncias você deve considerar usá-los, por que eles não tornarão obsoletos os bancos de dados relacionais e a importante consequência da persistência poliglota.

Ele ilustra bem o que é o NoSQL, as diferentes categorias e o que todos precisam entender quando vierem do mundo dos bancos de dados relacionais. Saudações.

Primeiro, você precisa entender a teoria do CAP (Consistência, Disponibilidade e Particionamento, onde você deve selecionar duas de três) e o nosso caso de uso de Negócios. O MongoDB satisfaz a consistência e o particionamento e o Couch DB satisfaz a disponibilidade e o particionamento.

Os vídeos Edureka no youtube sobre o NoSQL são alguns dos melhores tutoriais em vídeo.

https://www.youtube.com/watch?v=gJFG04Sy6NY

https://www.youtube.com/watch?v=KSq6tMMXZ8s

https://www.youtube.com/watch?v=3z1KFA2qcSo

Boas apresentações estão disponíveis em slideshare.net

http://www.slideshare.net/quipo/nosql-databases-why-what-and-when?qid=3bb9f7f6-a53d-41b1-8403-cd6f181d0ca7&v=qf1&b=&from_search=1

http://www.slideshare.net/EdurekaIN/no-sql-databases-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search=3 (esta apresentação suporta tutoriais em vídeo no youtube)

Para alguns casos de uso que você precisa, especialmente para consultas analíticas, você pode executar consultas SQL no MongoDB com este wrapper do Postgres.

Como agora existem muito mais bancos de dados NoSQL no mercado do que nunca, sugiro dar uma olhada no Quadrante Mágico do Gartner se você estiver procurando por um banco de dados que também seja ótimo para aplicativos corporativos baseados em suporte, expansibilidade, gerenciamento e custo.

http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb

Gostaria de sugerir o Couchbase a qualquer um que ainda não o tenha experimentado, mas não com base na versão mostrada no relatório (2.5.1), porque há quase duas revisões atrás do CB Server hoje, aproximando-se do lançamento do 4.0 no 2S15 .

http://www.couchbase.com/coming-in-couchbase-server-4-0

A outra parte do Couchbase como fornecedor / produto é que ele é um tipo de banco de dados multiuso. Ele pode atuar como um armazenamento K / V puro, banco de dados orientado a documentos com escala multidimensional, Memcached, além de cache com persistência e suporta SQL compatível com ANSI 92 com junções automáticas, replicação para clusters de DR com o pressionar de um botão e ainda possui um componente móvel embutido no ecossistema.

Se nada mais, vale a pena conferir os últimos benchmarks:

http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.html http://info.couchbase.com/NoSQL-Technical-Comparison-Report.html