Início / dba / Perguntas / 34014
Accepted
alfonx
Asked: 2013-02-03 05:04:28 +0800 CST

Usando Solr/Lucene para pesquisar tabelas não textuais?

  • 772

Estou criando um aplicativo da web para recuperar subconjuntos de uma tabela grande (4m linhas). As linhas de 4m mudam apenas uma vez por ano. A tabela tem mais de 200 colunas de tipos booleanos e numéricos. Não tem colunas de texto.

Os usuários consultarão subconjuntos desta tabela para download.

Estou bastante familiarizado com o banco de dados PostgreSQL 9.1 e meu plano é:

  • O webapp ajudará o usuário a criar consultas como "WHERE a=3 AND b=true AND c>300"
  • O banco de dados terá índices adequados para as colunas mais usadas.

AGORA .. Eu li aqui: https://stackoverflow.com/questions/10053050/why-is-solr-so-much-faster-than-postgres :

Recentemente, mudei do Postgres para o Solr e notei uma aceleração de aproximadamente 50x em nossas consultas. As consultas que executamos envolvem vários intervalos e nossos dados são listagens de veículos. Por exemplo: "Encontre todos os veículos com quilometragem < 50.000, $ 5.000 < preço < $ 10.000, marca=Mazda..."

Então, agora eu me pergunto: as pesquisas de Solr, Lucene, ElasticSearch e Amazon Cloud Search serão mais rápidas que o PostgreSQL, mesmo que nenhuma pesquisa de texto completo esteja envolvida?

full-text-search postgresql-9.1

1 respostas

  1. Best Answer

    As pesquisas do Solr/Lucene serão/podem ser mais rápidas do que o PostgreSQL, mesmo que nenhuma pesquisa de texto completo esteja envolvida?

    Sim. De acordo com o exemplo citado, pode ser muitas vezes mais rápido que um banco de dados relacional para determinados casos de uso. Não é realmente surpreendente.

    Solré um motor de busca. PostgreSQLé um mecanismo de banco de dados relacional.

    Solré construído desde o início para fazer uma coisa bem, pesquisar. Ele não pode fazer o trabalho de um sistema de banco de dados transacional. Solrnão pode garantir conformidade com ACID, não gerencia com eficiência a simultaneidade e não é um candidato viável para cargas de trabalho OLTP.

    PostgreSQLé construído desde o início para fazer uma coisa bem, processamento transacional. Ele também pode fazer um trabalho razoável de fornecer recursos de tipo de pesquisa, mas essa não é sua função principal. Ele garante conformidade com ACID, gerencia simultaneidade, não é um mecanismo de pesquisa.

    As linhas de 4m mudam apenas uma vez por ano.

    Nesse caso, você provavelmente não precisa dos principais recursos de um mecanismo de banco de dados relacional.

    Você precisa de um mecanismo de pesquisa. Pode ser Solr , Lucene , ElasticSearch , Amazon Cloud Search ou uma das dezenas de outros, mas antes de mais nada será uma plataforma de pesquisa, não um banco de dados relacional.

    • 9

relate perguntas