#database #rest #symfony #architecture #json-ld
#База данных #rest #symfony #архитектура #json-ld
Вопрос:
Мы пытаемся найти лучшее решение для работы с медленной базой данных на живом веб-сайте.
Базовая архитектура системы такова:
- Медленно (некоторые операции чтения и большинство операций записи выполняются быстро, другие занимают несколько секунд) Postgres DB. Мы не можем это контролировать.
- Монолитная автономная система, которая обращается к Postgres DB. Мы не можем это контролировать.
- Быстрые внутренние серверы, которые могут обращаться к базе данных Postgres. Мы можем разработать и установить программное обеспечение для этого сервера.
- Быстрые веб-серверы, использующие стек LAMP, которые могут НЕ обращаться к базе данных Postgres, но могут обращаться к внутреннему серверу. Мы можем разработать программное обеспечение для этого сервера.
- Быстрые базы данных MySQL, к которым может получить доступ любой пользователь. Мы полностью контролируем это.
Мы разрабатываем новое веб-приложение для запуска на веб-серверах с использованием Symfony 2.
Наш первоначальный план состоял в том, чтобы создать RESTful API для размещения на внутреннем сервере, который используется веб-приложением. Основная проблема, с которой мы сталкиваемся, заключается в том, что скорость веб-приложения ограничена скоростью Postgres DB, что неприемлемо для пользователей.
Кто-нибудь знает какие-либо стратегии для решения этой проблемы скорости?
Кэширование — очевидное решение, и мы, конечно, можем обсудить, насколько актуальными должны быть данные, но в определенных обстоятельствах они должны быть абсолютно актуальными. Например, если пользователь сохраняет некоторые изменения, они должны появиться немедленно. Мы рассмотрели возможность использования API с собственным быстрым хранилищем данных, которое он обновляет асинхронно из Postgres. Затем мы могли бы выполнять все операции чтения в этом быстром хранилище, фиксируя записи как в нем, так и в Postgres. Проблема, конечно, в согласованности данных и повышенной сложности системы.
Мы изучаем использование JSON-LD для представления данных, поскольку он хорошо подходит для того, с чем мы работаем, и использование стандарта, хотя и относительно молодого, должно облегчить любые серьезные архитектурные изменения в будущем, которые вполне могут произойти. Поскольку его можно было бы поместить непосредственно в хранилище документов, это потенциально упростило бы процесс.
Наши ключевые цели здесь:
- Обеспечить пользователям хорошую работу.
- Создайте систему, которая удобна в обслуживании и проста для понимания.
Любые рекомендации или предложения будут приветствоваться!
Ответ №1:
Я думаю, что главный вопрос, который нужно задать: почему Postgres DB такая медленная? Также из вашего объяснения неясно, что делают все эти системы и каковы зависимости / требования. Например, должны ли данные в PostgresDB быть актуальными? Это основная база данных? Является ли это интеграционной базой данных для монолитной автономной системы?
Если вы не можете изменить медленную базу данных Postgres, она должна быть актуальной с точностью до минуты, и веб-сайт зависит от этого и должен быть обновлен с точностью до минуты (в некоторых случаях), у вас проблема, потому что это невозможно. Если БД Postgres не требуется обновлять до последней минуты, потому что она все равно используется автономным приложением, вы можете обновлять эту БД асинхронно и использовать свои БД MySQL таким образом, чтобы обеспечить необходимую производительность.
Учитывая, что вы планируете использовать JSON-LD, я хотел бы услышать больше о системе, которую вы создаете. Можете ли вы поделиться дополнительной информацией?
Комментарии:
1. Спасибо, Маркус. Проблема в том, чтобы быть в курсе событий или нет. Мы думаем, что мы выяснили стратегию, которая будет работать для нашего варианта использования, который в значительной степени соответствует вашему описанию; обновление базы данных MySQL асинхронно, чтобы получать изменения из Postgres часто, но не обязательно с точностью до минуты. Затем мы запишем API как в базу данных MySQL, так и в Postgres, чтобы эти изменения были актуальными. Возможно, я смогу рассказать вам больше в другом месте о нашем использовании JSON-LD 🙂
Ответ №2:
Хм, вы могли бы потенциально использовать couchdb. Предпосылка couch заключается в том, что в конечном итоге она непротиворечива, но у вас есть локальная копия данных, с которыми вам нужно работать, и они мгновенно возвращаются в приложение, а затем обновляют центральный репозиторий так быстро, как это возможно.
Это также RESTful из коробки. Единственное, что вам нужно будет соединить, это соединение postgres — couchdb.
Ответ №3:
Например, если пользователь сохраняет некоторые изменения, они должны появиться немедленно.
Это также кэширование, поэтому, когда пользователь обновляет некоторые данные, срок действия кэша (который теперь содержит старые данные) истекает (либо Etag, либо удаление кэша вручную)