La pregunta: ¿Qué solución o consejos tendría que tratar con una base de datos muy grande (varios terabytes) indexada en hash fuertes con alta redundancia?Consejos para crear una base de datos de hashes muy grande
Algún tipo de almacenamiento invertido?
¿Hay algo que se pueda hacer con Postgres?
Estoy listo para transferir mi propio almacenamiento si es necesario.
(Pista: Debe ser de código abierto, sin Java, debe ejecutarse en Linux, debe estar basado en disco, C/C++/Python preferido)
Los detalles:
Necesito crear una gran base de datos, donde cada registro tiene:
- algunos metadatos arbitrarios (texto campos) incluyendo algunas claves
- uno hashes primarios (128 bits hash MD5, fuerte parecido)
El volumen de registros es lo que calificaría como bastante grande: varios 10 a 100 miles de millones). Existe una redundancia significativa de hashes en las filas (más del 40% de los registros tienen su hash compartida con al menos otro registro, existe algún hash en 100K registros)
El uso principal es buscar por hash, luego recuperar el metadata El uso secundario es buscar por clave principal y luego recuperar los metadatos.
Esta es una base de datos de tipo analítico, por lo que la carga general es mediana, mayormente leída, pocas escrituras, en su mayoría escrituras en lotes.
El enfoque actual es utilizar Postgres, con un índice en la clave principal y un índice en la columna hash. La tabla se carga en lote con el índice en el hash apagado.
Todos los índices son btrees. El índice en la columna hash es cada vez más grande, tan grande o más grande que la tabla misma. En una tabla de 120 GB, se tarda aproximadamente un día en recrear el índice. Sin embargo, los resultados de las consultas son bastante buenos.
El problema es que el tamaño proyectado para la base de datos de destino será superior a 4TB basado en pruebas con un conjunto de datos más pequeño de 400GB que representa aproximadamente el 10% del objetivo total. Una vez cargados en Postgres, más del 50% del almacenamiento desafortunadamente está siendo utilizado por el índice SQL en la columna hash.
Esto es demasiado grande. Y creo que la redundancia en hashes es una oportunidad para almacenar menos.
Tenga en cuenta también que aunque esto describe el problema, hay algunas de estas tablas que deben crearse.
Un hash de 128 bits no es realmente criptográfico en estos días. ¿Has intentado NO usar índices, sino particiones basadas en, digamos, los primeros 8 bits del hash? –
@Tyler 128 bits MD5 o SHA1 truncado es decente cifrado para mí. Al menos tiene un buen uso del rango clave.Intenté no usar índices y el rendimiento de búsqueda es terrible. ¿Puedes dar más detalles sobre la partición de claves? –
Así que use índices y tome el espacio de disco afectado. Optimice la velocidad o el espacio, elija uno. –