Em maio, uma nova versão do
Apache Ignite foi lançada - 2.5. Muitas alterações foram feitas, uma lista completa das quais podem ser encontradas nas Notas da Versão. E neste artigo, consideraremos as principais inovações que merecem atenção.
O Apache Ignite é uma plataforma horizontalmente escalável para armazenamento transacional de dados, bem como computação distribuída sobre esses dados no modo quase em tempo real.
O Ignite é usado quando é necessária escalabilidade horizontal e velocidade de processamento de dados muito alta. O último também é alcançado otimizando a plataforma para armazenar dados diretamente na RAM como armazenamento primário, e não como cache (computação na memória). Os recursos distintos do produto são um mecanismo de consulta completo ANSI SQL 1999, armazenamento em disco, RAM expansível, um grande número de ferramentas de integração integradas e aprendizado de máquina Zero-ETL.
Entre as empresas que usam o Apache Ignite estão empresas como
Veon / Beeline ,
Sberbank, Huawei, Barclays, Citi, Microsoft e muitas outras .
Nova opção de topologia: a estrela do ZooKeeper
Uma das principais alterações na versão 2.5 é uma nova versão da topologia. Anteriormente, o Ignite tinha apenas uma topologia em "anel", usada para trocar eventos em um cluster e fornecia escalabilidade rápida e eficiente, em uma escala de até 300 nós.
A nova topologia foi projetada para instalações de muitas centenas e milhares de nós.
Agora você pode escolher: use a topologia antiga, onde o Ignite é suficiente para você, ou - para clusters grandes -
complemente o Ignite grande com um pequeno ZooKeeper, através do qual a troca de eventos ocorrerá.
Por que isso e como isso ajuda?
O grande "anel" tem uma desvantagem: levando em consideração a troca e o processamento da rede, a notificação de todos os nós sobre um novo evento pode chegar a segundos. Isso é ruim por si só e se você levar em conta que a probabilidade de falha de um nó devido a uma falha temporária da rede, equipamento ou outros problemas aumenta com o tamanho do cluster, a reconstrução da topologia se torna uma tarefa bastante comum, especialmente em clusters construídos em hardware (de commodity) barato. No grande "anel", isso introduz caos adicional, interrompe o processamento do fluxo de eventos e o força a recomeçar, transmitindo simultaneamente informações sobre a nova topologia.
A nova “estrela”, onde o cluster do ZooKeeper está localizado no centro, permite não apenas manter a escalabilidade (o ZooKeeper também pode crescer horizontalmente), mas também aumentar significativamente sua escalabilidade - eficiência em grandes volumes. Afinal, compartilhando a responsabilidade de processar eventos e trabalhar com dados, podemos alocar um cluster ZooKeeper muito mais compacto para o processamento de eventos, reduzindo assim a dependência de eventos no tamanho do cluster.
Isso não afeta a troca de dados entre os nós do Ignite, por exemplo, durante o reequilíbrio, bem como o armazenamento ou a recuperação de dados, porque todas essas operações percorreram a topologia do evento por meio de conexões diretas entre os nós do cluster.
Além disso, adicionar uma nova topologia não afeta a antiga de nenhuma maneira - ela ainda é recomendada, pois é muito mais fácil de manter e mais leve, não requer elementos adicionais.
Mas se você atingiu o limite de escalar o “anel” do Ignite, não pode se envolver em microoptimização e hackers, não aplique conhecimentos específicos e “muletas”. Nesse caso, você tem uma solução oficialmente disponível e suportada que facilitará significativamente a implementação e o suporte de um cluster tão grande.
Informações detalhadas sobre a nova topologia podem ser
encontradas na documentação .
Thin Clients: Thin Java Client, autenticação de Thin Client
Na versão 2.4, foi fornecido suporte para thin clients fora do JDBC / ODBC, que não são participantes completos da topologia, exigem muito menos recursos, mas ao mesmo tempo oferecem funcionalidade reduzida. O primeiro thin client foi o cliente para .NET.
A partir da versão 2.5, um thin client para Java também está disponível.
Isso permite que o Ignite seja incorporado em aplicativos sensíveis a recursos, por exemplo, em aplicativos em dispositivos terminais, sem nenhuma camada extra. Anteriormente, essa tarefa exigia uma camada intermediária, que, por exemplo, via REST, recebia solicitações e, em seguida, usava o cliente interno “grosso” para trocar dados com o cluster Ignite.
O thin client pode ser usado conectando o arquivo JAR do núcleo de ignição "dependência zero" padrão, por exemplo, no repositório maven.
Um exemplo de uso de um thin client:
ClientConfiguration cfg = new ClientConfiguration().setAddresses("127.0.0.1:10800"); try (IgniteClient igniteClient = Ignition.startClient(cfg)) { System.out.println(">>> ."); final String CACHE_NAME = "put-get-example"; ClientCache<Integer, Address> cache = igniteClient.getOrCreateCache(CACHE_NAME); System.out.format(">>> [%s].\n", CACHE_NAME); Integer key = 1; Address val = new Address(", 20", 101000); cache.put(key, val); System.out.format(">>> [%s] .\n", val); Address cachedVal = cache.get(key); System.out.format(">>> [%s] .\n", cachedVal); } catch (...) { ... }
Também na versão 2.4, não havia autenticação para thin clients. A partir da versão 2.5, ele, juntamente com o suporte à criptografia ao acessar thin clients, será lançado no Ignite.
ClientConfiguration clientCfg = new ClientConfiguration() .setAddresses("127.0.0.1:10800");
Informações detalhadas podem ser
encontradas na documentação .
SQL: autenticação e gerenciamento de usuários, carregamento em massa rápido
O mecanismo SQL ANSI99 distribuído tem sido historicamente um dos pontos fortes e importantes recursos distintivos do Apache Ignite. Ele permite que uma "janela única", por meio do cliente Java / .NET / C ++ ou do driver JDBC / ODBC, execute consultas SQL sobre todo o cluster, na RAM e no Ignite Native Persistence.
Nas versões 2.0–2.4, os desenvolvedores se concentraram, além de aumentar a produtividade (o que nunca é suficiente), também em acelerar o carregamento de dados primários e em massa e suporte mais completo a DDL, operações como CREATE TABLE, ALTER TABLE, CREATE INDEX etc. que também através de uma "janela única" poderia ser consistentemente executada no cluster.
Na versão 2.5, foi dado um passo em direção ao desenvolvimento adicional de DDL: autenticação para SQL e os comandos correspondentes
CREATE USER ,
ALTER USER ,
DROP USER foram adicionados.
Se você planejou anteriormente hospedar o Ignite SQL em uma DMZ estéril com controle de acesso no nível de serviços subjacentes, agora poderá aumentar a segurança com a autenticação gerenciada por SQL.
Em termos de velocidade de download de grandes volumes de dados, surgiram 2,5 inovações em 2.
O primeiro é o
novo comando COPY SQL no JDBC, que permite transferir rapidamente, no modo em massa, o conteúdo de um arquivo CSV para uma tabela.
COPY FROM "/path/to/local/file.csv" INTO city ( ID, Name, CountryCode, District, Population) FORMAT CSV
O segundo é o modo de streaming para JDBC, ativado por meio do
novo comando SET . Ele permite carregar dados através de operações INSERT padrão para agrupar de forma transparente e carregar de maneira ideal novos registros no cluster Ignite. A transferência de operações acumuladas para o cluster ocorre ao preencher um lote ou ao fechar uma conexão JDBC.
SET STREAMING ON
Machine Learning: Algoritmos Genéticos, Particionamento
O aprendizado de máquina é uma das áreas estratégicas de desenvolvimento da Ignite. O ML implementa o paradigma Zero-ETL, que permite o treinamento diretamente nos dados que estão no armazenamento transacional Ignite. Assim, são alcançadas economias significativas de tempo e recursos na conversão de dados e na transferência de rede para um sistema de treinamento.
Na versão 2.5,
algoritmos genéticos são adicionados ao conjunto de ferramentas acessíveis.
Além disso, para otimizar o processo de aprendizado e minimizar a troca de rede, apareceu suporte para cálculos de ML, que contêm informações sobre as partições nas quais são executadas e são capazes de vincular informações adicionais a essas partições. Considerando que as partições são atômicas em termos de distribuição e uma partição não pode ser cortada entre vários nós, isso permite otimizar o processo de aprendizado, fornecendo mais garantias ao algoritmo.
Informações detalhadas podem ser
encontradas na documentação .
E muito mais
Também na versão 2.5, é implementado: