Лучший выбор для огромной таблицы базы данных, которая содержит только целые числа (необходимо использовать SUM () или AVG ()) - PullRequest
Новая
       22

Лучший выбор для огромной таблицы базы данных, которая содержит только целые числа (необходимо использовать SUM () или AVG ())

0 голосов
/ 23 июня 2011

В настоящее время я использую таблицу MySQL для онлайн-игры под LAMP.

Одна таблица огромна (скоро миллионы строк) и содержит только целые числа (идентификаторы, метки времени, логические значения, оценки).

Я сделал все, чтобы никогда не присоединяться к этой таблице.Тем не менее, я беспокоюсь о масштабируемости.Я думаю о переносе этой таблицы в другую, более быструю систему баз данных.Я использую промежуточные таблицы для расчета баллов, но в некоторых случаях мне приходится использовать SUM () или AVERAGE () непосредственно для некоторых отфильтрованных наборов строк в этой таблице.

Для вас, какая база данных лучше всего подходит для этого?Таблица?

Мои требования / спецификации:

  • Эта таблица содержит только целые числа (около 15 столбцов)
  • Мне нужно отфильтровать по определенным столбцам
  • Iхотелось бы иметь УНИКАЛЬНЫЕ КЛАВИШИ
  • Было бы неплохо иметь "INSERT ... ON DUPLICATE UPDATE", но я полагаю, что мои скрипты могут управлять им самостоятельно.
  • Мне нужно использовать SUM() или СРЕДНИЙ ()

спасибо

Ответы [ 2 ]

0 голосов
/ 24 июня 2011

Миллионы строк в таблице невелики. Вы не должны ожидать каких-либо проблем при выборе, фильтрации или добавлении данных, если индексируете соответствующие ключи, как подсказывает @ Tom-Squires.

Совокупные запросы (сумма и среднее значение) могут представлять проблему. Причина в том, что им требуется полное сканирование таблицы и, следовательно, несколько выборок данных с диска в память. Пара способов увеличить их скорость:

  1. Если ваши данные изменяются нечасто, то, вероятно, хорошим решением будет кэширование результатов запроса в вашем коде.
  2. Если оно часто меняется, то самый быстрый способ улучшить их производительность - это, вероятно, убедиться, что ядро ​​базы данных хранит таблицу в памяти. Быстрый расчет ожидаемого размера: 15 столбцов x 8 байт x миллионов = ~ 100 МБ - на самом деле не проблема (если вы не используете общий хост). Если ваша СУБД не поддерживает настройку этого параметра для конкретной таблицы, просто поместите ее в другую схему базы данных - это не должно быть проблемой, поскольку вы не выполняете никаких соединений с этой таблицей. Большинство двигателей позволит вам настроить это.
0 голосов
/ 23 июня 2011

Просто убедитесь, что у вас есть правильные индексы, поэтому выбор должен быть быстрым

...