speed - when use sql or nosql




Casos de uso para NoSQL (6)

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


Primeiro, você precisa entender a teoria CAP (Consistência, Disponibilidade e Particionamento, em que você tem que escolher dois de três) e nosso caso de uso de Negócios. MongoDB satisfaz consistência e particionamento e Couch satisfaz a disponibilidade e o particionamento.

Edureka vídeos no youtube sobre 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 o tutorial em vídeo no youtube)



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

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

Eu gostaria de sugerir o Couchbase para qualquer um que ainda não o tenha experimentado, mas não baseado na versão mostrada no relatório (2.5.1), pois são quase 2 revisões atrás do CB Server hoje, perto do lançamento do 4.0 no 2S15. .

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

A outra parte sobre o Couchbase como um fornecedor / produto é que ele é um tipo multiuso de banco de dados. Ele pode atuar como um armazenamento K / V puro, Banco de Dados Orientado por Documento com dimensionamento multidimensional, Memcached, cache-aside com persistência e suporta SQL compatível com ANSI 92 com associações automáticas, replicação para clusters DR com o apertar de um botão e até tem 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


Eu recomendo fortemente esta palestra de Martin Fowler:

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

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

Ele desenha uma boa imagem do que o NoSQL é, as diferentes categorias e as coisas que todos precisam entender quando vêm do mundo de bancos de dados relacionais. Saudações.


Eu tenho usado o NoSQL DBs por um tempo agora, 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 :

Uma vez que você tenha seus dados em JSON, (ele pode vir de uma API de terceiros ou ser exportado de um aplicativo SQL) no MongoDB é muito fácil importar e atualizar os dados JSON no banco de dados; por exemplo, usando o utilitário mongoimport linha de comando

Neste ponto é muito simples construir consultas dinâmicas com filtragem e agrupamento, que se encaixam bem com esse tipo de aplicação.

Por exemplo, usando o Aggregation Framework :

$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 apontar a facilidade com a qual podemos dinamicamente adicionar / remover filtros usando estruturas de dados php e evitar a tediosa concatenação de strings para construir 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 usar um banco de dados relacional , em que temos que 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 executa 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 a redundância para armazenar nossos dados desnormalizados nas coleções. Como apenas lemos dados, não precisamos nos preocupar com a sincronização de dados desordenados entre as atualizações.

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

Eu só estou escrevendo isso porque se eu tivesse lido algo assim algumas vezes atrás, teria me poupado algum tempo para fazer pesquisas

Espero que seja útil para alguém


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ômicos são semelhantes a documentos, porque é trivial serializar para e de objetos. É apenas mais divertido, e isso é um fator importante para projetos pessoais ou paralelos.





nosql