<\/a><\/noindex><\/p>\nEnt\u00e3o, aqui est\u00e1 o que aprendemos com essa experi\u00eancia.<\/h2>\n <\/p>\n
Sim, um n\u00f3 fora do ar n\u00e3o \u00e9 uma trag\u00e9dia. Essa \u00e9 a ess\u00eancia da resili\u00eancia da Cassandra. Mas um n\u00f3 pode estar ativo e ainda assim come\u00e7ar a apresentar uma queda de desempenho.<\/b>. Como se viu, isso se reflete imediatamente no desempenho de todo o cluster.<\/p>\n
<\/p>\n
A Cassandra n\u00e3o ir\u00e1 oferecer garantias onde o Oracle salvava com suas restri\u00e7\u00f5es.<\/b>. E se o autor do aplicativo n\u00e3o percebeu isso com anteced\u00eancia, um duplicado que chega para a Cassandra n\u00e3o \u00e9 pior que o original. Se chegou, ent\u00e3o vamos inserir.<\/p>\n
<\/p>\n
A Cassandra gratuita \"de f\u00e1brica\" rapidamente n\u00e3o agradou \u00e0 seguran\u00e7a da informa\u00e7\u00e3o: n\u00e3o h\u00e1 registro das a\u00e7\u00f5es dos usu\u00e1rios, nem restri\u00e7\u00f5es de direitos.<\/b>. As informa\u00e7\u00f5es sobre chamadas referem-se a dados pessoais, o que significa que todas as tentativas de solicit\u00e1-los ou alter\u00e1-los devem ser registradas com a possibilidade de auditoria futura. Tamb\u00e9m \u00e9 necess\u00e1rio ter consci\u00eancia da necessidade de separar os direitos em diferentes n\u00edveis para diferentes usu\u00e1rios. Um engenheiro de opera\u00e7\u00f5es comum e um superadministrador, que pode excluir livremente todo o keyspace \u2013 s\u00e3o pap\u00e9is diferentes, com responsabilidades e compet\u00eancias distintas. Sem essa clara distin\u00e7\u00e3o de direitos de acesso, o valor e a integridade dos dados ser\u00e3o colocados em d\u00favida mais rapidamente do que em um n\u00edvel de consist\u00eancia ANY. <\/p>\n
<\/p>\n
N\u00e3o consideramos que as chamadas requerem tanto an\u00e1lises s\u00e9rias quanto amostragens peri\u00f3dicas sob v\u00e1rias condi\u00e7\u00f5es. Como os registros selecionados devem ser exclu\u00eddos e sobrescritos (no \u00e2mbito da tarefa, precisamos manter o processo de atualiza\u00e7\u00e3o de dados quando os dados que nos chegaram inicialmente n\u00e3o estavam corretos), o Cassandra n\u00e3o \u00e9 nosso amigo aqui. Cassandra, como um cofre \u2013 \u00e9 conveniente para armazenar, mas n\u00e3o se consegue contar nela.<\/b><\/p>\n
<\/p>\n
Enfrentamos o problema de transferir dados para zonas de teste.<\/b> (5 n\u00f3s no teste contra 20 na produ\u00e7\u00e3o). Em tal caso, n\u00e3o ser\u00e1 poss\u00edvel usar o dump.<\/p>\n
<\/p>\n
O problema das atualiza\u00e7\u00f5es do esquema de dados do aplicativo que grava no Cassandra. Um rollback gerar\u00e1 uma grande quantidade de tombstones, o que pode de forma imprevis\u00edvel afetar nosso desempenho.<\/b>. Cassandra \u00e9 otimizada para escrita, e antes de gravar, n\u00e3o pensa muito. Qualquer opera\u00e7\u00e3o com dados existentes nela \u2013 tamb\u00e9m \u00e9 uma grava\u00e7\u00e3o. Ou seja, ao eliminar dados desnecess\u00e1rios, estaremos apenas gerando mais registros, e apenas uma parte deles ser\u00e1 marcada como tombstones.<\/p>\n
<\/p>\n
Timeouts durante a inser\u00e7\u00e3o. Cassandra \u00e9 excelente para grava\u00e7\u00f5es, mas \u00e0s vezes o fluxo de entrada pode deix\u00e1-la bastante confusa.<\/b>. Isso acontece quando o aplicativo come\u00e7a a tentar inserir repetidamente alguns registros que n\u00e3o podem ser inseridos por algum motivo. E precisaremos de um verdadeiro DBA para acompanhar o gc.log, os logs system e debug em busca de slow queries e m\u00e9tricas sobre compaction pending.\n<\/p>\n
<\/p>\n
V\u00e1rios data centers no cluster. De onde ler e para onde escrever?<\/b>
<\/p>\n
Como resolvemos<\/h2>\n <\/p>\n
Para que o n\u00f3 n\u00e3o regrida, desativamos o SWAP<\/b>. E agora, quando a mem\u00f3ria acaba, o n\u00f3 deve cair, em vez de gerar grandes pausas de gc.<\/p>\n
<\/p>\n
Portanto, n\u00e3o contamos mais com a l\u00f3gica no banco de dados. Os desenvolvedores do aplicativo est\u00e3o se adaptando e come\u00e7am a se precaver ativamente em seu pr\u00f3prio c\u00f3digo.<\/b> Uma divis\u00e3o perfeita e clara entre armazenamento e processamento de dados.<\/p>\n
<\/p>\n
Compramos suporte da DataStax.<\/b> A Cassandra em caixa j\u00e1 n\u00e3o est\u00e1 mais sendo desenvolvida (o \u00faltimo commit foi em fevereiro de 2018). Ao mesmo tempo, a Datastax oferece um excelente servi\u00e7o e uma grande quantidade de solu\u00e7\u00f5es desenvolvidas e adaptadas para sistemas existentes.<\/p>\n
<\/p>\n
Quero tamb\u00e9m destacar que a Cassandra n\u00e3o \u00e9 muito conveniente para consultas de sele\u00e7\u00e3o. Claro, o CQL \u00e9 um grande avan\u00e7o para os usu\u00e1rios (comparado ao Thrift). Mas se voc\u00ea tem departamentos inteiros acostumados a joins t\u00e3o convenientes, filtragens livres por qualquer campo e possibilidades de otimiza\u00e7\u00e3o de consultas, e esses departamentos est\u00e3o trabalhando para resolver reclama\u00e7\u00f5es e incidentes, a solu\u00e7\u00e3o com Cassandra parece a eles uma escolha hostil e sem sentido. E come\u00e7amos a resolver como nossos colegas poderiam realizar as sele\u00e7\u00f5es. <\/p>\n
<\/p>\n
Consideramos duas op\u00e7\u00f5es. Na primeira, escrevemos as chamadas n\u00e3o apenas no C*, mas tamb\u00e9m no banco de dados Oracle arquiv\u00edstico. No entanto, ao contr\u00e1rio do C*, neste banco de dados s\u00e3o armazenadas apenas as chamadas do m\u00eas atual (profundidade de armazenamento suficiente para casos de reaprecia\u00e7\u00e3o). Aqui j\u00e1 se via o seguinte problema: se escrevemos de forma s\u00edncrona, perdemos todas as vantagens do C*, relacionadas \u00e0 inser\u00e7\u00e3o r\u00e1pida; se o fizermos de forma ass\u00edncrona, n\u00e3o h\u00e1 garantia de que todas as chamadas necess\u00e1rias realmente cheguem ao Oracle. Havia uma vantagem, mas significativa: para explora\u00e7\u00e3o, continua sendo o mesmo PL\/SQL Developer familiar, ou seja, praticamente implementamos o padr\u00e3o \u201cFachada\u201d. Op\u00e7\u00e3o alternativa. Implementamos um mecanismo que extrai chamadas do C*, busca alguns dados para enriquecimento das tabelas correspondentes no Oracle, junta os conjuntos obtidos e nos fornece o resultado que depois usamos de alguma forma (rollback, repeti\u00e7\u00e3o, an\u00e1lise, admira\u00e7\u00e3o). Desvantagens: o processo acaba sendo bastante complexo, al\u00e9m disso, falta uma interface para os funcion\u00e1rios de opera\u00e7\u00e3o.<\/p>\n
<\/p>\n
No final, decidimos pela segunda op\u00e7\u00e3o. Para as extra\u00e7\u00f5es de diferentes bancos, utilizamos o Apache Spark.<\/b> A ess\u00eancia do mecanismo se resumiu a um c\u00f3digo Java que, com base nas chaves especificadas (assinante, hor\u00e1rio da chamada \u2013 chaves da se\u00e7\u00e3o), extrai os dados do C* e tamb\u00e9m os dados necess\u00e1rios para enriquecimento de qualquer outro banco de dados. Em seguida, junta-os em sua mem\u00f3ria e produz o resultado em uma tabela resultante. Acima do Spark, desenhamos uma interface web e isso se tornou bastante utiliz\u00e1vel.<\/p>\n
\n
Ao abordar a tarefa de atualiza\u00e7\u00e3o dos dados, o teste de produ\u00e7\u00e3o novamente considerou v\u00e1rias formas de solu\u00e7\u00e3o. Tanto a transfer\u00eancia via Sstloader quanto a op\u00e7\u00e3o de dividir o cluster na zona de teste em duas partes, cada uma das quais alternadamente acessa um cluster de produ\u00e7\u00e3o, alimentando-se assim dele. Na atualiza\u00e7\u00e3o do teste, estava planejado alternar suas posi\u00e7\u00f5es: a parte que funcionou no teste seria limpa e introduzida na produ\u00e7\u00e3o, enquanto a outra come\u00e7aria a trabalhar com os dados separadamente. No entanto, refletindo mais uma vez, avaliamos de forma mais racional quais dados valem a pena transferir e percebemos que as chamadas em si s\u00e3o uma entidade inconsistente para os testes, geradas rapidamente quando necess\u00e1rio, e exatamente o conjunto de dados de produ\u00e7\u00e3o n\u00e3o tem valor para transfer\u00eancia para o teste. Existem v\u00e1rios objetos acumuladores que realmente valem a pena transferir, mas s\u00e3o literalmente algumas tabelas, que n\u00e3o s\u00e3o muito pesadas. Portanto, n\u00f3s como solu\u00e7\u00e3o, novamente cont\u00e1mos com a ajuda do Spark, com o qual escrevemos e come\u00e7amos a usar ativamente um script para transfer\u00eancia de dados entre as tabelas de produ\u00e7\u00e3o e teste.<\/b><\/p>\n
<\/p>\n
Nossa pol\u00edtica atual de deployment nos permite operar sem rollbacks.<\/b> Antes da produ\u00e7\u00e3o, h\u00e1 uma obrigat\u00f3ria aplica\u00e7\u00e3o no teste, onde o erro n\u00e3o \u00e9 t\u00e3o caro. Em caso de falha, sempre \u00e9 poss\u00edvel descartar o keyspace e aplicar todo o esquema desde o in\u00edcio.<\/p>\n
<\/p>\n
Para garantir a disponibilidade cont\u00ednua do Cassandra, \u00e9 necess\u00e1rio ter um DBA e n\u00e3o apenas ele. Todos que trabalham com a aplica\u00e7\u00e3o devem entender onde e como monitorar a situa\u00e7\u00e3o atual e como diagnosticar problemas pontualmente.<\/b> Para isso, usamos ativamente o DataStax OpsCenter (administra\u00e7\u00e3o e monitoramento de cargas de trabalho), as m\u00e9tricas do sistema Cassandra Driver (n\u00famero de timeouts em grava\u00e7\u00e3o no C*, n\u00famero de timeouts em leitura do C*, lat\u00eancia m\u00e1xima, etc.), monitoramos o desempenho da pr\u00f3pria aplica\u00e7\u00e3o que interage com o Cassandra.\n<\/p>\n
<\/p>\n
Ao refletirmos sobre a quest\u00e3o anterior, percebemos onde pode estar o principal risco. Trata-se das formas de exibi\u00e7\u00e3o de dados que extraem informa\u00e7\u00f5es de v\u00e1rias consultas independentes ao armazenamento. Assim, podemos obter informa\u00e7\u00f5es bastante inconsistentes. Mas esse problema tamb\u00e9m seria relevante se estiv\u00e9ssemos trabalhando apenas com um \u00fanico datacenter. Portanto, a solu\u00e7\u00e3o mais sensata aqui \u00e9, sem d\u00favida, criar uma fun\u00e7\u00e3o de leitura em lote em um aplicativo externo, que garantir\u00e1 a coleta de dados em um \u00fanico per\u00edodo de tempo. Quanto \u00e0 separa\u00e7\u00e3o entre opera\u00e7\u00f5es de leitura e grava\u00e7\u00e3o em termos de desempenho, fomos paralisados pelo risco de que, em caso de alguma perda de conex\u00e3o entre os datacenters, poder\u00edamos obter dois clusters completamente incongruentes.<\/p>\n
<\/p>\n
No final, atualmente ficamos com o n\u00edvel de consist\u00eancia para grava\u00e7\u00e3o EACH_QUORUM e para leitura \u2013 LOCAL_QUORUM<\/b><\/p>\n
<\/p>\n
Impress\u00f5es e Conclus\u00f5es Resumidas<\/h2>\n <\/p>\n
Para avaliar a solu\u00e7\u00e3o resultante do ponto de vista do suporte operacional e das perspectivas de desenvolvimento futuro, decidimos considerar onde mais essa abordagem pode ser aplicada.<\/p>\n
<\/p>\n
Se pensarmos rapidamente, o escore de dados para programas como 'Pague quando puder' (carregamos informa\u00e7\u00f5es em C*, c\u00e1lculo realizado em scripts Spark), gest\u00e3o de reclama\u00e7\u00f5es com agrega\u00e7\u00e3o por categorias, armazenamento de pap\u00e9is e c\u00e1lculo da matriz de direitos de acesso dos usu\u00e1rios. <\/p>\n
<\/p>\n
Como podemos ver, o repert\u00f3rio \u00e9 amplo e diversificado. E se tivermos que escolher um lado entre os apoiadores e opositores do NoSQL, nos uniremos aos apoiadores, pois obtivemos benef\u00edcios, especialmente nas \u00e1reas que esper\u00e1vamos.<\/p>\n
<\/p>\n
At\u00e9 mesmo a vers\u00e3o do Cassandra out-of-the-box permite escalonamento horizontal em tempo real, resolvendo de forma absolutamente indolor a quest\u00e3o do aumento de dados no sistema. Conseguimos separar em um contorno um mecanismo altamente carregado para calcular agregados de chamadas, al\u00e9m de dividir o esquema e a l\u00f3gica do aplicativo, livrando-nos da pr\u00e1tica viciosa de escrever jobs e objetos personalizados diretamente no banco de dados. Obtivemos a capacidade de escolher e ajustar, para acelerar, em quais datacenters realizaremos o c\u00e1lculo e em quais gravaremos dados, protegendo-nos contra quedas, tanto de n\u00f3s individuais quanto do datacenter como um todo.<\/p>\n
<\/p>\n
Ao aplicar nossa arquitetura a novos projetos, e j\u00e1 tendo alguma experi\u00eancia, seria interessante levar em considera\u00e7\u00e3o as nuances descritas acima desde o in\u00edcio, evitando certas falhas e suavizando alguns pontos cr\u00edticos que n\u00e3o conseguimos evitar no in\u00edcio.<\/p>\n
<\/p>\n
Por exemplo, monitorar atualiza\u00e7\u00f5es da pr\u00f3pria Cassandra em tempo h\u00e1bil<\/b>, pois muitos dos problemas que encontramos j\u00e1 eram conhecidos e corrigidos.<\/p>\n
<\/p>\n
N\u00e3o instalar tanto o banco de dados quanto o Spark nos mesmos n\u00f3s<\/b> ou estritamente dividir de acordo com a quantidade de recursos permitida, j\u00e1 que o Spark pode consumir mais mem\u00f3ria do que o permitido, e rapidamente enfrentaremos o problema n\u00famero 1 da nossa lista.<\/p>\n
<\/p>\n
Desenvolver o monitoramento e a compet\u00eancia na opera\u00e7\u00e3o j\u00e1 na fase de testes do projeto. <\/b>Considerar ao m\u00e1ximo todos os potenciais consumidores da nossa solu\u00e7\u00e3o desde o in\u00edcio<\/b>, pois \u00e9 isso que, no final, determinar\u00e1 a estrutura do banco de dados.<\/p>\n
<\/p>\n
Rodar algumas vezes o esquema resultante para identificar poss\u00edveis otimiza\u00e7\u00f5es. Determinar quais campos podem ser serializados. Compreender quais tabelas adicionais precisamos criar para considerar da maneira mais precisa e otimizada as informa\u00e7\u00f5es e, posteriormente, fornecer as informa\u00e7\u00f5es solicitadas (por exemplo, considerando que os mesmos dados podem ser armazenados em tabelas diferentes, levando em conta diferentes crit\u00e9rios, podemos economizar consideravelmente o tempo do processador durante as leituras).<\/p>\n
<\/p>\n
Seria bom prever imediatamente a adi\u00e7\u00e3o de TTL e a limpeza de dados obsoletos.<\/b><\/p>\n
<\/p>\n
Ao extrair dados da Cassandra a l\u00f3gica do aplicativo deve operar de acordo com o princ\u00edpio FETCH, para que n\u00e3o todas as linhas sejam carregadas na mem\u00f3ria de uma s\u00f3 vez, mas selecionadas em lotes.<\/b><\/p>\n
<\/p>\n
\u00c9 desej\u00e1vel verificar a resist\u00eancia a falhas do sistema antes de migrar o projeto para a solu\u00e7\u00e3o descrita realizando uma s\u00e9rie de testes de falhas<\/b>, como perda de dados em um datacenter, recupera\u00e7\u00e3o de dados corrompidos ap\u00f3s um determinado per\u00edodo, quedas de rede entre datacenters. Esses testes n\u00e3o apenas permitir\u00e3o avaliar os pr\u00f3s e contras da arquitetura proposta, mas tamb\u00e9m fornecer\u00e3o uma boa pr\u00e1tica para os engenheiros que os realizam, e a habilidade adquirida ser\u00e1 muito \u00fatil se as falhas do sistema ocorrerem em produ\u00e7\u00e3o.<\/p>\n
<\/p>\n
Se estamos lidando com informa\u00e7\u00f5es cr\u00edticas (como dados para faturamento, c\u00e1lculo de d\u00e9bitos de clientes), \u00e9 importante tamb\u00e9m prestar aten\u00e7\u00e3o aos instrumentos que possam reduzir os riscos associados \u00e0s especificidades do SGBD. Por exemplo, usar a ferramenta nodesync (Datastax), desenvolvendo uma estrat\u00e9gia otimizada para seu uso, para n\u00e3o gerar carga excessiva no Cassandra em prol da consist\u00eancia.<\/b> e utiliz\u00e1-la apenas para tabelas espec\u00edficas em per\u00edodos determinados.<\/p>\n
<\/p>\n
Ent\u00e3o, ap\u00f3s seis meses de uso do Cassandra? Em geral, n\u00e3o h\u00e1 problemas pendentes. N\u00e3o tivemos quedas s\u00e9rias ou perda de dados. Sim, precisamos pensar na compensa\u00e7\u00e3o de alguns problemas que n\u00e3o haviam surgido antes, mas, no final, isso n\u00e3o prejudicou significativamente nossa solu\u00e7\u00e3o arquitet\u00f4nica. Se voc\u00ea est\u00e1 disposto a tentar algo novo e n\u00e3o tem medo de poss\u00edveis decep\u00e7\u00f5es, prepare-se para entender que nada \u00e9 gratuito. Voc\u00ea ter\u00e1 que se aprofundar na documenta\u00e7\u00e3o e lidar com suas pr\u00f3prias dificuldades mais do que em uma solu\u00e7\u00e3o legada antiga, e nenhuma teoria ir\u00e1 antecipar quais desafios espec\u00edficos voc\u00ea ir\u00e1 enfrentar.<\/p>\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0413\u043e\u0432\u043e\u0440\u044f\u0442, \u0432 \u0436\u0438\u0437\u043d\u0438 \u0432\u0441\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0440\u0430\u0437. \u0418 \u0435\u0441\u043b\u0438 \u0432\u044b \u043f\u0440\u0438\u0432\u044b\u043a\u043b\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0441 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438 \u0421\u0423\u0411\u0414, \u0442\u043e \u043f\u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0441 NoSQL \u0441\u0442\u043e\u0438\u0442 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0434\u043b\u044f \u043e\u0431\u0449\u0435\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 \u0432 \u0441\u0438\u043b\u0443 \u0431\u0443\u0440\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u044d\u0442\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u0440\u0435\u0447\u0438\u0432\u044b\u0445 \u043c\u043d\u0435\u043d\u0438\u0439 \u0438 \u0433\u043e\u0440\u044f\u0447\u0438\u0445 \u0441\u043f\u043e\u0440\u043e\u0432 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443, \u0447\u0442\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u043e\u0434\u043e\u0433\u0440\u0435\u0432\u0430\u0435\u0442 \u0438\u043d\u0442\u0435\u0440\u0435\u0441. \u0415\u0441\u043b\u0438 \u0432\u043d\u0438\u043a\u043d\u0443\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Como](\"\/wp-content\/uploads\/2019\/08\/4845d37a9928f888639c4ebeb7807787.jpg\")
![\"Como](\"\/wp-content\/uploads\/2019\/08\/c7b095dc8879011adb751c96427af512.jpg\")
<\/p>\n