Capacidad MySQL

[odrack]

Saludos a todo el FORO!!

He estado trabajndo desde hace algunos meses atras en un proyecto con BD a MySql, pero tengo la curiosidad de saber ¿Cuantos registros puede soportar MySQL en una base de datos? he investigado en otras pagina hacerca de esto y se muy bien que depende de la estructura de la base de datos y del la capacidad de servidor donde estara alojada, asi como tambien del trafico (conexiones simultaneas) de esta.

Ahora les pido su opinion acerca de esto. Tengo un servidor con doble nucleo y 2 procesadores a 2.8 Ghz, 4 Gb en memoria, aqui solamente estara almacenda la base de datos. Mensualmente he calculado que los registros sean aproximados a 400,000 registros, también he desarrollado algunas utilidades para limpiar la base de datos y dejarla como cuando se instalo por primera vez.
Por ultimo, habran aproximado 50 (equipos interrelacionando en el servidor, osea en el proyecto que desarrolle). ¿Creen que soporte la cantidad de registros sin que se alente el sistema?.

Saludos y son bienvenidos sus comentarios!!

[[enecumene]]

Hola, ¡Pues claro que MySQL soporta bastantes registros!, no por algo es el tercer mejor base de datos, puedes dormir tranquilo. .

Saludos.

[odrack]

Gracias por tu respuesta, me gustaria saber cuanto me puede soportar sin que se alente el sistema, o eso depende completamente de la capacidad del servidor?? Y tendrás alguna fuente donde dice que MySql se encuentre dentro de las 3 primeras bases de datos (no por que desconfie del foro, si no que me gustaria conocer mas sobre este tema). Es que es mi primer desarrollo a nivel empresarial y no me gustaria tener problemas, y me gustaria fundamentar por que es de las mejores bases de datos, que tambien tengo entendido que es lo mejor de lo mejor, pero esto me gustaria tenerlo con mas bases.

Saludos

[[egostar]]

Pues con una simple consulta en google hubieses encontrado lo que preguntas.

Empezado por MySQL Development

the complete database must be smaller than 8 million terabytes. I doubt you'll have this much data.

Salud OS

[[enecumene]]

Aquí te dejo un artículo:

http://mysql.softonic.com/linux/opin...momento-124685

Saludos.

[[poliburro]]

Un punto de gran peso, es el diseño de la base de datos. Si no la diseñas correctamente o tu programa abusa de los Table scan, Por muy potente que sea una base de datos se va a alentar.

Saludos

[odrack]

Saludos.

En eso tienes mucha razon poliburro, precisamente por eso hice esta pregunta en el foro, he investigado mucho hacerca de la base de datos y de capacidades, pero nada como preguntar a quien ha trabajado con ella y ha visto resultados. Debo mencionar que depende mucho del diseño de la base.

Gracias por todas sus respuestas que son bienvenidas!!!

[Northern]

Cox Communications - La cuarta televisión por cable más importante de EEUU, tienen más de 3.600 tablas y aproximadamente dos millones de inserciones cada hora.

Sacado de http://es.wikipedia.org/wiki/MySQL en el epígrafe "Usuarios destacados".


Saludos

P.D. yo también tenía unas cuantas preguntas (bastantes) pero gracias a google no las hago en el foro

[PepeLolo]

Existen algunos puntos importantes a tratar cuando se desarrolla una aplicación para BBDD.

a) El modelo de datos (la BBDD)
b) componentes de acceso

a.1) Lo primero y principal las PK deben ser de tipo integer y siempre PK simples. Esto simplifica muchisimo a la BBDD gestionar las relaciones FK y por otro lado se elimina la redundancia de campos en las tablas foranea. (En muchos modelos me he encontrado con hasta 10 campos formando la PK) ¡eso es el infierno!, 10 campos arrastrados por todas las tablas FK.

Si puedes define lasa restricciones en la BBDD pues estas se ejecutan mucho más rapido que si las has de evaluar en la aplicación (ya que necesitaras ejecutar sentencias SQL) y las restricciones se ejecutan en la BBDD cuando se ejecuta alguna transacción de actualización.

No construir indices a diestro y siniestro, es preferible esperar y construirlos cuando los necesitemos para una SQL.

Para construir un indice debemos tener en cuenta los criterios restrictivos de más a menos. Quiero decir si tenemos una tabla que contiene los artículos que compra un cliente (idVenta, idCliente, idArtículo, FechaVenta, precio, etc) y se quiere obtener los artículos vendidos a un cliente en un periodo, el indice tendrá que ser compuesto, for por los campos mas restrictivos (idCliente, FechaVenta, Artículo). y los campos en la condición WHERE deberan estar en el mismo orden que los campos del Indice.

Para los gestores de bbdd a la hora de optimizar la sql les simplifica determinar que indices deben usar si lo ven claro en la clausula WHERE o INNER JOIN ... ON

a.2) Si es posible las relaciones entre tablas no sean del tipo (1 a null), no siempre puede ser, pero dentro de la medida de lo posible evitarlo. Los left-right join son muy pesados en las Query.

a.3) De ser posible el uso de triggers, SP, funciones, vistas, etc pues estos se gestionan en el servidor y no viajan por la red (es lo peor). Si tienes que hacer un proceso muy complejo de recuperación de datos, realiza este en un SP y obten en la consulta lo que necesites, de ese modo te quitas muchas lineas de programación.

a.4) Uso de secuenciadores para obtener una PK. Muchos programadores confunden el uso de estos con los contadores (de factura, de pedidos, etc) no tienen ningún relación a excepción de la semantica. Son atransacionales, lo que quiere decir que no pertenecen a ninguna transación. Hagamos un uso indiscriminado de ellos, para eso los pusieron. Con esto te evitas otro uso muy comun, ejecutar una consulta para obtener el valor más alto de una tabla o lo que es peor ejecutar constantes recordcount del dataset.

a.5) Si necesitas consultas muy repetitivas en tus programas, crea vistas, esto te ayudará a simplificar la cantidad de código que tienes que repetir en tu aplicación a nivel de sentencias SQL.

a.6) Si se han de actualizar datos en otras tablas tras una inserción, edición o borrado, crea triggers para dicho proceso. ¡No te haces a la ídea de lo que simplifica las aplicaciones y la agilidad que le dará a tu sistema!. Conozco mucha gente negada au uso de dichos eventos de las BBDD y el día que les surgio la necesidad de crear uno, no han dejado de darse con la cacerola en la testa por no haberlos usado anteriormente.

a.7) Y lo que más le pesa a una BBDD son las joins, pues ha de remover miles de registros para obtener el resultado que deseamos.
Una premisa importante para determinar si una consulta esta bien construida es conocer el número de registros que ha tenido que consultar para devolver Y.
Si Y supera el número de registros de la tabla principal de la SQL (mal) si se aproxima peligrosamente (mal), si ha tenido que consultar más registros de los que nos ha devuelto (mal), el gestor nos estrá indicando que nos falta un indice para obtimizar la consulta.

b.1)Muy importante que los componentes de acceso a datos sean bajo demanda. Esto quiere decir que solo se traen registros tal y como los vamos necesitando cuando se navega por los registros.

No usar nunca componentes del tipo TTable. Entonces será la muerte de la aplicación antes de empezar a manejar datos.

b.2) Determinar el tipo de transacción a manejar, dependiendo del tipo de acceso que se vaya a realizar. No es lo mismo una transacción para actualización de datos, que una transacción para una consulta o un listado.

b.3) Las transacciones para actualizar datos deben ser pequeñas es decir, no es nada recomendable usar un componente TIBDataSet para actualizar un registro o 10 registros, si para ello, al iniciar la transacción tuvo la BBDD que recuperar miles de registros. Por ello es recomendable usar transacciones distintas, una para consultas y otra para procesos de actualización. Algunos componetes como los FIBPlus permiten manejar este dos transacciones simultaneamente (Consulta y actualización).

b.4) Alejarnos dentro de lo posible de lanzar alegremente de SQL con todos los procesos. Aunque no guste mucho el estilo o la filosofia, hay que pensar que no estamos trabajando con ficheros de datos, las rejillas son muy pero que muy lentas, es preferible trabajar siempre con pantallas de consultas que filtren los datos. Las rejillas de datos son buenas para un detalle o para mostrar el resultado de una consulta. Pensemos que el usuario siempre va a buscar un dato o un conjunto de datos concretos, por lo que mostrar una rejilla sin haber sufrido un filtro previo no tiene sentido.

Lo que indico aquí tiene mucha más importancia, que si una BBDD es capaz de soportar miles de registros. Hoy en día es lo de menos, con los RDBMS actuales estamos en una Galaxia totalmente distinta. Los problemas de cueyos de botella se encuentra en los diseños de las BBDD y en como atacamos a los datos.

PD: Una SQL por compleja que sea, tarde más de 3 segundos en retornar los primeros datos es una consulta a replantear (esta mal planteada, faltan indices o lo que es peor, se crea un producto cartesiano).

[odrack]

Muchas Gracias por la catedra pepelolo, para un buen desarrollo lo principal a tomar en cuenta es el diseño de la base de datos y el uso de indices, lo que has dicho en tu respuesta me ha ayudado a entender que tendre que modificar un poco mi proyecto ya que en algunas tablas arrastro campos desde su entrada (donde no uso indices), y asi rediseñar la BD con indices.

Saludos y gracias.