¿Qué motor de base de datos se debe usar para una base de datos de petabytes?

Dado:

  • Se espera que el volumen de datos alcance los petabytes en un par de años.

  • El conjunto completo de tipos de registro, aplicaciones y consultas no se conoce de antemano. Se espera que las partes interesadas sigan encontrando nuevos usos para los datos, como suele suceder con una gran base de datos.

  • El sistema se ejecutará en hardware básico distribuido en varios centros de datos.

  • Las soluciones de código abierto son las preferidas si es posible, por razones pragmáticas de querer poder modificar el código si es necesario y no querer entrar en una posición de negociación débil con un proveedor.

¿Cuál es el mejor motor de base de datos para usar?

Si solo estuviéramos hablando de terabytes, simplemente especificaría Postgres y listo, pero tengo entendido que no se puede esperar que una base de datos SQL lista para usar se escale a petabytes.

Me dan a entender que Yahoo modificó Postgres a esa escala. Me parece que esto básicamente implicaría transferir la carga de los programadores que escriben el código de la aplicación (que ahora obtienen los beneficios habituales de que no tienen que preocuparse tanto por no dejar pasar ningún error, porque una base de datos relacional hace mucho para hacer cumplir consistencia) a aquellos que mantienen el motor de la base de datos (transparentemente proporcionar esas garantías junto con consultas SQL rápidas en tal escala es un problema difícil).

Una alternativa sería tomar un buen motor de base de datos NoSQL y modificarlo según sea necesario. Esto pone más responsabilidad sobre los programadores de aplicaciones para que nunca cometan un error, pero hace que sea más fácil confiar en que cualquier aplicación determinada se puede hacer lo suficientemente rápido con el esfuerzo suficiente.

¿La primera opción se considera confiablemente viable en estos días?

¿Es la segunda opción una práctica típica? Si es así, ¿qué motor NoSQL es el mejor para este escenario?

¿Hay una tercera opción que me falta?

¡Una gran pregunta! No tengo una respuesta, pero creo que "distribuido en varios centros de datos" es clave allí. Personalmente, por instinto, me quedaría con una base de datos relacional, porque la indexación y la eficiencia van a ser muy importantes a medida que escalas, y simplemente no siento que NoSql pueda manejar eso (pero estaría feliz de estar equivocado) . Personalmente, obtendría MySQL sobre Postgres, pero Postgres sobre NoSql. Este es el sitio correcto para recomendaciones de software, pero si no recibe ninguna, intente dba.stackexchange.com
¿Está hablando de cargas de trabajo OLTP (alta tasa de inserciones/actualizaciones para filas individuales) o analíticas (pocas, pesadas, en su mayoría de solo lectura)? "Petabytes" implica datos históricos, mientras que "los programadores escriben el código de la aplicación" y "nunca dejan pasar ningún error" sugiere que está pensando en OLTP (que generalmente se dimensiona en términos de la cantidad de solicitudes simultáneas). Usar la misma instancia (yo diría incluso herramienta) para ambos es una mala idea.
@Nickolay Se requieren ambos, pero podría ser posible configurar dos bases de datos diferentes. En ese caso, ¿qué herramienta recomendaría para cada uno?

Respuestas (2)

Siento que sería irresponsable recomendar algo basado en los pequeños detalles proporcionados, pero como mis pensamientos no caben en un comentario, lo publicaré aquí.

Para el caso de uso de OLTP: si cree que Postgres es una buena opción en cuanto a características y para su equipo de desarrollo, y la única preocupación que tiene es escalar, las métricas que debe considerar son el tamaño de los datos operativos (la cantidad de datos consultados por las solicitudes OLTP) y el número de TPS (transacciones por segundo) y su tasa de lectura/escritura), en lugar de la cantidad total de datos que acumulará el sistema.

No tengo experiencia de primera mano con el escalado de Postgres, pero se dice que se pueden lograr 1,000,000 de consultas de lectura/s si los datos caben en la memoria, al igual que 10,000 escrituras/s . Puede colocar cachés delante de la base de datos para mejorar el rendimiento de lectura e implementar fragmentación (a través de extensiones) para escalar las escrituras.

Estoy tratando de evitar los debates NoSQL vs RDBMS, pero para aquellos cuya principal preocupación es la escalabilidad, la primera podría considerarse una práctica típica...

Para casos de uso de almacenamiento de datos/informes (ejecutar este SQL en terabytes de datos en un minuto) hay una clase de soluciones llamadas "bases de datos MPP" (si le gusta Postgres, es posible que haya oído hablar de Greenplum). Fragmentan los datos y ejecutan la consulta en varios nodos (de rendimiento relativamente alto) en paralelo, pero no están optimizados para procesar una gran cantidad de consultas ligeras.

Si necesita una forma rentable de almacenar los datos para análisis y/o no está dispuesto a limitarse a una sola herramienta, el ecosistema de Hadoop puede ser interesante. Pierde algo de eficiencia (y gasta recursos en desarrollar la experiencia), pero obtiene la capacidad de ejecutar soluciones arbitrarias de "big data" (ML, transmisión, gran cantidad de motores de base de datos) o código personalizado en su clúster.

Echa un vistazo a CockroachDB. Está hablando de big data y la plataforma necesita soportar una escalabilidad seria.

https://www.cockroachlabs.com/

Probablemente esté listo para usar y tenga una buena comunidad de código abierto.