Mysql: несколько таблиц или одна большая таблица?

Question

Этот вопрос уже задавался, но я не нашел "1 голосовой ответ".

Это лучше сделать:

• 1 большой стол с:

user_id | attribute_1 | attribute_2 | attribute_3 | attribute_4

• или 4 маленьких таблицы с: user_id | attribute_1

user_id | attribute_2

user_id | attribute_3

user_id | attribute_4

1 большой стол или много маленьких столов? Каждый пользователь может иметь только 1 значение для attribute_X. У нас много данных для сохранения (100 миллионов пользователей). Мы используем innoDB. Производительность действительно важна для нас (10 000 запросов / с).

Спасибо!

Франсуа

Answer 1

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

Например, возможная схема:

CREATE TABLE user_attributes (
  id INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
  user_id INT NOT NULL,
  attribute_name VARCHAR(255) NOT NULL,
  attribute_value VARCHAR(255),
  UNIQUE INDEX index_user_attributes_name(user_id, attribute_name)
);

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

Хотя требования к хранилищу для этого выше, чем расположение с фиксированными столбцами с постоянно разочаровывающими именами, такими как attribute1 В эпоху жестких дисков размером в терабайт стоимость достаточно мала, поэтому проблема возникает редко.

Как правило, вы создаете одну таблицу для этих данных, пока время вставки не станет проблемой. Пока ваши вставки быстрые, я бы об этом не беспокоился. На этом этапе вы захотите рассмотреть стратегию разделения, чтобы разделить эти данные на несколько таблиц с идентичной схемой, но только если это необходимо.

Я предположил бы, что это будет на стадии ~10-50 миллионов строк, но может быть выше, если количество операций вставки в этой таблице относительно низкое.

Не забывайте, что лучший способ оптимизировать активность чтения - это использовать кеш: самый быстрый запрос к базе данных - это тот, который вы не делаете. Для такого рода вещей вы обычно используете что-то вроде http://memcached.org/ для хранения результатов предыдущих выборок, и вы бы аннулировали это при записи.

Как всегда, сравните любую предложенную схему в масштабе производства.

Answer 2

1 большая таблица с: user_id | attribute_1 | attribute_2 | attribute_3 | attribute_4

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