Poryecto grande, ¿con MySQL?

[OsSk4R]

Buenas,

Verán, estoy a punto de iniciar un desarrollo de un proyecto bastante grande y, me preocupa el tema de MySQL. Hasta ahora nunca me he preocupado, pues hasta ahora siempre ha ido bien ya que lo que he hecho ha sido poca cosa, o sea, cosas pequeñas.

Entonces, este proyecto que les comento va a tener muchas tablas y muchos campos que quizás a la larga aumenten un poco y sus registros sean millones (ojala).

Mi pregunta es sencilla (creo) y es: ¿cuál sería el limite de MySQL?. O sea, si mi proyecto alcanzara un tamaño como facebook, tuenti, etc... (dejadme soñar ¬¬), ¿funcionaría bien con MySQL?, ¿o debería de utilizar otra BD?

Sinceramente, la única que conozco es MySQL, se que hay otras, pero con la única que he trabajo hasta el momento es MySQL, así que me gustaría saber si en proyectos tan grandes se puede hacer con MySQL o con otra.

Eso es todo y, muchas gracias

[Vun]

http://es.wikipedia.org/wiki/MySQL . Flickr usa Mysql, Google con Adwords tambien, con eso está dicho todo!

[OsSk4R]

No sabía que Adwords utilizase MySQL . Me he quedado soprendido con las aplicaciones/webs importantes que utilizan MySQL pero sobre todo con datos como:

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.

Bueno, me alegra saber que MySQL aguanta todo

Saludos y gracias

[gnzsoloyo]

El corazón del problema en una aplicación pesada está fundamentalmente en el hardware: No puedes usar una PC ni de 16 Gb Ram con 4 Mb Quadcore para eso. Se usan máquinas de otro tipo, por ejemplo, de un Sun SPARC Enterprise T5240 Server con cosas como:

Architecture
- Processor. Four-, six-, and eight-core 1.2 GHz or eight-core 1.4 GHz or eight-core 1.6 GHz UltraSPARC T2 Plus processors, two processors per system, maximum 128 threads.
- Cache. 4 MB integrated L2.
- Main memory. 32 FB DIMM slots, system maximum of 256 GB; support for 2 GB, 4 GB, and 8 GB low-voltage (1.55 V) DIMMs; minimum of 16 GB (8 x 2 GB).
- Internal disk: Up to eight or sixteen 146 GB/300 GB 2.5 in. SAS drives, depending on selected backplane; or up to eight 32 GB 2.5 in. SATA solid-state drives (SSD).

Recién por allí andamos hablando de verdaderos servidores de bases de datos...

[Vun]

Toma ya, un servidor de 256GB, yo pensaba que se distribuiria en varios o algo asi x_x

[gnzsoloyo]

También. ¿No pensarás que esos proyectos trabajan con uno solo de esos, ¿no?
LA distribución soluciona una parte del problema, pero cuando tienes 2 millones de inserciones por hora, 256 Gb de RAM solucionan bastantes cuellos de botella de concurrencia.
La distribución en una base de datos favorece muchas cosas, pero no es el único componente de la optimización para ese nivel de trabajo. La eficiencia de las consultas está muy afectada por la disponibilidad de memoria RAM, por ejemplo, y la recomendación de MySQL en esos casos es aumentarla; disponer de un server con gran cantidad y de alta performance es, así, una buena idea.
Por supuesto que son escenarios que nosotros habitualmente no vemos, pero eso no implica que no operemos contra ellos todos los días sin saberlo (un profesor mío afirmaba que la red bancaria del Banco Nación Argentina tenía 16 Tb de transacciones diarias hace tres años).