Ubuntu

Juguemos: Big Data fragmentado PostgreSQL

Juguemos: Big Data fragmentado PostgreSQL

Todo el mundo sabe que si tiene big data, necesita Apache Hadoop, ¿verdad? Es una plataforma de procesamiento de datos en clúster, asequible, escalable horizontalmente, ideal para casos de uso de almacenamiento de datos. Y saca los calcetines de los sistemas clásicos de administración de bases de datos relacionales como PostgreSQL que apenas pueden mantenerse al día cuando se juega con un terabyte de datos, y mucho menos con un petabyte. ¿Derecha? Bien quizás. Echemos un vistazo a PostgreSQL nuevamente y veamos qué puede hacer.

¿Qué tal una buena GPU?

Las unidades de procesamiento de gráficos (GPU) son la piedra angular de la revolución de la inteligencia artificial (IA). Las GPU sobresalen en operaciones aritméticas paralelas y entregan una gran cantidad de potencia de cómputo a un costo relativamente bajo, lo que las hace ideales para operaciones intensivas de cómputo (a diferencia de E / S) como el entrenamiento de redes neuronales artificiales. También son bastante buenos para cargas de trabajo de procesamiento de datos intensivos en computación, como almacenamiento de datos y análisis. Cuando se combina con operaciones vectorizadas y bibliotecas de E / S directas para las SSD NVMe, la densidad de núcleo pura de una GPU moderna de grado de servidor básicamente puede ofrecer tanta potencia en un solo chasis de servidor de 4U como un gran clúster de servidores Hadoop normales.

¿Qué significa? Bueno, PostgreSQL es altamente extensible por diseño, y una de esas extensiones para el núcleo de PostgreSQL es HeteroDB PG-Strom. PG-Strom es una extensión de código abierto que permite a PostgreSQL aprovechar las GPU de Nvidia para acelerar consultas analíticas complejas a gran escala. HeteroDB reconoce que PG-Strom puede habilitar un PostgreSQL único y escalado servidor de base de datos con múltiples GPU instaladas para manejar hasta alrededor de 100 TB de datos con un rendimiento de consultas de alrededor de 40 GB / s.

No vamos a jugar el juego de los puntos de referencia, pero las afirmaciones de rendimiento como estas son bastante impresionantes en comparación con Hadoop, que normalmente necesitaría alrededor de 28 servidores agrupados en un clúster para manejar una carga de trabajo similar, basada en una configuración típica de 20 TB de almacenamiento. medios por host y replicación HDFS 3x más gastos generales. Es probable que 28 piezas de hierro de tamaño decente (por lo general, el Hadoop moderno espera 128-256 GB de RAM por host y, por lo general, 16-32 núcleos de CPU por sistema) tengan un costo total de propiedad algo más alto que una sola caja ampliada con un un par de GPU Nvidia Tesla, incluso cuando se alquilan desde su nube informática favorita en lugar de comprarlas y ejecutarlas en las instalaciones.

Dos pueden jugar ese juego

Escucho lo que dices: “Tengo un poco al norte de un petabyte de datos, no un poco al sur de 100 terabytes, y un servidor PostgreSQL simplemente no me va a cortar, sin importar cuán impresionantes sean las estadísticas. Y además, la caja podría estrellarse, ¿y luego qué? Toda mi infraestructura de informes y análisis estaría inactiva «. No te preocupes. PostgreSQL lo tiene cubierto. PostgreSQL versión 11 y posteriores tienen un soporte nativo bastante impresionante para la fragmentación a través de fraccionamiento y envoltorios de datos externos características. Básicamente, declaras una tabla con particiones según la estrategia de partición que elijas y luego delegas las particiones de la tabla a tablas remotas en otros servidores PostgreSQL a través de la función de envoltorios de datos externos postgres_fdw. Para la partición, puede elegir entre las estrategias de partición RANGE, LIST o HASH.

Un beneficio de este enfoque es que el cliente no necesita saber nada sobre la ubicación de los datos, solo necesita consultar la tabla en el nodo principal, que luego ejecuta subconsultas en las particiones remotas y recopila los resultados, usando predicado pushdowns y otras características agradables para ejecutar las consultas de la manera más eficiente posible. Esto también se aplica a las consultas INSERT y UPDATE, combinaciones de tablas cruzadas, subconsultas correlacionadas, etc. Otro beneficio es que todas las consultas, incluidas las consultas INSERT y UPDATE, son completamente ACID (atómicas, coherentes, aisladas y duraderas) transaccional, incluso consultas distribuidas que abarcan varios servidores de bases de datos fragmentados. Esto ofrece más beneficios de la inmediatez de los datos que son difíciles de lograr con soluciones como Apache Hive.

«Sí Sí», Te escucho denunciar, «Pero las operaciones de escritura entrantes afectarían demasiado al nodo principal y las consultas de lectura analíticas del mismo nodo, eso no es factible para mis necesidades». Bueno, PostgreSQL también tiene algunas capacidades de replicación muy buenas. Con Replicación de streaming de PostgreSQL, puede configurar uno o más servidores receptores de replicación. Los servidores receptores de replicación pueden ser, opcionalmente, síncronos; en otras palabras, las transacciones no se confirman hasta que son confirmadas por los servidores receptores participantes. Con una combinación de replicación sincrónica y asincrónica, quizás incluyendo relés en cascada, debería poder implementar una configuración que se adapte a sus necesidades, donde las operaciones de escritura van al nodo principal, pero las consultas de lectura se ejecutan en las instancias de réplica.

Además, en una configuración de alta concurrencia, una configuración de PostgreSQL bien ajustada normalmente puede superar a los motores de lago de datos como Apache Hive y SparkSQL, que pueden comenzar a se desmoronan cuando se ejecutan más de una docena de consultas simultáneas.

¿Demasiado complicado por la mitad?

«Suena complejo de configurar y mantener» tu dices. Bueno, hay bastantes parámetros para configurar y también algunas consideraciones importantes para la alta disponibilidad. En comparación con el literalmente miles de los parámetros de configuración y ajuste que necesita conocer para configurar y mantener un clúster Hadoop estable y con rendimiento, sin embargo, una configuración de PostgreSQL fragmentada es objetivamente menos compleja.

«De acuerdo, pero Hadoop tiene conectividad de tienda de blobs, lo que significa que puedo almacenar y consultar mis datos en un sistema de almacenamiento de bajo costo como Amazon S3, Azure Blob Store o Google Cloud Storage». Bueno, aquí me tienes. Si necesita una solución de almacenamiento de datos que se ejecute al menor costo de almacenamiento posible, es posible que esté mejor con Apache Hive, Presto / Trino, o algo similar. Además, si no necesita que su sistema de datos esté siempre online, entonces un entorno Apache Hadoop o Spark basado en la nube efímero y respaldado por la plataforma de almacenamiento de blobs de su proveedor de servicios en la nube también podría tener un sentido comercial sólido para usted. OXO!

Sin embargo, si su objetivo es un rendimiento excelente y una alta disponibilidad, junto con una escalabilidad flexible, todo a un precio equilibrado, entonces un clúster PostgreSQL de big data bien diseñado y fragmentado, que ejecute la extensión de GPU PG-Strom de HeteroDB, podría presentar una buena solución para usted. .

Leave a Comment

You may also like