|
Задавайте вопросы, мы ответим
Вы не зашли.
Можно ли для FEDERATED с индексированными полями реализовать оптимизацию по скорости большого количества вставок аналогично приему:
lock table `table` write;
insert into `table` ....
...
unlock tables;
Насколько я понимаю, в чистом виде это не сделать, т.к. блокировки действуют только на том сервере, где выполняются, т.е. если блокировать на источнике, то все равно поток вставок на приемнике будет "дергать" индексы на каждую вставку. С другой стороны, если блокировать на приемнике, то на источнике вставка будет заблокирована, т.к. запросы на блокировку и вставку располагаются в разных потоках.
Подскажите, как оптимальнее сделать, если нужно сливать в одну FEDERATED-таблицу с нескольких серверов. От индексов отказываться не хотелось бы. (они для insert ignore нужны, чтобы не было дубликатов)
Или, может, есть красивое решение для избавления от дубликатов на следующем шаге после добавления записей? Тогда можно было бы отказаться от индексов на этапе вставки.
Спасибо.
Неактивен
Насколько я понимаю, Вы в любом случае будете дергать индекс на каждую вставку.
По крайней мере, Ваш пример никак не ограничивает использование индексов.
А что Вас смущает в простой вставке в таблицу?
Неактивен
paulus написал:
Насколько я понимаю, Вы в любом случае будете дергать индекс на каждую вставку.
По крайней мере, Ваш пример никак не ограничивает использование индексов.
А что Вас смущает в простой вставке в таблицу?
Может, плохо объяснил суть, но, как известно, в простейшем случае (без блокировок) при каждой вставке будет пересчитываться индекс.
Блокировки же позволяют обновить индекс один раз после unlock tables.
Не помню точно как влияет на это дело autocommit (может, подскажете заодно ?)
Неактивен
Транзакции с FEDERATED невозможны. Также как и блокировки. Перестройка индекса - не очень долгая операция, но на производительность влиять может. Слово FEDERATED и слово производительность не стоит употреблять в рамках одного предложения 
Для MyISAM работает еще ALTER TABLE DISABLE KEYS; ALTER TABLE ENABLE KEYS, но для FEDERATED не думаю, что это уместно.
Попробуйте multiple insert, то есть вставку многих строк одним оператором INSERT
Неактивен
rgbeast написал:
...Перестройка индекса - не очень долгая операция, но на производительность влиять может...
А при перестройке индекс сбрасывается на диск? Или по обстоятельствам, в зависимости от того, находится ли страница с индексом в памяти?
Вообще, у меня вставка в пустую таблицу. Где будет наращиваться индекс - в памяти или на диске?
Для MyISAM работает еще ALTER TABLE DISABLE KEYS; ALTER TABLE ENABLE KEYS, но для FEDERATED не думаю, что это уместно.
Вот, кстати, очень хорошая идея. Я буду применять это для таблицы-приемника, а она как раз MyISAM.
Попробуйте multiple insert, то есть вставку многих строк одним оператором INSERT
У меня insert into ... select *. К тому же, насколько я понял, пакетные вставки (предложенный Вами muliple insert) преобразуются (для FEDERATED) в отдельные запросы, верно? А как насчет моего случая?
В общем, при отключенных индексах вполне приемлемая производительность. Я работаю с этой таблицей на стороне приемника, она мне нужна только чтобы собрать воедино данные с нескольких узлов. Просто пока за один раз заливается порядка 600К записей (после обработки таблица чистится), производительность приемлемая. Но объемы будут расти, нужны все инструменты оптимизации.
Неактивен
Удаляйте индексы как класс DROP INDEX, вставляйте данные и затем ADD INDEX, это будет работать в любой конфигурации.
Про работу индекса, см. иллюстрацию http://slady.net/java/bt/view.php?w=600&h=450 индекс должен обновится на диске (или в дисковом кэше), но изменения локальны. См. также тему: http://sqlinfo.ru/forum/viewtopic.php?id=29
Неактивен
Полностью убрать индексы при вставке не получится - остается 1 уникальный, чтобы фильтровать дубликаты. Скорость даже при наличии этого ключа приемлемая, за исключением моментов, когда происходит обращение к диску (я так понимаю, сбрасывается индексный буфер). Это очень хорошо видно на графике KeyEfficiency в MySQL Administrator. В эти моменты запрос select count(*) from для таблицы-приемника как бы подвисает и резко снижается прирост новых записей. Когда идет работа с памятью - все гладко и равномерно вставляется. В связи с этим вопрос: можно ли как-то влиять на размер этого временного буфера, чтобы снизить вероятность обращения к диску?
Неактивен
Есть механизм KEY CACHE (в MyISAM): http://dev.mysql.com/doc/refman/5.1/en/ … cache.html
Можно увеличить key_buffer_size, тогда индексы будут работать быстрее. На запись это не должно влиять, так как после изменения индекс должен быть записан на диск (не целиком, а тот блок, который обновился). Здесь поможет только дисковый кеш операционной системы.
Неактивен
