Siete lecciones aprendidas mientras reddit.com llegaba a 270 millones de páginas vistas al mes [ENG]

Siete retos a los que los creadores de reddit se han enfrentado y solucionado desde el punto de vista técnico para que un sitio que recibe 270 millones de impresiones de página al mes sea viable: por ejemplo en reddit se precomputerizan todas las posibles alternativas de orden de noticias para poder ofrecer resultados rápidos a los usuarios. Según ellos "desperdiciar disco duro y memoria es mejor que tener al usuario esperando".

[#17 Coronavirus]

"Te pasas la vida escuchando que hay que normalizar las BDs. Pero eso sirve para optimizar el espacio usado, no la velocidad..."

Si el único problema de tener datos duplicados fuera el espacio usado...

[#1 Stash]

Despues de 18 años administrando sistemas, tras leer este alucinante artículo, llegas a la conclusión de que todo lo que has aprendido no sirve para nada.

Muy claro y muy concreto. Buen artículo.

[#2 Shinu]

#1 Hombre, claro que sirve... lo que pasa es que no debes administrar sistemas con una cantidad tan grande de tráfico

[#7 anxosan]

Bueno, mi página recibe una docena de visitas al día, y no la actualizo en condiciones desde hace meses por falta de tiempo, así que supongo que por ahora no habrá que preocuparse de esto.

[#14 Desactivado]

#11 Se hace lo que se puede. Todo sea por que mi única lectora tenga un servicio de calidad (Mi madre)

[#4 eduardor2k]

Yo tengo una web con bastante tráfico y de aquellas no tenia medios para pagar un servidor mejor, un amd 3000+ para 700/800 visitas simultaneas, al final tuve que reducir el dinamismo del sitio de tal manera que solo se modificara el estado del sitio SOLO cuando el usuario realizará una modificacion, con eso el sistema aguantaba bastante bien los momentos de carga.

[#18 Desactivado]

esto es mucho mas importante que el seo de los cojones, lo que pasa es que no tiene un nombre guay definido

pd: memcached rulez!

[#8 Desactivado]

La mía aguanta todo, pruebo dando muy muy muy rápido a actualizar y no se cae. No hay nada mejor que un efecto menéame bien simulado.

[#11 Desactivado]

#8 eso no es un efecto menéame simulado no es un efecto nada

[#3 Stash]

Hace tiempo algún que otro cluster en HP-UX si, pero evidentemente no con ese tráfico brutal. El comentario va mas en la línea de que no he trabajado en entornos de alto rendimiento como el que describen y te sorprende como resuelven los problemas.

Keep it simple, stupid.

[#10 gallir]

Cambiado el titular de "visitas" a "páginas vistas"

[#12 PerroVerd]

Interesante, pero el Open Schema me parece un dolor para emplearlo

[#5 equisdx]

No soy experto en sistemas pero es un artículo muy interesante. La principal idea que saco en claro es compartimenta y cachea todo

[#15 Pablosky]

Lesson 3: Open Schema

The essence of this lesson is: don't worry about the schema.

They used to spend a lot of time worrying about the database, keeping everthing nice and normalized. You shouldn’t have to worry about the database. Schema updates are very slow when you get bigger. Adding a column to 10 million rows takes locks and doesn’t work. They used replication for backup and for scaling. Schema updates and maintaining replication is a pain. They would have to restart replication and could go a day without backups. Deployments are a pain because you have to orchestrate how new software and new database upgrades happen together.

Instead, they keep a Thing Table and a Data Table. Everything in Reddit is a Thing: users, links, comments, subreddits, awards, etc. Things keep common attribute like up/down votes, a type, and creation date. The Data table has three columns: thing id, key, value. There’s a row for every attribute. There’s a row for title, url, author, spam votes, etc. When they add new features they didn’t have to worry about the database anymore. They didn’t have to add new tables for new things or worry about upgrades. Easier for development, deployment, maintenance. The price is you can’t use cool relational features. There are no joins in the database and you must manually enforce consistency. No joins means it’s really easy to distribute data to different machines. You don’t have to worry about foreign keys are doing joins or how to split the data up. Worked out really well. Worries of using a relational database are a thing of the past.

Sí, ahora si que realmente estoy seguro: realmente nunca he programado una web gigante... Lo estoy flipando ahora mismo.

¿No se ha dicho toda la vida que ejecutar código dentro de la BBDD es más rápido que hacerlo fuera? ¿No se ha dicho toda la vida que es mejor un join que dos consultas? Estas cosas me dejan ojiplático.

[#16 Hass]

#15 "¿No se ha dicho toda la vida que es mejor un join que dos consultas? Estas cosas me dejan ojiplático"

No, la idea es que no tengas que hacer ni un join ni dos consultas. La idea es tener una tabla con la información que necesitas, sin joins.

Te pasas la vida escuchando que hay que normalizar las BDs. Pero eso sirve para optimizar el espacio usado, no la velocidad...

[#21 Desactivado]

#16 eso sirve para garantizar la consistencia de los datos.

Lo que pasa, es que no es lo mismo que se vuelvan inconsistentes los datos del programa de facturación o los sistemas de un banco, que en meneame se pierda un voto o un comentario salga duplicado.

[#6 Desactivado]

Yo tengo mucho que aprender de todo esto, o probablemente contratar alguien externo, porque en un juego online por web en constante actualización se puede cachear muy muy muy muy pocas cosas

[#20 Desactivado]

En striker manager estamos cerca de esos 270M y como dice #6 un juego es lo más chungo para cachear puesto que se actualiza constantemente.

Aunque al principio lo pasamos mal, ahora estamos bastante estables y creo que podríamos superar esa cifra sin sufrir. Para mi la mejor optimización fueron los índices en la bd y revisar cada consulta sql hasta la saciedad.

[#22 Menda]

#20 ¿Y cuántos servidores tenéis para procesamiento, BD, load balancing y failover? Me gustaría saber un poco cómo lo hacéis

Supongo que al estar auspiciados por As, no tendréis problemas de financiación tampoco como podría tener otra persona.

[#23 Desactivado]

#22 Tenemos 2 servidores para front-end y 3 más para la BD.

Eso sí las capas de software, caches, bd, etc, son bastante numerosas.

Aunque pueda parecer que tener AS detrás es un seguro de vida, la verdad es que todo sale de U-Play Online. Nuestros servidores ni siquiera están en AS, por cierto, os recomiendo hetzner.de para el hosting (profesional eso sí), buenas máquinas, buen ancho de banda, buena calidad del servicio, y atención al cliente excelente.

[#24 Desactivado]

#22 Se me olvidaba, que lo habias preguntado:

La BD está particionada verticalmente y el balanceo se hace por DNS (simple, pero hasta ahora bastante efectivo).

No hay redundancia ni alta disponibilidad (si que se replica la BD, ojo), así que cuando hay problemas el juego tiene que cerrar.

[#13 Desactivado]

Entonces no sé como FREEBSD puede aguantar esas cargas en los servidores , pues FREEBSD trata de liberar memoria a toda costa para dar acceso a nuevas peticiones al milisegundo ...

[#9 acidotu]

3. Open Schema, o cómo tirar tu certificado de dba oracle a la basura

[#19 du_dua]

Qué raro ver la misma noticia en portada de reddit y aquí. Tan parecidas y tan distantes, sobre todo en lo que respecta a su usuario medio. Y eso que en reddit el usuario medio deja mucho que desear, pero es que en menéame se fomenta el talibanismo freak de niños de 12 años, aunque últimamente vaya mejorando.

Y por cierto, hay un subreddit de España, muy desangelado. No estaba de más una muda general de menéame para allá.

http://www.reddit.com/r/spain