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

Достижения

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

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

Все теги (72)

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

Все ответы (82)
  • Как сделать 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. Все это складыватся в переменную
    Что?! Зачем это понадобилось? Это как если бы в строительстве ставили кирпичный дом на фундамент целиком, а не по частям.
    Ответ написан
  • В чём преимущества и недостатки установок через apt и snap?

    romesses
    @romesses
    Backend инженер
    shurshur хорошо описал. Добавлю от себя:
    snap-пакет - когда нужна новизна версий и более частые выпуски новых версий. Своего рода, Docker, только для пакетов приложений.
    apt-пакет - когда нужна стабильность и официальный источник. Такие пакеты обновляются только с обновлением версии ОС.

    Допустим, при смене Debian stable на Debian testing - затрагивает всю ОС целиком, но не хочется терять стабильности системы. И тогда, если хочешь новую версию GIMP, которой нет в apt-репозитории - установи snap пакет. Вся стабильность ОС остается.
    Можно даже несколько свежих версий ПО установить, не умаляя стабильности в целом.
    Ответ написан
  • Как лучше реализовать данную архитектуру?

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

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

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

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

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

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

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