php - usa - Diseño de base de datos para mensajes similares a Facebook

que base de datos usa facebook

Question

Actualmente estoy planeando un nuevo sistema en PHP / MySQL y quiero asegurarme de que mi base de datos pueda manejar la cantidad de datos que planeo almacenar. Una de las características de mi nuevo proyecto es una característica de "mensajes" como Facebook. Quiero asegurarme de crear la mejor experiencia posible para el usuario final. El sitio web eventualmente manejará miles de usuarios con potencialmente millones de mensajes colectivamente. ¿Cuál sería el mejor enfoque para el diseño de la base de datos? ¿Es MySQL incluso la base de datos correcta para usar?

Answer 1

Facebook comenzó con MySQL y solo se trasladaron a Cassandra cuando tenían 7 TB de datos de la bandeja de entrada para más de 100 millones de usuarios.

Fuente: Lakshman, Malik: Cassandra - Un sistema de almacenamiento estructurado descentralizado .

Answer 2

La fragmentación no es necesaria para sus requisitos "generales" ... He tratado con una buena cantidad de datos y ni siquiera consideré las tablas particionadas y la implementación de fragmentos hasta que hubo numerosas tablas con más de mil millones de registros (para luego unirse a esos podría conseguir un poco lento). Indexe sus tablas con teclas inteligentes, e incluso puede considerar el uso de una estructura de tipo eav para mantener las tablas estrechas y liberarse de los rendimientos nulos en las consultas.

Arriba se escribió mientras estaba medio dormido, así que ignora los errores tipográficos;)

Answer 3

MySQL no tiene problemas con millones o cientos de millones de registros, siempre y cuando diseñe su base de datos correctamente.

Dicho esto, una "característica de mensajes como Facebook" es una definición bastante amplia. En general, definiría una tabla de messages que vincula cada mensaje al usuario que lo creó (es decir, tiene una columna userId en la tabla de mensajes). Si desea que los mensajes se envíen a varios usuarios, tiene una tabla message_recipients define la relación de uno a varios al almacenar múltiples registros que consisten en el messageId de messageId y un messageId recipientId . Agregue los índices adecuados a estas tablas y estará el 80% del camino.

Dicho esto, el 20% restante puede ser un asesino. Desafortunadamente, la forma en que use su base de datos determinará qué otra cosa debe hacer, y tendría que proporcionar muchos más detalles sobre su solicitud antes de que se puedan emitir esos juicios. Por ejemplo, es posible que desee considerar tener una solución de archivado automático que mantenga la tabla principal relativamente pequeña y mueva los datos antiguos a las tablas de copia de seguridad a las que se puede acceder si es necesario. Probablemente no lo necesite de inmediato, pero podría ayudar en el futuro.

Answer 4

No eres muy preciso en lo que quieres aprender. Bueno. Intentaré darte un consejo.

1. Normalización
2. Índices
3. MyISAM para mesas bajo alta carga.
4. Desnormalización (¡sic!), Pero debes entender qué estás haciendo
5. Fragmentación
6. Capa de base de datos minimalista para la flexibilidad

Answer 5

Si planea manejar grandes cantidades de datos (por supuesto, millones ni siquiera se acercan a calificar como grandes), entonces contrate a un profesional de la base de datos. El diseño eficiente y efectivo de la base de datos para grandes conjuntos de datos es un tema complejo y requiere un especialista.

En respuesta a su pregunta, sí, mysql puede manejar millones de registros fácilmente si el diseño es bueno y será una pesadilla si el diseño es malo, casi como cualquier otra base de datos moderna.

Answer 6

Si quiere decir "cómo debería verse mi tabla mysql para un sistema de mensajes", uso las siguientes columnas en mi sistema de mensajes:

message_id
fromuser
fromview
fromstatus
touser
toview
tostatus
title
text
poston
thread

Message_id es auto_increment, obviamente. Fromuser y touser son obvios. Fromstatus y tostatus está activo, borrado, purgado, borrador y lo mismo. Fromview y toview están configurados en ''sí'' y ''no''. El título, el texto y la fecha de publicación son obvios. El subproceso puede requerir un poco de esfuerzo de su parte según los formularios html y los scripts de visualización de mensajes.

Para su formulario, cree un bucle foreach basado en el campo "para:" y guarde una copia para cada destinatario.

Espero que este sistema de mensajes contenga millones, pero probablemente falten un par de años para millones. Lo mantengo pequeño y simple.

Answer 7

Si tiene un presupuesto, comience con MySQL y use un sistema como Zend :: DB o en un nivel superior de Doctrine.

Es más importante facilitar el cambio de DMBS y luego elegir su DBMS al principio.

Answer 8

Siempre que configure sus tablas para que sean relacionales y establezca las relaciones entre tablas, MySQL debería estar bien.

¿También podría sugerir Postgres?

Answer 9

Yo diría que leen sobre bases de datos orientadas a objetos así como sobre sistemas nosql, es un concepto muy interesante, utilizado activamente por marcos famosos como Ruby on rails, que le permite preocuparse menos por sus datos, ya que simplemente puede volcar su objeto directamente En la base de datos, sé que es un poco fuera de tema, pero las bases de datos menos complejas significan una transición más fácil a sistemas escalables, y solo estoy generando conciencia.

Sin embargo, la desventaja es no tener una base de usuarios tan sólida como las bases de datos relacionales, lo que dificulta encontrar respuestas a los problemas a medida que avanza, y una cantidad igualmente mayor de tiempo para adaptarse a su uso, pero consiste en datos sin pensar el diseño de la base de datos en cada etapa es lógico tener su lógica de negocios y acelera su tiempo de desarrollo, pero más adelante, cuando se enfrente a los cuellos de botella y los problemas de rendimiento, será más difícil de resolver ya que hay menos ayuda.

Answer 10

Si diseña su base de datos correctamente, el rendimiento debería deteriorarse logarithmically con la cantidad de datos. En otras palabras, el tiempo para ejecutar sus consultas crecerá mucho más lento que la cantidad de datos.

Para lograr este objetivo, tendrás que ser disciplinado sobre varias cosas:

• El diseño de su base de datos debe ser sólido. Comprender el modelo y la normalización de ER es esencial. Así es la comprensión de la anatomía de los índices y otras estructuras de datos físicos.
• Después de tener una buena base de datos normalizada, considere si algunos "bordes" de la misma deberían ser desnaturalizados juiciosamente por razones de rendimiento.
• A lo largo de todo este proceso, tenga en cuenta qué tipo de consultas realizará su aplicación cliente:
  • Diseñe índices de acuerdo con esto: indice específicamente para las consultas que sabe que necesitará, ¡no sobre-indexe!
  • Algunas decisiones de diseño, como el uso de claves naturales frente a sustitutas y las relaciones de identificación frente a no identificables pueden influir en la cantidad de UNIONES que necesitará.
  • Intente mantener el diseño de su base de datos amigable para las exploraciones de rango agrupado, las exploraciones de solo índice , etc.
• Utilice los mecanismos específicos de DBMS, como clustering , partición, compresión de claves, vistas materializadas (etc.) para su ventaja. Si el DBMS no admite algún mecanismo que considere esencial, ¡no tenga miedo de cambiar el DBMS! Por ejemplo, las tablas InnoDB siempre están agrupadas , lo que es una ventaja cuando se consulta en PK, pero puede ser una desventaja si necesita índices secundarios. Si necesita tablas basadas tanto en clústeres como en pilas, utilice algunos DBMS que las admitan (como Oracle o MS SQL Server). ²
• Codifique la aplicación del cliente cuidadosamente. Utilice de forma religiosa los parámetros vinculados y la preparation consultas: no solo minimizará la sobrecarga de planificación de consultas y análisis de SQL, sino que también será resistente a las inyecciones de SQL. Los ORM y las bibliotecas a menudo lo protegen para que no lo haga manualmente, pero aún debe entender lo que está pasando "debajo de las portadas".
• Y por último, pero no menos importante, no haga suposiciones, ¡ mida en su lugar! El rendimiento de la base de datos puede ser un acto de equilibrio fino (y bastante complejo), y el impacto de ciertas decisiones puede no ser evidente de inmediato

Si hace todo esto correctamente, tendrá que abordar las cantidades reales de datos de Facebook antes de que un DBMS "clásico" deje de ser adecuado. Miles de usuarios y millones o mensajes ni siquiera califican como "grandes" en este contexto.

¹ Un "cliente" desde la perspectiva de DBMS - esto también podría ser un nivel medio.

² El MyISAM tampoco está agrupado, pero tiene serias limitaciones (como la ausencia de soporte de transacciones) que deberían descalificarlo de cualquier uso normal.