Обработка огромной таблицы MYSQL

надеюсь, вы все делаете отлично. У нас есть огромная таблица mysql под названием "posts". Он имеет около 70,000 записей и дошел до размера 10GB.

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

каковы возможные решения, чтобы обработка этой таблицы стала проще, как и во всех аспекты.

структура таблицы выглядит следующим образом:

CREATE TABLE IF NOT EXISTS `posts` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `thread_id` int(11) unsigned NOT NULL,
  `content` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  `first_post` mediumtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `publish` tinyint(1) NOT NULL,
  `deleted` tinyint(1) NOT NULL,
  `movedToWordPress` tinyint(1) NOT NULL,
  `image_src` varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `video_src` varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `video_image_src` varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `thread_title` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `section_title` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `urlToPost` varchar(280) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `posts` int(11) DEFAULT NULL,
  `views` int(11) DEFAULT NULL,
  `forum_name` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `subject` varchar(150) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `visited` int(11) DEFAULT '0',
  `replicated` tinyint(4) DEFAULT '0',
  `createdOn` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `urlToPost` (`urlToPost`,`forum_name`),
  KEY `thread_id` (`thread_id`),
  KEY `publish` (`publish`),
  KEY `createdOn` (`createdOn`),
  KEY `movedToWordPress` (`movedToWordPress`),
  KEY `deleted` (`deleted`),
  KEY `forum_name` (`forum_name`),
  KEY `subject` (`subject`),
  FULLTEXT KEY `first_post` (`first_post`,`thread_title`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=78773 ;

Спасибо.

обновлено

Примечание: хотя я отлично заполнен для ответов, но почти все ответы были об оптимизации текущей базы данных, а не о том, как обычно обрабатывать большие таблицы. Хотя я могу оптимизировать базу данных на основе полученных ответов, это действительно не отвечает на вопрос об обработке огромных баз данных. Сейчас я говорю около 70 000 записей, но в течение следующих нескольких месяцев, если не недель, мы будем расти. Каждая запись может быть размером около 300 КБ.

3 ответов


мой ответ также является дополнением к двум предыдущим комментариям.

вы проиндексировали половину таблицы. Но если вы посмотрите на некоторые индексы (publish, deleted, movedToWordPress), вы заметите, что они равны 1 или 0, поэтому их избирательность низкая (количество строк, разделенных на количество различных значений этого столбца). Эти индексы-пустая трата места.

некоторые вещи также не имеют смысла. tinyint(4) - Это на самом деле не делает его 4-значным целым числом. Номер есть дисплей длина. tinyint - 1 байт, поэтому он имеет 256 возможных значений. Я предполагаю, что что-то пошло не так.

кроме того, 10 концертов в размере всего 75k записей? Как вы измерили размер? Кроме того, какое у вас оборудование?

редактировать в отношении вашего обновленного вопроса:

существует множество способов масштабирования баз данных. Я свяжу один вопрос/ответ, чтобы вы могли получить представление о том, что вы можете сделать:здесь. Другая вещь, которую ты можешь сделать, это стать лучше. аппаратура. Обычно причиной медленного увеличения размера баз данных является подсистема HDD и доступная память для работы с набором данных. Чем больше ОЗУ у вас есть - тем быстрее все это становится.

еще одна вещь, которую вы можете сделать, это разделить таблицу на две таким образом, чтобы одна таблица содержала текстовые данные, а другая-данные, относящиеся к тому, что ваша система требует для выполнения определенного поиска или сопоставления (вы бы поместили целочисленные поля). Используя InnoDB, вы получите огромный повысить производительность, если две таблицы связаны через какой-то внешний ключ, указывающий на первичный ключ. Поскольку InnoDB таков, что поиск первичных ключей выполняется быстро - вы открываете несколько новых возможностей для того, что вы можете сделать с вашим набором данных. Если ваши данные становятся все более огромными, вы можете получить достаточно ОЗУ, и InnoDB попытается буферизировать набор данных в ОЗУ. Есть интересная вещь под названием HandlerSocket это делает некоторые аккуратные магии с серверами, которые имеют достаточно оперативной памяти и используете InnoDB.

В конце концов, это действительно сводится к тому, что нужно делать и как вы делаете это. Поскольку вы не упомянули об этом, трудно дать оценку тому, что вы должны do. Мой первый шаг к оптимизации, безусловно, будет настроить экземпляр MySQL и создать резервную копию этой большой таблицы.


Я думаю, вам нужно изменить некоторые столбцы.

вы можете начать с уменьшения переменных var char.

image_src/video_src / video_image_src VARCHAR(500) немного слишком много, я думаю. (100 varchars достаточно, я бы сказал)

thread_title-это текст, но должен быть VARCHAR (200?) если ты скажешь мне то же самое с section_title

Ok вот ваша проблема content longtext

вам действительно нужен longtext здесь? longtext до 4GB пространство. Я думаю, если вы измените этот столбец на текст, он будет намного меньше

    TINYTEXT    256 bytes    
    TEXT    65,535 bytes    ~64kb
    MEDIUMTEXT   16,777,215 bytes   ~16MB
    LONGTEXT    4,294,967,295 bytes ~4GB

Edit: я вижу, вы используете полнотекстовый индекс. Я совершенно уверен, что это экономит много много много данных. Вы должны использовать другой механизм для поиска полного текста.


в дополнение к тому, что прокомментировал Майкл, медлительность может быть проблемой, основанной на том, насколько хорошо оптимизированы запросы и соответствующие индексы. Я бы попытался найти некоторые из запросов виновника, которые занимают больше времени, чем вы надеетесь, и опубликовать здесь в S/O, чтобы узнать, может ли кто-то помочь в оптимизации параметров.