He escuchado que el rendimiento de la base de datos relacional no fragmentada, como MySQL o PostgreSQL, se "rompe" más allá de 10 TB.
Sospecho que existen límites como tales, ya que no se obtendrían Netezza, Greenplum o Vertica, etc., sin embargo, me gustaría preguntar si alguien aquí tiene una referencia a algún documento de investigación o estudios de casos formales donde se cuantifican estos límites.
Respuestas:
No hay una respuesta simple a su pregunta, pero aquí hay algunas cosas para pensar.
Primero, la escala no es lo único de lo que preocuparse. Lo que haces con tus datos es. Si tiene 500 tablas de 30 TB de datos y está haciendo OLTP simple con muy pocos informes, no creo que tenga demasiados problemas. Hay bases de datos de 32 TB en PostgreSQL por ahí. Sin embargo, al mismo tiempo, el rendimiento se degradará un poco porque tiene que golpear el disco en todo. Del mismo modo, si tiene 50 TB de datos, pero tiene un conjunto de aproximadamente 100 GB, entonces puede construir un servidor con suficiente RAM para mantener esa parte de la base de datos en la memoria y usted es dorado.
Por otro lado, si está tratando de quitar el modo (valor más común) de 1TB de datos, no importa qué sistema esté utilizando, esto será doloroso con o sin fragmentación. (Editar: Sharding puede, de hecho, empeorar este problema ) .
Los principales problemas con los que se encontrará con grandes db's en MySQL y PostgreSQL implican el hecho de que ninguno de ellos admite el paralelismo intraquery. En otras palabras, una consulta se ejecuta como un solo bloque por un solo subproceso, y no se puede dividir en partes y ejecutar por separado. Esto suele ser un problema cuando se ejecutan grandes consultas analíticas sobre grandes cantidades de datos. Aquí es donde Postgres-XC y Green Plum vienen al rescate, ya que separan el almacenamiento de la ejecución, y pueden hacerlo a nivel de coordinador. Tenga en cuenta que Postgres-XC y Green Plum esencialmente usan fragmentación internamente, pero los coordinadores imponen toda la coherencia a nivel mundial.
Con el paralelismo intraconsulta, puede dividir la consulta, hacer que diferentes procesadores / canales de E / S de disco ejecuten partes de la misma e informar las partes del conjunto de resultados que se ensamblarán y se devolverán a la aplicación. Una vez más, esto suele ser más útil en cargas analíticas que de procesamiento de transacciones.
Lo segundo es que algunos sistemas, como Vertica o Greenplum, almacenan columnas de información juntas. Esto hace que el sistema sea más difícil de usar desde una perspectiva OLTP y disminuye el rendimiento allí, pero aumenta drásticamente el rendimiento para grandes cargas de trabajo analíticas. Entonces esta es una compensación específica de la carga de trabajo.
Entonces, la respuesta es que una vez que supere el tamaño de 1-2 TB, puede encontrarse con una serie de compensaciones entre sistemas y cargas de trabajo. Nuevamente, esto es específico para las bases de datos, el tamaño de los conjuntos de trabajo, etc. Sin embargo, en este punto, realmente tiene que ir con sistemas de copos de nieve, es decir, únicos y adaptados a su carga de trabajo.
Esto, por supuesto, significa que los límites generalmente no son cuantificables.
Editar : ahora he trabajado con una base de datos de 9 TB que maneja una mezcla de soporte de decisiones y cargas de trabajo de procesamiento transaccional en PostgreSQL. El mayor desafío es que si tiene preguntas que afectan a grandes porciones del conjunto de datos, tendrá que esperar un tiempo para obtener la respuesta.
Sin embargo, con cuidadosa atención a los fundamentos (incluidos los índices, el autovacuum, cómo funcionan en el nivel bajo, etc.) y los recursos informáticos suficientes, estos son completamente manejables (y estimo que serían manejables dentro del rango de 30 TB en Pg).
Edit2 : una vez que te dirijas a 100 TB, lo que funcione dependerá de tu conjunto de datos. Estoy trabajando en uno en este momento que no escalará en este rango porque alcanzará primero el límite de 32 TB por tabla en PostgreSQL.