Извините, ничего не найдено.

pax · 31.05.2015, 00:09

В общем есть таблица с 7-ю миллионами записей. Необходимо быстро вставлять в нее десяток записей. Как это лучше сделать и влияет ли на это движок таблицы?

Сейчас у меня таблица innodb и вставляет записи за несколько секунд. Хотелось бы это как-то ускорить...

Randomize · 31.05.2015, 01:24

Если есть доступ к my.ini смени эти параметры и рестартни:

innodb_buffer_pool_size = рам
innodb_read_io_threads = побольше потоков чтения
innodb_write_io_threads = побольше потоков записи
innodb_thread_concurrency = общее кол-во потоков

может имеет смысл врубить innodb_file_per_table

Попробуй сделать EXPAIN для такого INSERT запроса чтоб не ходить вокруг да около (ток мускуль 5.6)
http://dev.mysql.com/doc/refman/5.6/en/explain.html

Или профильнуть через SHOW PROFILES; после INSERT

h1dd3n · 31.05.2015, 11:23

Еще вставлять надо в одной транзакции. И чем меньше индексов тем быстрее будет.

pax · 31.05.2015, 15:07

Спасибо, попробую!

pax · 31.05.2015, 15:12

По настройкам стоит:

innodb_buffer_pool_size = 8388608000
innodb_read_io_threads = 4
innodb_write_io_threads = 4
innodb_thread_concurrency = 0
innodb_file_per_table = OFF

Что посоветуете при наличии процессора core i7 с восемью логическими ядрами?
MySql 5.5 установлен.

Nikich · 31.05.2015, 23:39

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

pax · 01.06.2015, 16:55

В общем сменил настройки mysql, при задании innodb_log_file_size сервер не стартует, оставил значение по умолчанию. Не понятно в чем проблема, логи почему-то пустые постоянно.

pax · 01.06.2015, 17:25

Судя по всему скорость инсерта записей ускорилась с нескольких секунд до десятков миллисекунд, спасибо всем за помощь!

moka · 01.06.2015, 17:29

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

pax · 01.06.2015, 18:02

реляционные, до key value пока не дорос наверное

moka · 01.06.2015, 18:55

Сообщение от pax

реляционные, до key value пока не дорос наверное

Там проще обычно.

Если тебе нужно шустрый insert, но очень шустрый read не сильно критичен, то бери mongodb. Т.к. у него на много выше скорость insert'а, но ниже скорость read'а обычно.

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

h1dd3n · 01.06.2015, 19:38

партицирование

moka · 02.06.2015, 13:21

Сообщение от h1dd3n

партицирование

Это поможет только если партицировать по (id % partitions), но это очень ограничено и усложнит запросы к бд.

Следственно партицирование не решает write проблемы, и обычно используется при высокой read нагрузке и огромных объемах данных (100гб+).

h1dd3n · 02.06.2015, 13:51

Сообщение от moka

Это поможет только если партицировать по (id % partitions), но это очень ограничено и усложнит запросы к бд.

Следственно партицирование не решает write проблемы, и обычно используется при высокой read нагрузке и огромных объемах данных (100гб+).

Что за бред. Я пониманию что тебе возможно трудно писать по-русски, но в твоем посте смысла просто 0...

Партицировать таблицу можно по дате (например, помесячно). При партицировании индекс становится тоже партицированным, что охренительно ускоряет insert. Если сейчас инсерт например 0.01, то при росте базы (это ведь таблица со статистикой, наверняка будет расти) время инсерта может сильно увеличиться и с этим уже ничего не поделаешь (только лишаться индексов или делить таблицу на несколько). А с партицированием будет обновляться только индекс соответствующей партиции (например, за месяц), что значит что даже через 10 лет инсерт будет примерно такой же как и сейчас (и при этом делить таблицу на несколько, или удалять из нее данные не надо)

moka · 02.06.2015, 13:59

Сообщение от h1dd3n

Что за бред. Я пониманию что тебе возможно трудно писать по-русски, но в твоем посте смысла просто 0...

Партицировать таблицу можно по дате (например, помесячно). При партицировании индекс становится тоже партицированным, что охренительно ускоряет insert. Если сейчас инсерт например 0.01, то при росте базы (это ведь таблица со статистикой, наверняка будет расти) время инсерта может сильно увеличиться и с этим уже ничего не поделаешь (только лишаться индексов или делить таблицу на несколько). А с партицированием будет обновляться только индекс соответствующей партиции (например, за месяц), что значит что даже через 10 лет инсерт будет примерно такой же как и сейчас (и при этом делить таблицу на несколько, или удалять из нее данные не надо)

Основная проблема скорости insert'а в данном случае связана не с размером таблицы, а со сложностью индексации на таблице + количество insert'ов в секунду, и работа требуемая на обработку данных даже до того как вставится в таблицу. И лишь потом уже фактор большой таблицы.

Следственно если нафиг убрать индексы которые нужны только для обработки данных, это уже сильно ускоряет вставку.

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