Dicen que vale la pena intentarlo todo en la vida al menos una vez. Y si está acostumbrado a trabajar con DBMS relacionales, entonces vale la pena familiarizarse con NoSQL en la práctica, en primer lugar, al menos para el desarrollo general. Ahora, debido al rápido desarrollo de esta tecnología, existen muchas opiniones encontradas y acalorados debates sobre este tema, lo que despierta especialmente el interés.
Si profundizas en la esencia de todas estas disputas, verás que surgen debido a un enfoque equivocado. Quienes utilizan bases de datos NoSQL exactamente donde se necesitan quedan satisfechos y reciben todas las ventajas de esta solución. Y los experimentadores que confían en esta tecnología como una panacea cuando no es aplicable en absoluto se sienten decepcionados, ya que han perdido las fortalezas de las bases de datos relacionales sin obtener beneficios significativos.
Les contaré nuestra experiencia en la implementación de una solución basada en Cassandra DBMS: a qué nos tuvimos que enfrentar, cómo salimos de situaciones difíciles, si pudimos beneficiarnos del uso de NoSQL y dónde tuvimos que invertir esfuerzos/fondos adicionales. .
La tarea inicial es construir un sistema que registre las llamadas en algún tipo de almacenamiento.
El principio de funcionamiento del sistema es el siguiente. La entrada incluye archivos con una estructura específica que describe la estructura de la llamada. Luego, la aplicación se asegura de que esta estructura se almacene en las columnas apropiadas. En el futuro, las llamadas guardadas se utilizarán para mostrar información sobre el consumo de tráfico de los suscriptores (cargos, llamadas, historial de saldo).
Está bastante claro por qué eligieron a Cassandra: escribe como una ametralladora, es fácilmente escalable y tolerante a fallos.
Entonces, esto es lo que nos dio la experiencia.
Sí, un nodo fallido no es una tragedia. Ésta es la esencia de la tolerancia a los fallos de Cassandra. Pero un nodo puede estar vivo y al mismo tiempo comenzar a sufrir en rendimiento. Al final resultó que, esto afecta inmediatamente el rendimiento de todo el clúster.
Cassandra no te protegerá donde Oracle te salvó con sus limitaciones.. Y si el autor de la aplicación no lo entendió de antemano, entonces el doble que llegó a Cassandra no es peor que el original. Una vez que llegue, lo colocaremos.
A IB no le gustó mucho la Cassandra gratuita lista para usar: No hay registro de las acciones del usuario ni diferenciación de derechos.. La información sobre las llamadas se considera dato personal, lo que significa que todos los intentos de solicitarla/modificarla de cualquier forma deben quedar registrados con posibilidad de auditoría posterior. Además, debe ser consciente de la necesidad de separar derechos en diferentes niveles para diferentes usuarios. Un ingeniero de operaciones simple y un superadministrador que puede eliminar libremente todo el espacio de claves son roles, responsabilidades y competencias diferentes. Sin esta diferenciación de derechos de acceso, el valor y la integridad de los datos se pondrán inmediatamente en duda más rápidamente que con CUALQUIER nivel de coherencia.
No tomamos en cuenta que las llamadas requieren análisis serios y muestreos periódicos para una variedad de condiciones. Dado que se supone que los registros seleccionados deben eliminarse y reescribirse (como parte de la tarea, debemos respaldar el proceso de actualización de datos cuando los datos ingresaron inicialmente a nuestro bucle de manera incorrecta), Cassandra no es nuestra amiga aquí. Cassandra es como una alcancía: es conveniente guardar cosas en ella, pero no se pueden contar.
Encontramos un problema al transferir datos a las zonas de prueba. (5 nodos en la prueba frente a 20 en el baile de graduación). En este caso, no se puede utilizar el volcado.
El problema con la actualización del esquema de datos de una aplicación que escribe en Cassandra. Una reversión generará una gran cantidad de obstáculos, lo que puede conducir a pérdidas de productividad de maneras impredecibles.. Cassandra está optimizada para grabar y no piensa mucho antes de escribir. Cualquier operación con datos existentes también es una grabación. Es decir, al eliminar lo innecesario, simplemente generaremos aún más registros y solo algunos de ellos estarán marcados con lápidas.
Tiempos de espera al insertar. Cassandra está hermosa en la grabación, pero a veces el flujo entrante puede desconcertarla significativamente. Esto sucede cuando la aplicación comienza a recorrer varios registros que no se pueden insertar por algún motivo. Y necesitaremos un administrador de base de datos real que supervise gc.log, los registros del sistema y de depuración en busca de consultas lentas y métricas de compactación pendientes.
Varios centros de datos en un clúster. ¿Desde dónde leer y dónde escribir?
¿Quizás dividirse en lectura y escritura? Y si es así, ¿debería haber un DC más cercano a la aplicación para escritura o lectura? ¿Y no acabaremos con un verdadero cerebro dividido si elegimos el nivel de coherencia equivocado? Hay muchas preguntas, muchas configuraciones desconocidas, posibilidades con las que realmente quieres jugar.
como decidimos
Para evitar que el nodo se hunda, desactivamos SWAP. Y ahora, si falta memoria, el nodo debería dejar de funcionar y no crear grandes pausas de gc.
Por lo tanto, ya no dependemos de la lógica de la base de datos. Los desarrolladores de aplicaciones se están reentrenando y están empezando a tomar precauciones activamente en su propio código. Separación clara ideal entre el almacenamiento y el procesamiento de datos.
Compramos soporte de DataStax. El desarrollo de Cassandra en caja ya cesó (el último compromiso fue en febrero de 2018). Al mismo tiempo, Datastax ofrece un excelente servicio y una gran cantidad de soluciones modificadas y adaptadas a las soluciones IP existentes.
También quiero señalar que Cassandra no es muy conveniente para consultas de selección. Por supuesto, CQL es un gran paso adelante para los usuarios (en comparación con Trift). Pero si tiene departamentos enteros que están acostumbrados a uniones tan convenientes, filtrado gratuito por cualquier campo y capacidades de optimización de consultas, y estos departamentos están trabajando para resolver quejas y accidentes, entonces la solución en Cassandra les parece hostil y estúpida. Y comenzamos a decidir cómo deberían hacer las muestras nuestros colegas.
Consideramos dos opciones: en la primera opción, escribimos llamadas no solo en C*, sino también en la base de datos archivada de Oracle. Sólo que, a diferencia de C*, esta base de datos almacena llamadas sólo para el mes actual (profundidad de almacenamiento de llamadas suficiente para casos de recarga). Aquí vimos inmediatamente el siguiente problema: si escribimos de forma sincrónica, perdemos todas las ventajas de C* asociadas con la inserción rápida; si escribimos de forma asincrónica, no hay garantía de que todas las llamadas necesarias lleguen a Oracle. Había una ventaja, pero grande: para el funcionamiento se mantiene el mismo desarrollador PL/SQL, es decir, prácticamente implementamos el patrón "Fachada". Una opción alternativa. Implementamos un mecanismo que descarga llamadas de C*, extrae algunos datos para enriquecerlos de las tablas correspondientes en Oracle, une las muestras resultantes y nos da el resultado, que luego usamos de alguna manera (retroceder, repetir, analizar, admirar). Desventajas: el proceso consta de varios pasos y, además, no existe una interfaz para los empleados de operación.
Al final nos decidimos por la segunda opción. Se utilizó Apache Spark para tomar muestras de diferentes frascos. La esencia del mecanismo se ha reducido a un código Java que, utilizando las claves especificadas (suscriptor, hora de la llamada - claves de sección), extrae datos de C*, así como los datos necesarios para el enriquecimiento de cualquier otra base de datos. Después de lo cual los une en su memoria y muestra el resultado en la tabla resultante. Dibujamos una cara web sobre la chispa y resultó bastante utilizable.
Al resolver el problema de actualizar los datos de las pruebas industriales, nuevamente consideramos varias soluciones. Ambos se transfieren vía Sstloader y la opción de dividir el cluster en la zona de prueba en dos partes, cada una de las cuales pertenece alternativamente al mismo cluster que el promocional, siendo así alimentadas por este. Al actualizar la prueba, se planeó intercambiarlos: la parte que funcionó en la prueba se borra y entra en producción, y la otra comienza a trabajar con los datos por separado. Sin embargo, después de pensarlo de nuevo, evaluamos de manera más racional los datos que valía la pena transferir y nos dimos cuenta de que las llamadas en sí mismas son una entidad inconsistente para las pruebas, que se generan rápidamente si es necesario, y es el conjunto de datos promocionales el que no tiene valor para transferir al prueba. Hay varios objetos de almacenamiento que vale la pena mover, pero se trata literalmente de un par de mesas y no muy pesadas. Por lo tanto, nosotros Como solución, Spark vino nuevamente al rescate, con la ayuda de la cual escribimos y comenzamos a usar activamente un script para transferir datos entre tablas, prom-test.
Nuestra política de implementación actual nos permite trabajar sin retrocesos. Antes de la promoción, se realiza una prueba obligatoria, en la que un error no sale tan caro. En caso de falla, siempre puedes descartar el espacio de casos y ejecutar todo el esquema desde el principio.
Para garantizar la disponibilidad continua de Cassandra, necesita un dba y no solo él. Todos los que trabajan con la aplicación deben comprender dónde y cómo observar la situación actual y cómo diagnosticar los problemas de manera oportuna. Para hacer esto, utilizamos activamente DataStax OpsCenter (administración y monitoreo de cargas de trabajo), métricas del sistema Cassandra Driver (número de tiempos de espera para escribir en C*, número de tiempos de espera para leer desde C*, latencia máxima, etc.), monitoreamos la operación. de la aplicación en sí, trabajando con Cassandra.
Cuando pensamos en la pregunta anterior, nos dimos cuenta de dónde podría estar nuestro principal riesgo. Estos son formularios de visualización de datos que muestran datos de varias consultas independientes al almacenamiento. De esta manera podemos obtener información bastante inconsistente. Pero este problema sería igualmente relevante si trabajáramos con un solo centro de datos. Entonces, lo más razonable aquí es, por supuesto, crear una función por lotes para leer datos en una aplicación de terceros, lo que garantizará que los datos se reciban en un solo período de tiempo. En cuanto a la división en lectura y escritura en términos de rendimiento, aquí nos detuvo el riesgo de que, con cierta pérdida de conexión entre los DC, pudiéramos terminar con dos grupos que son completamente inconsistentes entre sí.
Como resultado, por ahora detenido en el nivel de coherencia para escribir EACH_QUORUM, para leer - LOCAL_QUORUM
Breves impresiones y conclusiones.
Para evaluar la solución resultante desde el punto de vista del soporte operativo y las perspectivas de mayor desarrollo, decidimos pensar en dónde más se podría aplicar dicho desarrollo.
De buenas a primeras, luego puntuación de datos para programas como "Pague cuando sea conveniente" (cargamos información en C*, cálculo usando scripts Spark), contabilización de reclamos con agregación por área, almacenamiento de roles y cálculo de derechos de acceso de usuario según el rol matriz.
Como ves, el repertorio es amplio y variado. Y si elegimos el bando de los partidarios/oponentes de NoSQL, entonces nos uniremos a los partidarios, ya que recibimos nuestras ventajas, y exactamente donde esperábamos.
Incluso la opción Cassandra lista para usar permite el escalado horizontal en tiempo real, resolviendo de manera absolutamente sencilla el problema del aumento de datos en el sistema. Pudimos mover un mecanismo de carga muy alta para calcular agregados de llamadas a un circuito separado y también separar el esquema y la lógica de la aplicación, eliminando la mala práctica de escribir trabajos y objetos personalizados en la propia base de datos. Tuvimos la oportunidad de elegir y configurar, para acelerar, en qué DC realizaremos cálculos y en cuáles registraremos datos, nos aseguramos contra fallas tanto de los nodos individuales como del DC en su conjunto.
Al aplicar nuestra arquitectura a nuevos proyectos y ya tener algo de experiencia, me gustaría tener en cuenta de inmediato los matices descritos anteriormente, evitar algunos errores y suavizar algunos ángulos agudos que no se pudieron evitar inicialmente.
Por ejemplo, realizar un seguimiento de las actualizaciones de Cassandra de manera oportunaporque muchos de los problemas que tuvimos ya eran conocidos y solucionados.
No coloque la base de datos y Spark en los mismos nodos (o dividir estrictamente por la cantidad de uso de recursos permitido), ya que Spark puede consumir más OP de lo esperado y rápidamente obtendremos el problema número 1 de nuestra lista.
Mejorar el seguimiento y la competencia operativa en la etapa de prueba del proyecto. Inicialmente, tener en cuenta en la medida de lo posible a todos los consumidores potenciales de nuestra solución., porque de esto dependerá en última instancia la estructura de la base de datos.
Gire el circuito resultante varias veces para una posible optimización. Seleccione qué campos se pueden serializar. Comprender qué tablas adicionales debemos crear para tenerlas en cuenta de la manera más correcta y óptima, y luego proporcionar la información requerida cuando se solicite (por ejemplo, asumiendo que podemos almacenar los mismos datos en diferentes tablas, teniendo en cuenta diferentes desgloses según diferentes criterios, podemos ahorrar significativamente tiempo de CPU para solicitudes de lectura).
Promedio Proporcione inmediatamente la posibilidad de adjuntar TTL y limpiar datos obsoletos.
Al descargar datos de Cassandra La lógica de la aplicación debería funcionar según el principio FETCH, de modo que no todas las filas se carguen en la memoria a la vez, sino que se seleccionen en lotes.
Es aconsejable antes de transferir el proyecto a la solución descrita. comprobar la tolerancia a fallos del sistema realizando una serie de pruebas de choque, como la pérdida de datos en un centro de datos, la restauración de datos dañados durante un período determinado, la caída de la red entre centros de datos. Estas pruebas no sólo permitirán evaluar los pros y los contras de la arquitectura propuesta, sino que también proporcionarán buenas prácticas de preparación para los ingenieros que las realicen, y la habilidad adquirida estará lejos de ser superflua si las fallas del sistema se reproducen en producción.
Si trabajamos con información crítica (como datos de facturación, cálculo de la deuda de los suscriptores), también vale la pena prestar atención a las herramientas que reducirán los riesgos que surgen debido a las características del DBMS. Por ejemplo, utilice la utilidad nodesync (Datastax), habiendo desarrollado una estrategia óptima para su uso para En aras de la coherencia, no cree una carga excesiva en Cassandra. y usarlo solo para ciertas tablas en un período determinado.
¿Qué le pasa a Cassandra después de seis meses de vida? En general, no hay problemas sin resolver. Tampoco permitimos accidentes graves o pérdida de datos. Sí, tuvimos que pensar en compensar algunos problemas que no habían surgido antes, pero al final esto no empañó mucho nuestra solución arquitectónica. Si quieres y no tienes miedo de probar algo nuevo y, al mismo tiempo, no quieres decepcionarte demasiado, prepárate para el hecho de que nada es gratis. Tendrá que comprender, profundizar en la documentación y montar su propio rastrillo individual más que en la antigua solución heredada, y ninguna teoría le dirá de antemano qué rastrillo le espera.
Fuente: habr.com