Должен ли я использовать mysql или ssdb для хранения данных как/vote?

Question

Каждый пользователь может голосовать за любого видео, в настоящее время мы используем MySQL, но теперь у нас есть более 200 миллионов строк в одной таблице с полями, как это:

id 
user_id  # the voter 
video_id # voted video 
author_id # author of the video 
state  # 1 for normal and 0 for cancelled, maybe others 
created_at 

Самый распространенный запрос получить избирателей конкретных видео, но, возможно, избиратели видео определенного автора или видео, проголосовавшие определенным пользователем, также необходимы, обычно упорядоченные по времени.

Должен ли я оштукатурить таблицу в 100 осколков (по видео_иде) или вместо этого использовать ssdb?

Если я выберу первое, для запроса по запросу author_id или user_id данные должны храниться несколько раз.

Если я выбираю ssdb, я должен использовать упорядоченный набор и хранить временную метку в качестве оценки для сортировки и иметь несколько ключей для каждого пользователя или видео, чтобы запрашивать разные поля и обрабатывать разные состояния. И сложно изменить код и перенести данные.

Answer 1

Было такое же замешательство. Что я делаю, используя их оба вместе:

• Redis для кэширования горячих данных;
• MySQL для постоянных данных;

Нет сомнений, что ключи Redis имеют большую сложность, однако для сокращения запросов к MySQL должен быть модуль кэширования.

И потому, что я просто использовать Redis в качестве кэша-памяти, то данные в нем может быть выбрасывал в любое время: я могу создать новые структуры данных в Redis с данными из MySQL

И лично я этого не делаю. хотите поместить все данные только в Redis: память намного дороже, чем жесткий диск на IAAS.

Желание это помогает :)

Answer 2

Если вы идете с MySQL, вам нужно несколько советов о деталях ...

CREATE TABLE Votes (
    # id -- no need for this 
    user_id INT UNSIGNED NOT NULL,  # the voter 
    video_id INT UNSIGNED NOT NULL, # voted video 
    author_id INT UNSIGNED NOT NULL, # author of the video 
    state TINYINT UNSIGNED (or ENUM) NOT NULL, # 1 for normal and 0 for cancelled, maybe others 
    created_at TIMESTAMP NOT NULL, 
    PRIMARY KEY(video_id, user_id), -- see note 
    + some indexes; see below 
) ENGINE = InnoDB; 

Неясно, что будет однозначно идентифицировать запись. Я что-то догадался, но я предполагаю, что пользователь может голосовать только один раз.

INT UNSIGNED предполагает, что у вас не будет более 4 миллиардов идентификаторов. Он занимает 4 байта, а не BIGINT - 8 байтов. Если вам не нужно больше 16M идентификаторов для определенной вещи, используйте MEDIUMINT UNSIGNED (всего 3 байта).

«Самый распространенный запрос - получить избирателей определенного видео». (? Не «Количество голосов»)

SELECT user_id FROM Votes WHERE video_id = ?; 
# INDEX(video_id, user_id) -- not needed, assuming the PK specified above. 
-- or 
SELECT user_id FROM Votes WHERE video_id = ? ORDER BY created_at; 
INDEX(video_id, created_at, user_id) 

«но, возможно, избиратели клипов определенного автор» (Похоже video_id здесь неуместно):

SELECT user_id FROM Votes WHERE author_id = ?; 
INDEX(author_id, user_id) 
-- or 
SELECT user_id FROM Votes WHERE author_id = ? ORDER BY created_at; 
INDEX(author_id, created_at, user_id) 

«или видео проголосовавшего определенного пользователя, также необходимый, обычно упорядоченный по времени."

SELECT video_id FROM Votes WHERE user_id = ? ORDER BY created_at; 
INDEX(user_id, created_at, video_id) 

С этими предложениями, запросы будут достаточно быстро. Кроме того, MySQL будет делать это самостоятельно кэширование, поэтому добавление другого кэширования слой, вероятно, не поможет (особенно, если он крадет RAM).