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

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

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

Я сделал все, чтобы никогда не пришлось ПРИСОЕДИНЯТЬСЯ к этому столу. Однако меня беспокоит масштабируемость. Я думаю о перемещении этой единственной таблицы в другую более быструю систему баз данных. Я использую промежуточные таблицы для вычисления оценок, но в некоторых случаях мне приходится использовать SUM() или AVERAGE() непосредственно для некоторых отфильтрованных наборов строк этой таблицы.

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

Мои требования/характеристики:

  • Эта таблица содержит только целые числа (около 15 столбцов)
  • Мне нужно отфильтровать по определенным столбцам
  • Я хочу иметь УНИКАЛЬНЫЕ КЛЮЧИ
  • Было бы неплохо иметь «INSERT... ON DUPLICATE UPDATE», но я полагаю, что мои скрипты могут справиться с этим сами по себе.
  • я должен использовать СУММ() или СРЗНАЧ()

Благодарность


database average sum scalability integer
person Thomas    schedule 23.06.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

person Tom Squires    schedule 23.06.2011
comment
Спасибо за ваш быстрый ответ. Итак, вы думаете, что MySQL может легко управлять такими таблицами и функциями SQL. - person Thomas; 23.06.2011
comment
Да, если у вас есть правильные индексы. Правильно проиндексированная огромная таблица по-прежнему должна быть быстрой для поиска. Поместите кластеризованный индекс в поле, которое вы собираетесь поместить в предложение where en.wikipedia.org /wiki/Index_%28database%29 - person Tom Squires; 23.06.2011
comment
Почти все поля в том или ином случае будут в предложении where. Я уже поставил индексы на некоторые из них. Я должен проверить последствия создания большого количества индексов - person Thomas; 25.06.2011

arrow_upward
0
arrow_downward

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

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

  1. Если ваши данные изменяются нечасто, то кэширование результатов запроса в вашем коде, вероятно, является хорошим решением.
  2. Если она часто меняется, то самый быстрый способ улучшить их производительность, вероятно, состоит в том, чтобы убедиться, что ваш механизм базы данных хранит таблицу в памяти. Быстрый расчет ожидаемого размера: 15 столбцов x 8 байт x миллионов = ~ 100 МБ - на самом деле это не проблема (если вы не находитесь на общем хосте). Если ваша СУБД не поддерживает настройку для конкретной таблицы, просто поместите ее в другую схему базы данных - это не должно быть проблемой, поскольку вы не выполняете никаких соединений с этой таблицей. Большинство двигателей позволят вам настроить это.
person Elad    schedule 24.06.2011
comment
Спасибо за Ваш ответ. Это действительно полезно. Думаю с памятью проблем нет. База данных размещена в облачном хостинге, где я могу легко изменить свойства серверов. - person Thomas; 25.06.2011