MySQL количество данных в таблице - PullRequest
3 голосов
/ 09 февраля 2010

Я проектирую систему, и, углубившись в цифры, я понимаю, что она может достичь точки, где может быть таблица с 54 240 211 584 записями в год (приблизительно). WOW !!!!

Итак, я понизил это до 73 271 952 записей / год (приблизительно).

Я получил цифры, запустив несколько примеров того, что произойдет, если:
а) безуспешно = 87 пользователей,
б) низкий модерируемый успех = 4300 пользователей,
в) высокий модерируемый успех = 13199 пользователей,
г) успех = 55100 пользователей
д) невероятный успех = нет

Учитывая, что таблица используется для операторов SELECT, INSERT, UPDATE & JOIN и что эти операторы будут выполняться любым пользователем, входящим в систему ежечасно / ежедневно / еженедельно (исторические данные не доступны):

Вопрос 1: подходит ли 2-е количество / удобно для движка MySQL, чтобы производительность не оказывала значительного влияния ???

Вопрос 2: Я установил таблицу как InnoDB, но, учитывая тот факт, что я обрабатываю все операторы с помощью JOINS и что я готов столкнуться с проблемой ограничения в 4 ГБ, полезен InnoDB ???

Быстрый обзор таблиц:
Таблица № 1: пользователь / покупка события. До 15 столбцов, некоторые из них VARCHAR.
Таблица № 2: билеты при покупке. До 8 столбцов, только TINYINT. Первичный ключ INT. В каждой таблице # 1 вставляется от 4 до 15 строк.
Таблица № 3: предметы по билетам. 4 колонки, только TINYINT. Первичный ключ INT. 3 строки вставлены каждой таблицей # 2 вставки. Я хочу сохранить это как отдельный стол, но если кто-то должен умереть ...

Таблица № 3 является целью вопроса. Я уменьшил до 2-го количества, сделав строку каждой таблицы № 3 столбцом таблицы № 2.

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

Каждый ответ помогает, но было бы более полезно, например:
i) 33 754 240 401 584: нет, поэтому давайте отбросим последний номер.
ii) 3 375 424 021 158: нет, поэтому давайте отбросим последний номер.
iii) 337 542 402 115: нет, поэтому давайте отбросим последний номер. И так до тех пор, пока мы не получим что-то вроде «ну, это зависит от многих факторов ...»

Что бы я считал "небольшим влиянием на производительность" ??? До 1 000 000 записей выполнение запросов не более 3 секунд. Если 33 754 240 211 584 записей займут около 10 секунд, для меня это отлично.

Почему бы мне просто не проверить это самостоятельно ??? Я думаю, что я не способен сделать такой тест. Я хотел бы просто вставить это количество строк и посмотреть, что произойдет. Я предпочитаю в первую очередь точку зрения человека, который уже знал о чем-то подобном. Помните, я все еще на стадии проектирования

Заранее спасибо.

Ответы [ 3 ]

3 голосов
/ 09 февраля 2010

54,240,211,584 - это много. У меня есть опыт работы с таблицами mysql до 300 миллионов строк, и он справляется с этим без особых проблем. Я не уверен, что вы на самом деле спрашиваете, но вот некоторые заметки:

  • Используйте InnoDB, если вам нужна поддержка транзакций или вы выполняете много операций вставки / обновления. Таблицы MyISAM плохо подходят для транзакционных данных, но хорошо, если вы очень много читаете и время от времени делаете только массовые вставки / обновления.

  • Для MySQL нет ограничения в 4 Гб, если вы используете последние выпуски / не используете операционные системы. Мой самый большой стол сейчас 211Gb.

  • Очистка данных в больших таблицах очень медленная. например удаление всех записей за месяц занимает у меня несколько часов. (Удаление отдельных записей происходит быстро).

  • Не используйте int / tinyint, если вы ожидаете много миллиардов записей, они обернутся вокруг.

  • Получите что-нибудь работающее, исправьте масштабирование после первого выпуска. Нереализованная идея в значительной степени бесполезна, и то, что работает (пока), может быть очень полезным.

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

  • Посмотрите на секционированные таблицы, недавно появившуюся в MySQL функцию, которая может помочь вам в масштабировании.

1 голос
/ 09 февраля 2010

Начните с того уровня, на котором вы находитесь. Построй оттуда.

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

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

0 голосов
/ 09 февраля 2010

Нет предела 4Gb, но, конечно, есть ограничения. Не планируйте слишком далеко вперед. Если вы только начинаете и планируете стать следующим Facebook, это здорово, но у вас нет ресурсов.

Получите что-нибудь работающее, чтобы вы могли показать своим инвесторам:)

...