database - soporta - Almacenamiento de "votos" en una base de datos

optimizar consultas lentas mysql

Question

Estoy escribiendo lo que será una aplicación de intranet, y una de sus características es más o menos análoga a la votación del contenido, similar a lo que SO, Amazon y muchos otros sitios hacen.

Suponiendo que cada pieza de contenido votable tiene una ID única, y cada usuario (están autenticados) tiene una ID única, la manera más fácil sería tener una tabla de "votos" ...

ContentID int
UserID int
VoteValue int

Pero esto crea una fila por voto: con millones de contenido y decenas de miles de usuarios, esa mesa será enorme. ¿Es esta la mejor manera de hacerlo? Quiero decir, si un int toma 4 bytes, cada fila toma 12 bytes. Si un millón de contenido obtiene cien votos, eso equivale a 400 MB más en almacenamiento, ¿no? Parece ... me gusta mucho :). Incluso si VoteValue es una minúscula (que probablemente esté bien) y solo 1 byte, todavía hay un par de cientos de megabytes en la tabla. Quiero decir Sheesh.

¿Hay una manera más inteligente? ¿Debería guardar esta tabla de "votos" en una base de datos separada (ignorando los posibles problemas de integridad de datos) para dividirla de los datos "principales" en términos de almacenamiento y rendimiento?

(Me doy cuenta de que en el mundo de hoy 400 MB no es una tonelada, pero parece mucho MUCHO para almacenar votos, ¿no?)

Answer 1

Bueno, sí, pero debes mirar la imagen más grande. Con un millón de piezas de CONTENIDO:

(Tamaño del contenido) >> (Tamaño de los votos): donde ">>" significa "mucho mayor".

Si tiene un millón de contenido, puede ser un terabyte de datos donde los votos son de 400 MB. Gran cosa, ¿verdad?

También me gustaría añadir, si te preocupa la escalabilidad, echa un vistazo a este blog:

http://highscalability.com/

Answer 2

Personalmente, siempre y cuando tenga buenos índices en su lugar, lo está haciendo de la manera correcta. Dependiendo de su uso, para el rendimiento puede tratar de evitar golpear la tabla de votos almacenando información de recuento secundario, pero en general si debe realizar un seguimiento de QUIÉN ha votado algo, debe hacerlo de la manera en que lo ha enumerado.

No me molestaría en moverme a otra base de datos, si estás REALMENTE preocupado en SQL Server podrías crear un grupo de archivos separado para mantenerlo ..... pero muy probablemente no sea necesario.

Answer 3

Probablemente también quiera la identificación del autor del contenido en la tabla, para una detección más fácil del abuso de votación. (Sí, se trata de información supuestamente redundante. Una alternativa es crear regularmente una tabla de resumen para ver quién está votando sobre quién).

Por lo que vale, la tabla de votación de perlmonks se ve así:

 `vote_id` int(11) NOT NULL default ''0'',
 `voter_user` int(11) NOT NULL default ''0'',
 `voted_user` int(11) default NULL,
 `weight` int(11) NOT NULL default ''0'',
 `votetime` datetime NOT NULL default ''0000-00-00 00:00:00'',
 `ip` varchar(16) default NULL,
 PRIMARY KEY  (`vote_id`,`voter_user`),
 KEY `voter_user_idx` (`voter_user`,`votetime`),
 KEY `voted_user_idx` (`voted_user`,`votetime`)

(vote_id es la identificación del contenido, ip es una dirección IP).

Answer 4

Si necesita rastrear si un usuario ha votado por un artículo en particular, y si hay diferentes valores de voto (por ejemplo, 1 estrella a 5 estrellas), entonces esto es lo más compacto posible.

No olvide que para obtener velocidades de acceso razonables, necesitará indexar los datos (dos índices, probablemente uno con ContentID como columna principal, uno con ID de usuario como columna principal).

Tendrá que decidir si hay una razón para no almacenar la tabla por separado de otras tablas. Lo que esto significa depende del DBMS que use: con Informix, la tabla estaría en la misma base de datos pero almacenada en un espacio de base de datos diferente, y podría tener los índices almacenados en otros dos espacios de base de datos diferentes.

Answer 5

Diría que necesita averiguar cómo se usarán estos votos y diseñar primero consultas específicas para su modelo de datos. Esto no es necesariamente un modelo de SQL. Si vienes del mundo de SQL, pasar por el tutorial oficial de MongoDB ayuda a despejar la mente para el comienzo.

Por ejemplo, si solo necesita almacenar y mostrar los votos de una página de un solo ejemplar, puede ser conveniente almacenar los votos en un solo campo de cadena del problema, que se verá como id1:id2:id3: Suponiendo que todos los identificadores son de la misma longitud, hay algunas propiedades interesantes:

1. Cuente todos los votos para el problema:

   len(issue.votes)/len(id)

2. Buscar He votado sobre el tema

   myid in issue.votes

3. Encuentre todos los problemas que votó:

   select issue.id from issues where issue.votes contains(myid)

4. Encuentra los problemas más votados

   select issue.id from issues order by len(issue.votes) desc limit 10

Esta arquitectura permite evitar costosos cálculos de lectura en estos casos específicos, pero la actualización de issue.votes en el voto puede ser más costosa que agregar una fila en una tabla. En este caso, 100 votos con 4 bytes por id + separador son cadenas de 500 bytes. En su variante propuesta, 100 votos son 800 bytes.

Descargo de responsabilidad: nunca implementé algo como esto, es solo una idea.