Si le hubiera preguntado a un profesional de TI si el almacenamiento de objetos es bueno para las bases de datos, la respuesta durante la mayor parte de la última década habría sido un rotundo “no”.
La respuesta habría sido bastante obvia porque las bases de datos, especialmente en entornos ocupados y de misión crítica, están sujetas a muchos cambios por parte de muchos usuarios, ya sea simultáneamente o casi simultáneamente.
Las bases de datos necesitan IOPS (operaciones de entrada/salida por segundo) y necesitan alguna forma de hacer cumplir la consistencia de los datos, lo que significa que el almacenamiento SAN de acceso en bloque ha sido durante mucho tiempo la forma de lograrlo.
Sin embargo, esa respuesta “no” puede haber cambiado en los últimos años a algo más parecido a un “tal vez”.
Con el auge de las bases de datos que utilizan el almacenamiento en memoria, hay una gran cantidad de IOPS cerca de la computación, por lo que es posible que el almacenamiento de objetos sea el sitio para el almacenamiento masivo de conjuntos de datos, con segmentos movidos a la memoria durante el procesamiento.
Pero, ¿constituye esto operaciones de base de datos que utilizan almacenamiento de objetos?
Las SAN son buenas para IOPS pero la capacidad es un cuello de botella
Durante un par de décadas, el almacenamiento de acceso en bloque SAN fue el recurso ideal para ejecutar bases de datos y las aplicaciones empresariales basadas en ellas. IOPS era el rey, ya que potencialmente numerosas solicitudes de E/S llegaban a la base de datos desde los sistemas cliente.
Para hacerle frente, las SAN se hicieron cada vez más grandes y con mayor rendimiento, con la eventual adopción generalizada de medios flash muy rápidos, en términos de IOPS. El consejo actual de NetApp sobre el tamaño del almacenamiento para SAP HANA, por ejemplo, es en términos de HDD SAS (presumiblemente en el sitio) y capacidad flash.
Pero si bien las SAN pueden brindar resultados en términos de IOPS, incluso si eso se vuelve parcialmente redundante a medida que las bases de datos de la aplicación se almacenan en la memoria, aún tienen sus límites, y eso es en términos de escala. Aquí, el almacenamiento de objetos sobresale. No puede producir el tipo de IOPS que una SAN puede proporcionar a las operaciones de la base de datos, pero puede brindar rendimiento en grandes volúmenes.
Hay dos buenas razones por las que eso es un gran problema en este momento. Uno, durante varios años los volúmenes de datos que se analizan han crecido cada vez más. Dado que el almacenamiento de acceso a archivos o bloques comienza a volverse difícil de manejar por encima de los 100 TB, el almacenamiento de objetos parece una buena apuesta con su capacidad de escalar a PB.
Al mismo tiempo, el almacenamiento de objetos se ha convertido en el modo de almacenamiento de facto para la nube, lo que aumenta su prevalencia tanto fuera como dentro del sitio. Además, como parte del telón de fondo, hemos visto el surgimiento de aplicaciones basadas en bases de datos en memoria, como SAP HANA, entregadas en la nube.
Un gran beneficio del almacenamiento de objetos en la nube es el bajo costo. En Amazon, por ejemplo, el almacenamiento de archivos o bloques puede costar 10 veces más que el almacenamiento de objetos.
Almacenamiento de objetos, S3 como almacenamiento masivo para bases de datos, AI/ML
Con el surgimiento del almacenamiento de objetos, y en particular S3, hemos visto el aumento de su uso como almacenamiento masivo que se puede entregar al trabajo de base de datos en memoria y para análisis de IA/ML.
Junto a esta trayectoria ha estado el surgimiento de bases de datos que funcionarán con S3 (o almacenamiento compatible con S3) como almacén de datos, como MongoDB, CockroachDB, MariaDB y Teradata. El fenómeno de almacenamiento de datos en la nube Snowflake también está basado en S3.
Pero tenemos que recordar las limitaciones. Las SAN funcionan bien con las bases de datos porque las solicitudes de los usuarios literalmente se sumergen y leen, escriben, etc., en partes de los archivos. Existen mecanismos para limitar la posibilidad de conflictos entre las solicitudes de los usuarios.
El almacenamiento de objetos no puede funcionar de la misma manera que una fuente de datos para bases de datos como lo hacen los archivos, con bloques dentro que se pueden manipular, pero puede almacenar datos a capacidades mucho mayores en el almacenamiento de objetos. La arquitectura para el almacenamiento de objetos y el trabajo con bases de datos es diferente, esta última almacenada en la memoria para los procesos de trabajo y luego reenviada al almacén de respaldo del objeto.
¿Eso hace que el almacenamiento de objetos se asemeje más a un archivo en estos casos? Posiblemente, aunque proveedores como Minio han asumido el desafío de proporcionar un acceso rápido a los conjuntos de datos almacenados en el almacenamiento de objetos para casos de uso de bases de datos y análisis. Minio lo llama almacenamiento “tibio”, por lo que claramente no es increíblemente rápido en términos de E/S y mayor rendimiento.
S3 Select: S3 cumple con SQL
La idea de almacenes de objetos muy grandes con la posibilidad de elegir el subconjunto de datos que desea y trabajar en eso es la idea detrás de S3 Select. Aquí utiliza declaraciones de consulta SQL para filtrar el contenido de un almacén de datos y simplemente extraer los datos que desea. Esto reduce los costos de salida de datos y le brinda un conjunto de datos más pequeño y una latencia más baja.
Los resultados de S3 Select están disponibles en los formatos CSV, JSON y Apache Parquet, y puede realizar consultas desde la consola de AWS, la línea de comandos o a través de las API, lo que significa que es muy posible seleccionar datos de S3 para analizarlos en un cómputo local más rápido.
Sin embargo, no es realmente una base de datos. Y dado que los datos vienen en formatos específicos, como CSV y JSON, necesitará algo de codificación para convertirlos en la herramienta de análisis que elija.
Entonces, ¿el almacenamiento de objetos es bueno para las bases de datos? El veredicto es: depende, o no realmente.
El almacenamiento de objetos no puede almacenar bases de datos de una manera que brinde a múltiples usuarios un acceso consistente con los principios de atomicidad, consistencia, aislamiento y durabilidad (ACID). El almacenamiento de objetos está descartado para casos de uso que satisfagan las necesidades de procesamiento transaccional. El almacenamiento de objetos no tiene la E/S o los mecanismos de bloqueo de subarchivos para hacer esto.
Sin embargo, el almacenamiento de objetos se destaca en el almacenamiento de grandes volúmenes de datos, de los cuales se puede descargar un subconjunto, a tasas de rendimiento potencialmente altas, para su retención en la memoria durante el procesamiento local. Estos son los tipos de enfoques impulsados por empresas como Minio y posiblemente en casos de uso que utilizan AWS S3 Select. Pero en su mayoría estamos hablando de procesamiento por lotes de datos en la configuración de análisis.