Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Из 1С можно выгружать только измененные объекты, используя планы обмена или версионирование, незачем гонять весь каталог в 26000 товаров каждый раз при загрузке. А маленький файлик с сотней позиций и в xml загружался бы в течении доли секунды
Да, выгрузка только изменений у нас тоже реализована. Статья именно о сокращении времени полной выгрузки.
Тоже решали подобную задачу. Приходится часто выгружать БД из 1С. Сейчас на выгрузку базы уходит 3-4 часа. А по изменениям добились производительности 5000 объектов /мин. Тут описывали подход: habrahabr.ru/company/Centrobit/blog/140901/
Все хотим замутить выгрузку 1млн. объектов и замерить результаты…
Все хотим замутить выгрузку 1млн. объектов и замерить результаты…
я эту задачу решал 10 лет назад, путем формированием собственного xml, который весил раз в двадцать пять меньше CommerceML. Время парсинга этого файла у мменя занимало не более минут. Был каталог нескольких тысяч наименований.
Далее, я пытался сохранять предыдущие товарные позиции и слал только дифы в том же xml. Благо, я использовал msxml как инструмент создания xml и транспорт. С Дифами выходило хуже, но что-то уже получалось.
Изменения (дифы) были следующие:
— товар временно отсутствовал
— изменилась цена
— добавилась новая товарная позиция.
в общем — это дела давно минувших дней и многие ньюансы уже позабылись.
что касается формата JSON то в эпоху РНР 3, всеми любимого нами расширения php_json не было, ну не текст же парсить :).
Далее, я пытался сохранять предыдущие товарные позиции и слал только дифы в том же xml. Благо, я использовал msxml как инструмент создания xml и транспорт. С Дифами выходило хуже, но что-то уже получалось.
Изменения (дифы) были следующие:
— товар временно отсутствовал
— изменилась цена
— добавилась новая товарная позиция.
в общем — это дела давно минувших дней и многие ньюансы уже позабылись.
что касается формата JSON то в эпоху РНР 3, всеми любимого нами расширения php_json не было, ну не текст же парсить :).
о… реликт см в конце phpconf.ru/history/2004/programm-3/
XML и JSON по природе своей не сильно отличаются, и такая кардинальная разница в скорости парсинга может случиться только в случае, если для разбора XML использовалась какая-то ну очень неудачная библиотека, которая жутко свопила на диск. То есть теоретически можно было и с XML работать также быстро — все дело только в библиотеке подходящей (конечно, если используемая платформа таковую поддерживает).
А статья интересная — всегда приятно, когда за счет смены инструментария на более подходящий, производительность ускоряется на порядки.
А статья интересная — всегда приятно, когда за счет смены инструментария на более подходящий, производительность ускоряется на порядки.
Ну видимо парсер такой был написан,
я только что закончил подобный исправлять раньше парсил 28-30 минут, памяти съедал 1,5 гигабайта
сейчас 120-140 секунд и памяти 93 мегабайта
Входные данные
XML 250-280 тыс. товаров
php 5.4
я только что закончил подобный исправлять раньше парсил 28-30 минут, памяти съедал 1,5 гигабайта
сейчас 120-140 секунд и памяти 93 мегабайта
Входные данные
XML 250-280 тыс. товаров
php 5.4
Благодарю за статью (вернее идею в ней).
Попросите Вашего 1Сника объяснить как он сделал свою часть. Мне было бы очень интересно, да и Вам вторая статья ;)
Попросите Вашего 1Сника объяснить как он сделал свою часть. Мне было бы очень интересно, да и Вам вторая статья ;)
Он не хабражитель, а испорченным телефоном я предпочёл бы не быть. Но в целом, для него это было просто формирование текстового файла определённой структуры с экранированием некоторых символов типа бекслеша. Собственно это для меня на выходе был JSON, а для него просто ещё один формат выгрузки в текст. Не уверен что тут есть о чём писать вторую статью.
Сделать сериализацию в json на 1С не так уж сложно. Можно самому написать за день, а можно готовое взять, например infostart.ru/public/119601/ или infostart.ru/public/61194/
А сам интернет-катало на чем реализован? Node.js? Что происходит после парсинга? Складывается в базу?
После парсинга данные сливаются в mySQL. Либо полной заменой, либо update если выгрузка только изменений. Сам движок сайта не на Node.JS. Там Perl.
А в перле нет встроенного парсера json? Если есть, то насколько он медленнее чем тот, что в node? А то может не имеет смысла добавлять новую технологию в стек?
Нативного вроде нет, хотя если я ошибаюсь — строго прошу не судить.
В случае с описанным проектом, Node.JS применяется не только для парсинга, поэтому речи о добавлении новой технологии в стек не идёт. К тому же мы давно уже используем эту «новую технологию» и страха перед ней не испытываем. Ну, разве что немного трепет.
В случае с описанным проектом, Node.JS применяется не только для парсинга, поэтому речи о добавлении новой технологии в стек не идёт. К тому же мы давно уже используем эту «новую технологию» и страха перед ней не испытываем. Ну, разве что немного трепет.
не ради холивара, а просто как вариант:
Обмен по xml или json это все хорошо и действительно быстрее стандартных средств (и более гибко), но, это все-равно медленно.
был опыт следующего обмена:
1) из 1С в промежуточную таблицу/БД (она так же может быть в облаке)
2) от туда в таблицу/БД с которой работает сайт
3) сайт берет из своей таблицы/БД
имхо, работа с бд всегда быстрее, чем с файлом.
Зачем делали промежуточную БД? За выгрузку и загрузку отвечали разные люди и что бы из 1с ничего не испортить в боевой бд сайта, решили сделать промежуточный узел
Обмен по xml или json это все хорошо и действительно быстрее стандартных средств (и более гибко), но, это все-равно медленно.
был опыт следующего обмена:
1) из 1С в промежуточную таблицу/БД (она так же может быть в облаке)
2) от туда в таблицу/БД с которой работает сайт
3) сайт берет из своей таблицы/БД
имхо, работа с бд всегда быстрее, чем с файлом.
Зачем делали промежуточную БД? За выгрузку и загрузку отвечали разные люди и что бы из 1с ничего не испортить в боевой бд сайта, решили сделать промежуточный узел
А при чём тут холивар? Вполне себе тоже обкатанная схема. У нас были проекты где 1С-ка по ODBC напрямую работала с базой сайта. Забирала заказы, обновляла номенклатуру. 1С 8-ка вполне работает с такими внешними данными представляя их внутри как справочники. У такой схемы есть свои нюансы, и она тоже имеет ряд минусов и особенностей, но в целом схема тоже ходовая. Просто рассматривать её надо не «вместо» а как «одно из» решений.
Совсем забыл. Есть же ещё вариант двустороннего обмена через SOAP. Тоже со своими за и против.
Работа с нативными для языка объектами всегда на порядки быстрее чем со сторонними сущностями, которые еще нужно парсить. У нас так же были ужасные тормоза, когда мы пытались обмениваться из 1С большими данными (двухсторонний обмен). Но как только выгрузку из 1С сделали в JSON, а загрузку в 1С-вском текстовом формате, так все сразу стало летать.
Когда интрегрировался с 1С, тоже выбрал json.
Вот моя рекурсивная функция, которая может преобразовать практически любую структуру данных 1С в json:
pastebin.com/HFaEaETX
Вот моя рекурсивная функция, которая может преобразовать практически любую структуру данных 1С в json:
pastebin.com/HFaEaETX
А вы заглядывали в изначальный XML, который формировала 1С?
Бывает такое, что программисты 1С сохраняют в формат XML именнос средствами 1С — и в итоге там столько «мусора», что объем чуть ли не в 2-3 раза увеличивается. Это примерно то же самое, что html из MS Word сохранять.
Исходя из постановки исходных данных, имеется 26000 позийций, средний размер позиции в XML можно принять в 2Кб, то есть 52Мб должно быть максимум. Поэтому и говорю, что возможно XML был не оптимальным.
Хотя при таких объемах JSON все равно оптимальнее — правильно сделали, что перешли.
Хотя в своем проекте NodeJS не использовал. Обходились cron-заданием на сервере, которое парсило залитый файл по FTP либо через SSH. Так же в случае SSH можно запустить скрипт удаленно.
В свое время тоже писал по этому поводу статью, но там более глобально: как вообще исключить ручную работу для обновления прайсов. Не сочтите за пиар — тем более, что писалось давно. Но эти «решения» работают в нонстопе уже лет 5 — так что кому-то может будет и интересно.
Бывает такое, что программисты 1С сохраняют в формат XML именнос средствами 1С — и в итоге там столько «мусора», что объем чуть ли не в 2-3 раза увеличивается. Это примерно то же самое, что html из MS Word сохранять.
Исходя из постановки исходных данных, имеется 26000 позийций, средний размер позиции в XML можно принять в 2Кб, то есть 52Мб должно быть максимум. Поэтому и говорю, что возможно XML был не оптимальным.
Хотя при таких объемах JSON все равно оптимальнее — правильно сделали, что перешли.
Хотя в своем проекте NodeJS не использовал. Обходились cron-заданием на сервере, которое парсило залитый файл по FTP либо через SSH. Так же в случае SSH можно запустить скрипт удаленно.
В свое время тоже писал по этому поводу статью, но там более глобально: как вообще исключить ручную работу для обновления прайсов. Не сочтите за пиар — тем более, что писалось давно. Но эти «решения» работают в нонстопе уже лет 5 — так что кому-то может будет и интересно.
Бывает такое, что программисты 1С сохраняют в формат XML именнос средствами 1С — и в итоге там столько «мусора», что объем чуть ли не в 2-3 раза увеличивается. Это примерно то же самое, что html из MS Word сохранять.
Не знаю, может у вас какие-то неправильные программисты, но XML, выгруженные средствами 1С, получается вполне нормальный.
Никакого мусора там и близко нет — только то, что программист захотел написать.
Если речь идет, конечно, о выгрузке XML, а не встроенном механизме распределенных баз — но он предназначен только для обмена 1С-1С. Или о сериализации объектов — но это тоже для других целей.
А как вы с изображениями работаете?
Там всё просто. При формировании выгрузки, изображения пакуются (без сжатия) в отдельный архив images.zip и также кладутся по FTP. Сервис на стороне сайта, после того как закончил с базой, просто распаковывает этот архив в каталог с изображениями. Если выгрузка частичная, то в архиве тоже только те картинки которые надо переписать. Данные о том, где какая картинка находится, и есть ли она вообще содержатся в поле каждой номенклатурной единицы.
Я в итоге пришел к прямому запросу в mysql из 1c. Уж очень удобная конструкция «on duplicate update»…
Мы делаем так: если большая база, то выгрузка CSV, разбитую на файлы (300-500 строк), дальше 1С дергает на стороне сайта обработчик этих файлов и сообщает о результате. Если нужны точечные корректировки, то используем свой формат на основе XML-RPC. Немного про формат можно почитать в нашем блоге. А вообще, ComerceML — это большая конфетка на палочке, вроде вкусная, но есть ее долго, в карман не засунешь, а выбросить жалко. Как все быстро в итоге у нас работает можно посмотреть в статье про создание ИМ из 1С за 7 минут.
Спасибо за статью. И про замечание по отладке. Свой формат иногда в выигрыше не только по быстродействию, но и по сроку разработки тех или иных фич. В нашем решении 1C-B2B (личный кабинет для партнеров), которое работает с 1С в режиме реального времени то же при кастомизации останавливаемся на json формате. Но когда дело доходит до интеграции с внешним сайтом, CommerceML звучит из уст руководителей ИТ-отделов как безальтернативный вариант. Ну и еще многим известная cms в придачу… А Вы красиво показали про уместность альтернативных технологий.
Вы не думали что у вас php прохо настроен на сервере? На тарифе для известной cms за 700р в мес 7 000 наименований обрабатываются сервером около 3 минут. Но не больше 10 точно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Node.JS и выгрузка каталога из 1С на сайт