¿Existe un limite de conexiones a la BD?

[Pixeltwo]

Hola compañer@s, realmente es la primera vez que posteo en este foro, no obstante no suelo hacerlo dado que normalmente suelo encontrar las respuestas... pero esta pregunta en especifico o es que la planteo mal o no se que ocurre, que no encuentro nada al respecto.

En primer lugar, teniendo como base que se que supuestamente la base de datos soporta 100 conexiones por defecto ( cuyo valor puede ser modificado ). Pero es aqui donde entra mi duda...

Por ejemplo, tengo un proyecto web, donde hay muchas aplicaciones por ajax que están constantemente haciendo consultas a la BD, si a eso le sumamos muchos usuarios al mismo tiempo, esas 100 conexiones se podrian superar " imaginemos ". Bien, entonces que hariamos? ir configurar para que nuestras conexiones fueran un poquito mayores, supongamos ahora le ponemos 300. De acuerdo; pero esto entonces viene influyendo en cuestion del servidor que tengamos en ese momento o como? porque por poner un ejemplo, Algo como facebook tiene unos cuantos servidores, que ocurre? cada servidor maneja una BD diferente o todos influencian en la misma BD? es algo que realmente aun no le acabo de encontrar sentido o " me he hecho un lio" disculpad si es muy noob esta pregunta jeje...


PD: ¿La mejor manera para poner en funcionamiento un proyecto web en donde continuamente se ralizan consultas a la BD... es diviendolo en varios servidores, pero a su vez, quien tiene la BD en si mismo?.


Esa es mi consulta en si. Imagino no llevará mas de dos lineas responder algo tan simple, siento las molestias!!


Muchas gracias de antemano chic@s.


Saludos!!

[gnzsoloyo]

Por un lado ten en cuenta que el que un DBMS instalado en local esté configurado por default para soportar hasta 100 conexiones simultáneas, no significa que esa sea la forma de instalarlo obligatoria. Es sólo una configuración base, y los hosting jamás la usan, no les alcanzaría ni por milagro.
Por otro lado, cuando haces la instalación del DBMS bien puedes reconfigurarlo para soportar 200, 500 ó 1.000. Eso dependerá de tu decisión y necesidades.
De todos modos, el 90% del problema en realidad no será tuyo: Será de los que te provean del hosting, ya que tu verdadera misión es definir qué servicio y DBMS te conviene usar. El resto es asunto de ellos.
Además, ten en cuenta el detalle que una inmensa parte de las capacidades de concurrencia no está dada por los límites del DBMS, sino por el hardwaer disponible. En otras palabras: Más conexiones, más hardware. Muchas conexiones: mucho hardware y de alta calidad. Esto es así simplemente porque lo que debe resistir tantas conexiones no es solamente la base de datos, sino también el sistema completo.

En otras palabras:
- Deberías empezar al revés: Hacer una estimación de crecimiento de tu web para los próximos dos años, y partir de lo que necesites para entonces como base. Ampliar sobre la marcha no resulta.
- Sobre la base de una estimación realista de crecimiento, necesitas seleccionar dos cosas: Qué DBMS usarás y qué hosting te conviene, en cuanto a recursos que te proveen. Ten bien en cuenta que para ese momento no eres tú quien tiene que ocuparse de cuántas conexiones simultáneas soportará el sistema, sino quienes te proveen del servicio.

[Pixeltwo]

Perfecto, muchas gracias por quitarme esa duda, entonces ya quedo mas tranquilo teniendo como base que mas es problema de la compañia que me de el servicio.

Para empezar, he visto una oferta muy buena que ofrece Dinahosting, en la cual todo se va incluyendo en caso de necesitarse y solo pagas por lo utilizado, sin duda, me parece la decision mas acertada sin tener " una base solida " de lo que pueda crecer el proyecto.

El BDMS en mi caso es Phpmyadmin a nivel local claramente, no obstante, no se que me de Dinahosting. En todo caso aun quedo con esa duda.. Por decir algo, empezamos con un servidor claramente, en donde está alojada la BD, perfecto. Pero si se crece, como va la cosa? en caso de necesitar mas bases de datos o todo va a la misma Bd de un principio?, realmente no se si me explico bien en esta parte.

Caso 1 :

Usuario -> BD principal -> respuesta -> usuario.

Caso 2:

Usuario -> //// BD 1 //// BD 2 //// BD 3 /// BD 4 /// etc /// -> respuesta -> usuario. (teniendo en cuenta que cada una de esas BD, tienen las mismas tablas, pero controlan diferentes datos, por ejemplo, en la BD1 los 1000 primeros usuarios, en la BD <1000 , la B3 <2000 , etc..).



Como funciona este apartado en si?? es ahi donde tengo el bloqueo!



Muchas gracias por la rapida respuesta.

Un grato saludo!

[matanga]

Hay dos temas que podrías ver para resolver estas dudas, Partitioning de tablas y Cluster de servidores de base de datos, en resumen:

Las particiones de tablas sirven para almacenar los datos de una misma tabla en diferentes segmentos físicos donde cada segmento puede estar en distintas ubicaciones (discos del servidor), por ejemplo, si tienes una tabla de facturación con un campo fecha_factura, la puedes particionar por este campo con el método por rangos.

Código:

CREATE TABLE facturas (
    id INT NOT NULL,
    fecha_factura DATE NOT NULL
)
PARTITION BY RANGE ( YEAR(fecha_factura) ) (
    PARTITION p1 VALUES LESS THAN (2010),
    PARTITION p2 VALUES LESS THAN (2011),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);

Esto tiene varias ventajas, por un lado el costo, al permitir distribuir el almacenamiento a nivel de partición, si un servidor tiene un grupo de discos rápidos (generalmente más caros) y otro grupo de discos lentos, puedes poner las particiones de mayor acceso en los discos rápidos y las de menor acceso en los discos lentos, de esta manera optimizas el costo de almacenamiento. Por otro lado el rendimiento, supongamos que quieres obtener todas las facturas del año 2011 con la consulta SELECT * FROM facturas WHERE YEAR(fecha_factura) >= 2011, en este caso, el motor entiende que la partición p3 tiene todos los datos, por lo que hace un recorrido (FULL SCAN) solo de esa partición y no de toda la tabla. Más info en http://dev.mysql.com/doc/refman/5.6/...titioning.html

El otro tema es Cluster de servidores, esto te permite tener varios servidores donde cada uno de ellos tiene una copia completa de la base de datos, esto es útil para:

Balanceo de carga, es decir, distribuir las peticiones de los usuarios entre los equipos que componen el cluster (en el caso de modificación de datos existe un proceso de sincronización), a veces tener un solo servidor gigante es más caro que varios pequeños, o si la demanda de hardware crece, puede ser más barato agregar un servidor nuevo al cluster que comprar disco, memoria, procesadores, etc para potenciar el servidor existente.

Protección ante fallos, si tienes un único servidor y tiene un fallo es posible que se de una interrupción del servicio. Dentro de un cluster, si un servidor cae, los demás siguen funcionando con normalidad, además si después el servidor vuelve a estár activo, el proceso de sincronización actualizará cualquier dato faltante.

Más info en http://www.mysql.com/products/cluster/architecture.html

En cualquier caso, esto es solo informativo, como bien te comentaron, si vas a contratar un hosting, toda esta gestión es problema del proveedor del servicio.

Saludos

[Pixeltwo]

Iniciado por matanga

Hay dos temas que podrías ver para resolver estas dudas, Partitioning de tablas y Cluster de servidores de base de datos, en resumen:

Las particiones de tablas sirven para almacenar los datos de una misma tabla en diferentes segmentos físicos donde cada segmento puede estar en distintas ubicaciones (discos del servidor), por ejemplo, si tienes una tabla de facturación con un campo fecha_factura, la puedes particionar por este campo con el método por rangos.

Código:

CREATE TABLE facturas (
    id INT NOT NULL,
    fecha_factura DATE NOT NULL
)
PARTITION BY RANGE ( YEAR(fecha_factura) ) (
    PARTITION p1 VALUES LESS THAN (2010),
    PARTITION p2 VALUES LESS THAN (2011),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);

Esto tiene varias ventajas, por un lado el costo, al permitir distribuir el almacenamiento a nivel de partición, si un servidor tiene un grupo de discos rápidos (generalmente más caros) y otro grupo de discos lentos, puedes poner las particiones de mayor acceso en los discos rápidos y las de menor acceso en los discos lentos, de esta manera optimizas el costo de almacenamiento. Por otro lado el rendimiento, supongamos que quieres obtener todas las facturas del año 2011 con la consulta SELECT * FROM facturas WHERE YEAR(fecha_factura) >= 2011, en este caso, el motor entiende que la partición p3 tiene todos los datos, por lo que hace un recorrido (FULL SCAN) solo de esa partición y no de toda la tabla. Más info en [url]http://dev.mysql.com/doc/refman/5.6/en/partitioning.html[/url]

El otro tema es Cluster de servidores, esto te permite tener varios servidores donde cada uno de ellos tiene una copia completa de la base de datos, esto es útil para:

Balanceo de carga, es decir, distribuir las peticiones de los usuarios entre los equipos que componen el cluster (en el caso de modificación de datos existe un proceso de sincronización), a veces tener un solo servidor gigante es más caro que varios pequeños, o si la demanda de hardware crece, puede ser más barato agregar un servidor nuevo al cluster que comprar disco, memoria, procesadores, etc para potenciar el servidor existente.

Protección ante fallos, si tienes un único servidor y tiene un fallo es posible que se de una interrupción del servicio. Dentro de un cluster, si un servidor cae, los demás siguen funcionando con normalidad, además si después el servidor vuelve a estár activo, el proceso de sincronización actualizará cualquier dato faltante.

Más info en [url]http://www.mysql.com/products/cluster/architecture.html[/url]

En cualquier caso, esto es solo informativo, como bien te comentaron, si vas a contratar un hosting, toda esta gestión es problema del proveedor del servicio.

Saludos

Excelente respuesta de verdad, me ha quitado todas las dudas de raiz. Consultaré todo eso que adjuntas y me meteré mas en el tema ahora sabiendo desde donde partir.

Sin duda la mejor opciones la 2º, como bien planteas, son mas las ventajas que inconvenientes, sin duda alguna y como no, es la que mas bien " creo " usan las compañias de bandera.


Un grato saludo y gracias nuevamente!