Местоположение
Кипр

Достижения

Все достижения (4)

Наибольший вклад в теги

Все теги (83)

Лучшие ответы пользователя

Все ответы (100)
  • Возможно ли установить контейнер как сервер?

    romesses
    @romesses
    Backend инженер
    Если у вас вычислительные задачи на том контейнере, то есть немалая вероятность, что вам не удастся выиграть отказом от Docker.
    Пожалуй, разве только если вы запускаете контейнер слишком часто. Тогда это будет иметь смысл. Но тогда вы неправильно пользуетесь Docker.

    Попробуйте переселить тот контейнер на машину помощнее. А лучше даже распараллелить, увеличив количество экземпляров. В итоге, это, может быть, даже архитектурная задача.
    Ответ написан
  • Как сделать select из множества однотипных таблиц mysql?

    romesses
    @romesses
    Backend инженер
    На этот момент пока есть мысль выполнить разовую миграцию в одну целую таблицу при помощи хранимой процедуры, где будет алгоритм с 2-мя циклами (годам и месяцам), выполняющий INSERT INTO SELECT в новую таблицу.
    Причем, новая таблица должна быть построена с партициями по годам и месяцам, чтобы решить предполагаемую проблему с количеством данных, из-за чего и возникла идея разбить на множество таблиц.
    Альтернативно, можно выполнить дамп всех таблиц и "склеить" их при импорте.

    Собственно, выполнив миграцию, можно будет самым обычным способом производить выборки логов в нужном диапазоне дат.

    А, вообще, если у вас в логах хранятся метрики (история цифр), то подумайте о переходе на другие СУБД (аналитические, временных серий и пр.).
    Ответ написан
  • Какая инфраструктура должна быть для 24/7 парсера обновляющего БД?

    romesses
    @romesses
    Backend инженер
    Можно построить архитектуру приложений так, что API будет работать преимущественно в режиме чтения с СУБД.
    А другой процесс-воркер будет получать задачи через очередь сообщений и интенсивно писать в СУБД.
    В API вместо блокирующего ответ клиенту парсинга нужно сразу слать задание в очередь сообщений. Тогда соединения не будут удерживаться подолгу, а почти сразу будут закрыты по отправке в очередь.
    Все, что шлется в API для добавления в очередь, можно возвращать ответ 202 (Accepted).
    Как только воркер выполнит задачу, он обновит результат парсинга в БД. А тем временем, при обращении по API информация будет считана с БД без каких-либо блокирующих операций.

    То есть небольшой апгрейд состоит в схеме:
    APIs (write) -> MQ -> Worker(s) -> DB
    APIs (read) <-> DB
    Так легко добавить любой компонент в случае большой нагрузки.

    Ну и, необходимо замерять нагрузку, чтобы знать где узкое горлышко.
    Ответ написан
  • Что случится с программой (Go, Python, JS, PHP), если потребуется выделить память, а оперативная память в ОС закончилась?

    romesses
    @romesses
    Backend инженер
    Не имеет значения какой язык программирования будет использован. ОС, прежде всего, постарается обслужить аппетиты программы. И если доступной ОЗУ не хватит, полезет в файл/раздел подкачки (swap).
    В Линукс программу убьет защитный механизм OOM как только превысит определенный порог нагрузки на ресурсы системы. В Windows - не знаю, возможно просто не выделит критический кусок памяти для приложения.

    А если программа не умеет обрабатывать ошибки нехватки памяти, то она просто зависнет или рухнет с посмертным дампом.

    1. Из сети (диска) читается файл чанками
    Ух, замечательно!

    2. Все это складыватся в переменную
    Что?! Зачем это понадобилось? Это как если бы в строительстве ставили кирпичный дом на фундамент целиком, а не по частям.
    Ответ написан
  • Как лучше реализовать данную архитектуру?

    romesses
    @romesses
    Backend инженер
    Когда пользователь ждет пока агрегатор выполнит свою работу - это нехорошо. Правильнее, чтобы первый захотел некоторый контент и сразу мог получить его, прямиком с БД, а в идеале с кэша частозапрашиваемого контента.
    Для этого агрегатору необходимо регулярно выполнять свою работу независимо от посетителей, в фоне. Разумеется, пайплайн агрегатора должен заранее знать откуда заполучать контент или же одноразово получить список источников в начале, пройтись по ним и занести данные в БД. Затем регулярно обновлять с уже известных источников независимо от захода пользователей.

    Ну а если в БД пусто и позарез нужно выдать контент, то остается плохой вариант - дать пользователю ждать, пока контент не будет скачан, обработан агрегатором и получен обратно. В данном случае, при попытке получения контента можно выдать сообщение, что мол, "Извините-с-с, заходите чуток позже" или же "Подождите 5 сек, я быстро-быстро". А когда свежий контент уже был обработан, то отправить назад контент по SSE/WebSocket. Или же short polling просто клиент будет периодично выполнять запросы к API с надеждой получить контент.
    Вот здесь можно прочесть о способах взаимодействия

    Поэтому я вижу такую архитектуру при работе с пользователем:
    Client -> API -> cache/DB (read)
                 \
                  MQ
                     \
                   [Aggregator]
                          \
                          DB (write)

    Здесь [Aggregator] может означать как монолитный механизм скачивания-обработки, где все в одном, так и микросервисную архитектуру.

    По мне, так бизнес-логику на Go писать не очень удобно и ее лучше осуществлять на более высокоуровневых языках. Так что в Go я бы реализовывал механизм скачивания контента и извлечения нужных частей, а в Python/Ruby/Perl и т.д. - логику самого агрегатора (смешение, композитинг контента).
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (7)