Tablas muuuuy gigantes

[leif_sk8er]

Buenas, estoy haciendo pruebas con una tabla por que tengo pensado crear unas tablas para gestionar las estadisticas de un portal.

En portales anteriores, con unas 200,000 paginas vistas mensuales, era facil llegar a los 3 millones de registros en un año, y no es que sea muy visitada la pagina comparandola con otras webs. Tanto en una tabla de estadisticas como de movimientos, imaginar con la facilidad que pueden ir aumentando esas tablas.... :S

La duda teorica que tengo, ya que luego tengo que hacer filtrados de esas tablas en las consultas, es llegado el punto de tener 50 o 100 millones de registros.

Se que las tablas no tienen un limite de filas, pero mi duda es:¿Cuando empieza a resentirse la velocidad en busquedas de la tabla?

Lo que tenia pensado es hacer un sistema en el que cuando hayan mas de 10millones de registros me cree una tabla nueva, asi hasta el infinito, y otra tabla donde voy guardando los nombres de las tablas nuevas que creo (estadisticas1, estadisticas2, estadisticas3...) De esa forma con una funcion recursiva en mi lenguaje de programacion podria ir recorriendo tablas hasta encontrar el limite que desee en cada ocasion.

Ahora bien, ¿Es mas efectivo esto o no hace falta complicarse tanto?

Me gustaria la solucion mejor, pensando en el caso hipotetico que tuviese 100 millones de registros diarios. Ya que en este punto del proyecto tan inicial me da lo mismo hacerlo de una forma o de otra... lo que no me gustaria es hacerlo de una y despues modificarlo por no ser estable o funcional en su rendimiento, y puestos aprendo ha hacer esto de la mejor forma! :D

Siempre he alucinado como google analitycs guarda tantos millones de millones de registros :O, con lo que en teoria se puede... ahora solo hay que aprender como

A ver si algún gurú de las bases de datos me puede orientar para ponerme con ello :) Muchas gracias!

[_Ruben_]

Yo veo innecesario dividir los registros en varias tablas. Uso como el ejemplo el que tienes.

Si tienes 3 tablas cada una con 10 millones de registros, para realizar una búsqueda tendrías que buscar en la tabla 1, recorrer 10 millones de registros, buscar en la tabla 2, recorrer otros 10 millones, y después en la tabla 3 y recorrer los últimos 10 millones. Total: Recorres 30 millones de registros y tienes que cambiar de tabla 2 veces.

Si tienes 1 tabla con 30 millones de registros, pare realizar una búsqueda tendrías que buscar en la tabla y recorrer los 30 millones de registros. Total: Recorres 30 millones de registros y no tienes que cambiar de tabla.

¿Dónde está la ventaja de dividir en tablas? Yo no la veo.

Eso de la forma en la que lo planteas. Si cada tabla tuviese la información de un país ya sería distinto porque si supone una mejora ya que eliges 1 tabla de las 3 que tengas y buscas en sus 10 millones de registros, si no está no tienes que seguir buscando porque sabes que en las otras tablas no vas a encontrar lo que buscas. Esto si supone un ahorro.

Pero con millones y millones de registros como planteas, esto sigue siendo una solución no muy buena.

El caso de Google Analitycs... seguro que usa decenas de bases de datos siguiendo uno o varios criterios para dividir la información en la base de datos. Pero esto precisamente no es algo que sea barato hacer.

[pamda]

Iniciado por leif_sk8er

Siempre he alucinado como google analitycs guarda tantos millones de millones de registros :O, con lo que en teoria se puede... ahora solo hay que aprender como

No fuiste el unico que tuvo ese pensamiento

y otra cosa, los antecedentes familiares les respaldan a los creadores de Google

a nosotros, los mortales nos queda experimentar...

mi comentario no viene al caso, pero es una opinion!
saludos!

[gildus]

Holas,

Las bases de datos pueden existir como existen los servidores de ahora, mientras vaya creciendo tu data tambien ira creciendo tu hardware, y a esto tambien ira creciendo tu red, y luego ha esto tambien ira creciendo tu datacenter, etc.

Existen varias tecnicas para poner a tu servidor de base de datos con millones o trillones de datos en estado operativo y libre o casi libre de fallos, que son los clusteres de bases de datos, y clusteres de servidores. Actualmente asi funcionan los cloud computing de la red.

Saludos
Gildus

[leif_sk8er]

Iniciado por _Ruben_

Yo veo innecesario dividir los registros en varias tablas. Uso como el ejemplo el que tienes.

Si tienes 3 tablas cada una con 10 millones de registros, para realizar una búsqueda tendrías que buscar en la tabla 1, recorrer 10 millones de registros, buscar en la tabla 2, recorrer otros 10 millones, y después en la tabla 3 y recorrer los últimos 10 millones. Total: Recorres 30 millones de registros y tienes que cambiar de tabla 2 veces.

Si tienes 1 tabla con 30 millones de registros, pare realizar una búsqueda tendrías que buscar en la tabla y recorrer los 30 millones de registros. Total: Recorres 30 millones de registros y no tienes que cambiar de tabla.

¿Dónde está la ventaja de dividir en tablas? Yo no la veo.

Eso de la forma en la que lo planteas. Si cada tabla tuviese la información de un país ya sería distinto porque si supone una mejora ya que eliges 1 tabla de las 3 que tengas y buscas en sus 10 millones de registros, si no está no tienes que seguir buscando porque sabes que en las otras tablas no vas a encontrar lo que buscas. Esto si supone un ahorro.

Pero con millones y millones de registros como planteas, esto sigue siendo una solución no muy buena.

El caso de Google Analitycs... seguro que usa decenas de bases de datos siguiendo uno o varios criterios para dividir la información en la base de datos. Pero esto precisamente no es algo que sea barato hacer.

YO me referia a cuando vas recorriendo las tablas de 10 millones en 10 millones, tal vez en la primera tabla ya has llegado a los 50 movimientos que querias... que es lo normal, entonces... ¿ Que sentido tiene recorrer los otros 20 millones?

[gnzsoloyo]

Para eso existe el SQL... para que no tengas tu que pensar cómo se recorren los 30 millones de registros.
Para decirlo de una forma simple: Si necesitas 30 resultados, y la tabla tiene 30 millones de registros, lo que haces es hacer una consulta en SQL con la que le pides al DMS esos 30 registros. El cómo lo hace internamente es totalmente irrelevante. Para eso son diseñados.
Ahora bien, si estás pensando en hacer tu mismo una rutina almacenada (stored procedure) para recorrer esos 30 millones y verificar uno a uno, entonces estás razonando como programador de aplicaciones y no como desarrollador de bases de datos. Eso no se hace, uno diseña la consulta que pueda devolver lo que se necesita y deja que el DBMS se encargue del resto.
¿Se entiende?

La velocidad de las consultas se puede optimizar de muchas formas, pero para eso tienes que ponerte a estudiar profundamente los temas, mucho de lo cual queda fuera del alcance de los autodidactas. Incluso necesitas estudiar cosas que están fuera del ámbito exclusivo de las bases de datos (sistemas operativos, hardware, conexiones, redes, y un largo etcétera), lo que sólo suele hacerse en estudios formales.

En el caso del diseño de la base de datos Google, por empezar ellos tienen su propio DBMS, que no funciona en un servidor, sino en granjas de servidores. La misma topologia de la distribución de esa base (en grid), permite que una misma consulta pueda ser respondida por múltiples servidores simultáneamente en un tiempo reducido, y además filtrada adecuadamente con algoritmos de búsqueda que ellos diseñaron (esa fue la clave de su éxito). En otras palabras, no es un tema donde puedas usar conocimientos básicos aprendidos en tutoriales. Es bastante más complejo.

[_Ruben_]

Iniciado por leif_sk8er

YO me referia a cuando vas recorriendo las tablas de 10 millones en 10 millones, tal vez en la primera tabla ya has llegado a los 50 movimientos que querias... que es lo normal, entonces... ¿ Que sentido tiene recorrer los otros 20 millones?

Evidentemente si en la primera tabla encuentras lo que buscas no debes seguir buscando, pero así no se analiza el rendimiento correctamente, ya que estás suponiendo un caso más o menos aceptable. El rendimiento se analiza comprobando el peor caso, y el peor caso en tablas desordenadas es que lo que buscas sea el último registro de todos.

Tal vez en la primera tabla este, y tal vez no. Piensa que estén como estén ordenadas siempre habrá un registro que esté el último y por el hecho de estar en la base de datos puede ser buscado. Si lo haces eficiente para la mayoría de casos, en general tu web será rápida, pero si lo haces eficiente para el peor caso, tu web será siempre rápida y ante los casos comunes mucho más rápida.

De todas formas, dividir la información en tablas dentro de una misma base de datos física es una solución que a nivel profesional no se utiliza porque sigue sin ser una solución eficiente.

[HackmanC]

Hola,

Iniciado por leif_sk8er

... Se que las tablas no tienen un limite de filas, pero mi duda es:¿Cuando empieza a resentirse la velocidad en busquedas de la tabla?

Se comienza a resentir cuando nuestros conceptos se salen de la lógica natural, es decir, cuando comenzamos a hacer cosas ilógicas. Y para eso los que inventan los sistemas de computación se pasan buen rato pensando en como resolver los problemas normales que se presentan en todas las circunstancias de forma adecuada.

Lo único es que hay que seguir sus instrucciones y no hacerlo como nos guste más, porque pensamos que nosotros siempre tenemos la razón. En el caso de MySQL hay un apartado en el manual específicamente para optimizar nuestras consultas y enseñarnos a evitar crear consultas que van a ser ineficientes, inclusive nos muestra instrucciones para investigar el comportamiento de nuestras consultas al momento de echarlas a andar dentro de MySQL.

En MySQL, que desde mi punto de vista no es la más rápida, no hay problema con un millón de registros, es más, hace un tiempo hice unas pruebas para ver que tan eficiente era en una sola computadora normal de tipo escritorio, procesador dual core de 2.6, 1 Gb de RAM, etc., y estos fueron los resultados.

Dos tablas con un campo de índice de llave primaria, un campo con un valor numérico sin índice y ocho campos de texto de 160 caracteres:

Código MySQL:

select
  a.id_codigo A,
  b.id_codigo B
from tabla1 a
inner join tabla2 b on a.id_codigo = b.id_codigo
where b.data > a.data - 5000 and b.data < a.data + 5000;
 

1000000 rows in set (46.89 sec)

Si no es suficientemente rápida la búsqueda para ti entonces tendrías que buscar otro método. Pero el problema real nunca es ese, sino ¿para qué? o ¿por qué?... ¿existe otro concepto mejor para ordenar mis datos? ¿Mi red es suficientemente rápida para transmitir un millón de registros? ¿puedo hacerlo en dos consultas separadas? ¿Puedo separar los datos en varias tablas? Y normalmente vas a encontrar como hacerlo de otra forma más eficiente, dependiendo completamente de las necesidades reales.

Los 'LOGS' en todos los sistemas populares se guardan por un tiempo, después se hacen copias de seguridad y se borran.

Saludos,

ps:

Para insertar los registros borré la llave primaria, porqué inserté uno a uno, sino hubiera tomado mucho tiempo, y para realizar la prueba la volví a crear y para crear el índice le tomó poco tiempo.