Таблица MYSQL становится большой - PullRequest
2 голосов
/ 21 апреля 2011

У меня есть таблица, в которую добавляется около 100 000 строк каждый день.Я должен генерировать отчеты из этой таблицы.Я использую PHP для генерации этих отчетов.Недавно сценарий, который делал это, занимал слишком много времени для завершения.Как я могу улучшить производительность, переключившись на что-то другое, чем MYSQL, который в долгосрочной перспективе масштабируется.

Ответы [ 8 ]

8 голосов
/ 21 апреля 2011

MySQL очень масштабируемый, это точно.

Ключ не меняет БД с Mysql на другой, но вы должны:

  1. Оптимизировать ваши запросы (может показаться глупым для других, но я помню, например, что огромное улучшение, которое я сделал некоторое время назад, это изменение SELECT * на выбор только тех столбцов, которые мне нужны. Это частая проблема, с которой я сталкиваюсь и в коде других)
  2. Оптимизация дизайна таблиц ( нормализация и т. Д.).
  3. Добавление индексов в столбцах, которые вы часто используете в запросах.

Похожие советы здесь

2 голосов
/ 21 апреля 2011

Вам следует прочитать следующее и немного узнать о преимуществах хорошо спроектированной таблицы innodb и о том, как лучше всего использовать кластерные индексы - доступно только с innodb!

Пример включает таблицу с 500 миллионами строк с временем запроса 0,02 секунды.

MySQL и NoSQL: помогите выбрать правильный

Надеюсь, вы найдете это интересным.

2 голосов
/ 21 апреля 2011

Сначала проанализируйте, почему (или: если) ваши запросы медленные: http://dev.mysql.com/doc/refman/5.1/en/using-explain.html

2 голосов
/ 21 апреля 2011

Для генерации отчетов или загрузки файлов с большими порциями данных вам следует использовать значение flush и увеличивать ограничение по времени и предел памяти.

Я сомневаюсь, что проблема заключается в количестве строк, поскольку MySQL может поддерживать ALOT строк. Но вы, конечно, можете извлекать x строк за раз и обрабатывать их кусками.

Я предполагаю, что ваш MySQL правильно настроен для повышения производительности.

1 голос
/ 22 апреля 2011

Я собираюсь сделать некоторые предположения

  • Ваши 100-тысячные строки, добавляемые каждый день, имеют временные метки, которые либо отображаются в режиме реального времени, либо смещены на относительно короткий промежуток времени (максимум часов); ваши 100к строк добавляются либо в течение дня, либо несколькими большими партиями.
  • Данные никогда не обновляются
  • Вы используете движок InnoDB (Честно говоря, было бы безумно использовать MyISAM для больших таблиц, потому что в случае сбоя перестройка индекса занимает непомерно много времени)

Вы не объяснили, какие отчеты вы пытаетесь сгенерировать, но я предполагаю, что ваша таблица выглядит следующим образом:

 CREATE TABLE logdata (
   dateandtime some_timestamp_type NOT NULL,
   property1 some_type_1 NOT NULL,
   property2 some_type_2 NOT NULL,
   some_quantity some_numerical_type NOT NULL,
   ... some other columns not required for reports ...
   ... some indexes ...

 );

И что ваши отчеты выглядят как

SELECT count(*), SUM(some_quantity), property1 FROM logdata WHERE dateandtime BETWEEEN some_time_range GROUP BY property1;
SELECT count(*), SUM(some_quantity), property2 FROM logdata WHERE dateandtime BETWEEEN some_time_range GROUP BY property2;

Теперь, как мы видим, оба этих отчета сканируют большое количество таблицы, потому что вы отчитываетесь по большому количеству строк.

Чем больше временной диапазон, тем медленнее будут отчеты. Более того, если у вас есть много ДРУГИХ столбцов (скажем, некоторых varchars или больших двоичных объектов), о которых вы не заинтересованы в отчете, они также замедляют ваш отчет (поскольку серверу все еще нужно проверять строки).

Вы можете использовать несколько возможных методов для ускорения этого:

  • Добавьте индекс покрытия для каждого типа отчета, чтобы поддерживать нужные вам столбцы и опускать столбцы, которые вам не нужны. Это может сильно помочь, но медленные вставки вниз.
  • Суммируйте данные в соответствии с измерением (ями), о которых вы хотите сообщить. В этом вымышленном случае все ваши отчеты либо подсчитывают строки, либо SUM () генерируют some_quantity.
  • Создание зеркальных таблиц (содержащих те же данные), которые имеют соответствующие первичные ключи / индексы / столбцы для ускорения отчетов.
  • Использовать движок колонки (например, Infobright)

Суммирование обычно является привлекательным вариантом, если ваш сценарий использования поддерживает его;

Возможно, вы захотите задать более подробный вопрос с объяснением вашего варианта использования.

1 голос
/ 21 апреля 2011

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

Распространены базы данных транзакций и отчетов.

0 голосов
/ 21 апреля 2011

Ограничение по времени может быть временно отключено для определенного файла, если вы знаете, что он может потенциально работать в течение указанного времени, вызвав set_time_limit (0); в начале вашего сценария.

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

0 голосов
/ 21 апреля 2011

Ваш лучший выбор - что-то вроде MongoDB или CouchDB, обе из которых являются нереляционными базами данных, ориентированными на хранение огромных объемов данных.Это предполагает, что вы уже настроили установку MySQL для повышения производительности и что ваша ситуация не выиграет от распараллеливания.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...