⏩ 💇🏾 📡 Libro "Bases de datos. Ingeniería de confiabilidad 😦 👋 🤖

Hola habrozhiteli! En el campo de TI, se produjo una verdadera revolución: comenzaron a trabajar con la infraestructura como con el código. Este proceso crea no solo nuevos problemas, sino también oportunidades para garantizar el tiempo de actividad de las bases de datos. Los autores han preparado esta guía práctica para cualquier persona que desee unirse a la comunidad de ingenieros modernos de confiabilidad de bases de datos (DBRE).

En este libro: • requisitos de almacenamiento y requisitos de gestión de riesgos. • Creación y desarrollo de una arquitectura que brinde soporte transparente a la base de datos. • racionalizar el proceso de gestión de versiones. • almacenamiento, indexación y replicación de datos. • determinar las características del almacén de datos y seleccionar las mejores opciones para su uso. • investigación de componentes de arquitectura y creación de arquitecturas orientadas al procesamiento de big data.

¿Para quién es este libro?

, , . , . , . , , . .

, Linux/Unix, - / . , — — — . , , .

, , , . , , .

, , . , - , . , Excel, .

Estructura de publicación

. . , , , . : , , , . , . !

, : (DBRE), (RE). , . DBR- , , .

, . . , . — , . , , , , , , , . .
, .

1 . , — , DBRE, — , , DBRE .

2 . , . , , — , . , .
3 . . .

4 . . , , . , .

5 6 . . , , , , , .

7 . , , DBE. — , . , , , .

8 . , ? SQL? — , .

9 . . .

10 , . , , . , .

11 . , , . , , , .

12 (), , , . , « » () , , . — .

, 13 . , .

Copia de seguridad de restauracion

En los capítulos 5 y 6, nos enfocamos en diseñar y administrar la infraestructura. Esto significa que tiene una buena idea de cómo crear e implementar infraestructuras distribuidas en las que funcionan las bases de datos, así como administrarlas. Analizamos los métodos para agregar rápidamente nuevos nodos para aumentar la capacidad o reemplazar un nodo fallido. Ahora es el momento de discutir lo más importante: hacer copias de seguridad y restaurar datos.

Seamos realistas: todos consideran retroceder y restaurar actividades aburridas y tediosas. Para la mayoría, estos procedimientos son el epítome de la rutina. Al equipo no le gusta interactuar con ingenieros junior y contratistas externos y trabajar con herramientas de terceros. Antes, teníamos que lidiar con un software de respaldo horrible. Simpatizamos con usted, sinceramente.

Sin embargo, este es uno de los procesos más importantes en su trabajo. Mover datos importantes entre nodos, centros de datos y transferirlos a archivos a largo plazo es un movimiento constante del activo más valioso de su negocio: la información. Recomendamos encarecidamente que no considere las operaciones de recuperación y copia de seguridad como operaciones de segunda clase, sino que las trate como operaciones VIP. Todos no solo deben comprender los objetivos de la recuperación de datos, sino también estar familiarizados con los principios de este trabajo y el monitoreo del proceso. La filosofía de DevOps supone que todos deberían poder escribir código e implementarlo en un sistema que realmente funcione. Invitamos a cada ingeniero a participar en procesos críticos de recuperación de datos al menos una vez.

Creamos y almacenamos copias de datos (copias de seguridad y archivos) como un medio para satisfacer una necesidad específica. Son necesarios para la recuperación. A veces, la recuperación es un asunto agradable y pausado, por ejemplo, cuando se crea un entorno para auditores o se crea un entorno alternativo. Pero con mayor frecuencia se requiere reemplazar rápidamente los nodos fallidos o aumentar la capacidad de los clústeres existentes.

Hoy, en entornos distribuidos, nos enfrentamos a nuevos desafíos en la copia de seguridad y recuperación de datos. Como antes, la mayoría de los conjuntos de datos locales se distribuyen dentro de límites razonables, hasta un máximo de unos pocos terabytes. La diferencia es que estos conjuntos de datos locales son solo parte de un gran conjunto distribuido. La recuperación del sitio es un proceso relativamente controlado, pero mantener el estado en un clúster es una tarea más difícil.

Principios básicos

Comenzamos discutiendo los principios básicos de la copia de seguridad y recuperación de datos. Para un especialista en bases de datos experimentado o ingeniero de sistemas, algunos de ellos pueden parecer elementales. Si es así, puede desplazarse fácilmente por varias páginas.

¿Físico o lógico?

Una copia de seguridad física de la base de datos realiza una copia de seguridad de los archivos reales en los que se almacenan los datos. Esto significa que los formatos de archivo típicos de la base de datos son compatibles y, por lo general, hay un conjunto de metadatos en la base de datos que determina qué archivos son y qué estructuras de bases de datos hay en ellos. Si, al crear copias de seguridad de archivos, espera que otra instancia de la base de datos pueda usarlos, entonces deberá hacer una copia de seguridad y guardar los metadatos asociados a ella, en los que se basa esta base de datos, para que la copia de seguridad sea portátil.

Al crear una copia de seguridad lógica, los datos se exportan desde la base de datos a un formato que, en teoría, se puede transferir a cualquier sistema. Por lo general, los metadatos también se guardan, pero lo más probable es que sean relevantes para el momento en que se realizó la copia de seguridad. Un ejemplo es la exportación de todas las instrucciones de inserción necesarias para completar una base de datos vacía al actualizarla. Otro ejemplo es una cadena JSON. Como resultado, las copias de seguridad lógicas, por lo general, toman mucho tiempo, porque no se trata de una operación física de copia y escritura, sino de extracción de datos fila por línea. Del mismo modo, la recuperación va acompañada de todos los gastos generales habituales de la base de datos, como bloquear y crear registros de rehacer y deshacer.

Un gran ejemplo de esta separación es la distinción entre la replicación basada en filas y la replicación basada en instrucciones. En muchas bases de datos relacionales, la replicación basada en agentes significa que después de escribir en el sistema de control de versiones, se les agrega un diario de operadores del lenguaje de manipulación de datos (DML, o insertar, actualizar, reemplazar, eliminar). Estas declaraciones se pasan a las réplicas en las que se reproducen. Otro enfoque para la replicación se basa en cadenas o Change Data Capture (CDC).

¿Autónomo u operativo?

Una copia de seguridad fuera de línea (o en frío) es aquella en la que la instancia de la base de datos que usa los archivos está deshabilitada. Gracias a esto, puede copiar archivos rápidamente sin preocuparse por mantener el estado en este momento, mientras que otros procesos leen y escriben datos. Esta es una condición ideal, pero muy rara.

Con una copia de seguridad en línea (o en caliente), aún copia todos los archivos, pero existe una complejidad adicional asociada con la necesidad de obtener una instantánea coherente de los datos, que debe existir en ese momento durante el cual se realiza la copia de seguridad. Además, si el tráfico actual accede a la base de datos durante la copia de seguridad, debe tener cuidado de no exceder el rendimiento del subsistema de E / S en el nivel de almacenamiento. Incluso limitando la carga, puede encontrar que los mecanismos utilizados para mantener la consistencia introducen demoras irrazonables en la aplicación.

Completo, incremental y diferencial

Tener una copia de seguridad completa, sin importar qué método se cree, significa que el conjunto de datos local está completamente reservado. Para conjuntos de datos pequeños, esto es bastante común. Para 10 TB, esto puede llevar una cantidad de tiempo increíble.

Las copias de seguridad diferenciales le permiten hacer una copia de seguridad solo de los datos que han cambiado desde la última copia de seguridad completa. Pero en la práctica, generalmente se realiza una copia de seguridad de más datos que solo los cambios, porque los datos se organizan en forma de estructuras de cierto tamaño: páginas. El tamaño de la página es, por ejemplo, 16 o 64 Kbytes, y la página contiene muchas líneas de datos. Las copias de seguridad diferenciales hacen una copia de seguridad de todas las páginas en las que se han cambiado los datos. Por lo tanto, con tamaños de página grandes, se obtienen copias de seguridad de un tamaño mucho mayor que si solo se almacenaran datos modificados allí.

Las copias de seguridad incrementales son similares a las copias de seguridad diferenciales, excepto que la fecha de la última copia de seguridad a la que se refieren los datos modificados es incremental o completa. Por lo tanto, al restaurar desde una copia de seguridad incremental, es posible que deba restaurar la última copia de seguridad completa, así como una o más copias de seguridad incrementales, para llegar al punto actual.

Sabiendo esto, discutiremos varios puntos que deben considerarse al elegir una estrategia efectiva de respaldo y recuperación de datos.

Consideraciones de recuperación de datos

Al elegir una estrategia efectiva por primera vez, debe considerar nuevamente sus objetivos de calidad de servicio (SLO), que se discutieron en el Capítulo 2. En particular, debe tener en cuenta los indicadores de disponibilidad y confiabilidad. Cualquiera sea la estrategia que elija al final, aún debe incluir la capacidad de recuperar datos dentro de los límites predefinidos de tiempo de actividad. Y tendrá que realizar una copia de seguridad rápidamente para garantizar el cumplimiento de sus especificaciones de confiabilidad.

Si realiza una copia de seguridad todos los días y mantiene los registros de transacciones entre las copias de seguridad en el almacenamiento a nivel del sitio, puede perder fácilmente estas transacciones hasta la próxima copia de seguridad.

Además, debe considerar cómo funciona el conjunto de datos dentro de un ecosistema holístico. Por ejemplo, sus pedidos pueden almacenarse en una base de datos relacional, donde todo se arregla en forma de transacciones y, por lo tanto, se restaura fácilmente en relación con otros datos almacenados en esta base de datos. Sin embargo, después de que se forma el pedido, el flujo de trabajo puede ser activado por un evento almacenado en el sistema de colas o el almacenamiento del tipo "clave-valor". Estos sistemas pueden garantizar la integridad de los datos solo ocasionalmente o incluso brevemente (para ser efímero), haciendo referencia, si es necesario, a la base de datos relacional o utilizándola para la recuperación. ¿Cómo considerar estos flujos de trabajo durante la recuperación?

Si se trata de un entorno en el que se está desarrollando rápidamente, puede resultar que los datos almacenados en la copia de seguridad fueron escritos y utilizados por una versión de la aplicación, y después de restaurar otra se ejecuta. ¿Cómo interactuará la aplicación con datos obsoletos? Bueno, si los datos están versionados, entonces esto se puede tener en cuenta, pero debe tener en cuenta esta posibilidad y estar preparado para tales casos. De lo contrario, la aplicación puede dañar lógicamente estos datos, lo que conducirá a problemas aún mayores en el futuro.

Todos estos y muchos otros matices que no se pueden predecir deben tenerse en cuenta al planificar la recuperación de datos. Como se indicó en el capítulo 3, es imposible prepararse para cualquier situación. Pero es muy importante intentar hacerlo. La recuperación de datos es una de las tareas más importantes de un ingeniero para garantizar la confiabilidad de la base de datos. Por lo tanto, su plan de recuperación de datos debe ser lo más amplio posible y tener en cuenta tantos problemas potenciales como sea posible.

Escenarios de recuperación

Habiendo tenido en cuenta todo lo anterior, discutiremos los tipos de incidentes y operaciones que pueden requerir la recuperación de datos para que se puedan planificar todas las necesidades. Primero, puede dividir todos los escenarios en planificados y no planificados. Considerando la recuperación de datos solo como una herramienta para resolver emergencias, limitará las herramientas de su equipo solo a la atención de emergencia y simulará accidentes. Por el contrario, si la recuperación de datos se incluye en las actividades cotidianas, se puede esperar un mayor grado de conciencia y una resolución exitosa de emergencias. Además, tendremos más datos para determinar si la estrategia de recuperación es compatible con nuestros SLO. Con unas pocas ejecuciones diarias del script, será más fácil obtener un conjunto de muestras,que incluye valores límite y que se puede usar con bastante confianza para la planificación.

Escenarios de recuperación programados

¿En qué tareas diarias pueden integrarse los procesos de restauración? Aquí está la lista que encontramos con mayor frecuencia en diferentes sitios:

la creación de nuevos nodos y agrupaciones en un entorno de operación industrial;
creación de diversos ambientes;
realización de extracción, transformación y carga (Extracto, Transformación y Carga, ETL) y etapas del proceso tecnológico de procesamiento de datos para almacenamientos ubicados secuencialmente;
pruebas de rendimiento.

Al realizar estas operaciones, asegúrese de incluir el proceso de recuperación en la pila de control operativo. Considere los siguientes indicadores.

Hora. ¿Cuánto tiempo lleva completar cada componente y todo el proceso? Desempacando? ¿Copiar? ¿Ejecución de registro? ¿Pruebas?
El tamaño. ¿Cuánto espacio ocupa una copia de seguridad, comprimida y sin comprimir?
. ?

Esta información lo ayudará a evitar problemas de ancho de banda, lo que ayudará a garantizar la estabilidad del proceso de recuperación.

Nuevos nodos y clústeres en un entorno operativo industrial

Ya sea que sus bases de datos formen parte de una infraestructura inmutable o no, existen oportunidades para reconstrucciones regulares, en las que se utilizarán los procedimientos de recuperación según sea necesario.

Las bases de datos rara vez se incluyen en el escalado automático de sistemas debido a la cantidad de tiempo que puede requerirse para la carga inicial de un nuevo nodo y su colocación en un clúster. Sin embargo, no hay razones que impidan que el equipo cree un cronograma para agregar regularmente nuevos nodos al clúster para probar estos procesos. Chaos Monkey ( http://bit.ly/2zy1qsE): una herramienta desarrollada por Netflix que apaga los sistemas al azar, le permite hacer esto de tal manera que pueda probar todo el proceso de monitoreo, emisión de notificaciones, clasificación y restauración. Si aún no lo ha hecho, puede incluir esto en el plan de la lista de verificación de los procesos que su departamento de operaciones debe realizar a intervalos regulares para que todos los empleados se familiaricen con el procedimiento. Estas acciones le permiten probar no solo la recuperación total e incremental, sino también la inclusión de la replicación y el proceso de poner en funcionamiento el nodo.

Crea diferentes ambientes

Inevitablemente creará entornos de desarrollo, integración y pruebas operativas para demostración y otros fines. Algunos de estos entornos requieren una recuperación de datos completa, y necesitan implementar la recuperación de nodos y la recuperación completa del clúster. Algunos entornos tienen otros requisitos, como soporte de recuperación parcial para pruebas de características y limpieza de datos para garantizar la privacidad del usuario. Esto le permite probar la recuperación de datos en un momento específico, así como la recuperación de objetos específicos. Todo esto es muy diferente de la recuperación completa estándar y es útil para reparar el daño causado por las acciones del operador y los errores de la aplicación. Al crear una API,que proporcionan recuperación de datos a nivel de instalación y en un momento específico, puede facilitar la automatización y la familiarización de los empleados con estos procesos.

Procesos ETL y de canalización para almacenes de datos ubicados más abajo en la tubería

En cuanto a las tareas de construcción de un entorno, los procesos y las API de recuperación de instantáneas o al nivel de objetos individuales se pueden aplicar con éxito al transferir datos de bases de datos de trabajo a tuberías para un análisis posterior y para transmitir el almacenamiento .

Prueba de campo

Durante la ejecución de varios escenarios de prueba, necesitará copias de los datos. Algunas pruebas, por ejemplo, de capacidad y carga, requieren un conjunto completo de datos, lo cual es excelente para una recuperación completa. Las pruebas funcionales pueden requerir conjuntos de datos más pequeños, lo que permitirá la recuperación en un momento específico y en el nivel de la instalación.

La prueba de recuperación de datos en sí misma puede ser una operación continua. Además de utilizar procesos de recuperación de datos en escenarios cotidianos, puede configurar operaciones de recuperación continua. Esto automatizará las pruebas y la validación para identificar rápidamente cualquier problema que pueda surgir si se interrumpe el proceso de copia de seguridad. Cuando se trata de implementar este proceso, muchos preguntan cómo verificar el éxito de una recuperación.

Al crear una copia de seguridad, puede obtener una gran cantidad de datos que luego puede usar para probar, por ejemplo:

El identificador más reciente en la secuencia de incremento automático
contador de línea para objetos;
sumas de comprobación para subconjuntos de datos que solo se insertan y, por lo tanto, pueden considerarse inmutables;
sumas de comprobación en archivos de definición de esquema.

Como con cualquier prueba, el enfoque debe ser multinivel. Hay una serie de pruebas que tendrán éxito o fallarán rápidamente. Este debería ser el primer nivel de prueba. Los ejemplos son comparar sumas de verificación para definiciones de metadatos / objetos, iniciar con éxito una instancia de base de datos y conectarse con éxito a una secuencia de replicación. Las operaciones que pueden llevar más tiempo, como el cálculo de sumas de verificación y las tablas de conteo, deben realizarse más adelante durante la verificación.

Guiones no planificados

Teniendo en cuenta todos los escenarios diarios planificados que se pueden utilizar, el proceso de recuperación de datos debe estar bien depurado, documentado, resuelto y suficientemente libre de errores y problemas. Gracias a esto, los escenarios no planificados rara vez resultan tan aterradores como podrían ser. El equipo no debería ver la diferencia entre la recuperación planificada y la no planificada. Enumeramos y consideramos en detalle las situaciones que pueden requerir que realicemos procesos de recuperación:

error de usuario
error de la aplicación;
disponibilidad de servicios de infraestructura;
errores del sistema operativo y errores de hardware;
fallas de hardware;
fallas del centro de datos.

Error del usuario Idealmente, los errores del usuario rara vez deberían ocurrir. Al construir una "barandilla" y una "barrera" para los ingenieros, puede evitar muchas de estas situaciones. Sin embargo, siempre existe la posibilidad de que el operador accidentalmente cause daños. Un ejemplo típico es la cláusula WHERE olvidada en todas partes y para todos cuando se ejecuta UPDATE o DELETE en una aplicación cliente de base de datos. O, por ejemplo, la ejecución del script de limpieza de datos no se realiza en un entorno de prueba, sino en un sistema de "producción" en funcionamiento. A menudo, la operación se realiza correctamente, pero en el momento incorrecto o no para esos hosts. Todo esto se relaciona con errores del usuario. A menudo se identifican y corrigen de inmediato. Sin embargo, a veces las consecuencias de tales cambios pasan desapercibidas durante varios días o semanas.

Errores de aplicación

Los errores de aplicación son los peores de los escenarios discutidos, ya que pueden ser muy insidiosos. Las aplicaciones cambian constantemente la forma en que interactúan con los almacenes de datos. Muchas aplicaciones también gestionan integridad referencial y punteros externos a recursos tales como archivos o identificadores de terceros. Da miedo imaginar lo que sucederá si solo realiza un cambio que estropea los datos, los elimina o agrega datos incorrectos de maneras que pueden pasar desapercibidas durante bastante tiempo.

Servicios de infraestructura

En el Capítulo 6, presentamos la magia de los servicios de administración de infraestructura. Desafortunadamente, estos sistemas pueden resultar tan destructivos como útiles, lo que puede conducir a consecuencias a gran escala relacionadas con la edición de un archivo, apuntando a otro entorno o configuraciones de configuración incorrectas.

Errores del sistema operativo y errores de hardware

Los sistemas operativos y los equipos con los que interactúan también son sistemas creados por personas, por lo que pueden producirse errores que pueden tener consecuencias inesperadas debido a configuraciones indocumentadas o poco conocidas. En el contexto de la recuperación de datos, esto es especialmente cierto con respecto a la forma en que los datos se transfieren desde la base de datos a través de cachés del sistema operativo a sistemas de archivos, controladores y eventualmente a discos. El daño o la pérdida de datos ocurre mucho más a menudo de lo que pensamos. Desafortunadamente, nuestra confianza y dependencia en estos mecanismos da lugar a la expectativa de integridad de datos en lugar de escepticismo al respecto.

Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?

. , , . , . — .

, ZFS, , . RAID-, , .

Fallos de

hardware Los componentes de hardware fallan en principio, y en los sistemas distribuidos esto ocurre regularmente. Constantemente encuentra fallas de disco, memoria, procesador, controlador y dispositivo de red. Las consecuencias de estas fallas de hardware pueden ser la falla de los nodos o demoras en los nodos, lo que hace que el sistema sea inutilizable. Los sistemas compartidos, como los dispositivos de red, pueden influir en grupos completos, haciéndolos inaccesibles o dividiéndolos en grupos más pequeños que no son conscientes de que la red se ha dividido. Esto puede generar discrepancias rápidas y significativas en los datos que deben combinarse y corregirse.

Fallos del centro de datos

A veces, los problemas de hardware a nivel de red provocan bloqueos en el centro de datos. Sucede que sobrecargar los backplanes de almacenamiento provoca fallas en cascada, como fue el caso de los servicios web de Amazon en 2012 ( http://bit.ly/2zxSpzR ). A veces, los huracanes, terremotos y otros desastres conducen a la falla de centros de datos completos. La recuperación posterior probará incluso las estrategias de recuperación más confiables para la fuerza.

Alcance del script

Después de enumerar los escenarios planificados y no planificados que pueden requerir recuperación, agregamos una dimensión más a estos eventos para que nuestra presentación se vuelva voluminosa. Esto será útil para elegir el método de respuesta más apropiado. Considere las siguientes opciones:

falla localizada dentro de un solo nodo;
falla de todo el clúster;
Una falla que afecta a todo el centro de datos o a varios clústeres.

En el caso de una falla local o de un solo sitio, la recuperación se limita a un host. Puede agregar un nuevo nodo al clúster para aumentar la capacidad o reemplazar un nodo fallido. O bien, el sistema implementa una actualización continua y luego la restauración se realizará nodo por nodo. En cualquier caso, esta es una recuperación local.

A nivel de clúster, la necesidad de recuperación es global para todos los miembros de este clúster. Quizás hubo un cambio destructivo o eliminación de datos que cayeron en cascada a todos los nodos. O necesita introducir un nuevo clúster para probar la capacidad.

Si hubo una falla en la escala del centro de datos o en varios grupos, significa que es necesario restaurar todos los datos en el lugar de su ubicación física o en toda el área de la falla. Esto puede deberse a una falla del almacén de datos compartidos o una falla que causó una falla catastrófica del centro de datos. Tal recuperación también puede ser necesaria durante la implementación planificada de un nuevo sitio secundario.

Además del alcance, hay un alcance de conjunto de datos. Aquí puede enumerar tres opciones posibles:

un objeto
varios objetos;
metadatos de la base de datos.

A la escala de un objeto, solo este objeto en particular requiere recuperación de datos, algunos o todos. El caso discutido anteriormente, como resultado de lo cual cuando se realizó la operación DELETE, se eliminaron más datos de lo planeado, se refiere a una falla dentro del mismo objeto. Si varios objetos fallan, varios o, posiblemente, todos los objetos en una base de datos particular se ven afectados. Esto puede suceder si la aplicación está dañada, la actualización o la migración del segmento falla. Finalmente, se producen bloqueos en la escala de los metadatos de la base de datos cuando todo está en orden con los datos almacenados en la base de datos, pero se pierden los metadatos que los hacen utilizables, como los datos del usuario, los privilegios de seguridad o el cumplimiento de los archivos del sistema operativo.

Consecuencias del guión

Es importante no solo identificar el escenario que requiere recuperación e identificar el área de falla, sino también determinar las posibles consecuencias, ya que serán significativas al elegir un enfoque para la recuperación. Si la pérdida de datos no afecta el SLO, puede elegir un enfoque metódico y lento que minimice la expansión de las consecuencias. Los cambios más globales que conducen a la interrupción del SLO deben abordarse con precaución, eligiendo una recuperación rápida del servicio y solo luego pasando a una limpieza a largo plazo. Todos los enfoques se pueden dividir en las siguientes tres categorías.

El impacto en el SLO, la falla de la aplicación, afectó a la mayoría de los usuarios.
Amenaza SLO, algunos usuarios han sufrido.
Las funciones que no amenazan el SLO se ven afectadas.

Sobre los autores

Campbell Lane (Laine Campbell) es gerente senior (Directora Senior) de la empresa de diseño Fastly. También fue fundadora y directora ejecutiva de PalominoDB / Blackbird, un servicio de consultoría que mantiene bases de datos para varias compañías, incluidas Obama for America, Activision Call of Duty, Adobe Echosign, Technorati, Livejournal y Zendesk. Tiene 18 años de experiencia operando bases de datos y sistemas distribuidos escalables.

Cherity Majors(Charity Majors) es el CEO y cofundador de honeycomb.io. Combinando la precisión de los agregadores de registros, las métricas de velocidad de series temporales y la flexibilidad de las métricas de rendimiento de aplicaciones (APM), Honeycomb es el primer servicio analítico de nueva generación en el mundo. Cheriti anteriormente era especialista en operaciones de Parse / Facebook, administrando una enorme flota de conjuntos de réplicas MongoDB, así como Redis, Cassandra y MySQL. También trabajó en estrecha colaboración con el equipo de RocksDB en Facebook, participando en el desarrollo y la implementación de la primera instalación de Mongo + Rocks del mundo utilizando la API de complemento de almacenamiento.

»Se puede encontrar más información sobre el libro en el sitio web del editor
» Contenido
» Extracto

Para Khabrozhiteley 25% de descuento en el cupón - Bases de datos

Al pagar la versión impresa del libro, se envía un libro electrónico por correo electrónico.

Libro "Bases de datos. Ingeniería de confiabilidad