NoSQL (MongoDB) vs Lucene (ou Solr) como seu banco de dados

280

Com o movimento NoSQL crescendo com base em bancos de dados baseados em documentos, observei o MongoDB recentemente. Percebi uma semelhança impressionante com como tratar itens como "Documentos", assim como Lucene (e usuários do Solr).

Então, a pergunta: por que você deseja usar o NoSQL (MongoDB, Cassandra, CouchDB, etc) sobre Lucene (ou Solr) como seu "banco de dados"?

O que estou procurando (e tenho certeza que os outros estão procurando) em uma resposta é algumas comparações profundas deles. Vamos pular as discussões de banco de dados relacionais juntas, pois elas servem a um propósito diferente.

O Lucene oferece algumas vantagens sérias, como poderosos sistemas de busca e peso. Sem mencionar as facetas do Solr (que Solr será integrado ao Lucene em breve, sim!). Você pode usar documentos Lucene para armazenar IDs e acessar os documentos como tais, como o MongoDB. Misture-o com o Solr e agora você obtém uma solução com balanceamento de carga baseada em WebService.

Você pode até fazer uma comparação de provedores de cache fora de processo, como Velocity ou MemCached, ao falar sobre armazenamento de dados e escalabilidade semelhantes do MongoDB.

As restrições do MongoDB me lembram o uso do MemCached, mas eu posso usar o Velocity da Microsoft e ter mais poder de coleta de agrupamento e lista do MongoDB (eu acho). Não é possível obter mais rápido ou escalabilidade do que o armazenamento em cache de dados na memória. Até Lucene tem um provedor de memória.

O MongoDB (e outros) têm algumas vantagens, como a facilidade de uso de sua API. Atualize um documento, crie um ID e armazene-o. Feito. Legal e fácil.

mongodb solr lucene memcached nosql eduncan911
fonte
8
Veja stackoverflow.com/questions/2546494/…
bajafresh4life
4
Obrigado, mas isso não responde à minha pergunta: qual é, por que eu usaria o MongoDB em vez do Lucene no meu banco de dados? Ambos lidam com documentos, mas o Lucene tem algumas opções de pesquisa muito poderosas. +1 para encontrar uma pergunta relacionada. Pesquisei várias vezes no Stackoverflow e não fiz uma comparação próxima.
precisa saber é o seguinte
Como você está usando o Lucene para fornecer funcionalidade semelhante ao MongoDB? Você está vinculando-o a um banco de dados relacional para armazenamento?
Philip Tinney
1
@ Philip: É uma pergunta hipotética. Por que não usar o Lucene como armazenamento de documentos? Você obtém muito mais poder de pesquisa e escalabilidade (quando misturado ao Solr, tornando o Lucene ainda mais fácil de usar).
eduncan911

Respostas:

250

Essa é uma ótima pergunta, algo sobre o qual eu ponderei bastante. Resumirei minhas lições aprendidas:

  1. Você pode facilmente usar o Lucene / Solr no lugar do MongoDB para praticamente todas as situações, mas não vice-versa. A publicação de Grant Ingersoll resume aqui.

  2. O MongoDB etc. parece servir a um propósito em que não há exigência de pesquisa e / ou lapidação. Parece ser uma transição mais simples e sem dúvida mais fácil para os programadores que se desintoxicam do mundo RDBMS. A menos que alguém esteja acostumado, Lucene & Solr têm uma curva de aprendizado mais acentuada.

  3. Não existem muitos exemplos de uso do Lucene / Solr como um armazenamento de dados, mas o Guardian avançou e resumiu isso em um excelente deck de slides , mas eles também não se comprometem a pular totalmente o movimento Solr e a "investigar" combinando o Solr com o CouchDB.

  4. Por fim, vou oferecer nossa experiência, infelizmente não posso revelar muito sobre o caso de negócios. Trabalhamos na escala de vários TB de dados, um aplicativo quase em tempo real. Depois de investigar várias combinações, decidiu ficar com Solr. Até agora, não há arrependimentos (6 meses e contando) e não vejo motivo para mudar para outro.

Resumo: se você não possui um requisito de pesquisa, o Mongo oferece uma abordagem simples e poderosa. No entanto, se a pesquisa for a chave da sua oferta, é provável que você adote uma única tecnologia (Solr / Lucene) e otimize o que é necessário - menos peças móveis.

Meus 2 centavos, espero que tenha ajudado.

Mikos
fonte
10
Solr não possui funcionalidade de redução de mapa. Portanto, relatórios, estatísticas, cálculo de pontuações etc. não são possíveis! Use Solr somente se você tem / CAN ameaça seus dados como dados de texto
Roland Kofler
8
O Solr não possui o recurso de redução de mapa embutido, mas você pode combinar com o Hadoop. architects.dzone.com/articles/solr-hadoop-big-data-love
Mikos
6
Reduza o mapa não, mas tem a capacidade de executar uma consulta em paralelo em vários servidores solr e agregar esses resultados. Portanto, embora ele não tenha o map-purpose de uso geral, ele já gravou o que você escreveria com map-red, que são consultas de pesquisa paralela.
chubbsondubs
@Roo: Seria uma opção usar o Lucene como um banco de dados principal e criar índices agregados com o MongoDB de alguma forma? Ou isso não faz sentido? E Mikos: ótima resposta e +1 para a experiência do mundo real mencionada.
Careta do Desespero
2
de solr6 ele suporta mapa reduzir a funcionalidade com expressões paralelas
Divyang Shah
36

Você não pode atualizar parcialmente um documento no solr. É necessário republicar todos os campos para atualizar um documento.

E o desempenho é importante. Se você não confirmar, sua alteração no solr não terá efeito; se você confirmar sempre, o desempenho será prejudicado.

Não há transação no solr.

Como o solr tem essas desvantagens, algumas vezes o nosql é uma escolha melhor.

Peter Long
fonte
13
O MongoDB também não possui transações.
user183037
1
Solr ou Lucene têm pesquisa em tempo real, portanto, comprometer-se não é um problema.
mihaicc
1
@ user183037 no MongoDB, todas as atualizações em um documento são Atomic. E FYI, Lucene não tem transações (em seu sentido) quer
Aravind Yarram
48
Esta resposta ficou incorreta. O Solr 4+ oferece suporte a atualizações parciais, e soft commits / quase em tempo real acabam com a maioria dos problemas dos commits "antigos" do Solr.
Mauricio Scheffer
1
Eles acrescentaram suporte para transações on MongoDB 4.
Jonas
26

Usamos o MongoDB e o Solr juntos e eles apresentam um bom desempenho. Você pode encontrar meu blog aqui, onde descrevi como usamos essas tecnologias juntos. Aqui está um trecho:

[...] No entanto, observamos que o desempenho da consulta do Solr diminui quando o tamanho do índice aumenta. Percebemos que a melhor solução é usar o Solr e o Mongo DB juntos. Em seguida, integramos o Solr ao MongoDB armazenando conteúdo no MongoDB e criando um índice usando o Solr para pesquisa de texto completo. Armazenamos apenas o ID exclusivo de cada documento no índice Solr e recuperamos o conteúdo real do MongoDB após pesquisar no Solr. Obter documentos do MongoDB é mais rápido que o Solr, porque não há analisadores, pontuação etc. [...]

Parvin Gasimzade
fonte
3
Boa publicação no blog. Sim, é exatamente assim que eu usei o Lucene no passado com datastores SQL e MySql mais antigos (armazenando IDs no Lucene e recuperando os tipos complexos do datastore). Tecnicamente, porém, essa questão era explorar as diferenças entre os dois - não exatamente como usar o "melhor dos dois mundos". +1 por usá-lo dessa maneira, pois é realmente a única maneira real de usar grandes quantidades de dados.
eduncan911
Obrigado pela sua resposta. Sei que a questão é escolher o Nosql em vez do Lucene, mas aqui quero mostrar que, em vez de escolher um sobre o outro, usá-los de maneira híbrida fornecerá o melhor resultado.
Parvin Gasimzade 26/12/12
2
Você se lembra (agora 1,5 anos depois) aproximadamente do tamanho do banco de dados Solr quando o desempenho da consulta diminuiu tanto que você começou a pensar em adicionar o MongoDB? (Era 10.000 docs ou 10.000.000 docs?)
KajMagnus
Muito útil. Eu trabalho em GIS e, portanto, poder combinar texto completo com pesquisa espacial dessa maneira é muito intrigante. Já usamos o MongoDB e o Postgres, e eu penso no Solr há algum tempo.
John Powell
2
@ParvinGasimzade o link da postagem do blog não está funcionando. Você poderia fornecer outro link ou fonte?
esquecimento
24

Observe também que algumas pessoas integraram o Solr / Lucene no Mongo, armazenando todos os índices no Solr e também monitorando as operações do oplog e atualizando em cascata as atualizações relevantes no Solr.

Com essa abordagem híbrida, você pode realmente ter o melhor dos dois mundos com recursos como pesquisa de texto completo e leituras rápidas com um armazenamento de dados confiável, que também pode ter uma velocidade de gravação impressionante.

É um pouco técnico de configurar, mas há muitos tailers oplog que podem ser integrados ao solr. Confira o que o rangepan fez neste artigo.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

Prasith Govin
fonte
Se eu entendi corretamente, o motivo pelo qual você usa o MongoDB (além do Solr) é que o MongoDB tem inserção mais rápida + velocidade de leitura? Você também indicou que o MongoDB possui um armazenamento de dados mais confiável? (Ou você estava se referindo a Solr?) - Com o que você começou inicialmente? Apenas MongoDB, apenas Solr ou ambos Mongo + Solr?
#
12

Pela minha experiência com os dois, o Mongo é ótimo para uso simples e direto. A principal desvantagem do Mongo que sofremos é o baixo desempenho em consultas imprevistas (você não pode criar índices mongo para todas as combinações possíveis de filtro / classificação, você simplesmente não pode).

E aqui, onde o Lucene / Solr prevalece bastante, especialmente com o cache do FilterQuery, o desempenho é excelente.

mjalajel
fonte
10

Como ninguém mais o mencionou, deixe-me acrescentar que o MongoDB não possui esquema, enquanto o Solr impõe um esquema. Portanto, se é provável que os campos dos seus documentos sejam alterados, esse é um dos motivos para escolher o MongoDB em vez do Solr.

Aquarelle
fonte
6
que IMHO não é bem verdade. O Solr tem um esquema como definido em schema.xml, MAS também possui 'campos dinâmicos', ou seja, campos cujos tipos são determinados por curingas, para que você possa ter todos os campos correspondentes, digamos, *_iindexados como campos inteiros. quando a adição de documentos, então você pode ter documentos conaining campos como count_i, foo_i, bar_ique são todos entendidos como campos inteiros sem aparecer no schema.xmlliteralmente. bem sem esquema, eu diria. consulte youtube.com/watch?v=WYVM6Wz-XTw para obter mais informações.
flow
Eu tenho que voltar e aumentar isso com um +1, porque isso é verdade - as alterações de esquema no Solr sempre estiveram em uma PITA para manter a sincronização com outros armazenamentos de dados.
precisa saber é o seguinte
4
O Solr possui um recurso que suporta esquema ou sem esquema!
quer
5

@ mauricio-scheffer mencionou o Solr 4 - para os interessados, o LucidWorks está descrevendo o Solr 4 como "o NoSQL Search Server" e há um vídeo em http://www.lucidworks.com/webinar-solr-4-the-nosql -search-server / onde eles detalham os recursos do NoSQL (ish). (O -ish é para a versão deles sem esquema ser realmente um esquema dinâmico.)

Beth
fonte
1

Se você deseja apenas armazenar dados usando o formato de valor-chave, o Lucene não é recomendado porque seu índice invertido desperdiçará muito espaço em disco. E com a economia de dados em disco, seu desempenho é muito mais lento que os bancos de dados NoSQL, como redis, porque os redis salvam dados na RAM. A maior vantagem do Lucene é que ele suporta muitas consultas, portanto, as consultas difusas podem ser suportadas.

张洪岩
fonte
1

As soluções de terceiros, como uma cauda de mongo op-log, são atraentes. Permanecem alguns pensamentos ou perguntas sobre se as soluções podem ser totalmente integradas, assumindo uma perspectiva de desenvolvimento / arquitetura. Não espero encontrar uma solução totalmente integrada para esses recursos por alguns motivos (um tanto especulativos e sujeitos a esclarecimentos e não atualizados com os esforços de desenvolvimento):

  • mongo é c ++, lucene / solr são java
  • lucene suporta vários formatos de documento
    • mongo está focado em JSON (BSON)
  • lucene usa documentos imutáveis
    • atualizações de campo único são um problema, se estiverem disponíveis
  • índices de luceno são imutáveis ​​com operações de mesclagem complexas
  • consultas mongo são javascript
  • O mongo não possui analisadores / tokenizadores de texto (AFAIK)
  • os tamanhos de mongo doc são limitados, o que pode ir contra o lucene
  • operações de agregação mongo podem não ter lugar no lucene
    • lucene tem opções para armazenar campos em documentos, mas isso não é a mesma coisa
    • O solr de alguma forma fornece agregação / estatísticas e consultas SQL / gráfico
Darren Weber
fonte
0

O MongoDB Atlas terá em breve um mecanismo de pesquisa baseado em luceno. O grande anúncio foi feito na conferência MongoDB World 2019 desta semana. Essa é uma ótima maneira de incentivar mais o uso do produto MongoDB Atlas de alta receita.

Eu esperava vê-lo inserido na versão 4.2 do MongoDB Enterprise, mas não há notícias de trazê-lo para sua linha de produtos no local.

Mais informações aqui: https://www.mongodb.com/atlas/full-text-search

Gary Russo
fonte