O Lindorm oferece múltiplos engines: o engine de tabela ampla, engine de séries temporais, engine de busca, engine de computação e engine de streaming. Esses engines são compatíveis com APIs de código aberto como HBase, Cassandra, S3, OpenTSDB, Solr e HDFS , além de oferecer suporte a consultas SQL, processamento de séries temporais e busca full-text.
Cada engine pode ser dimensionado de forma independente para se adaptar a cargas de trabalho dinâmicas. O engine de tabela ampla e o engine de séries temporais oferecem throughput de alta concorrência.
Selecione um engine
Selecione um ou mais engines de acordo com suas necessidades. A tabela a seguir descreve cada engine.
|
Engine |
Compatibilidade |
Cenário |
Descrição |
|
Engine de tabela ampla (LindormTable) |
Compatível com SQL, a API do HBase, Cassandra Query Language (CQL) e a API do Amazon S3. |
Adequado para gerenciar e analisar metadados, pedidos, faturas, personas de usuários, informações sociais, feeds, logs e trajetórias. |
Engine distribuído para dados semiestruturados e estruturados em larga escala. Suporta índices secundários globais, buscas multidimensionais, colunas dinâmicas e TTL. Processa dezenas de milhões de requisições concorrentes e armazena até centenas de petabytes de dados. Em comparação com o HBase de código aberto: throughput de leitura/escrita de 3 a 7 vezes superior, latência P99 dez vezes menor, taxa de compressão duas vezes maior e custo de armazenamento 50% inferior. Inclui separação de dados quentes e frios. O service integrado GanosBase oferece suporte a dados espaciais e espaço-temporais para consultas de trajetórias históricas em larga escala. |
|
Engine de séries temporais (LindormTSDB) |
Fornece uma API HTTP e é compatível com a API do OpenTSDB. |
Indicado para armazenar e processar dados de séries temporais, como dados de medição e dados operacionais de dispositivos em cenários de IoT e monitoramento. |
Engine distribuído otimizado para dados de séries temporais. Suporta consultas SQL, algoritmos de compressão dedicados para séries temporais com taxas de compressão aprimoradas, consultas e agregações multidimensionais de linhas temporais, downsampling e dimensionamento elástico. |
|
Engine de busca (LindormSearch) |
Compatível com SQL e as APIs do Apache Solr e Elasticsearch. |
Projetado para consultar grandes volumes de dados, como logs, textos e documentos. Por exemplo, é possível pesquisar logs, faturas e personas de usuários. |
Engine de busca distribuído com armazenamento e computação desacoplados. Indexa dados dos engines de tabela ampla e de séries temporais de forma transparente para acelerar consultas. Suporta busca full-text, agregação, consultas multidimensionais complexas, dimensionamento horizontal, arquitetura de escrita única com múltiplas leituras, recuperação de desastres entre zonas e TTL. |
|
Engine de computação (LDPS) |
Compatível com a API do Apache Spark. |
Recomendado para cenários como produção de grandes volumes de dados, análises interativas, aprendizado computacional e computação em grafos. |
Service de computação distribuída cloud-native compatível com os modelos e APIs do Spark da comunidade. Profundamente integrado aos engines de armazenamento do Lindorm para aproveitar recursos de dados subjacentes e índices na execução eficiente de jobs distribuídos. |
|
Engine de streaming |
Compatível com SQL e a API do Apache Kafka. |
Mais indicado para cenários como processamento de dados de IoT, processamento de logs de aplicação, análise de prazos logísticos, processamento de dados de viagens e processamento de trajetórias em tempo real. |
Engine para armazenamento e computação leve de dados de streaming. Armazena dados de streaming no Lindorm para processamento em tempo real. Combinado com o service GanosBase do engine de tabela ampla, viabiliza análises de trajetória em tempo real, como geofencing e estatísticas regionais. |
Selecione as especificações e a quantidade de nós
O Lindorm suporta scale-out horizontal dos nós de engine. Adicionar nós resolve problemas como alta latência e desempenho instável. No entanto, apenas adicionar nós não resolve problemas de hotspot em um único nó — nesse caso, é necessário atualizar a especificação do nó. A especificação do nó determina a capacidade de tratamento de hotspot por nó. Nós com especificações inferiores podem sofrer carga excessiva ou erros de falta de memória (OOM) sob tráfego intenso.
Avalie sua carga de trabalho e escolha especificações de nó adequadas. Para atualizar as especificações dos nós, utilize o console do Lindorm. Para mais informações, consulte Change instance type. Para obter assistência, entre em contato com o suporte técnico do Lindorm (ID DingTalk: s0s3eg3).
Engine de tabela ampla (LindormTable)
Os nós do LindormTable suportam especificações de 4 cores / 8 GB até 32 cores / 256 GB, com scale-out horizontal. Escolha uma especificação com base na taxa de requisições por nó (linhas/s) e na contagem de regions.
Quando Product Type está defina como Lindorm, a especificação mínima do LindormTable é 4 cores / 16 GB.
Algumas otimizações de desempenho exigem nós com mais de 16 GB de memória, e determinadas otimizações de escrita requerem pelo menos 3 nós. Recomenda-se no mínimo 3 nós com 8 cores / 32 GB cada (preferencialmente 16 cores / 64 GB).
Especificações recomendadas:
< 1.000 requisições/s por nó, < 500 regions por nó: 4 cores / 16 GB.
< 20.000 requisições/s por nó, < 1.000 regions por nó: 8 cores / 32 GB ou superior.
-
> 20.000 requisições/s por nó, > 1.000 regions por nó: 16 cores / 64 GB ou superior.
ImportanteA taxa de requisições e a contagem de regions não são os únicos fatores para a escolha das especificações dos nós.
-
Para cargas de trabalho complexas, as recomendações acima podem ser insuficientes. Escolha uma especificação superior se qualquer uma das situações a seguir se aplicar:
O tamanho das linhas atinge kilobytes ou megabytes.
As requisições SCAN utilizam filtros complexos.
A taxa de acerto do cache é baixa — a maioria das requisições lê dados do disco.
A instância contém muitas tabelas.
Para services online, opte por mais memória para melhorar as taxas de acerto do cache.
Para tarefas offline de carga pesada (MapReduce, Spark) ou TPS/QPS muito elevados, priorize mais cores de CPU.
Se a utilização de CPU permanecer em 70% ou acima, considere atualizar a especificação do nó.
-
Engine de séries temporais (LindormTSDB)
Os nós do LindormTSDB suportam especificações de 4 cores / 8 GB até 32 cores / 256 GB. Selecione a especificação e a quantidade de nós com base no seu TPS (pontos de medição/segundo).
Quando Product Type está defina como Lindorm, a especificação mínima do LindormTSDB é 4 cores / 16 GB.
Especificações recomendadas (cluster de 3 nós):
TPS < 1,9M: 4 cores / 16 GB por nó.
TPS < 3,9M: 8 cores / 32 GB por nó.
TPS < 7,8M: 16 cores / 64 GB por nó.
TPS < 11M: 32 cores / 128 GB por nó.
Essas recomendações pressupõem desempenho ideal de processamento de dados. A capacidade real depende do seu modelo de negócio, tamanho do lote e concorrência. Para mais informações, consulte Results of write tests e Query test results.