Forum Webscript.Ru
Общие => Базы данных => Тема начата: kosm от 04 Марта 2004, 10:37:28
-
Ребят, дайте плиз дельный совет, как на практике решаются такие задачи?
1.Есть простая табличка с полями "наименование" и "наличие", записей порядка 20000.
2.Есть некий файл (CSV), с теми же двумя полями, который пользователь кладет на сервер через форму, записей порядка 1000.
Как можно наиболее оптимально и быстро отметить то, что изменил пользователь в файле, который загрузил на сервер?
Первое что приходт на ум, это построчный UPDATE из файла CSV в цикле. Но это порядка 1000 записей, и даже если на запись по 1сек, что не так, то это уже приличное время, за которое апаа не успевает его выполнить и отваливается по тайм ауту :(
Второй вариант (http://forums.webscript.ru/showthread.php?s=&postid=86903#post86903) мне когда подсказал уважаемый Alexandr, теоретически выглядит красиво.
Данные из CSV файла загружаются во временную табличку LOAD, а потом UPDATE головной таблици по условию из временной.
Вопрос, делал ли кто уже подобное? На сколько это действительно быстро и реально ли вообще?
PS: В обоих случая для ускорения процесса можно иметь еще одно поле "дата изменения" и включаеть еще и его в условие.
Ваше мнение, уважаеиые специалисты?
-
Для вставки есть такая штука как расширенная вставка(когда в один запрос можно много записейдобавить), может для апдейта тоже есть. Хотя не уверен что это ускорит дело.
-
Z@
Что за расширенная вставка?
Если делать по строчно, то наверно думаю большой выгоды не будет. Тут именно большой прирост в скорости нужен, чтобы укладываться в 30 сек, ну или чуть по-больше, если удасться с хостингом договориться увеличить таймаут.
PS: Дасть ли чего разбиение по транзакциям? Ведь если я явно не указваю START TRANS, то он для каждой опирации делает COMMIT?
-
Поправочка ко второму варианту с временной таблицей.
Сейчас посмотрел спецификацию по команде UPDATE MySQL - похоже что с помощью ее не свести будет две таблицы :( Множественные таблице в этой конструкции стали поддерживаться только с 4-й версии MySQL, у меня же 3.23.41 :(
Может конечно можно как нить извратиться, но пока не знаю как...
Давайте ребят, подключайтесь к обсуждению... Тема ведь наверно довольно злободневная и все борятся за скорость :) И навернякак уже кто-то на чем-то остановился?
PS: Еще вариант, который останется, если ничего не найду, так это запуск скрипта локально по крону... и пущай себе там пыхтит по тихоньку.
-
По первому варианту (построчно): не думаю, что будет работать более 1-2 сек. (у меня используется этот вариант для обновления прайсов http://www.autodealer.ru/price/part/ - бегу по каждой строчке, чищу, вставляю), даже дома (на винде) не более 5 сек.
Второй вариант, более реален (конечно если надо вставить 1 в 1), ты его хоть попробуй....
kosm:
PS: В обоих случая для ускорения процесса можно иметь еще одно поле "дата изменения" и включаеть еще и его в условие.
Ваше мнение, уважаеиые специалисты?
Полный идиотизм
-
kosm:
у меня же 3.23.41
Делай так
REPLACE tbl SELECT * FROM tbl_for_up
-
Alexandr , рад видеть тебя! :)
По первому варианту: не совсем понял, у тебя весь процесс занимает 5 сек или одна строчка? Если строчка, то у меня примерно тоже, т.е. долго.
Второй вариант проверил - действительно быстро. На локальной машинке загрузка во временную табличку ~0,5 сек, а у хостера ~10сек, что вполне приемлемо.
Проверить перекачку по REPLACE как ты советовал на рабочей базе не получилось, т.к. я сам себя и всех окружающих ввел в заблуждение. Проблемма в том, что одна запись из CSV файла, может несколько раз фигурировать в записях БД (это я только сейчас выяснил, когда попытался сделать это поле UNIQUE, т.к. это обязательное требование для REPLACE).
Еще какие нить мысли есть?
-
kosm:
По первому варианту: не совсем понял, у тебя весь процесс занимает 5 сек или одна строчка?
Процесс:
1) юзер заливает файл (название детали, цена, валюта - разделитель таб.)
2) бегу по каждой строчке чищу название детали (трим, убираю лишние символы..., и т.д.), цену, валюту
3) для каждой строчки делаю инсерт в главную таблицу
Для ~5000 записей это ВСЁ занимает 1-2 сек. (у хостера на *nix\'e)
Кстати, основная таблица ~350000 записей....
kosm:
На локальной машинке загрузка во временную табличку ~0,5 сек, а у хостера ~10сек, что вполне приемлемо.
Ну и тормозной же хостер....
kosm:
Проблемма в том, что одна запись из CSV файла, может несколько раз фигурировать в записях БД (это я только сейчас выяснил, когда попытался сделать это поле UNIQUE, т.к. это обязательное требование для REPLACE).
kosm:
Есть простая табличка с полями "наименование" и "наличие", записей порядка 20000
Должна быть простая табличка с полями "id" (PRIMARY KEY), "наименование" и "наличие".
И такая табличка должна быть при любом варианте....
И CSV файл должен содержать id\'шники редактируемых строк.
-
Alexandr, хочу сразу извиниться - это я лоханулся :)
Только сейчас доперло, что индекса-то у меня по этому полю нет! Создал - стало работать на лок.машинке вместо 1.5-2 минут, 3 сек :)
Так что вопрос снимается - буду обрабатывать построчно.
Спасибо!