Задать вопрос
  • Какой способ кэширования лучше?

    Встал вопрос - какой способ кэширования данных быстрее - MySQL с движком MEMORY, или же memcached?

    Быстрее memcached, незначительно. Удобнее redis, значительно.
    Ответ написан
    4 комментария
  • Как правильно организовать кэш приложения?

    jaxtr
    @jaxtr
    JavaEE/Spring-разработчик
    Иметь отдельное приложение для отслеживания актуальности кэша - дополнительная (ненужная) головная боль.
    Лучше будет реализовать корректное использование кэша:
    • При запросе записи, кэшировать возвращённый результат
    • При изменении/удалении записи, обновлять/удалять кэш
    • При бездействии кэша (невостребованности в течение некоторого времени), удалять


    В Java EE и Spring это всё настраивается аннотациями.
    Ответ написан
    Комментировать
  • Какую оптимальную архитектуру выбрать?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    ты не можешь кэшировать работу логики приложения -> тк ты сталкнешся с тем что кэш не соответствует реальной модели данных, и это приводит к ошибкам в сервисе (погугли инвалидация кэша), в итоге чтоб тебе держать кэш корректным тебе нужно будет еще больше нагрузки проводить и сверять корректность кэша с данными в БД.
    так что про кэширование логики забудь, кэширую простые готовые ответы пользователю, не поболее того.
    1. Для гиганского ускорения (в тысячи раз) тебе нужно перенести модель и логику в оперативную память, а для этого забыть про всякие там ноды хуеды, а перейти на статически типизированные компилированные языки, и уже эту модель данных в памяти асинхронно сохранять в базу данных, тогда все летать будет.
    2. Для легкой и самое главное корректной разработки сервиса с большим количеством "событийных" зависимостей - желательно использовать "Функциональное реактивное программирование" (в гугле поищешь материалы почему и как это реализуется)
    Ответ написан
    Комментировать
  • Как правильно реализовать архитектуру веб-приложения?

    veentoo
    @veentoo
    Full-Stack Software Engineer
    имхо, вариант 2 - Отдельный сервис - бэкенд, хотя бы на тот случай, если понадобится авторизация для других клиентов.
    Ответ написан
    Комментировать