Din que todo na vida paga a pena intentalo polo menos unha vez. E se estás afeito a traballar con DBMS relacionais, paga a pena familiarizarte con NoSQL na práctica, en primeiro lugar, polo menos para o desenvolvemento xeral. Agora, debido ao rápido desenvolvemento desta tecnoloxía, hai moitas opinións contrapostas e debates acalorados sobre este tema, o que alimenta especialmente o interese.
Se afondas na esencia de todas estas disputas, podes ver que xorden debido a un enfoque incorrecto. Os que usan bases de datos NoSQL exactamente onde son necesarios quedan satisfeitos e reciben todas as vantaxes desta solución. E os experimentadores que confían nesta tecnoloxía como panacea onde non é aplicable en absoluto quedan decepcionados, xa que perderon os puntos fortes das bases de datos relacionais sen obter beneficios significativos.
Vouvos contar a nosa experiencia na implementación dunha solución baseada no DBMS Cassandra: o que tivemos que afrontar, como saímos de situacións difíciles, se puidemos beneficiarnos do uso de NoSQL e onde tivemos que investir esforzos/fondos adicionais. .
A tarefa inicial é construír un sistema que rexistre as chamadas nalgún tipo de almacenamento.
O principio de funcionamento do sistema é o seguinte. A entrada inclúe ficheiros cunha estrutura específica que describe a estrutura da chamada. Despois, a aplicación garante que esta estrutura estea almacenada nas columnas adecuadas. No futuro, as chamadas gardadas utilízanse para mostrar información sobre o consumo de tráfico dos abonados (cobros, chamadas, historial de saldos).
Está bastante claro por que elixiron a Cassandra: ela escribe como unha metralleta, é facilmente escalable e tolerante a fallas.
Entón, isto é o que nos deu a experiencia
Si, un nodo fallido non é unha traxedia. Esta é a esencia da tolerancia ás culpas de Cassandra. Pero un nodo pode estar vivo e ao mesmo tempo comezar a sufrir no rendemento. Como se viu, isto afecta inmediatamente o rendemento de todo o clúster.
Cassandra non te protexerá onde Oracle te salvou coas súas limitacións. E se o autor da aplicación non entendeu isto de antemán, entón o dobre que chegou a Cassandra non é peor que o orixinal. Unha vez que chegue, poñémolo.
A IB non lle gustou moito a Cassandra libre fóra da caixa: Non hai rexistro de accións de usuario, nin diferenciación de dereitos. A información sobre as chamadas considérase datos persoais, o que significa que todos os intentos de solicitala/modificala de calquera forma deben rexistrarse coa posibilidade de realizar unha auditoría posterior. Ademais, cómpre ter en conta a necesidade de separar dereitos en diferentes niveis para diferentes usuarios. Un sinxelo enxeñeiro de operacións e un superadministrador que poden eliminar libremente todo o espazo clave son diferentes roles, diferentes responsabilidades e competencias. Sen esa diferenciación de dereitos de acceso, o valor e a integridade dos datos entrarán en cuestión inmediatamente máis rápido que con CALQUERA nivel de consistencia.
Non tivemos en conta que as chamadas requiren tanto análises serias como mostraxes periódicas para unha variedade de condicións. Dado que se supón que os rexistros seleccionados deben ser eliminados e reescritos (como parte da tarefa, debemos apoiar o proceso de actualización de datos cando os datos entraron inicialmente no noso bucle incorrectamente), Cassandra non é a nosa amiga aquí. Cassandra é como unha hucha: é conveniente poñer as cousas, pero non podes contar nela.
Atopamos un problema ao transferir datos ás zonas de proba (5 nodos na proba fronte a 20 no baile de graduación). Neste caso, non se pode utilizar o vertedoiro.
O problema coa actualización do esquema de datos dunha aplicación que escribe a Cassandra. Un retroceso xerará unha gran cantidade de lápidas, o que pode provocar perdas de produtividade de xeito imprevisible.. Cassandra está optimizada para gravar, e non pensa moito antes de escribir. Calquera operación con datos existentes tamén é unha gravación. É dicir, eliminando o innecesario, simplemente produciremos aínda máis rexistros, e só algúns deles estarán marcados con lápidas.
Tempos de espera ao inserir. Cassandra é fermosa na gravación, pero ás veces o fluxo entrante pode desconcertala significativamente. Isto ocorre cando a aplicación comeza a circular por varios rexistros que non se poden inserir por algún motivo. E necesitaremos un DBA real que supervisará gc.log, rexistros do sistema e depuración para consultas lentas, métricas de compactación pendentes.
Varios centros de datos nun clúster. De onde ler e onde escribir?
Quizais dividido en lectura e escritura? E se é así, debería haber un DC máis próximo á aplicación para escribir ou ler? E non acabaremos cun verdadeiro cerebro dividido se escollemos o nivel de consistencia incorrecto? Hai moitas preguntas, moitas opcións descoñecidas, posibilidades coas que realmente queres xogar.
Como decidimos
Para evitar que o nodo se afunda, desactivouse SWAP. E agora, se hai falta de memoria, o nodo debería baixar e non crear grandes pausas de gc.
Entón, xa non dependemos da lóxica da base de datos. Os desenvolvedores de aplicacións están a reciclarse e comezan a tomar precaucións activamente no seu propio código. Separación clara ideal de almacenamento e procesamento de datos.
Compramos soporte de DataStax. O desenvolvemento de Cassandra en caixa xa cesou (o último compromiso foi en febreiro de 2018). Ao mesmo tempo, Datastax ofrece un excelente servizo e un gran número de solucións modificadas e adaptadas para as solucións IP existentes.
Tamén quero sinalar que Cassandra non é moi conveniente para as consultas de selección. Por suposto, CQL é un gran paso adiante para os usuarios (en comparación con Trift). Pero se tes departamentos enteiros afeitos a combinacións tan convenientes, filtrado gratuíto por calquera campo e capacidades de optimización de consultas, e estes departamentos traballan para resolver queixas e accidentes, entón a solución de Cassandra parécelle hostil e estúpida. E comezamos a decidir como deberían facer as mostras os nosos compañeiros.
Consideramos dúas opcións. Na primeira opción, escribimos chamadas non só en C*, senón tamén na base de datos de Oracle arquivada. Só, a diferenza de C*, esta base de datos almacena as chamadas só para o mes actual (profundidade de almacenamento de chamadas suficiente para os casos de recarga). Aquí vimos inmediatamente o seguinte problema: se escribimos de forma sincrónica, entón perdemos todas as vantaxes de C* asociadas á inserción rápida; se escribimos de forma asíncrona, non hai garantía de que todas as chamadas necesarias entraran en Oracle. Había unha vantaxe, pero unha gran: para o funcionamento permanece o mesmo programador PL/SQL familiar, é dicir, practicamente implementamos o patrón "Fachada", unha opción alternativa. Implementamos un mecanismo que descarga as chamadas de C*, extrae algúns datos para o enriquecemento das táboas correspondentes en Oracle, une as mostras resultantes e dános o resultado, que logo usamos dalgún xeito (retrocedemos, repetimos, analizamos, admiramos). Contras: o proceso é bastante de varios pasos e, ademais, non hai unha interface para os empregados da operación.
Ao final, decidimos pola segunda opción. Utilizouse Apache Spark para facer mostras de diferentes frascos. A esencia do mecanismo reduciuse a código Java, que, utilizando as claves especificadas (abonado, tempo de chamada - teclas de sección), extrae datos de C*, así como os datos necesarios para o enriquecemento de calquera outra base de datos. Despois únese a eles na súa memoria e mostra o resultado na táboa resultante. Debuxamos unha cara web sobre a faísca e resultou bastante útil.
Ao resolver o problema da actualización dos datos das probas industriais, consideramos de novo varias solucións. Tanto a transferencia a través de Sstloader como a opción de dividir o clúster na zona de proba en dúas partes, cada unha das cales pertence alternativamente ao mesmo clúster co promocional, sendo así alimentado por el. Ao actualizar a proba, estaba previsto intercambialas: a parte que traballou na proba borrase e entra en produción, e a outra comeza a traballar cos datos por separado. Non obstante, despois de pensalo de novo, avaliamos de forma máis racional os datos que pagaba a pena transferir e decatámonos de que as propias chamadas son unha entidade inconsistente para as probas, que se xeran rapidamente se é necesario, e que é o conxunto de datos promocionais o que non ten valor para transferir ao proba. Hai varios obxectos de almacenamento que paga a pena mover, pero estes son literalmente un par de mesas, e non moi pesadas. Polo tanto nós Como solución, Spark veu de novo ao rescate, coa axuda do cal escribimos e comezamos a usar activamente un script para transferir datos entre táboas, proba de baile.
A nosa política de implantación actual permítenos traballar sen retrocesos. Antes da promoción, hai unha proba obrigatoria, onde un erro non é tan caro. En caso de falla, sempre pode soltar o espazo de casos e tirar todo o esquema desde o principio.
Para garantir a dispoñibilidade continua de Cassandra, necesitas un dba e non só el. Todos os que traballen coa aplicación deben comprender onde e como mirar a situación actual e como diagnosticar os problemas de forma oportuna. Para iso, utilizamos activamente DataStax OpsCenter (Administración e seguimento de cargas de traballo), as métricas do sistema Cassandra Driver (número de tempo de espera para escribir en C*, número de tempo de espera para ler desde C*, latencia máxima, etc.), supervisar o funcionamento. da propia aplicación, traballando con Cassandra.
Cando pensamos na pregunta anterior, decatámonos de onde podería estar o noso principal risco. Estes son formularios de visualización de datos que mostran datos de varias consultas independentes ao almacenamento. Deste xeito podemos obter información bastante inconsistente. Pero este problema sería igual de relevante se traballáramos cun só centro de datos. Polo tanto, o máis razoable aquí é, por suposto, crear unha función por lotes para ler datos nunha aplicación de terceiros, o que garantirá que os datos se reciban nun único período de tempo. En canto á división en lectura e escritura en termos de rendemento, aquí detívose o risco de que con algunha perda de conexión entre os DC, puidésemos acabar con dous clústeres completamente inconsistentes entre si.
Como resultado, polo de agora detívose no nivel de coherencia para escribir EACH_QUORUM, para ler - LOCAL_QUORUM
Breves impresións e conclusións
Co fin de avaliar a solución resultante desde o punto de vista do apoio operativo e das perspectivas de desenvolvemento, decidimos pensar onde se podería aplicar tal desenvolvemento.
De primeiras, a puntuación de datos para programas como "Pagar cando sexa conveniente" (cargamos a información en C*, o cálculo mediante scripts Spark), a contabilización de reclamacións coa agregación por área, o almacenamento de roles e o cálculo dos dereitos de acceso dos usuarios en función da función. matriz.
Como vedes, o repertorio é amplo e variado. E se escollemos o campo de partidarios/opositores de NoSQL, entón unirémonos aos seguidores, xa que recibimos as nosas vantaxes e exactamente onde esperabamos.
Incluso a opción de Cassandra fóra da caixa permite a escala horizontal en tempo real, resolvendo de forma absolutamente sen dor o problema de aumentar os datos no sistema. Puidemos mover un mecanismo de carga moi alta para calcular agregados de chamadas a un circuíto separado e tamén separar o esquema e a lóxica da aplicación, eliminando a mala práctica de escribir traballos e obxectos personalizados na propia base de datos. Tivemos a oportunidade de elixir e configurar, para acelerar, sobre que DC realizaremos cálculos e sobre cales rexistraremos os datos, asegurámonos contra fallos tanto de nodos individuais como de DC no seu conxunto.
Aplicando a nosa arquitectura a novos proxectos, e xa tendo algo de experiencia, gustaríame ter en conta inmediatamente os matices descritos anteriormente, e evitar algúns erros, suavizar algúns recunchos afiados que non se podían evitar nun principio.
Por exemplo, a realizar un seguimento das actualizacións de Cassandra de forma oportunaporque xa eran coñecidos e solucionados bastantes dos problemas que temos.
Non coloque a propia base de datos e Spark nos mesmos nodos (ou dividir estrictamente pola cantidade de uso permitido de recursos), xa que Spark pode comer máis OP do esperado e obteremos rapidamente o problema número 1 da nosa lista.
Mellorar a competencia operativa e de seguimento na fase de proba do proxecto. Inicialmente, teña en conta na medida do posible todos os potenciais consumidores da nosa solución, porque diso dependerá finalmente a estrutura da base de datos.
Xire o circuíto resultante varias veces para unha posible optimización. Seleccione os campos que se poden serializar. Comprender que táboas adicionais debemos facer para ter en conta de forma máis correcta e óptima e, a continuación, proporcionar a información requirida previa solicitude (por exemplo, asumindo que podemos almacenar os mesmos datos en táboas diferentes, tendo en conta diferentes desagregacións segundo diferentes criterios, podemos aforrar moito tempo de CPU para as solicitudes de lectura).
Non está mal Proporcione inmediatamente a anexa TTL e a limpeza de datos obsoletos.
Ao descargar datos de Cassandra A lóxica da aplicación debería funcionar co principio FETCH, de xeito que non todas as filas se carguen na memoria á vez, senón que se seleccionen por lotes.
É recomendable antes de transferir o proxecto á solución descrita comprobar a tolerancia a fallos do sistema realizando unha serie de probas de choque, como a perda de datos nun centro de datos, a restauración de datos danados durante un período determinado, o abandono da rede entre os centros de datos. Tales probas non só permitirán avaliar os pros e os contras da arquitectura proposta, senón que tamén proporcionarán unha boa práctica de quecemento para os enxeñeiros que as realizan, e a habilidade adquirida estará lonxe de ser superflua se se reproducen fallos do sistema na produción.
Se traballamos con información crítica (como datos de facturación, cálculo da débeda do abonado), tamén paga a pena prestar atención ás ferramentas que reducirán os riscos derivados das características do DBMS. Por exemplo, use a utilidade nodesync (Datastax), despois de desenvolver unha estratexia óptima para o seu uso en orde por mor da coherencia, non crees unha carga excesiva sobre Cassandra e utilízao só para determinadas táboas nun período determinado.
Que lle pasa a Cassandra despois de seis meses de vida? En xeral, non hai problemas sen resolver. Tampouco permitimos accidentes graves nin perda de datos. Si, tivemos que pensar en compensar algúns problemas que antes non xurdiran, pero ao final isto non enturbio moito a nosa solución arquitectónica. Se queres e non tes medo de probar algo novo e, ao mesmo tempo, non queres estar demasiado decepcionado, prepárate para o feito de que nada é gratis. Terás que entender, afondar na documentación e montar o teu propio rastrillo individual máis que na antiga solución herdada, e ningunha teoría che dirá de antemán que rastrillo está esperando por ti.
Fonte: www.habr.com