Сколько строк "слишком много" для таблицы MySQL?
Возможный дубликат:
Сколько строк в базе данных СЛИШКОМ МНОГО?
Я создаю схему базы данных для приложения, которое будет иметь пользователей, и каждый пользователь будет иметь множество строк в таблицах отношений, таких как "избранное".
Каждый пользователь может иметь тысячи избранных, и могут быть тысячи зарегистрированных пользователей (со временем).
Учитывая, что пользователи никогда не удаляются, потому что это либо оставило бы другие сущности сиротства, либо их тоже удалили (что нежелательно), и поэтому эти таблицы будут продолжать расти навсегда, мне было интересно, могут ли результирующие таблицы слишком большой (например, строки 1kk), и я должен беспокоиться об этом и делать что-то вроде отметки старых и неактивных пользователей как удаленных и удалять отношения, которые влияют на них (например, избранные и другие настройки).
Это путь? Или может mysql легко обрабатывать строки 1kk в таблице? Есть ли известный предел? Или это полностью зависит от оборудования?
Ответы
Ответ 1
Я согласен с klennepette и Брайаном - с несколькими предостережениями.
Если ваши данные по сути являются реляционными и подвержены запросам, которые хорошо работают с SQL, вы должны иметь возможность масштабировать до сотен миллионов записей без экзотических требований к оборудованию.
Вам нужно будет инвестировать в индексирование, настройку запросов и случайную жертву реляционной модели в интересах скорости. Вы должны хотя бы кивать на производительность при разработке таблиц - например, предпочитая целые числа для строк для ключей.
Если, однако, у вас есть требования к документам, нужен бесплатный текстовый поиск или есть много иерархических отношений, вам может потребоваться снова посмотреть.
Если вам нужны транзакции ACID, вы можете столкнуться с проблемами масштабируемости раньше, чем если вы не заботитесь о транзакциях (хотя это вряд ли повлияет на вас на практике); если у вас длительные или сложные транзакции, ваша масштабируемость довольно быстро уменьшается.
Я бы рекомендовал создать проект с нуля с учетом требований к масштабируемости. То, что я делал в прошлом, настроено на тестовую среду, заполненную миллионами записей (я использовал DBMonster, но не уверен, что это все еще), и регулярно тестировать код незавершенного производства в этой базе данных с помощью инструментов тестирования нагрузки, таких как Jmeter.
Ответ 2
Вот пример, демонстрирующий, что может быть достигнуто с использованием хорошо продуманной/нормализованной схемы innodb, которая использует преимущества индексированных индексов первичных ключей innodb (недоступных с myisam). Пример основан на форуме с потоками и содержит 500 миллионов строк и времени выполнения запросов 0,02 секунды при загрузке.
MySQL и NoSQL: помогите выбрать правильный вариант
Ответ 3
Миллионы строк в порядке, десятки миллионов строк в порядке - при условии, что у вас есть даже отдаленно приличный сервер, т.е. несколько Gbs ОЗУ, достаточно места на диске. Вам нужно будет узнать об индексах для быстрого извлечения, но с точки зрения возможности MySQL справиться с этим, никаких проблем.
Ответ 4
В основном это зависит от аппаратного обеспечения, но при этом MySQL хорошо масштабируется.
Я бы не стал слишком беспокоиться о размере таблицы, если впоследствии это станет проблемой, вы всегда можете использовать partitioning, чтобы облегчить стресс.
