Целесообразно ли использовать обрабатывающий демон с очередью?



Всем привет! Хотим вынести часть функциональности проекта php в обрабатывающий демон с очередью (и блэкджеком). Задача - довольно оперативно пробежаться по записям в БД (количество записей может варьироваться от 20 до 300000) и обработать их, создав новые записи. php прекрасно справится с 2000 записями, а при больших он будет кушать память и время.Мы дальше также будем часть функционала также выносить в демоны - в связи с этим вопрос - что сейчас популярно для обработки больших массивов данных, и какие подводные камни могут быть у тех или иных технологий. C, LUA, Golang - что использовать что бы потом не было мучительно больно ?
972   48  

Comments

  1. Павел Сидорович
    Павел Сидорович 5 лет назад
    "довольно оперативно" это сколько? может проблема в хранилище, а не в обработке?
  2. Сергей Аксёнов
    Сергей Аксёнов 5 лет назад
    У меня есть принцип: если какую-то задачу можно решить, не расширяя зоопарк - надо её так и решать. Проблема откушивания памяти решается аккуратным написанием логики курсора, чтобы не всасывал сразу 300к записей, а брал порциями по 5-10к, условно. Проблема скорости на сегодняшний день обычно лежит не в домене ЯП, а в БД, СХД и коннективити.
    • Сергей Аксёнов
      Сергей Аксёнов 5 лет назад
      Ну то есть BulkWrite скорее всего решит проблемы скорости. Проверено на связках PHP+Postgres и PHP+Mongo.
  3. Андрей Викторов
    Андрей Викторов 5 лет назад
    Не, выгрузка из БД и запись набора инсертов - это не проблема. Проблема в обработке max_memory и.т.д. Ну т.е. чую что это не задача для пыха, там надо обрабатывать содержимое записей по регуляркам. Довольно оперативно - это не кушать много памяти и пара тройка секунд на обработку.
    • Сергей Аксёнов
      Сергей Аксёнов 5 лет назад
      Андрей Викторов что значит "обработка max_memory"?
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      Сергей Аксёнов значит при определенном количестве записей в зависимости от их содержимого php скрипт съест всю память отведенную и свернется в трубочку, (никого об этом не известив). Ну не способен он на такие обработки. Даже если убрать оттуда ORM и все делать в ассоциативных масивах.
    • Михаил Буйлов
      Михаил Буйлов 5 лет назад
      Любой язык свернется в трубочку при определенных объемах. Современные версии пхп жрут не сильно больше памяти , чем похожие языки. Сворачивание пхп в трубочку можно мониторить (писать успешность выполнения скрипта, например). Но если вам надо это правда быстро - Используйте тарантул. Он умеет прикидываться Mysql, В нем есть lua. На худой конец - напишите хранимую процедуру в самом mysql(но я бы не стал)
    • Сергей Аксёнов
      Сергей Аксёнов 5 лет назад
      Андрей Викторов мне кажется, вы плохо умеете готовить ваш PHP. Для начала, у консольного PHP нет ограничения по памяти, проверьте - в /etc/php/7.2/cli/php.ini должно быть memory_limit = -1 Съесть всю память в системе может код на любом другом ЯП, это не свойство ЯП, а свойство данных, хранение структур в памяти не сильно отличается между языками. В общем, мне больше нечего добавить к тому, что я уже сказал.
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      Михаил Буйлов переход на tarantul мы пока откладываем, завязываться на возможности БД и хранимых процедур не у нас и так там куча хранимок устали уже, хотим потом появится что то новое придется искать новых специалистов.Зря я про БД упомянул - есть массив со строками варьируемой длины как в ширину так и в длину его надо обработать и создать на основании него другой массив.PHP не подходит вот ж... чую.
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      Сергей Аксёнов услышал, но я боюсь, первую версию мы так и делаем.
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      PHP обрабатывает регулярки через нативный PCRE. Если регулярки не динамические — PHP их кеширует, и работает оно так же как в любом другом ЯП. Наоборот, в Go его стандартные регэкспы могут не решать вашей проблемы или работать сильно медленнее.Если что, против этого либо подключают PCRE либу, либо вместо регулярок пишут нативные обработчики.
    • Григорий Кочанов
      Григорий Кочанов 5 лет назад
      Если ваш обработчик ошибок не умеет обработать и записать в лог ошибку падения по памяти - посмотрите, как это сделано в фреймворках. Даже yii это умеет.
    • Илья Ширшов
      Илья Ширшов 5 лет назад
      Можете вызывать gc насильно.
  4. Igor Podlesny
    Igor Podlesny 5 лет назад
    горизонтальное масштабирование — если там очереди™, what else?
  5. Egor Rukhvadze
    Egor Rukhvadze 5 лет назад
    Golang, Python
  6. Андрей Якубовский
    Андрей Якубовский 5 лет назад
    Задача похожая на медиатор. Решал подобную на C++. Предыдущее решение на python 8 часов, текущее на С++ 15 минут, объем данных 400 Гб.
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      С точки зрения медиатора, как то так, да - он должен контролировать очередь и следить за количеством одновременных выполнений, и оперативкой. Т.е. если запрос в очереди - и память уже на исходе, не пускать его в обработку пока не завершатся предыдущие.
    • Андрей Якубовский
      Андрей Якубовский 5 лет назад
      ну с точки зрения С\С++ с контролем памяти\нитей\нагрузки готово решения я не нашел, golang в этом случае будет хорошим выбором
    • Igor Podlesny
      Igor Podlesny 5 лет назад
      Да че уж тут решение искать, если слэш найти не удается(?)
  7. Николай Рыбин
    Николай Рыбин 5 лет назад
    +1 за голанг, очень скорость обработки могут повысить горутины. По памяти будет выигрыш, но не факт, что в разы
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      а там есть механизм контроля за работой горутин, например если она откушала много памяти - остановить ее, выполнить остальные а потом поставить в очередь?
    • Николай Рыбин
      Николай Рыбин 5 лет назад
      Можно изначально контролировать количество горутин + убивать по таймауту. По памяти контролировать горутину сложно, можно например по внешнему тригеру убивать горутины, а внешним тригером может быть проверка памяти всего процесса
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Андрей, вам действительно нужно контролировать горутины? Заранее по задаче не оценить, сколько памяти она съест?
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      Vitaly Levchenko можно оценить только для этого нужно дернуть селект лишний
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Андрей, ну и ладно, если селект в hot data.
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      А по сути, то Go приложение знает, сколько оно прямо сейчас ест памяти. Без разделения по горутинам, но для реализации ограничения расхода памяти это не нужно. Если расход памяти задачи стабилен, это быстрое и надёжное решение.
  8. Vitaly Levchenko
    Vitaly Levchenko 5 лет назад
    Если вычисления не слишком ёмкие, то безразлично на чём делать. PHP имхо лучше — код уже написан.Скорее всего у вас затык в том, как вы читаете или пишете данные. Или в том, как запускаете обработчики.
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      вычисления могут быть очень ёмкие. запросы на вычисления могут появляться внезапно и много а могут и вообще длительное время не появляться. хочется что бы это внезапно не обваливало сервер и умело себя контролировать в случае большой очереди. Да, надо посмотреть на го
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Андрей, любой крупный PHP сервис решал вопрос контроля нагрузки на обработку очереди. Чаще всего достаточно ограничить число обработчиков. И внезапные задачи просто накапливаются в очереди, ничего не ломая.
  9. Денис Габайдулин
    Денис Габайдулин 5 лет назад
    kafka + spark.Сразу получаете масштабирование, отказойчивость (fault tolerance), какую хотите семантику (at least once, exactly once).p.s. Хадуп не нужен в этой схеме. Kafka также опциональна.
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Не-не-не. Давайте сразу Хадуп, крупный кластер и команду из десятка инженеров! Главное, чтобы инвесторы не жадничали!
    • Илья Аверьянов
      Илья Аверьянов 5 лет назад
      Или kafka + kafka-streams
    • Денис Габайдулин
      Денис Габайдулин 5 лет назад
      Кстати вот вы сметесь, а первый мой "кластер" состоял из одного мастера и двух воркеров (spark standalone), которые физически располагались на двух commodity серерах. Читал я из jdbc/cassandra/logs, а писал в cassandra. Использовался для adhoc анализа и для анализа экспериментов в мелком проекте.
  10. Андрей Викторов
    Андрей Викторов 5 лет назад
    Все, тему закрываем, спасибо большое! Итог. Сначала юзаем php и смотрим как оно себя ведет, если все плохо пишем на golang.
  11. Григорий Кочанов
    Григорий Кочанов 5 лет назад
    У PHP есть несколько расширений, с которыми можно оптимизировать и распараллелить работу с данными. Можно посмотреть на swoole с корутинами, каналами, heap и буферами. Загляните в PECL - https://pecl.php.net/packages.php?catpid=27
  12. Алексей Паршуков
    Алексей Паршуков 5 лет назад
    300 000 не очень много. Я бы сначала посчитал математику подключения новой технологии в проект. Скорее всего купить сервер с памятью будет дешевле.
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      Это триста тысяч абзацев текста. Как пример сложности (ни в коем случае не это ) - на входе книжка Л.Толстого "Война и Мир", нужно пробежаться по всем абзацам, найти упоминание Наташи Ростовой и в этих абзацах заменить Наталью Ростову например на Таню Буланову, в нужных падежах. И все новые абзацы где были изменения - вернуть. (В рамках одной транзакции, а не по частям.)
    • Павел Сидорович
      Павел Сидорович 5 лет назад
      Андрей Викторов если это все на неподготовленных структурах данных и через регулярки, то тогда это будет проблема не только на пхп.
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      Павел Сидорович слава Богу структуры немного размечены тегами, и Наташа Ростова в спанах.
    • Павел Сидорович
      Павел Сидорович 5 лет назад
      Андрей Викторов eval? ) ну или какой еще способ шаблонизации без регулярок или замен? с утечкой памяти вопрос можно решить при грамотном профилировании и если это не косяк сторонней библиотеки. у нас пхп форкается и живет месяцами
  13. Иван Ремень
    Иван Ремень 5 лет назад
    Тарантул либо голанг, зависит от подробностей задачи.
    • Андрей Викторов
      Андрей Викторов 5 лет назад
      Иван Ремень тарантул - это субд, голанг это язык. проблема не в бд и не хранении а в грамотной обработке без последствий. но тут говорят что зоопарк пока не надо разводить, попробуем на пыхе.
    • Иван Ремень
      Иван Ремень 5 лет назад
      Андрей Викторов в тарантуле помимо субд ещё и отличный Lua application server. Вычисления близкие к данным по определению быстрее, чем гонять данные по сети. Ну и то, что в диск гарантированно не придётся идти даёт отличное ускорение. Если не хочется менять хранилище, то Гошка хорошо отработает с мускулем, но на тарантуле быстрее.
    • Иван Ремень
      Иван Ремень 5 лет назад
      Андрей Викторов но да, без разведения зоопарка вобще идеально будет)
  14. Mons Anderson
    Mons Anderson 5 лет назад
    Tarantool
  15. Андрей Викторов
    Андрей Викторов 5 лет назад
    Как же здесь много поклонников тарантула :))
    • Yury Pachin
      Yury Pachin 5 лет назад
      Victor Poluksht а похоже на секту )
  16. Yury Pachin
    Yury Pachin 5 лет назад
    Берите чего помоднее, чего уж там.