« Rev
@ru_modx   3776
Fwd »


Sergey_K
а это пиздец
Pavel
а это пиздец
и всякие значения типа 000000111111
Sergey_K
там просто ИНН заполняется из внешнего API а они гады иногда вместо инн шлют всякую лажу из символов.
ну так лажу из символов приводите к инту, будет пустая строка. и шлите в жопу
Pavel
UPDATE protocols p LEFT JOIN winners w ON p.inn = w.inn SET p.inn = w.inn
а тут наверное вот так: UPDATE protocols p LEFT JOIN winners w ON p.winner_id = w.id SET p.inn = w.inn ?
Sergey_K
ну наверное, я ваши поля не учел
Sergey_K
сделайте EXPLAIN <ваш запрос>
Sergey_K
Он вам покажет, что делать будет
Sergey_K
Скорее всего там мрак
Pavel
сделайте EXPLAIN <ваш запрос>
сделаю обязательно! как думаете прервать этот запрос сейчас и заново нормальный ваш поставить?
Pavel
чето я на вы перешел со всеми ) туплю наверное
Pavel
всё. прервал. сейчас буду химичить
Pavel
Скорее всего там мрак
плюс - в phpmyadmin через закладку sql лучше же не делать такое а лучше сразу через консоль на компьютере подобное выполнять ?
Sergey_K
всё. прервал. сейчас буду химичить
ну сделай джойн по 1000 строк, я не помню, лимит там можно ставить? думаю да
Sergey_K
сравни эксплейн по первому запросу и второму
Sergey_K
думаю там лишние 50 минут и зарыты :)
Pavel
пипец..
Pavel
вот так плавно приближаемся в bigdata )
Sergey_K
не понял
Pavel
не понял
да это я оправдываюсь. за свою неграмотность в подобных вещах связанных в БД. привык что выборки маленькие - максимум несколько десятков тысяч записей. а тут пару лямов.
Pavel
и уже приходится следить за производительностью.
Sergey_K
пара миллионов это не очень много
Sergey_K
когда я пришел в одну телеком-контору, там один товар импортировался 3 минуты
Pavel
пара миллионов это не очень много
ну вот я наслушался на тостере что это вообще все ерунда. когда порядк 10к записей в день добавляется.
Sergey_K
ну пока у тебя пара десятков тысяч, то наверное да
Sergey_K
а дальше уже на шару пролететь не получится
Sergey_K
одна запись
Sergey_K
там был джойн 4 талиц
Sergey_K
в одной было 2 миллиарда записей
Sergey_K
во второй 200 миллионов
Sergey_K
в третьей 2 миллиона и четвертая чота типа сто тысяч
Pavel
одна запись
я когда пишу загрузкичи в модх из разных файлов, то замечаю, что прогрессия скорости падает со временем. чем если бы порциями по 500 записей закидывал за раз.
Sergey_K
модх сам тоже странный
Sergey_K
Операция типа getObject('msOrder', 4232) Занимает 6кб памяти
Sergey_K
Добавляешь $order->getOne('Address') и памяти уходит 36кб
Pavel
модх сам тоже странный
но вообще такая тенденция и в других системах есть. Те же 80 тыщ товаров раньше загружал в другую Базу данных. Первая сотка быстрее, чем за минуту загружалась. а дальше - дольше. Когда уже несколько тысяч записей добавлено, то медленно-медленно начинает работать. И недавно еще 6300 товаров в модх загружал. оставил на всю ночь. прогрузилось порядка 4000. Начал доробить - всё стало быстро.
Pavel
Добавляешь $order->getOne('Address') и памяти уходит 36кб
а как думаешь из-за того что память забивается начинает падать скорость? ведь шурстить по всей базе не заставляет никто программу. а все равно при добавлении начинается замедление с ростом количества добавленных позиций. Хотя там же процессоры модх юзаешь. они наверняка прежде, чем добавить поиск по всей базе делают.
Pavel
а как добавлял? через api modx?
через процессоры.
Pavel
но не просто товар, а товар и его характеристики, ТВ поля - всё за один проход. Потом разделил скрипт на несколько частей. Сначала товар добавляется. потом уже опции, потом тв поля
Sergey_K
Надо конкретику смотреть
Sergey_K
ТВ вообще проклятая сущность :))
Pavel
ТВ вообще проклятая сущность :))
ну это факт. но если отдельным циклом прогнать заполнение ТВ, то норм. а точнее отдельным скриптом
Nikolay
через процессоры.
как минимум alias'ы генерятся, в базе ищутся дубли по всем записям
Sergey_K
Процессоры, я подозреваю, просто не заточены на массовые опрации
Pavel
как минимум alias'ы генерятся, в базе ищутся дубли по всем записям
проклятье. да. но что факт, то если по 500 или по 200 записей за раз добавлять, то суммарный выигрыш от этого ощутимый. чем если за один цикл сразу тыщ 10 товаров добавить через процессоры.
Nikolay
вот это конечно интересно...
Pavel
вот это конечно интересно...
память может быть забивается.
Pavel
я х.з.
Nikolay
если скрипт превысит память то он по идее отрубится
Pavel
просто для себя сделал такое - каждый раз проходим цикл с нуля пока не дошли до нужной записи в файле, которой еще нет в базе с и нее начинаем. Считанные секунды занимает пройтись по всем записям и проверить есть ли с таким, к примеру артикулом товар. если есть, то continue.
Sergey_K
скорее всего там идут локи в базе
Sergey_K
потому что, простите, все то же full table scan
Sergey_K
у тебя php лупит запрос за запросом и если там один блокирует со сраными индексами, то все встанет колом, а сверху накидывается еще 500
Pavel
потому что, простите, все то же full table scan
который включается при добавлении?
Nikolay
а какой именно процессор кстати?
Sergey_K
при поиске
Sergey_K
а лок при обновлении
Sergey_K
и если там полнотабличный поиск, то будет ждать
Sergey_K
тогда претензий к процессорам нет, я не прав, а БД просто говно
Sentinel
Мне тут подсказали, чтобы tv не грузить если их много, можно отдельную таблицу под них создать и тогда вызов будет быстрым
Sergey_K
если будет кривой индекс, то будет то же самое
Sergey_K
это все просто посмотреть логами
Sergey_K
по времени запросов
Sergey_K
я про то, чтобы писать в лог информацию
Sergey_K
но explain тоже тебе поможет
Sergey_K
ты запустил? что говорит?
Pavel
я про то, чтобы писать в лог информацию
где дата начала и дата окончания записи фиксируется?
Sentinel
ну это херь
не знаю, был успешный опыт
Sentinel
проверю отпишу 😉
Pavel
ты запустил? что говорит?
нет еще. workbench только инсталлировал
« Rev
@ru_modx   3776
Fwd »