O Elasticsearch pode ser usado como um banco de dados NoSQL? Analisaremos as várias propriedades do Elasticsearch que o tornam um dos mecanismos de pesquisa e análise mais flexíveis, escaláveis ​​e eficientes para responder à pergunta inicial.

Passo a passo para instalar o Stack ELK

O que é um banco de dados NoSQL?


O NoSQL- database define o NoSQL como um "banco de dados de última geração que aborda principalmente alguns dos pontos: sendo não-relacional, distribuído, de código aberto e horizontalmente escalável". Em outras palavras, não é uma definição muito precisa.

Não é sobre SQL em particular. Por exemplo, a linguagem de consulta do Hive é claramente inspirada pelo SQL. O mesmo vale para a linguagem de consulta do Esper, que opera em fluxos em vez de relações. Além disso, você sabia que o PostgreSQL foi chamado de "Postgres" e teve "Quel" como sua linguagem de busca? Embora seja um ORDBMS, agora também possui muitos recursos para torná-lo viável como um armazenamento de documentos no formato “schemaless”.

Também não é sobre ACID-ity. O Hyperdex é um exemplo de banco de dados NoSQL que visa fornecer transações ACID. O MySQL, certamente um banco de dados SQL, tem um histórico de interpretações duvidosas sobre o que ACID realmente significa.

Relações? Enquanto a maioria dos bancos de dados NoSQL não suportam unir-se no mesmo sentido que os bancos de dados relacionais tradicionais e deixam isso como um exercício para o usuário, existem aqueles que o fazem, como RethinkDB, Hive e Pig. O Neo4j, um banco de dados orientado por gráfico, é excelente em atravessar relações em gráficos. O Elasticsearch tem um conceito de "query time" unindo-se a relações parent/child, e "index time" unindo-se a “nested types”.

Distribuído? Embora existam alguns bancos de dados SQL distribuídos, e alguns projetos com o objetivo de serem semelhantes a um NoSQLite, os bancos de dados mais recentes tendem a ser distribuídos de uma maneira ou de outra.

Para resumir, não faz sentido definir com precisão o NoSQL, nem simplesmente dizer que o Elasticsearch é um banco de dados NoSQL do tipo "document store".

Sem transações

O Lucene, no qual o Elasticsearch é construído, tem uma noção de transações. O Elasticsearch, por outro lado, não possui transações no sentido típico. Não há como reverter um documento enviado, e você não pode enviar um grupo de documentos e ter todos ou nenhum deles indexados. O que ele tem, no entanto, é um log write-ahead para garantir a durabilidade das operações sem ter que fazer um Lucene-commit. Você também pode especificar o nível de consistência das operações de índice, em termos de quantas réplicas devem confirmar a operação antes de retornar. Este padrão é um quorum, ou seja, \ (\ lfloor \ frac {n} {2} \ rfloor + 1 \) .

A visibilidade das alterações é controlada quando um índice é atualizado, o que, por padrão, é uma vez por segundo e acontece em uma base de shard-by-shard. O controle de concorrência é feito especificando a versão dos documentos enviados.


Esquema Flexível

O Elasticsearch não exige que você especifique um esquema antecipadamente. Lance um documento JSON e ele fará algumas suposições para inferir seu tipo. Ele faz um bom trabalho em coisas como valores numéricos, booleans e timestamps. Para strings, ele usará o analisador "standard", que geralmente é bom para começar.

Embora seja indiscutivelmente "schema free", no sentido de que você não precisa especificar um esquema, gostamos de considerá-lo como "esquema flexível". Para desenvolver uma ótima pesquisa e/ou análise, você realmente precisa ajustar seus esquemas. O Elasticsearch possui um extenso conjunto de ferramentas poderosas para ajudá-lo, como modelos dinâmicos, objetos de vários campos etc.

Relações e Restrições

Elasticsearch é um banco de dados orientado a documentos. O gráfico de objetos inteiro que você deseja pesquisar precisa ser indexado. Portanto, antes de indexar seus documentos, eles devem ser desnormalizados. A desnormalização aumenta o desempenho da performance (já que não é necessária a associação de query), usa mais espaço (porque as coisas devem ser armazenadas várias vezes), mas torna as coisas consistentes e atualizadas.

Por exemplo, digamos que você tenha configurado um banco de dados contendo clientes, pedidos e produtos, e deseje procurar pedidos de acordo com o nome de um produto e cliente. Isso poderia ser resolvido pela indexação de pedidos com todas as informações necessárias sobre o cliente e os produtos. A busca é fácil, mas o que acontece quando você quer mudar o nome do produto? Em um design relacional com normalização adequada, você simplesmente atualizaria o produto.  

Com um banco de dados de documentos desordenados, cada pedido com o produto teria que ser atualizado.

Em outras palavras, com bancos de dados orientados a documentos, como o Elasticsearch, projetamos nossos mapeamentos e armazenamos nossos documentos de forma otimizada para pesquisa e recuperação.

A maioria dos bancos de dados relacionais também permite especificar restrições para definir o que é e o que não é consistente. Por exemplo, integridade referencial e exclusividade podem ser aplicadas. Você pode exigir que a soma dos movimentos da conta seja positiva e assim por diante. Bases de dados orientadas a documentos tendem a não fazer isso, e o Elasticsearch não é diferente.

Saiba como encontrar e remover documentos duplicados no Elasticsearch.

Robustez

Um banco de dados deve ser robusto. Idealmente, deve ser possível cancelar uma costly query e você certamente não quer que o banco de dados pare de funcionar.

Infelizmente, o Elasticsearch atualmente não lida com erros OutOfMemory muito bem. É importante fornecer ao Elasticsearch memória suficiente e ter cuidado antes de executar pesquisas com requisitos de memória desconhecidos em um cluster de produção.

Embora seja provável que isso melhore à medida que o Elasticsearch se desenvolva, é importante lembrar que ele é construído para velocidade, com a suposição de que a memória é abundante

Saiba como criar um Dockerfile para Elasticsearch.

Distribuído

Antes de Shay Banon criar o Elasticsearch, ele estava trabalhando no Compass. Percebendo que seria difícil transformá-lo em um mecanismo de pesquisa distribuído, ele começou do zero e criou o Elasticsearch - projetado para ser distribuído e fácil de escalar para lidar com grandes quantidades de dados.

O Elasticsearch é incrivelmente fácil de usar, mas os sistemas distribuídos geralmente são complicados. A própria natureza de um sistema distribuído implica em uma infinidade de coisas que podem dar errado. Como tal, diferentes sistemas de banco de dados focam em diferentes pontos: alguns lutam por garantias fortes e outros por estarem sempre disponíveis. Além disso, o que um sistema de banco de dados alega alcançar quando ocorre um problema raramente é o que ele realmente enfrenta.

Em termos de consistência, disponibilidade e tolerância a partições, o Elasticsearch é um sistema CP, para uma definição bastante fraca de "consistente". Se você tiver uma carga de trabalho somente de leitura, o Elasticsearch permitirá que você atinja o comportamento do AP tendo um "mínimo de masternodes", ou seja, não exigindo um quorum. Geralmente, você precisará que a maioria dos nós no cluster esteja disponível. Escrever em um cluster mal configurado sem essa maioria, ou seja, cluster com um "split brain", pode resultar em perda de dados irrecuperável.

Em termos de escala, um índice é dividido em um ou mais fragmentos. Isso é especificado quando o índice é criado e não pode ser alterado. Assim, um índice deve ser dividido proporcionalmente com o crescimento esperado. À medida que mais nós são adicionados a um cluster do Elasticsearch, ele faz um bom trabalho ao realocar e mover os fragmentos. Como tal, o Elasticsearch é muito fácil de escalar.

Segurança

O Elasticsearch não possui recursos para autenticação ou autorização. Você deve considerar qualquer pessoa que possa se conectar ao seu cluster do Elasticsearch para ter direitos de "super user", especialmente se os poderosos recursos de script do Elasticsearch estiverem habilitados.

Conclusão

Certamente é possível usar o Elasticsearch como um repositório principal. Um bom exemplo é quando se usa o Logstash - uma ferramenta fantástica para gerenciar logs e enviá-los ao Elasticsearch, além de arquivá-los em outro lugar apenas por precaução.

E quanto a sistemas como o Postgres, que vêm com pesquisa de texto completo e transações ACID? (Outros exemplos são os recursos de texto completo do MySQL, MongoDB, Riak etc.) Embora você possa implementar a pesquisa básica com o Postgres, há uma grande lacuna no desempenho e nos recursos. Como mencionado na seção sobre transações, o Elasticsearch pode "trapacear" e fazer muito cache, sem se preocupar com o controle de simultaneidade de múltiplas versões, entre outras coisas. A pesquisa também é mais do que encontrar uma palavra-chave em um texto: trata-se de aplicar conhecimento específico de domínio para implementar bons modelos de relevância, fornecer uma visão geral dos resultados e realizar tarefas como verificação ortográfica e autocompletar. Tudo de maneira rápida.

Fonte: Elastic