Rendimiento de base de datos gigante

legent #1 Mar '15 Penitente

Estoy diseñando la base de datos de una web y todos los datos los recojo de otras, haciendo scrapping o de API's. Las tablas se estan haicendo enormes, la tabla principal tiene almacenadas mas de 500.000 filas (unicas) y hay una tabla por ejemplo many to many que tiene mas de 3 millones de entradas (son entradas simples de referencias por id).

Mi pregunta es, esto cada vez se hara mas grande y posiblemente llegue a almacenar mas de 5 o 10 millones de datos en una sola tabla. Afectara al rendimiento de las consultas en la web y sera insostenible? El hosting lo aguantara?

La verdad es que es la primera vez que me ocurre esto.
pd: Lo unico que almaceno en las tablas es o int o texto plano bastante corto en plan url, id's, titulos, etc.

RaymaN #2 Mar '15 Sureño

Mientras los índices estén bien creados y todo bien configurado no habrá problema hasta varias decenas de millones, que por cierto no es gigante ni de lejos xD

1 2 respuestas

bLero #3 Mar '15

500.000 filas son un juguete para la mayoría de DBMS.

Hasta que no pases los 100 millones no tienes de que preocuparte siempre y cuando las consultas que hagas sean sencillas.

1 respuesta

Leirlux #4 Mar '15

Lo que dice #2 y aparte configurar slow-queries si puedes. ¿Qué gestor de BD usas?

1 respuesta

legent #5 Mar '15 Penitente

#2 Hahahha bueno nunca habia trabajado con bases de datos que ocupan 1 gb o mas y que tienen millones de registros.

#3 Si, la base de datos es bastante simple no pasa de las 6 o 7 tablas, asi que las consultas seran de lo mas simple del mundo.

#4 mysql ahora en local y cuando lo suba al hosting supongo que tambien mysql

1 respuesta

Leirlux #6 Mar '15

#5 Pues en el my.cnf puedes configurar las slowqueries para que haya menos carga al hacer consultas en big tables. Busca por google cómo hacerlo, ahora mismo no recuerdo, pero se tienen que añadir 2 o 3 lineas al fichero, haces un service restart y punto pelota. Acuérdate de configurar también el key_buffer_size entre el 20 y 50% de la RAM del equipo donde tienes el MySQL, y configura que no haya muchas queries lanzadas al mismo tiempo. Con eso debería bastar, aunque tirará lento por lo general.

2 respuestas

legent #7 Mar '15 Penitente

#6 Y si por ejemplo quiero cargar datos de 10.000 registros y en vez de mostrarlos todos los voy partiendo en paginas? hara que las consultas tengas menos carga no?

3 respuestas

RaymaN #8 Mar '15 Sureño

#7 si vas a tener consultas muy repetidas haz uso de redis como cache.

2 respuestas

Leirlux #9 Mar '15

#7 Haz lo de #8 y np

eXtreM3 #10 Mar '15

#8 esa caché funciona igual aunque los datos devueltos sean dinámicos?

1 respuesta

RaymaN #11 Mar '15 Sureño

#10 ¿a qué te refieres con dinámicos? En redis almacenas todo lo devuelto por la consulta, normalmente con un tiempo de expiración aunque si hay algún cambio se elimina de redis para que vuelva a generar la consulta.

B

[Borrado] #12 Mar '15

#6 Activar slow-queries es que te muestre en un log las consultas que tardan x segundos en ejecutarse para que las puedas optimizar, no optimiza por defecto nada.
#1 El rendimiento te lo va a dar en base a donde lo tengas alojado y la arquitectura de tu aplicación. Si tienes 10M de registros en una tabla y tu aplicación hace búsquedas sin cachear por ejemplo te dará problemas dependiendo del número de consultas simultáneas.

1 1 respuesta

E

elraro #13 Mar '15

#7 si necesitas mostrar 100.000 registros muestralos sí o sí. Pero si por ejemplo quieres ir haciendo un listado, paginación es tu amigo.

Leirlux #14 Mar '15

#12 Pero en base a esos log a lo que me refería que no puse, es que puedes luego montar y definir cachés en base a lo más buscado. Eso si ayuda.

Rendimiento de base de datos gigante

Usuarios habituales

Tags