Разное

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

В таблице приведены количество записей (левая колонка) и время в секундах для их занесения.

Как на основании этих сведений оценить время, которое потребуется для занесения одного миллиона записей? Полутора миллионов записей?

50000 1230 100000 2940 150000 5170 200000 8110 250000 11320 300000 15220 350000 19450 400000 24610 450000 30430 500000 36730 550000 44050 600000 51730

Вы во время обновления индексы отключаете? Таблицу блокируете? Время обновления сильно зависит от того, куда заносятся данные... более того, на больших системах с миллиардами записей для записи выделяют отдельный сервер (master), с которого вообще никогда никто ничего не читает (SELECT), данные с него распространяются при помощи репликации на подчиненные сервера (slave), с них уже осуществляется чтение, таблицы в них индексированы. На master-сервере все индексы отключены - это существенно ускоряет запись, так как не нужно сортировать индекс каждый раз при вставке нового значения (а файлы индексов могут достигать довольно большого размера - это кстати минус и за этим нужно следить, чтобы их размер оставался не очень большим, иначе пользы от индексирования будет не много).

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

А в данном случае импорт идет в базу типовой CMS. Как они ею управляют, я не знаю. Блокируют ли, отключают ли индексы - неизвестно.

Меня удивляет огромное время записи. Планируется импортировать полтора миллиона строк, но процесс идет так долго, что я даже не могу его протестировать. Вот и приходится строить гипотезы...

Реально закачал 600 тысяч записей, на что ушло 51730 секунд, а размер бызы получился 300,1 Мб. До плутора миллионов решил тестовый дамп не качать, а просто прикинуть на основании предшествующих записей, сколько на это уйдет времени.

Не знаю на сколько верно такое предположение, но.....
Если предположить, что время добавления каждых 50000 записей возрастает в равномерной геометрической прогрессии....
То в приведенных данных каждые новые 50000 добавляются в среднем на 18,595% времени дольше, чем предыдущие....
Следовательно, при добавлении 1,5 млн. записей (подключаем эксель), последние 50000 будут добавляться 165408,5 секунд, а общее время добавления всех 1,5млн составит 1057688 секунд или 12 суток, 5 часов и еще с копейками.
_______
Экселевский файл во вложении.

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

Спасибо за анализ!

CMS не ваша, но доступ к структуре БД у вас же есть?
Попробуйте отрубить индексы, инсертнуть, а потом восстановить индексы. Должно быть значительно быстрее.
Или это CMS установленная на хостинге и идущая в нагрузку к хостинг-плану?

Доступ к БД есть.

Проиндексированную базу я полностью удалил и все установил заново, так что приведенные данные относятся к непроиндексированной базе.

Просто она такая мудреная и потому медленная.

Я про структуру БД...
Например если в базе есть таблица

CREATE TABLE `catalog` (   `id_catalog` int(11) NOT NULL,   `name` tinytext NOT NULL,   PRIMARY KEY (`id_catalog`) ) ENGINE=MyISAM DEFAULT CHARSET=cp1251

, то ее индекс будет обновляться по мере добавления данных, после каждого оператора INSERT, что заметно замедлит процесс.

Но если сперва выполнить

ALTER TABLE catalog DROP PRIMARY KEY

, т.е. удалить индекс, то вставка будет вестись без индексирования и быстро. А после окончания вы проиндексируете базу один раз командой

ALTER TABLE `catalog` ADD PRIMARY KEY ( `id_catalog` ) ;

, чем вернете структуру в исходное состояние.

Надеюсь, cheops меня поправит, если я не прав.

Интересная идея! Надо попробовать...

>А в данном случае импорт идет в базу типовой CMS.
В Bitrix? В инфоблоки? Или уже другую CMS используете?

Я гоняю всех трех лидеров - и Битрикс, и HostCMS, и UMI.CMS. В этом отношении они примерно одинаковые, но Битрикс самый тормозной и малохольный (по импорту).

Пока что импорт из CSV.

>В этом отношении они примерно одинаковые, но Битрикс самый тормозной и малохольный (по
>импорту).
Ага, плата за архитектуру... можно пробоваться вынести критичные инфоблоки в отдельные таблицы - должно быть побыстрее. Как вам, кстати, UMI?

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

В общем, там упор на рекламу, а не на суть, и это мне не нравится. Даже техподдержка называется "Служба заботы".

А вот хостинг у них очень хороший! Пожалуй, самый лучший из всех, что я знаю. И быстрый, и гибкий в настройках, и ресурсов много, и техподдержка замечательная - для любой CMS будет хорошей площадкой.

Хм... с Bitrix может и разберешься, но приходится перелопатить тонны документации, причем документация для редактора по объему чуть не больше, чем документация для разработчика (и черта с два чего запрограммируешь, пока не перелопатишь обе). При разработке явно хотели и редакторам и программистам угодить... лично, я от Bitrix не в восторге, учитывая, что ориентируются они на массовый хостинг, не задействуя никаких нововведений PHP... да что там PHP, их визуальный редактор использует стили .header, .r и .l, которые задействует каждый второй верстальщик, в результате все рассыпается (вот не уж-то сложно ввести пространство имен для стилей редактора, пусть тысячи разработчиков сайтов мучаются, чем небольшая команда Bitrix). Сами шаблоны - это дикая смесь HTML и PHP, в которой понятное дело преобладает табличная верстка... да еще визуальный редактор использует <font>. Утверждают, что это дескать шаблоны, которые и трогать не приходится, так как это шаблоны... фактически же вся разработка сосредотачивается в их редактировании (особенно, если верстка внешняя, а не специально под Bitrix заточена).

PS Жалко, что на UMI такой отзыв, я её на днях поковырять собирался, вероятно, придется отложить.

Жалко, что на UMI такой отзыв, я её на днях поковырять собирался, вероятно, придется отложить.

У Вас такой огромный опыт, что Вы наверняка легко и быстро сможете понять самое главное. Все таки, UMI - это "восходящая звезда"... Без их участия давно уже не проходит ни одно мероприятие, так что эту систему наверняка раскрутят.