H
А что делать когда в бд нужно загрузить из к примеру файла эксель 100 000 строк с 50 столбцами, все данные + делать проверками к примеру на наличие записи? Сейчас это проходит больше чем за 10 - 20 минут.
Size: a a a
2020 May 29
H
От меня требуют это сделать меньше чем за минуту
VS
за минуту врядли грузанёшь
v
А что делать когда в бд нужно загрузить из к примеру файла эксель 100 000 строк с 50 столбцами, все данные + делать проверками к примеру на наличие записи? Сейчас это проходит больше чем за 10 - 20 минут.
Делить 100 000 на чанки, например по 200 записей, делать комбинированный запрос на связанный ID в БД используя оператор IN и получать уже существующие записи в БД, к примеру только их связующий ID.
Самим php проверять существование по уже загруженной записи и формировать 3 коллекции: INSERT, UPDATE, DELETE.
Далее в конце чанка делать по 1 запросу на каждое действие.
Таким образом всех видов запросов на чанк будет по примерно по 1шт.
SELECT - 1
INSERT - 1
UPDATE - 1
DELETE - 1
Делать комибинированный UPDATE изредка бывает сложно, так как необходимо использовать конструкцию CASE .. WHEN … THEN, но это в принципе неплохой вариант)). В противном случае можно делать множество UPDATE записей в LOW PRIORITY.
Самим php проверять существование по уже загруженной записи и формировать 3 коллекции: INSERT, UPDATE, DELETE.
Далее в конце чанка делать по 1 запросу на каждое действие.
Таким образом всех видов запросов на чанк будет по примерно по 1шт.
SELECT - 1
INSERT - 1
UPDATE - 1
DELETE - 1
Делать комибинированный UPDATE изредка бывает сложно, так как необходимо использовать конструкцию CASE .. WHEN … THEN, но это в принципе неплохой вариант)). В противном случае можно делать множество UPDATE записей в LOW PRIORITY.
H
Делить 100 000 на чанки, например по 200 записей, делать комбинированный запрос на связанный ID в БД используя оператор IN и получать уже существующие записи в БД, к примеру только их связующий ID.
Самим php проверять существование по уже загруженной записи и формировать 3 коллекции: INSERT, UPDATE, DELETE.
Далее в конце чанка делать по 1 запросу на каждое действие.
Таким образом всех видов запросов на чанк будет по примерно по 1шт.
SELECT - 1
INSERT - 1
UPDATE - 1
DELETE - 1
Делать комибинированный UPDATE изредка бывает сложно, так как необходимо использовать конструкцию CASE .. WHEN … THEN, но это в принципе неплохой вариант)). В противном случае можно делать множество UPDATE записей в LOW PRIORITY.
Самим php проверять существование по уже загруженной записи и формировать 3 коллекции: INSERT, UPDATE, DELETE.
Далее в конце чанка делать по 1 запросу на каждое действие.
Таким образом всех видов запросов на чанк будет по примерно по 1шт.
SELECT - 1
INSERT - 1
UPDATE - 1
DELETE - 1
Делать комибинированный UPDATE изредка бывает сложно, так как необходимо использовать конструкцию CASE .. WHEN … THEN, но это в принципе неплохой вариант)). В противном случае можно делать множество UPDATE записей в LOW PRIORITY.
Сколько по времени может мне обойтись?
v
Сколько по времени может мне обойтись?
Все зависит от нагрузки на бд, использование индексов и внешних ключей.
v
Когда базу ФИАС импортировали первые 500тыс загрузилис за примерно 3 минуты.
До 20 миллионов скорость сохранялась более менее, после 20 миллионов уже стало заметно тормозить ))
Но это были только операции записи. По глупости забыли предварительно грохнуть индексы и на транзакцию отключить проверку внешних ключей
До 20 миллионов скорость сохранялась более менее, после 20 миллионов уже стало заметно тормозить ))
Но это были только операции записи. По глупости забыли предварительно грохнуть индексы и на транзакцию отключить проверку внешних ключей
H
Когда базу ФИАС импортировали первые 500тыс загрузилис за примерно 3 минуты.
До 20 миллионов скорость сохранялась более менее, после 20 миллионов уже стало заметно тормозить ))
Но это были только операции записи. По глупости забыли предварительно грохнуть индексы и на транзакцию отключить проверку внешних ключей
До 20 миллионов скорость сохранялась более менее, после 20 миллионов уже стало заметно тормозить ))
Но это были только операции записи. По глупости забыли предварительно грохнуть индексы и на транзакцию отключить проверку внешних ключей
За сколько в итоге они все загрузили?
v
За сколько в итоге они все загрузили?
Средствами PHP - за 5 дней 30 миллионов с поддержкой индексов и внешних ключей))
v
Потом мы стали умнее и сделали конвертер xml базы фиаса в sql на python.
В итоге получили дамп с 30 миллионами записей за 30 минут, и за 2 часа с отключенными индексами и внешними ключами импортнули.
Потом еще около 1 часа создавались индексы и проверялись ключи.
В итоге получили дамп с 30 миллионами записей за 30 минут, и за 2 часа с отключенными индексами и внешними ключами импортнули.
Потом еще около 1 часа создавались индексы и проверялись ключи.
H
Простите, я не совсем понял что повлияло на такую большую разницу во времени.
v
Простите, я не совсем понял что повлияло на такую большую разницу во времени.
В основном индексы и внешние ключи. Но и небольшие тормоза php при стрим парсинге xml документа объемом больше 6 гб.
При записи в таблицу с индексами, БД сразу их перестраивает, с учетом что у нас было много индексов и не только первичный, а если существует внешний ключ с неотключенной проверкой то каждая запись проверяется на корректность внешнего ключа - это тормозит процесс записи.
При записи в таблицу с индексами, БД сразу их перестраивает, с учетом что у нас было много индексов и не только первичный, а если существует внешний ключ с неотключенной проверкой то каждая запись проверяется на корректность внешнего ключа - это тормозит процесс записи.
H
Теперь понял)
S
Всем привет) ребят был какой то плагин, у которого был виджет для панели управления. Он показывал входящие запросы от клиентов, ни кто не помнит про этот плагин
A
Если что, есть русская инструкция по созданию плагина) https://octoclub.ru/d/32-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BF%D0%BB%D0%B0%D0%B3%D0%B8%D0%BD%D0%B0-%D1%87%D0%B5%D1%80%D0%B5%D0%B7-artisan-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D1%8F-%D0%B4%D0%BB%D1%8F-%D0%BD%D0%BE%D0%B2%D0%B8%D1%87%D0%BA%D0%BE%D0%B2-%D1%87%D0%B0%D1%81%D1%82%D1%8C-1
++ еще раз спасибо, наконец добил
A
Alex245235 (28.23) увеличил карму ReaZzon (3138.23)
NK
++ еще раз спасибо, наконец добил
Красавчик )
🇺L
Привет
S
Делить 100 000 на чанки, например по 200 записей, делать комбинированный запрос на связанный ID в БД используя оператор IN и получать уже существующие записи в БД, к примеру только их связующий ID.
Самим php проверять существование по уже загруженной записи и формировать 3 коллекции: INSERT, UPDATE, DELETE.
Далее в конце чанка делать по 1 запросу на каждое действие.
Таким образом всех видов запросов на чанк будет по примерно по 1шт.
SELECT - 1
INSERT - 1
UPDATE - 1
DELETE - 1
Делать комибинированный UPDATE изредка бывает сложно, так как необходимо использовать конструкцию CASE .. WHEN … THEN, но это в принципе неплохой вариант)). В противном случае можно делать множество UPDATE записей в LOW PRIORITY.
Самим php проверять существование по уже загруженной записи и формировать 3 коллекции: INSERT, UPDATE, DELETE.
Далее в конце чанка делать по 1 запросу на каждое действие.
Таким образом всех видов запросов на чанк будет по примерно по 1шт.
SELECT - 1
INSERT - 1
UPDATE - 1
DELETE - 1
Делать комибинированный UPDATE изредка бывает сложно, так как необходимо использовать конструкцию CASE .. WHEN … THEN, но это в принципе неплохой вариант)). В противном случае можно делать множество UPDATE записей в LOW PRIORITY.
Проще залить ВСЕ во временную таблицу (временную временную или постоянную, чтобы память не убивать).
Приджойнить ее к основной, обновив доп поле айдишником существующей записи.
Приджойнить ее к основной, обновив доп поле айдишником существующей записи.
🇺L
Скажите, а
{% partial account ~ '::signin' %} - как должна выглядеть запись, чтобы подставить туда свой signin.htm, а не дефолтовый из плагина?