<\/a><\/noindex><\/p>\nAs\u00ed que, esto es lo que nos trajo la experiencia<\/h2>\n <\/p>\n
S\u00ed, un nodo ca\u00eddo no es una tragedia. Esa es la esencia de la tolerancia a fallos de Cassandra. Pero un nodo puede estar en funcionamiento y a\u00fan as\u00ed experimentar una disminuci\u00f3n en el rendimiento.<\/b>. Como se ha descubierto, esto afecta inmediatamente al rendimiento de todo el cl\u00faster.<\/p>\n
<\/p>\n
Cassandra no proteger\u00e1 donde Oracle salvaba con sus restricciones.<\/b>. Y si el autor de la aplicaci\u00f3n no lo entendi\u00f3 de antemano, entonces el duplicado que llega para Cassandra es tan bueno como el original. Si lleg\u00f3, lo insertamos.<\/p>\n
<\/p>\n
La versi\u00f3n gratuita de Cassandra \u2018de f\u00e1brica\u2019 no fue bien recibida por la seguridad de la informaci\u00f3n: no hay registro de las acciones de los usuarios, tampoco hay diferenciaci\u00f3n de derechos.<\/b>La informaci\u00f3n sobre las llamadas se refiere a datos personales, lo que significa que todos los intentos de solicitarlos\/modificarlos deben ser registrados con la posibilidad de auditor\u00eda posterior. Tambi\u00e9n es necesario reconocer la importancia de separar los derechos en diferentes niveles para diferentes usuarios. Un ingeniero de operaciones y un superadministrador, que pueden eliminar todo el keyspace sin restricciones, son roles diferentes, con distintas responsabilidades y competencias. Sin esta delimitaci\u00f3n de los derechos de acceso, el valor y la integridad de los datos estar\u00e1n en cuesti\u00f3n m\u00e1s r\u00e1pidamente que con un nivel de consistencia ANY. <\/p>\n
<\/p>\n
No tuvimos en cuenta que se requiere una an\u00e1lisis seria de las llamadas, as\u00ed como muestreos peri\u00f3dicos bajo diversas condiciones. Dado que se prev\u00e9 eliminar y sobrescribir los registros seleccionados (en el marco de la tarea, debemos mantener el proceso de actualizaci\u00f3n de datos ante datos incorrectos inicialmente recibidos), Cassandra no es la mejor opci\u00f3n aqu\u00ed. Cassandra, como alcanc\u00eda, es conveniente para almacenar, pero no puede realizar c\u00e1lculos.<\/b><\/p>\n
<\/p>\n
Nos encontramos con un problema al transferir datos a zonas de prueba.<\/b> (5 nodos en la prueba frente a 20 en producci\u00f3n). No se podr\u00e1 utilizar un volcado en este caso.<\/p>\n
<\/p>\n
Problema con las actualizaciones del esquema de datos de la aplicaci\u00f3n que escribe en Cassandra. Una reversi\u00f3n generar\u00e1 una gran cantidad de tumbas, lo que puede afectar nuestro rendimiento de manera impredecible.<\/b>Cassandra est\u00e1 optimizada para escritura, y antes de escribir, no piensa mucho. Cualquier operaci\u00f3n con datos existentes en ella tambi\u00e9n es una escritura. Es decir, al eliminar lo innecesario, simplemente generamos m\u00e1s registros, y solo una parte de ellos ser\u00e1 marcada como tumbas.<\/p>\n
<\/p>\n
Tiempo de espera en las inserciones. Cassandra es excelente en escritura, pero a veces el flujo de entrada puede complicarla considerablemente.<\/b>Esto sucede cuando la aplicaci\u00f3n comienza a repetir varios registros que no se pueden insertar por alguna raz\u00f3n. Y necesitaremos un verdadero DBA que supervise gc.log, los registros del sistema y de depuraci\u00f3n en busca de consultas lentas, y m\u00e9tricas sobre la compactaci\u00f3n pendiente.\n<\/p>\n
<\/p>\n
Varios centros de datos en el cl\u00faster. \u00bfDe d\u00f3nde leer y a d\u00f3nde escribir?<\/b>
<\/p>\n
C\u00f3mo lo resolvimos<\/h2>\n <\/p>\n
Para que el nodo no se desacelere, desactivamos SWAP<\/b>. Y ahora, cuando falte memoria, el nodo deber\u00eda caer, en lugar de generar largas pausas de recolecci\u00f3n de basura.<\/p>\n
<\/p>\n
As\u00ed que ya no confiamos en la l\u00f3gica en la base de datos. Los desarrolladores de la aplicaci\u00f3n est\u00e1n reentren\u00e1ndose y comenzando a protegerse activamente en su propio c\u00f3digo.<\/b> Una separaci\u00f3n clara y perfecta entre el almacenamiento y el procesamiento de datos.<\/p>\n
<\/p>\n
Compramos soporte de DataStax.<\/b> Ya han dejado de desarrollar Cassandra de caja (el \u00faltimo commit fue en febrero de 2018). Al mismo tiempo, Datastax ofrece un excelente servicio y una gran cantidad de soluciones mejoradas y adaptadas a los sistemas existentes.<\/p>\n
<\/p>\n
Tambi\u00e9n quiero se\u00f1alar que Cassandra no es muy c\u00f3moda para las consultas de selecci\u00f3n. Por supuesto, CQL es un gran paso hacia los usuarios (en comparaci\u00f3n con Thrift). Pero si tienes departamentos completos acostumbrados a tales uniones convenientes, a la filtraci\u00f3n libre por cualquier campo y a las posibilidades de optimizaci\u00f3n de consultas, y estos departamentos trabajan para cerrar reclamos y emergencias, la soluci\u00f3n en Cassandra les parece hostil y tonta. Y comenzamos a buscar c\u00f3mo nuestros colegas pueden realizar selecciones. <\/p>\n
<\/p>\n
Se consideraron dos opciones. En la primera opci\u00f3n, escribimos las llamadas no solo en C*, sino tambi\u00e9n en la base de datos archivada de Oracle. Sin embargo, a diferencia de C*, en esta base de datos solo se almacenan las llamadas del mes actual (una profundidad de almacenamiento suficiente para los casos de re-etiquetado). Aqu\u00ed se vislumbr\u00f3 de inmediato el siguiente problema: si escribimos de forma sincr\u00f3nica, perdemos todas las ventajas de C*, relacionadas con la inserci\u00f3n r\u00e1pida; si lo hacemos de forma asincr\u00f3nica, no hay garant\u00eda de que todas las llamadas necesarias realmente hayan sido ingresadas en Oracle. Pero hab\u00eda una ventaja significativa: para la operaci\u00f3n, sigue siendo el mismo PL\/SQL Developer familiar, es decir, pr\u00e1cticamente realizamos el patr\u00f3n de<\/p>\n
<\/p>\n
Al final, nos decidimos por la segunda opci\u00f3n. Para las selecciones de diferentes bancos, utilizamos Apache Spark.<\/b> La esencia del mecanismo se redujo a un c\u00f3digo en Java, que, seg\u00fan las claves especificadas (suscriptor, hora de la llamada - claves de la secci\u00f3n), extrae datos de C*, as\u00ed como los datos necesarios para enriquecer desde cualquier otra base de datos. Luego, los une en su memoria y muestra el resultado en una tabla de resultados. Sobre Spark, dibujamos una interfaz web y result\u00f3 ser bastante adecuada para la operaci\u00f3n.<\/p>\n
\n
Al abordar la tarea de actualizaci\u00f3n de datos, el equipo de producci\u00f3n volvi\u00f3 a evaluar varias soluciones. Tanto la transferencia a trav\u00e9s de Sstloader como la opci\u00f3n de dividir el cl\u00faster en el \u00e1rea de prueba en dos partes, cada una de las cuales se alterna en un cl\u00faster con el de producci\u00f3n, con este \u00faltimo aliment\u00e1ndolo. Al actualizar la prueba, se planeaba intercambiarlas: la parte que trabajaba en la prueba se limpiar\u00eda e introducir\u00eda en producci\u00f3n, mientras que la otra comenzar\u00eda a trabajar con los datos por separado. Sin embargo, tras una segunda reflexi\u00f3n, evaluamos de manera m\u00e1s racional qu\u00e9 datos vale la pena transferir y nos dimos cuenta de que las llamadas en s\u00ed son una entidad inconsistente para las pruebas, gener\u00e1ndose r\u00e1pidamente en caso de necesidad, y precisamente el conjunto de datos de producci\u00f3n no tiene valor para ser transferido a pruebas. Hay varios objetos acumuladores que vale la pena transferir, pero son literalmente un par de tablas, y no son muy pesadas. As\u00ed que, como soluci\u00f3n, Spark volvi\u00f3 a ayudar, con el cual escribimos y comenzamos a utilizar de manera activa un script para la transferencia de datos entre las tablas de producci\u00f3n y prueba.<\/b><\/p>\n
<\/p>\n
Nuestra pol\u00edtica actual de despliegue nos permite trabajar sin retrocesos.<\/b> Antes de proceder a producci\u00f3n, se requiere un despliegue obligatorio en pruebas, donde el error no tiene tanto costo. En caso de fracaso, siempre se puede eliminar el caso y aplicar todo el esquema desde el principio.<\/p>\n
<\/p>\n
Para garantizar la disponibilidad continua de Cassandra se necesita un DBA y no solo \u00e9l. Todos los que trabajan con la aplicaci\u00f3n deben entender d\u00f3nde y c\u00f3mo ver la situaci\u00f3n actual y c\u00f3mo diagnosticar problemas de manera oportuna.<\/b> Para ello, utilizamos activamente DataStax OpsCenter (Administraci\u00f3n y monitoreo de cargas de trabajo), m\u00e9tricas del sistema del controlador de Cassandra (n\u00famero de timeouts de escritura en C*, n\u00famero de timeouts de lectura desde C*, latencia m\u00e1xima, etc.), y monitoreamos la operaci\u00f3n de la propia aplicaci\u00f3n que trabaja con Cassandra.\n<\/p>\n
<\/p>\n
Al reflexionar sobre la pregunta anterior, nos dimos cuenta de d\u00f3nde podr\u00eda estar el principal riesgo. Este riesgo radica en las formas de visualizaci\u00f3n de datos que extraen informaci\u00f3n de m\u00faltiples consultas independientes a la base de datos. De este modo, podr\u00edamos obtener informaci\u00f3n bastante inconsistente. Sin embargo, este problema tambi\u00e9n ser\u00eda relevante si solo estuvi\u00e9ramos trabajando con un solo centro de datos. Por lo tanto, la opci\u00f3n m\u00e1s sensata aqu\u00ed es, por supuesto, implementar una funci\u00f3n de lectura de datos por lotes en una aplicaci\u00f3n externa, que asegure la obtenci\u00f3n de datos dentro de un mismo per\u00edodo de tiempo. En lo que respecta a la separaci\u00f3n entre lectura y escritura en t\u00e9rminos de rendimiento, nos detuvo el riesgo de que, ante alguna p\u00e9rdida de conexi\u00f3n entre los centros de datos, pudi\u00e9ramos obtener dos cl\u00fasteres completamente inconsistentes entre s\u00ed.<\/p>\n
<\/p>\n
En resumen, actualmente nos hemos decidido por un nivel de consistencia de escritura de EACH_QUORUM y de lectura de LOCAL_QUORUM<\/b><\/p>\n
<\/p>\n
Impresiones y conclusiones breves<\/h2>\n <\/p>\n
Para evaluar la soluci\u00f3n obtenida desde el punto de vista del soporte operativo y las perspectivas de desarrollo futuro, decidimos pensar en d\u00f3nde m\u00e1s podr\u00eda aplicarse tal desarrollo.<\/p>\n
<\/p>\n
Si pensamos r\u00e1pidamente, ser\u00eda el scoring de datos para programas tipo 'Paga cuando te convenga' (cargamos informaci\u00f3n en C* y realizamos c\u00e1lculos en scripts de Spark), la gesti\u00f3n de reclamaciones con agregaci\u00f3n por categor\u00edas, almacenamiento de roles y c\u00e1lculo basado en la matriz de roles de acceso de los usuarios. <\/p>\n
<\/p>\n
Como podemos ver, el repertorio es amplio y variado. Y si tenemos que elegir un bando entre los defensores y opositores de NoSQL, nos uniremos a los defensores, ya que hemos obtenido sus beneficios, especialmente donde los esper\u00e1bamos.<\/p>\n
<\/p>\n
Incluso la opci\u00f3n de Cassandra lista para usar permite realizar escalabilidad horizontal en tiempo real, resolviendo de manera absolutamente indolora la cuesti\u00f3n del aumento de datos en el sistema. Logramos llevar a cabo un mecanismo de c\u00e1lculo de agregados de llamadas altamente cargado en un contorno separado, adem\u00e1s de dividir el esquema y la l\u00f3gica de la aplicaci\u00f3n, eliminando la pr\u00e1ctica perjudicial de escribir trabajos y objetos personalizados directamente en la base de datos. Obtuvimos la posibilidad de elegir y configurar, para acelerar, en qu\u00e9 centros de datos vamos a realizar los c\u00e1lculos y en cu\u00e1les se registrar\u00e1n los datos, asegur\u00e1ndonos contra ca\u00eddas tanto de nodos individuales como del centro de datos en su conjunto.<\/p>\n
<\/p>\n
Al aplicar nuestra arquitectura a nuevos proyectos, y ya teniendo cierta experiencia, quisiera tener en cuenta los aspectos mencionados anteriormente de inmediato y evitar ciertos errores, suavizando algunos puntos cr\u00edticos que no pudimos evitar inicialmente.<\/p>\n
<\/p>\n
Por ejemplo, monitorear oportunamente las actualizaciones de Cassandra<\/b>, porque muchos de los problemas que enfrentamos ya eran conocidos y se hab\u00edan solucionado.<\/p>\n
<\/p>\n
No colocar tanto la base de datos como Spark en los mismos nodos<\/b> (o mantener estrictamente separados los recursos permitidos), ya que Spark puede consumir m\u00e1s memoria RAM de la permitida, y r\u00e1pidamente obtendremos el problema n\u00famero 1 de nuestra lista.<\/p>\n
<\/p>\n
Mejorar el monitoreo y la competencia operativa ya en la etapa de pruebas del proyecto. <\/b>Inicialmente tener en cuenta al m\u00e1ximo todos los posibles consumidores de nuestra soluci\u00f3n<\/b>, porque de esto depender\u00e1 la estructura final de la base de datos.<\/p>\n
<\/p>\n
Revisar varias veces el esquema resultante en busca de posibles optimizaciones. Identificar qu\u00e9 campos se pueden serializar. Entender qu\u00e9 tablas adicionales necesitamos crear para considerar de manera m\u00e1s precisa y \u00f3ptima, y luego devolver la informaci\u00f3n requerida a trav\u00e9s de las consultas (por ejemplo, suponiendo que los mismos datos se pueden almacenar en diferentes tablas, considerando diferentes desagregaciones por diferentes criterios, se puede ahorrar tiempo del procesador en las consultas de lectura).<\/p>\n
<\/p>\n
No est\u00e1 mal prever desde el principio la asignaci\u00f3n de TTL y la limpieza de datos obsoletos.<\/b><\/p>\n
<\/p>\n
Al exportar datos de Cassandra la l\u00f3gica de la aplicaci\u00f3n debe funcionar bajo el principio de FETCH, para que no todas las filas se carguen en memoria de una vez, sino que se seleccionen por lotes.<\/b><\/p>\n
<\/p>\n
Es recomendable verificar la resistencia a fallos del sistema antes de la migraci\u00f3n del proyecto a la soluci\u00f3n descrita realizando una serie de pruebas de estr\u00e9s<\/b>, como la p\u00e9rdida de datos en un centro de datos, la recuperaci\u00f3n de datos da\u00f1ados durante un per\u00edodo, ca\u00eddas de red entre centros de datos. Estas pruebas no solo permitir\u00e1n evaluar los pros y los contras de la arquitectura propuesta, sino que tambi\u00e9n proporcionar\u00e1n una buena pr\u00e1ctica a los ingenieros que las realicen, y la habilidad adquirida no ser\u00e1 en vano si los fallos del sistema se reproducen en producci\u00f3n.<\/p>\n
<\/p>\n
Si trabajamos con informaci\u00f3n cr\u00edtica (como datos para la facturaci\u00f3n o el c\u00e1lculo de deudas del suscriptor), tambi\u00e9n debemos prestar atenci\u00f3n a las herramientas que permitan reducir los riesgos derivados de las particularidades de la base de datos. Por ejemplo, utilizar la utilidad nodesync (Datastax), desarrollando una estrategia \u00f3ptima para su uso, para no generar una carga excesiva en Cassandra por razones de consistencia<\/b> y utilizarla solo para ciertas tablas en un periodo espec\u00edfico.<\/p>\n
<\/p>\n
\u00bfQu\u00e9 tal, despu\u00e9s de medio a\u00f1o de vida con Cassandra? En general, no hay problemas sin resolver. No hemos sufrido accidentes graves ni p\u00e9rdidas de datos. S\u00ed, tuvimos que pensar en la compensaci\u00f3n de algunos problemas que antes no exist\u00edan, pero al final esto no afect\u00f3 gravemente nuestra soluci\u00f3n arquitect\u00f3nica. Si est\u00e1s dispuesto a probar algo nuevo y no te asusta la idea de experimentar, ten en cuenta que no hay nada gratuito. Tendr\u00e1s que investigar, sumergirte en la documentaci\u00f3n y recolectar tus propios obst\u00e1culos m\u00e1s que con una soluci\u00f3n heredada antigua, y ninguna teor\u00eda te podr\u00e1 decir de antemano qu\u00e9 obst\u00e1culos te esperan a ti en particular.<\/p>\n
Fuente: 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
![\"C\u00f3mo](\"\/wp-content\/uploads\/2019\/08\/4845d37a9928f888639c4ebeb7807787.jpg\")
![\"C\u00f3mo](\"\/wp-content\/uploads\/2019\/08\/c7b095dc8879011adb751c96427af512.jpg\")
<\/p>\n