Descripción general del sistema de almacenamiento de datos

Confiable, escalable y mantenible

Muchos de estos ahora requieren un uso intensivo de datos en lugar de un uso intensivo de cómputo. Para este tipo de aplicaciones, la potencia de procesamiento de la CPU a menudo no es el primer factor limitante, la clave radica en la cantidad de datos, la complejidad de los datos y el polígono rápido de los datos.
Módulos de aplicación de uso intensivo de datos:

• Base de datos: almacena datos y admite acceso secundario.
• Caché: Almacene en caché los resultados de operaciones complejas o costosas para acelerar el próximo acceso.
• Indexación: busque datos por palabras clave y admita varios filtros.
• Procesamiento de flujo: envíe mensajes continuamente a otro proceso y procéselos de forma asíncrona.
• Procesamiento por lotes: Procese periódicamente grandes cantidades de datos acumulados.
  Nuestras bases de datos, colas y cachés comunes se denominan colectivamente " sistemas de datos " .
  La siguiente es una arquitectura de sistema común:

Pero en realidad, cuando el programa se ejecuta, no es ideal y surgirán varios problemas. Por ejemplo: si ocurre una falla parcial en el sistema, ¿cómo garantizar la corrección e integridad de los datos? ¿Cómo proporciona un servicio constante a los clientes cuando se producen rebajas? ¿Cómo escala el sistema a medida que aumenta la carga? En base a esto, presentamos las siguientes tres características del sistema:

• Confiabilidad (Reliability)
  Cuando ocurren accidentes (falla de hardware, software, error humano, etc.), el sistema debe funcionar normalmente, el rendimiento puede verse reducido, pero se garantiza el funcionamiento normal.
• Escalabilidad (Scalability)
  Con el crecimiento de la escala de datos, como el volumen de datos, el tráfico o la complejidad, el sistema debe coincidir con este crecimiento de manera razonable
• Mantenibilidad (Maintainability)
  A medida que pasa el tiempo, cuando los recién llegados se unen al desarrollo y operación y mantenimiento del sistema, el sistema debería funcionar sin problemas.

fiabilidad

Para el software, las expectativas típicas incluyen:

• La aplicación realiza las funciones esperadas por el usuario.
• Se pueden tolerar los errores del usuario o el uso incorrecto.
• El rendimiento puede manejar escenarios típicos, presión de carga razonable y volumen de datos.
• El sistema está protegido contra cualquier acceso no autorizado y uso indebido.

escalabilidad

Descripción Carga útil

Primer vistazo a las operaciones comerciales típicas de Twitter:

• Publicar tweets: los usuarios pueden enviar mensajes a todos los seguidores, con un promedio de aproximadamente 4,6 mil solicitudes por segundo y un pico de aproximadamente 12 mil solicitudes por segundo.
• Navegación en la línea de tiempo de la página de inicio: Promedio de 300 000 solicitudes/s Ver las últimas noticias del objeto en cuestión.
  Las personas cuidadosas encontrarán que el punto no son demasiados mensajes para enviar, sino una gran estructura de despliegue: cada usuario seguirá a muchas personas y será seguido por muchas personas. Se puede realizar el siguiente procesamiento:
  (1) Insertar el nuevo mensaje enviado en la colección global de tweets. Cuando el usuario vea la línea de tiempo, primero encuentre a todos los seguidores, enumere todos los tweets de estas personas y finalmente ordene por tiempo. Sentencias SQL similares:

SELECT tweets.*, users.* FROM tweets JOIN users ON tweets.sender_id = user.id JOIN follows ON follows.followee_id = users.id WHERE follows.follwer_id = current_user

El modelo relacional admite la línea de tiempo:
(2) Mantenga un caché para la línea de tiempo de cada usuario, similar a un buzón de tweet para cada usuario. Cuando un usuario tuitea un nuevo tuit, se consulta a sus seguidores y el tuit se inserta en la memoria caché de la línea de tiempo de cada seguidor. (Agregue una capa de mecanismo de almacenamiento en caché)

Como se muestra en la imagen:
La desventaja obvia de este método es que aumenta la carga de trabajo.Si hay 75 seguidores y 4.6k tweets por segundo, entonces se requiere 4.6 X 75 = 354k por segundo para escribir en el caché. Si un usuario tiene muchos seguidores, es difícil de lograr.
Podemos ponderar según la frecuencia de twittear del usuario Actualmente, twittear se implementa en base al método 2, pero estamos pasando a un método que combina los dos métodos.

mantenibilidad

Un buen sistema de software no puede detenerse en el momento inicial. También es necesario considerar el coste de mantenimiento posterior y el coste de adaptación de los recién llegados, que se pueden resumir en tres principios:

• Operatividad: Es conveniente que el equipo de operación mantenga el sistema funcionando sin problemas. (observación, seguimiento, automatización, previsibilidad)
• Simplicidad: Simplifica la complejidad del sistema para facilitar que los nuevos ingenieros entiendan el sistema. (abstracto, comprensible, limpio, conciso, elegante)
• Capacidad de evolución: los ingenieros pueden mejorar fácilmente el sistema y adaptarlo a escenarios atípicos a medida que cambian los requisitos, también conocido como extensibilidad, modificabilidad o plasticidad.

Modelo de datos y lenguaje de consulta

El desarrollo de cualquier software es inseparable del modelo de datos, que es la infraestructura. Los programas complejos pueden tener muchas capas intermedias, pero la idea básica es la misma, cada capa oculta la complejidad de la capa subyacente al proporcionar un modelo de datos conciso.

modelo de datos

modelo jerárquico

Representa los datos anidados en registros (árboles), que pueden admitir relaciones de uno a muchos, pero es más difícil admitir relaciones de muchos a muchos. Para resolver este problema, surgió más tarde un modelo relacional y un modelo de red.

modelo relacional

El modelo de datos más popular hoy en día es SQL, cuyo objetivo es ocultar los detalles de implementación detrás de una interfaz más concisa. NOSQL ocupa el segundo lugar. Puede proporcionar un rendimiento de escritura ultrarrápido y admitir algunas operaciones de consulta específicas. En la actualidad, muchos sistemas de aplicación se implementan combinando los dos.

modelo de red

La diferencia entre este y el modelo jerárquico es que un registro puede tener múltiples padres, los enlaces entre registros no son claves foráneas, sino más bien punteros en el lenguaje, y la única forma de acceder a los datos es elegir un registro comenzando desde la raíz. (similar al gráfico, lista enlazada)

modelo de documento

Resuelve principalmente la agregación de información local, que se puede detectar o mostrar fácilmente al mismo tiempo. Pero la desventaja más obvia es que no puede realizar consultas de operaciones conjuntas en varias tablas.

Modelo de datos de gráfico

Un gráfico consta de dos tipos de objetos: vértices (también conocidos como nodos/entidades) y bordes (también conocidos como relaciones/arcos). A medida que las relaciones entre los datos se vuelven más y más complejas, se vuelve más natural modelar los datos en un gráfico. modelo

Con tantos modelos, ¿cómo elegimos uno? A través de la descripción, todos pueden conocer también las características de cada modelo.

• Los datos de la aplicación son similares a los documentos (árbol de relaciones de uno a muchos, al cargar todo el árbol a la vez), y es más apropiado elegir el modelo de documento.
• El modelo relacional está más inclinado a la descomposición de datos, descomponiendo el modelo de documento en varias tablas.
• Los gráficos son más adecuados para redes sociales, gráficos web, redes de carreteras
• La mayoría de las bases de datos actuales admiten tablas relacionales y de documentos.

lenguaje de consulta de datos

Hay lenguajes de consulta declarativa (SQL) y de consulta imperativa (IMS, CODASYL).
Imperativo:

function getSharks() {
    
    
	var sharks = [];
	for (var i = 0; i < animals.length; i++) {
    
    
		if (annimals[i].family === "Sharks") {
    
    
			sharks.push(animals[i]);
		}
	}
}

SQL:

SELECT * FROM animals WHERE family = 'Sharks';

Si el lenguaje declarativo se ejecuta en paralelo, mientras que el lenguaje imperativo es difícil de paralelizar en varios núcleos y máquinas porque especifica un orden de ejecución específico.

Consulta MapReduce

Es un modelo de programación para el procesamiento por lotes de cantidades masivas de datos en muchas máquinas. No es declarativo ni imperativo, sino algo intermedio: la lógica de la consulta se expresa en fragmentos de código que la máquina puede llamar repetidamente. Se basa en las funciones de mapa (también llamado recopilar) y reducir (también llamado doblar o inyectar) en lenguajes de programación funcionales.

consulta de gráfico

Cypher (llamado así por un personaje de The Matrix ) es un lenguaje de consulta declarativo para gráficos de propiedades.

Almacenamiento ternario y SPARQL

En el almacenamiento ternario, toda la información se almacena en una forma muy simple de tres partes (sujeto, predicado, objeto), como: (chico malo, me gusta, jugar), chico malo es el sujeto, como es el predicado (verbo), El juego es el objeto. Los cuerpos de las ternas son equivalentes a los vértices del grafo. El objeto es uno de los dos tipos siguientes:

1. Valores en tipos de datos primitivos, como cadenas o números. El predicado y el objeto del triplete corresponden entonces a la clave y el valor de las propiedades del sujeto (vértice), respectivamente. Tales como: (hxg, edad, 26) es como el vértice hxg, atributo {"edad": 26}.
2. Otro vértice en el gráfico, en este momento el predicado es el borde del gráfico, el sujeto es el vértice de la cola y el objeto es el vértice de la cabeza. Por ejemplo: (hxg, amor, hxm), los sujetos hxg y hxm son ambos vértices, y el predicado amor es la etiqueta de la arista que los une.
   SPARQL (pronunciado: chispa) es un lenguaje de consulta almacenado ternario que emplea el modelo de datos RDF .

Almacenamiento y recuperación de datos

Todos los sistemas son inseparables de la interacción de datos, el almacenamiento de datos y la recuperación/adquisición. Una base de datos más simple, que se implementa mediante dos funciones Bash:

#!/bin/bash
db_set () {
    
    
	echo "$1,$2" >> database
}

db_get () {
    
    
	grep "^$1，" database | sed -e "s/^$1,//" | tail -n 1
}

Estas dos funciones implementan un almacén de clave-valor. Llame al valor clave db_set y guárdelo directamente en la base de datos (archivo). Este método adopta el método de agregar.Si una determinada clave se actualiza varias veces, la versión anterior no se sobrescribirá. En su lugar, comprobará directamente la última aparición de la clave para encontrar el último valor (tail -n 1). Pero es obvio que si el archivo es demasiado grande, el rendimiento de la función db_get es muy pobre Cada vez que obtiene una clave, debe recorrer desde el principio y la complejidad del tiempo es O (n). Por lo tanto, existe el concepto de índice, pero no importa cuál sea el índice, aumentará la sobrecarga de actualización de datos.

índice hash

El índice se realiza a través del mapa hash (tabla hash), si está compuesto por archivos adicionales arriba. El mapa hash en la memoria se puede guardar, y cada clave se asigna a un desplazamiento de byte específico en el archivo de datos uno por uno, para que se pueda encontrar la posición de cada valor.

El enfoque central adoptado por Bitcask (el motor de almacenamiento predeterminado en Riak) es el ejemplo anterior. Puede proporcionar lectura y escritura de alto rendimiento. Siempre que todas las claves se puedan colocar en la memoria, solo se requiere una dirección de disco para cargar el valor en la memoria. Por supuesto, solo agregar un archivo no es suficiente, se requiere cortar el registro. El procesamiento de compresión también se puede realizar para eliminar claves duplicadas y, cuando se comprime, también se puede escribir en un nuevo archivo de segmento y se pueden fusionar varios segmentos al mismo tiempo. En una implementación real, existen las siguientes preguntas importantes:

• Formato de archivo: la adición de registro debe usar formato binario, primero registrar la longitud de la cadena en bytes y luego mantenerse al día con la longitud original de la cadena
• Eliminar registro: para eliminar una clave, se debe agregar un identificador de eliminación especial (también llamado lápida) al archivo de datos. Al fusionar archivos, una vez que se encuentra una lápida, la clave se descarta.
• Recuperación de fallas: si se reinicia la base de datos, el mapa hash de memoria se perderá y, si se cargan todos los archivos de escaneo, llevará mucho tiempo. Bitcask almacena cada instantánea del mapa hash en el disco, que se puede cargar en la memoria más rápido.
• Registros parcialmente escritos: la base de datos falla en cualquier momento, incluso durante el proceso de agregar registros al registro. Los archivos Bitcask incluyen sumas de verificación, que se pueden encontrar parcialmente corruptas y descartadas.
• Control de concurrencia: dado que los archivos de datos se agregan, son inmutables y no se escriben secuencialmente, varios subprocesos pueden leerlos al mismo tiempo.
• Limitaciones: debe almacenarse en la memoria, si el volumen de datos de la clave es demasiado grande, el costo será muy alto. La consulta de rango de intervalo es extremadamente ineficiente.
  Alguien preguntó, ¿por qué no actualizar el archivo en su lugar, pero tener que agregarlo?
• En primer lugar, agregar y fusionar segmentos son principalmente escrituras secuenciales, que son mucho más rápidas que las escrituras aleatorias.
• La concurrencia y la recuperación de fallas son mucho más simples si los archivos de segmento son agregables o inmutables, por ejemplo: no se preocupe por fallar cuando los valores sobrescritos dejan archivos con valores antiguos y nuevos.
• La fusión de segmentos antiguos evita el problema de la fragmentación de archivos de datos con el tiempo.

SSTables&LSM-Árbol

Si se requiere que las claves que se escribirán estén ordenadas, este formato se convierte en una tabla de cadenas ordenadas, denominada: SSTable. La clasificación de memoria generalmente tiene árboles rojo-negro o árboles AVL.
Proceso de compilación (LevelDB y RocksDB):

• Escriba datos y agréguelos a un árbol equilibrado en memoria (como un árbol rojo-negro). Este árbol en memoria a veces se llama memtable.
• Cuando la memoria es más grande que un cierto umbral (generalmente unos pocos megabytes), se escribe en el disco como un archivo SSTable y, al mismo tiempo, puede continuar agregándose a una nueva instancia de memtable.
• Maneje la solicitud de lectura, intentando una recuperación de memoria, luego el último archivo de segmento de disco, recorriendo los otros archivos una última vez hasta que se encuentre el objetivo.
• El proceso en segundo plano realiza periódicamente la fusión y compactación de segmentos, descartando los valores sobrescritos o eliminados.
  Hay un problema con el esquema anterior: si la base de datos falla, los datos escritos más recientemente (en la tabla de memoria pero no en el disco) se perderán. Por esta razón, primero puede mantener un archivo separado en el disco y cada escritura agregará el registro, fallando. Luego se puede restaurar la tabla de memoria. Cada vez que se escribe una tabla mem en SSTabl, se puede descartar el registro correspondiente.
  El motor de almacenamiento basado en el principio de archivo de clasificación por fusión y compresión generalmente se denomina motor de almacenamiento LSM.

optimización del rendimiento

• Si encuentra una clave que no existe, siempre volverá y accederá al archivo de segmento anterior (IO de disco múltiple). En base a esto, los motores de almacenamiento suelen utilizar filtros Bloom.
• LevelDB y RocksDB usan compresión por niveles, HBase usa clasificación de tamaño y Cassabdra admite ambos. Clasificación de tamaño: las SSTables más nuevas y más pequeñas se fusionan sucesivamente en SSTables más antiguas y más grandes. Jerarquía: un rango de claves se divide en múltiples SSTables más pequeñas, y las más antiguas se mueven a "niveles" separados.

árboles B

Es la implementación de índice estándar de casi todas las bases de datos relacionales, y muchas bases de datos no relacionales también se utilizan con frecuencia. Los detalles específicos de la implementación se pueden encontrar en este blog que escribí antes: El principio de implementación y optimización interna de MySQL
Para resolver el problema de que la operación necesita cubrir diferentes páginas, y la inserción causa el desbordamiento de la página, debe dividirse. En este momento, si la base de datos falla después de completar la escritura parcial de la página, eventualmente provocará daños en el índice. Debido a que es necesario agregar un registro de escritura anticipada (WAL), también se denomina registro de rehacer. Puede admitir modificaciones adicionales. El árbol B actualiza primero el WAL y luego modifica el árbol. Cuando se produce un bloqueo, se puede restaurar al último estado coherente.

optimización del rendimiento

• Copiar sobre escribir: en lugar de sobrescribir y mantener WAL para la recuperación de fallas, algunas bases de datos usan páginas modificadas escritas en una ubicación diferente, y se crea una nueva versión de la página principal en el árbol y apunta a la nueva ubicación.
• Guardar la información abreviada de la clave puede ahorrar espacio y se pueden insertar más claves en la página, de modo que el árbol tenga un factor de ramificación más alto y reduzca el número de capas (árbol B+).
• Algunas implementaciones de árbol B diseñan el árbol de modo que las páginas de hojas adyacentes se almacenen en el disco secuencialmente, y mantener este orden se vuelve cada vez más difícil a medida que crece el árbol.
• Agregando punteros adicionales al árbol, cada página hoja puede hacer referencia a otras páginas hermanas a la izquierda y a la derecha, que se pueden escanear secuencialmente (árbol B+).

Comparado

• LSM-tree es más rápido para escribir y B-tree es más rápido para leer.
• El árbol B escribe datos al menos dos veces, una en el registro de escritura anticipada y otra en la propia página del árbol (también pueden producirse saltos de página).
• La desventaja del almacenamiento de registros es que la compresión interferirá con las operaciones de lectura y escritura Incluso si se trata de una compresión incremental, debido a los recursos concurrentes limitados del disco, es fácil esperar solicitudes de lectura y escritura al comprimir.
• Si el volumen de escritura es alto, pero la compresión no puede igualar la velocidad a la que se escriben los nuevos datos, el disco seguirá teniendo archivos de segmento sin fusionar hasta que se quede sin espacio.

otros índices

El índice de clave principal, el índice secundario, el índice de varias columnas, el índice de texto completo y el índice difuso no se describirán aquí.

Procesamiento de transacciones frente a procesamiento analítico

Las transacciones no necesariamente tienen ACID, las transacciones solo significan permitir que los clientes lean y escriban con baja latencia.
Cosas como comentarios de blogs, acciones de juegos, contactos de la libreta de direcciones, etc. se denominan procesamiento de transacciones en línea (OLTP).
Al igual que el análisis de datos, escanear una gran cantidad de registros se denomina procesamiento analítico en línea (OLAP).

base de datos

El almacén de datos es una base de datos separada que los analistas pueden usar sin afectar las operaciones de OLTP, y todos los almacenes son copias de OLTP. Cada gran empresa tendrá un almacén de datos.
Almacén de datos y proceso ETL (Extracción-Transformación-Carga) simplificado:

Esquemas de análisis de estrellas y copos de nieve

El esquema en estrella surge cuando se visualiza la tabla, la tabla de hechos está en el medio, rodeada por una serie de tablas de dimensiones, por ejemplo: blog personal, comentarios, me gusta, navegación, tipos de artículos, etc., todos están almacenados y asociados alrededor la tabla de artículos. Una variación de esta plantilla se convierte en el esquema de copo de nieve, donde las dimensiones se subdividen en subespacios.

almacenamiento columnar

A veces, la cantidad de datos almacenados en la tabla es grande y hay muchas columnas. Consultamos algunas de estas columnas a la vez, pero en la mayoría de las bases de datos, el almacenamiento está dispuesto en forma de filas, por lo que es necesario cargar todas las filas del disco en la memoria, analizarlas y filtrar las filas que no. no cumplir con los criterios. **Esto lleva mucho tiempo.
Si se usa el almacenamiento en columnas, todos los valores de cada columna se almacenan juntos, y cada columna se almacena en un archivo separado, y la consulta solo necesita leer y analizar las columnas utilizadas en la consulta, lo que puede ahorrar mucho trabajar.

compresión de columna

La compresión de columna general se basa en la compresión de mapa de bits.

Ancho de banda de memoria y vectorización

Para consultas de almacenamiento de datos que escanean millones/decenas de millones, el ancho de banda para cargar datos del disco a la memoria es un cuello de botella importante. Necesitamos considerar cómo otorgar de manera eficiente el ancho de banda de la memoria para el caché de la CPU, y la compresión de columnas puede hacer que se carguen más filas en la columna en el caché L1.

Operaciones de escritura de almacén de columnas

Actualmente usando LSM-tree. Todas las escrituras se ingresan primero en el almacén de memoria, se agregan a la estructura ordenada y luego están listas para escribirse en el disco. Cuando se han acumulado suficientes escrituras, se fusionan con el archivo de columna en el disco y se escriben en un nuevo archivo en lotes. (El almacén de datos comercial Vertica adopta este enfoque)

Codificación y evolución de datos

En los proyectos de desarrollo, a menudo se encuentra que el flujo ascendente y descendente, o incluso el formato/esquema de datos lógicos del propio código, cambia. En este momento, el programa debe ajustarse en consecuencia (por ejemplo: agregar campos al registro, lectura del programa). Para un sistema maduro y enorme, no es fácil de actualizar e iterar.

• Para los programas del lado del servidor, es posible que se requieran actualizaciones graduales (implementación por etapas), implementadas en una pequeña cantidad de nodos (o volumen pesado), verifique si es normal e implemente gradualmente en su totalidad.
• Para el cliente, solo puede depender de las actualizaciones de los usuarios.

Al mismo tiempo, significa que las versiones de código antiguas y nuevas, así como los formatos de datos nuevos y antiguos, pueden coexistir en el sistema al mismo tiempo. Por lo tanto, es necesario mantener la compatibilidad bidireccional al diseñar:
compatibilidad con versiones anteriores: el código más nuevo puede leer datos escritos por código antiguo.
Compatibilidad con versiones anteriores: el código antiguo puede leer datos escritos por código nuevo.
La compatibilidad con versiones anteriores es fácil, la compatibilidad con versiones anteriores requiere que el código antiguo ignore las adiciones realizadas por las versiones más nuevas del código.

Formato de codificación de datos

Los programas generalmente tienen al menos dos representaciones de datos diferentes:

• En la memoria, los datos se almacenan en estructuras como objetos, estructuras, listas, arreglos, tablas hash y árboles.
• Cuando los datos se escriben en un archivo o se envían a través de la red, deben codificarse en algún tipo de secuencia de bytes independiente.
  La conversión de representación de memoria a secuencia de bytes se convierte en codificación (serialización), y el proceso opuesto se convierte en decodificación (deserialización)

formato específico del idioma

A menudo, cada lenguaje de programación tiene su propio método de codificación de funciones a las que el otro lenguaje no puede acceder directamente. La decodificación también plantea problemas de seguridad.

JSON, XML y variantes binarias

JSON, XML, incluido CSV, son todos formatos de texto, que son muy legibles. JSON distingue entre cadenas y números, no entre enteros y flotantes, y no especifica precisión. Los números enteros mayores que 2 a la potencia de 53 no se pueden representar exactamente en números de punto flotante de doble precisión IEEE 754 . Twitter usa la API para devolver JSON que contiene la ID de Twitter dos veces, una es un número JSON y la otra es una cadena decimal, para resolver el problema de que JS no analiza el número correctamente. La desventaja es que ocupa mucho espacio.
La codificación binaria es pequeña en tamaño y rápida en la transmisión de red, lo cual es muy adecuado para escenarios con una gran cantidad de datos.

Thrift与Búferes de protocolo

Thrift define el formato de datos:

struct Person {
    
    
	1: required string  userName,
	2: optional i64 age, 
}

Los búferes de protocolo definen el formato de los datos:

message Person {
    
    
	required string  user_name  = 1;
	optional int64  age         = 2, 
}

Si el campo se establece como obligatorio, pero no se completa, fallará en el tiempo de ejecución.

Avro

Es otro formato de codificación binaria que tiene algunas diferencias interesantes con Protocol Buffers y Thrift. Avro comenzó en 2009 como un subproyecto de Hadoop.
Avro IDL (editado por humanos):

record Persion {
    
    
	string userName;
	union {
    
    null, long}  favorite = null;
	array<string> interests;
}

Formulario Avro JSON:

{
	"type":"record",
	"name":"Person",
	"fields": [
		{"name":"userName",    "type": "sting"},
		{"name":"favorite",    "type": ["null", "sting"], "default": null},
		{"name":"interests",    "type": {"type", "array", "items": "string"}},
	]
}

Ventajas de definir un esquema de datos:

• Son más compactos que las diversas variantes de "JSON binario" y pueden omitir nombres de campo en los datos codificados.
• Los esquemas son una forma valiosa de documentación, porque los esquemas son necesarios para la decodificación para que pueda estar seguro de que están actualizados.
• La base de datos de esquemas permite verificar los cambios de esquema para la compatibilidad hacia adelante y hacia atrás antes de implementar cualquier cosa.
• Para los lenguajes tipificados estáticamente, la capacidad de generar código a partir de esquemas es útil, lo que permite la verificación de tipos en el momento de la compilación.

modo de flujo de datos

Los datos pueden fluir de un proceso a otro en una variedad de formas. Métodos comunes de flujo de datos:

• base de datos
• Llamadas de servicio (REST y RPC)
• mensajería asíncrona

DESCANSAR

REST no es un protocolo, sino una filosofía de diseño basada en los principios de HTTP. Hace hincapié en formatos de datos simples, utiliza direcciones URL para identificar recursos y utiliza funciones HTTP para el control de la memoria caché, la autenticación y la negociación del tipo de contenido.

JABÓN

Se basa en el protocolo XML para enviar solicitudes de API web.

Mensajería (RabbitMQ, ActiveMQ, HornetQ, NATS, Kafka)

En pocas palabras, el cliente pasa a otro proceso con baja latencia.
ventaja:

• Puede actuar como un área de caché, suavizar los picos y aumentar la disponibilidad del sistema.
• Puede enviar mensajes automáticamente a procesos bloqueados, evitando la pérdida de mensajes.
• Evita la necesidad de que el remitente sepa la dirección IP y el número de puerto del receptor.
• Admite el envío de un mensaje a múltiples destinatarios.
• Se logra la separación de emisor y receptor.

Lo anterior es un breve resumen del sistema de almacenamiento.