¿Pueden las GPU mejorar el rendimiento de una base de datos?

Zuljin · 9 Abril 2018

En tuiter compartieron este enlace

https://sqlmaria.com/2018/03/01/can...&utm_medium=social&utm_campaign=ReviveOldPost

En él explican teóricamente la posible ventaja de incorporar la GPU al procesamiento de una base de datos.

Al final el periodista le manda una alabanza a lo genial y estupendo que es Oracle, pero no deja de ser interesante la comparación de los tipos de procesos que actualmente se le pueden enviar a la GPU para realmente sacarle el jugo.

De todas maneras no se como va a terminar la acelerada del canal PCI Express. No se si sea buena idea, bajo la actual arquitectura, chantar el pci express directo al procesador y saltarse lo que antes era el southbridge.

NIN · 20 Marzo 2019

en la práctica, saltarse el southbridge y tener comunicación directa con el procesador baja la latencia y aumenta el ancho de banda. no le veo el inconveniente.

K3rnelpanic · 21 Marzo 2019

NIN dijo:
en la práctica, saltarse el southbridge y tener comunicación directa con el procesador baja la latencia y aumenta el ancho de banda. no le veo el inconveniente.

Buena Zuljin, te contestaron casi 1 año después :risas

NIN · 21 Marzo 2019

de a poco se arma la discusión :risas

como experiencia en algo similar, usé una radeon 4850 junto a una aplicación para reventar contraseñas de ficheros RAR. Lo que iba a tardar unos 20 o 30 minutos con CPU, la GPU le tomó menos de 5 minutos.
En ese aspecto, tener 800 procesadores en vez de 2 incrementaba enormemente la tasa de combinaciones que podía hacer la aplicación por segundo. Si eso se lleva a una base de datos, en conjunto a un arreglo de discos robusto y con una buena tasa de IOPS, debiera reflejarse en un beneficio brutal, considerando que las GPU ahora estan por sobre los 10 TFLOPS y las CPU deben estar llegando recién a los 100 GFLOPS
El desarrollo de un motor que haga trabajar a una GPU debe ser más complicado, supongo, pero el potencial que demuestran lo vale.

Miguelwill · 26 Marzo 2019

con la suficiente RAM , que pueda levantar toda la DB en memoria, no sería tan necesario que los discos sean especialmente rápidos (aunque un raid10 ayudaría bastante)
y concuerdo que hacer un motor db compatible con cálculo paralelo para GPU debe ser complicado, esperemos ver algo así pronto (hasta un plugin que sirva como organizador sería útil )

Enviado desde mi TA-1039 mediante Tapatalk

K3rnelpanic · 28 Marzo 2019

miguelwill dijo:
con la suficiente RAM , que pueda levantar toda la DB en memoria, no sería tan necesario que los discos sean especialmente rápidos (aunque un raid10 ayudaría bastante)
y concuerdo que hacer un motor db compatible con cálculo paralelo para GPU debe ser complicado, esperemos ver algo así pronto (hasta un plugin que sirva como organizador sería útil )

Enviado desde mi TA-1039 mediante Tapatalk

Algo así como un SAP HANA pero orientado a GPU? :zippyte

Miguelwill · 29 Marzo 2019

VittokoX dijo:
Algo así como un SAP HANA pero orientado a GPU?

mm desconozco que hace, pero si te refieres a mantener y operar datos en memoria, si, seria algo asi supongo

NIN · 31 Marzo 2019

El SAP HANA es un servidor comun y corriente. Dependiendo de la generación de servidor que compres, puedes ver configs desde 64GB en RAM, doble procesador y arreglos basados en discos mecanicos, mezcla mecanicos + ssd caché o ssd puro. Sea como sea, no usa GPGPU para el motor de DB.
En esta pagina le ponen algo de color y promocionan a nvidia pero en resumen las GPU procesan en paralelo y las CPU en secuencial. En ese aspecto se pretende aprovechar el poder de calculo de las GPU. Me imagino que la única forma de no generar un cuello de botella en la DB por parte del almacenamiento es usar unidades de estado sólido. Pienso que a futuro veremos unidades de estado sólido con mayor durabilidad y rendimiento a costos mas aterrizados producto de esto.

K3rnelpanic · 1 Abril 2019

NIN dijo:
El SAP HANA es un servidor comun y corriente. Dependiendo de la generación de servidor que compres, puedes ver configs desde 64GB en RAM, doble procesador y arreglos basados en discos mecanicos, mezcla mecanicos + ssd caché o ssd puro. Sea como sea, no usa GPGPU para el motor de DB.
En esta pagina le ponen algo de color y promocionan a nvidia pero en resumen las GPU procesan en paralelo y las CPU en secuencial. En ese aspecto se pretende aprovechar el poder de calculo de las GPU. Me imagino que la única forma de no generar un cuello de botella en la DB por parte del almacenamiento es usar unidades de estado sólido. Pienso que a futuro veremos unidades de estado sólido con mayor durabilidad y rendimiento a costos mas aterrizados producto de esto.

SAP Hana es una BD en memoria.

nibal2 · 1 Abril 2019

Hace un par de semanas fuimos a una inducción en SAP Hana, se supone que como requisito para funcionar el disco debe ser SSD, también tener una buena cantidad de RAM.

En papel pintaba para buena BD, quizá en algunos meses pueda hacer algún proyecto con esa bd

dwyer · 1 Abril 2019

VittokoX dijo:
SAP Hana es una BD en memoria.

Con razón piden tantos requisitos y sobre todo en ram.

Saludos

Enviado desde mi LadriNokia mediante Tapatalk

Marcel · 1 Abril 2019

nibal2 dijo:
Hace un par de semanas fuimos a una inducción en SAP Hana, se supone que como requisito para funcionar el disco debe ser SSD, también tener una buena cantidad de RAM.

En papel pintaba para buena BD, quizá en algunos meses pueda hacer algún proyecto con esa bd

Ojo que hace rato que Oracle tiene las mismas funciones y una vez que entres a Hana no vas a poder salir

Yo les pediría además que respalden las aseveraciones, mostrando los estudios que muestran los saltos de rendimiento que indican.

NIN · 5 Abril 2019

VittokoX dijo:
SAP Hana es una BD en memoria.

Me refería que SAP HANA, independiente que resida en memoria, sigue estando montado en un servidor convencional. Me llama la atención que ahora este pidiendo almacenamiento sobre SSD. No he revisado en detalle en que se beneficia que sea sobre SSD a lo que fué en su momento sobre discos mecánicos, fuera del evidente encarecimiento del equipo. Les tengo muy poca confianza a los SSD para usarlos en almacenamiento de datos críticos. Por mucho respaldo que se haga, prefiero tener un sistema lo más recuperable posible y los SSD, ante catastrofes, son muy dificiles de recuperar.

K3rnelpanic · 5 Abril 2019

Claramente, si tienes un servidor SAP (con los costos que eso conlleva), además de la licencia de soporte, se entiende que debes tener una solución de respaldos acorde a lo que esa solución requiere.
No nos vamos a andar cagando con los backups :risas

NIN · 5 Abril 2019

Para alguien inserto en TI es obvio que la solución de respaldo es crítica. No así para el cliente final, que muchas veces acepta la alternativa de backup cuando sufrió la pérdida de datos a causa de no realizar la inversión inicial. Mucha gente se confía que un equipo nuevo no va a fallar en el corto plazo. Por otra parte, como los respaldos también podrían fallar es que me parece una alternativa no descartable poder llegar a la instancia de recuperar datos desde el arreglo original. En ese punto, es menos complejo recuperar de un arreglo de discos mecánicos que de unidades de estado sólido ante una falla física.

Zuljin · 5 Abril 2019

Me voy a ir un poco al off topic, pero acá en 7 años hemos reemplazo muchos discos "mecánicos" de los storage, y la verdad es que no recuerdo que hayamos tenido que cambiar un disco de estado sólido del mismo storage.

Además, fiarse de la reparación del disco es más riesgoso que la cresta.

Enviado desde mi Redmi Note 5A Prime mediante Tapatalk

NIN · 5 Abril 2019

y la vida media de cada disco de cuanto fué? cuanto llevan de uso los ssd?? tampoco es para fiarse pero viendo todos los posibles escenarios, hay un buen porcentaje de éxito en recuperar un disco mecánico. Una unidad SSD por otra parte, muere un chip flash, murió toda la info del disco. Algo similar a como ocurre cuando sufre headcrash un disco mecánico. Aún si los chips flash se salvan y solo se quema la MCU, se debe reconstruir la info desde los chips cosa bastante compleja porque el MCU en los SSD guardan los datos de acuerdo a un algoritmo de escritura.

Zuljin · 5 Abril 2019

NIN dijo:
y la vida media de cada disco de cuanto fué? cuanto llevan de uso los ssd?? tampoco es para fiarse pero viendo todos los posibles escenarios, hay un buen porcentaje de éxito en recuperar un disco mecánico. Una unidad SSD por otra parte, muere un chip flash, murió toda la info del disco. Algo similar a como ocurre cuando sufre headcrash un disco mecánico. Aún si los chips flash se salvan y solo se quema la MCU, se debe reconstruir la info desde los chips cosa bastante compleja porque el MCU en los SSD guardan los datos de acuerdo a un algoritmo de escritura.

Los discos se adquirieron más o menos en la misma fecha.

Igual yo hablo pensando en un sistema con arreglos de discos con un IO de la puta madre, pero en un escenario de estación de trabajo tampoco veo que la primera línea de recuperación sea correr a Kepler a que te salve el disco.

Enviado desde mi Redmi Note 5A Prime mediante Tapatalk

NIN · 5 Abril 2019

Zuljin dijo:
Los discos se adquirieron más o menos en la misma fecha.

Igual yo hablo pensando en un sistema con arreglos de discos con un IO de la puta madre, pero en un escenario de estación de trabajo tampoco veo que la primera línea de recuperación sea correr a Kepler a que te salve el disco.

Enviado desde mi Redmi Note 5A Prime mediante Tapatalk

Claro que no. El respaldo siempre es el ideal, fuera que recuperar datos es bastante caro. Sin embargo errar es humano. Si la politica de respaldo no se aplicó cuando se debió aplicar, el cloud no sincronizó toda la data o el sysadmin llegó con la weá e hizo mierda el datacenter porque lo echaron o anda a saber que cosa pudo pasar, creo conveniente considerar la dificultad de recuperar la data del arreglo principal. Además, en el caso de HANA, no se si le beneficie usar SSD o HDD en terminos de velocidad si se considera que la DB se mueve en RAM. En ese caso es mejor considerar las características de la RAM del servidor y el ancho de banda del controlador de memorias de las CPU y buscar la alternativa de almacenamiento mas robusta y fiable. Poco tiempo atrás llegó a la oficina un HANA montado en un DL380 G8 con dos discos muertos y otro con falla electrónica. De 8 discos SAS de 600GB solo pude extraer imagenes de 5 y dos de los 5 presentaban sectores defectuosos. A pesar de ser un RAID 50, no tenía el minimo de discos para poder intentar rearmar el arreglo. El IT animal de la empresa jamás cambió los discos. Ni me dí la molestia de preguntar por respaldos. Estos discos corrieron 5 años aproximadamente antes que fallaran. No fué una falla accidental puesto que ya tenía alertas de disco el servidor. Se envió a Kepler porque tenía buen pronóstico de recuperación. El disco que identifiqué con falla electrónica se reparó y con eso se pudo extraer la data. Ni hablar del costo...

K3rnelpanic · 5 Abril 2019

NIN dijo:
Claro que no. El respaldo siempre es el ideal, fuera que recuperar datos es bastante caro. Sin embargo errar es humano. Si la politica de respaldo no se aplicó cuando se debió aplicar, el cloud no sincronizó toda la data o el sysadmin llegó con la weá e hizo mierda el datacenter porque lo echaron o anda a saber que cosa pudo pasar, creo conveniente considerar la dificultad de recuperar la data del arreglo principal. Además, en el caso de HANA, no se si le beneficie usar SSD o HDD en terminos de velocidad si se considera que la DB se mueve en RAM. En ese caso es mejor considerar las características de la RAM del servidor y el ancho de banda del controlador de memorias de las CPU y buscar la alternativa de almacenamiento mas robusta y fiable. Poco tiempo atrás llegó a la oficina un HANA montado en un DL380 G8 con dos discos muertos y otro con falla electrónica. De 8 discos SAS de 600GB solo pude extraer imagenes de 5 y dos de los 5 presentaban sectores defectuosos. A pesar de ser un RAID 50, no tenía el minimo de discos para poder intentar rearmar el arreglo. El IT animal de la empresa jamás cambió los discos. Ni me dí la molestia de preguntar por respaldos. Estos discos corrieron 5 años aproximadamente antes que fallaran. No fué una falla accidental puesto que ya tenía alertas de disco el servidor. Se envió a Kepler porque tenía buen pronóstico de recuperación. El disco que identifiqué con falla electrónica se reparó y con eso se pudo extraer la data. Ni hablar del costo...

Eso entonces es culpa del TI.
Si se va a tener SAP HANA como base, lo mínimo es contar con todas las opciones viables de seguridad de la información, de lo contrario quedarse con SQL nomas.

Por cierto, Hana necesita de ssd ahora porque la cantidad de datos que mueve es gigantesca, y los amiguitos de SAP, para garantizar que el producto cumpla con lo que promete, sostiene el uso de discos de estado sólido y diversos ajustes en la distribución de la data en los distintos discos.

Trust me, I'm an engineer :risas

Enviado desde mi Redmi Note 4 mediante Tapatalk

¿Pueden las GPU mejorar el rendimiento de una base de datos?

Fundador

Opteron Fanboy

non serviam

Opteron Fanboy

I am online

non serviam

I am online

Opteron Fanboy

non serviam

pajarón nuevo

Sonidista-Computin

Master

Opteron Fanboy

non serviam

Opteron Fanboy

Fundador

Opteron Fanboy

Fundador

Opteron Fanboy

non serviam