Cita:
Empezado por erickperez6
No es necesario ser muy inteligente para saber que todos estos casos superan los GB facilmente, quizas el dato exacto de que sean 20gb, 40gb, etc... solo es cuestion de indagar un poquito mas en las fuentes y en la pagina oficial de mysql y los numeritos aparecen. Pero el punto es que evidentemente son base de datos "gigantescas". Pero por lo que veo eres una persona que aunque te busque las fuentes no entraras en razon, y contra eso yo no puedo luchar.
|
Hola.
NO veo la razón de atacar personalmente a Al. Estas dejando ver que no es una persona inteligente, pero francamente no creo que eso sea cierto ni que vos tengas suficientes argumentos para afirmar tal cosa.
Cita:
Empezado por erickperez6
no sabian que se utilizaba para sistemas criticos y alta albergadura
|
francamente, me pregunto que quisiste decir con esto..
Cita:
Empezado por erickperez6
Tambien el sistema de youtube esta montando en mysql (les preguntamos que tamaño tiene por si las dudas? los videos son almacenados en la DB)
|
¿de donde sacas la información para afirmar tal cosa?
Mis fuentes dicen algo distinto:
Cita:
YouTube uses MySQL to store metadata....
To scale out the database, they first used MySQL replication. Like everyone else that goes down this path, they eventually reach a point where replicating the writes to all the DBs, uses up all the capacity of the slaves. They also hit a issue with threading and replication, which they worked around with a very clever “cache primer thread” working a second or so ahead of the replication thread, prefetching the data it would need.
As the replicate-one-DB approach faltered, they resorted to various desperate measures, such as splitting the video watching in to a separate set of replicas, intentionally allowing the non-video-serving parts of YouTube to perform badly so as to focus on serving videos.
Their initial MySQL DB server configuration had 10 disks in a RAID10. This does not work very well, because the DB/OS can’t take advantage of the multiple disks in parallel. They moved to a set of RAID1s, appended together. In my experience, this is better, but still not great. An approach that usually works even better is to intentionally split different data on to different RAIDs: for example, a RAID for the OS / application, a RAID for the DB logs, one or more RAIDs for the DB table ...
In spite of all these effort, they reached a point where replication of one large DB was no longer able to keep up. Like everyone else, they figured out that the solution database partitioning in to “shards”. This spread reads and writes in to many different databases (on different servers) that are not all running each other’s writes. The result is a large performance boost, better cache locality, etc. YouTube reduced their total DB hardware by 30% in the process.
It is important to divide users across shards by a controllable lookup mechanism, not only by a hash of the username/ID/whatever, so that you can rebalance shards incrementally.
|
Ves que no ha sido sin dolor cómo han llegado a una solución que les funcione... y como se puede leer en el artículo completo, por supuesto usan caches para bajar la carga en la base de datos. De hecho, usan
memcached, que en las primeras dos líneas de su página dice:
Cita:
|
memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.
|
fuente
Cita:
Empezado por erickperez6
Por cierto, el gestor de busqueda de google creo que esta montado en BD2 de IBM, si consigo la fuente se los confirmare, no recuerdo donde fue que lei el articulo hace un tiempo.
|
Nada mas errado que esto. No usan ninguna base de datos comercial, ni relacional... tienen
su propia solución al asunto, como era de esperarse. Por cierto, youtube también usa BigTable.
Francamente, creo que Al y los demás miembros de este club merecen una disculpa por el ataque personal.
También es de esperar que, en próximas oportunidades, confirmes tus suposiciones antes de hacer afirmaciones en estos foros, y con mayor razón si las afirmaciones son en tono ofensivo.