|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
У меня есть сервер с 4 ядрами и 32гб памяти на амазоне
есть таблица в которую я очень часто пишу данные
размер таблицы 18гб и каждый день по +1гб добавляется
CREATE TABLE IF NOT EXISTS `rss` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`hash` binary(16) NOT NULL,
`domain` varchar(40) NOT NULL,
`level` int(1) NOT NULL,
`base_topic` int(7) NOT NULL,
`city` varchar(40) NOT NULL,
`keyword` varchar(40) NOT NULL,
`title` varchar(255) NOT NULL,
`description` text NOT NULL,
`url` varchar(255) NOT NULL,
`image` varchar(255) NOT NULL,
`date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `hash` (`hash`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=56220564 ;
проблема заключается в том что я уже не могу выполнить запрос SELECT COUNT(`id`) FROM `rss`
проблемы с перемещением по таблице то есть лимит 20000000, 10 не отрабатывает быстро
я пробовал поставить партишен на таблицу но это не помогло
ALTER TABLE rss
PARTITION BY LINEAR KEY (id) PARTITIONS 100 - тормозить еще больше стало
запросы вида
SELECT SQL_CALC_FOUND_ROWS DISTINCT `rss`.`id`, `rss`.`domain` AS `owner`, `rss`.`level`, `rss`.`base_topic`, `rss`.`city` AS `city_name`, `rss`.`keyword`, `rss`.`title`, `rss`.`description` AS `descriptionTEXT`, `rss`.`url` AS `slug`, `rss`.`url` AS `url_source`, `rss`.`image` AS `images`, `rss`.`date`, '' AS `price`, '' AS `city_slug`, '' AS `state_name`, '' AS `state_code`
FROM `topics2rss`, `rss`
WHERE `topics2rss`.`id_rss` = `rss`.`id` AND `topics2rss`.`id_topic` IN () ";
ORDER BY `level` ASC
LIMIT 99
что вообще можно сделать с таблицами размер которых начинает привышать 2гб???
подскажите как можно оптимизировать таблицу
Неактивен
2 гигабайта здесь не при чем, дело в запросах. LIMIT 20000000, 10 не может работать быстро в принципе - он может работать либо медленно либо очень медленно, так как необходимо перебрать 20 млн записей. Ваш запрос относится к тем, которые выполняются очень медленно - попробуйте разбить его на два, как описано здесь http://webew.ru/articles/4856.webew
Неактивен
хорошо, а как быть с тем что весит этот запрос SELECT COUNT(`id`) FROM `rss`?
а еще мне надо перенести эти данные в elastic search, как я могу их все прочитать? за один раз это абсурд же полный, только через лимиты как я понимаю? но все запросы с лимитами висят
и еще вопрос: как mysql работает с файлами такого объема, файл надо же открыть перемотать в нужное место и считать нужную информация и я как понимаю чем больше файл тем труднее прочитать его
Неактивен
rgbeast написал:
2 гигабайта здесь не при чем, дело в запросах. LIMIT 20000000, 10 не может работать быстро в принципе - он может работать либо медленно либо очень медленно, так как необходимо перебрать 20 млн записей. Ваш запрос относится к тем, которые выполняются очень медленно - попробуйте разбить его на два, как описано здесь http://webew.ru/articles/4856.webew
я не совсем понял на какие 2 запроса, если вторую таблицу убрать, суть не меняется, я не могу прочитать данные из таблицы, как мне написать запрос чтобы я мог все 30м записей куда то перенести?
Спасибо что помогаете, пытаюсь докопаться до сути
Отредактированно maxjoin (20.03.2013 03:45:27)
Неактивен
maxjoin написал:
я не совсем понял на какие 2 запроса, если вторую таблицу убрать, суть не меняется, я не могу прочитать данные из таблицы, как мне написать запрос чтобы я мог все 30м записей куда то перенести?
Спасибо что помогаете, пытаюсь докопаться до сути
Важно, что в первом запросе будет только SELECT id и ему не придется сортировать длинные данные. Во втором запросе в SELECT будут все поля.
Неактивен
maxjoin написал:
хорошо, а как быть с тем что весит этот запрос SELECT COUNT(`id`) FROM `rss`?
а еще мне надо перенести эти данные в elastic search, как я могу их все прочитать? за один раз это абсурд же полный, только через лимиты как я понимаю? но все запросы с лимитами висят
и еще вопрос: как mysql работает с файлами такого объема, файл надо же открыть перемотать в нужное место и считать нужную информация и я как понимаю чем больше файл тем труднее прочитать его
В InnoDB SELECT count будет всегда медленным. Храните независимо число строк, обновляйте при апдейтах и иногда пересчитывайте.
Не будет висеть запрос WHERE id>XXX LIMIT 1000; Ему не надо просмативать и отбрасывать миллион записей - он сразу по индексу найдет откуда начать.
Работа с файлом не представляет принципиальных проблем. Если разобьете на 100 файлов, то для диска это будет то же самое.
Неактивен
ок, забыли про этот запрос. Проблема сейчас в том, что висит SELECT COUNT(`id`) FROM `rss`, почему? и как выгрузить данные в другую систему использую запросы а не дамп?
Неактивен
ответ #6
Неактивен
rgbeast написал:
maxjoin написал:
хорошо, а как быть с тем что весит этот запрос SELECT COUNT(`id`) FROM `rss`?
а еще мне надо перенести эти данные в elastic search, как я могу их все прочитать? за один раз это абсурд же полный, только через лимиты как я понимаю? но все запросы с лимитами висят
и еще вопрос: как mysql работает с файлами такого объема, файл надо же открыть перемотать в нужное место и считать нужную информация и я как понимаю чем больше файл тем труднее прочитать егоВ InnoDB SELECT count будет всегда медленным. Храните независимо число строк, обновляйте при апдейтах и иногда пересчитывайте.
Не будет висеть запрос WHERE id>XXX LIMIT 1000; Ему не надо просмативать и отбрасывать миллион записей - он сразу по индексу найдет откуда начать.
Работа с файлом не представляет принципиальных проблем. Если разобьете на 100 файлов, то для диска это будет то же самое.
Спасибо, тут другой вопрос возникает Не будет висеть запрос WHERE id>XXX LIMIT 1000;, как узнать следующий id если порядок их сбит к примеру удалением строк 1,2,3,4,6,7,9,10...
или надо уже на уровне скриптов логику включать? запоминать последний id из предыдущего запроса
Неактивен
Запоминать последний id. Это не так сложно.
Неактивен
Спасибо, реально помогло
есть еще такой вопрос, некоторые знакомые мне говорили что мускл можно использовать как ключ значение хранилище, говорили что объем базы 2 тб и движек myisam и все работает хорошо, у меня возник вопрос реально ли это. и как я знаю myisam нестабилен и если он сломается то сервер надолго вылетит из продакшена. стоит ли верить все этому? мы используем монго под хранение данных ключ значение но как то не совсем довольны, там у него свои проблемы есть
Отредактированно maxjoin (20.03.2013 19:56:10)
Неактивен
Попробуйте, протестируйте для своих целей. Если можете - запустите стенд на несколько месяцев с копией базы продакшена. Заодно потестируйте ситуацию порчи индекса - сколько займет восстановление (это может быть действительно долго). Чтобы не было дайнтайма, используйте репликацию и если много апдейтов, то лучше InnoDB.
Неактивен
спасибо за ценную информацию
Неактивен
Страниц: 1
