Django подключение к серверу и Prestodb и разбиение на страницы данных - PullRequest
Новая
       13

Django подключение к серверу и Prestodb и разбиение на страницы данных

0 голосов
/ 13 февраля 2020

У меня есть простая инфраструктура, использующая сервер django для API и PrestoDb в качестве механизма запросов. У меня все работает нормально, но у меня есть несколько ограничений в зависимости от prestodb:

  • Prestodb не поддерживает разбиение на страницы, Как я могу управлять огромным количеством данных? загрузка его в память обходится дорого.
  • Я открываю и закрываю соединение для presto снова и снова для каждого запроса. Как лучше всего использовать только одно или два соединения и использовать их во всем приложении?
  • Что такое правильный способ показать пользователям ошибки вместо необработанных исключений preto?
  • Какой механизм кэширования следует использовать для общих данных?
  • Я использую сельдерей для фоновых заданий, есть ли другие? для выполнения фоновых заданий, которые не загружаются на python сервере?
  • Каковы рекомендации для django? Любая полезная ссылка?

Ответы [ 2 ]

3 голосов
/ 13 февраля 2020

Вопрос очень широкий, поэтому позвольте мне ответить только на часть, касающуюся нумерации страниц.

Presto поддерживает разбиение на страницы через SQL Стандартный OFFSET m FETCH NEXT n ROWS ONLY синтаксис или OFFSET m LIMIT n упрощенный синтаксис.

Подробнее об этом можно прочитать в сообщении в блоге https://prestosql.io/blog/2020/02/03/beyond-limit-presto-meets-offset-and-ties.html

Конечно, это в основном подходит для ad-ho c запросов или когда у вас нет возможность улучшить фактическую структуру запроса. Для запланированных запросов или запросов, являющихся частью какого-либо рабочего процесса (не ad-ho c), рекомендуется использовать предикаты запросов (при необходимости) вместо OFFSET. Подробнее на https://use-the-index-luke.com/sql/partial-results/fetch-next-page.

1 голос
/ 13 февраля 2020

Прежде всего, Presto создан не для транзакционных, а для аналитических целей, обычно с большим объемом данных. В случае транзакций MySql / Postgres, подключенный с помощью Django ORM / Models, является лучшим выбором.

  • Нет, это не так. Согласно здесь и здесь вы должны получить все данные, кэшировать их в бэкэнде и запросить их. Запрос / фильтр должен быть очень конкретным, чтобы получить небольшой объем данных, представляющих интерес. Например, рассмотрите возможность добавления фильтра даты и ограничения его несколькими днями / месяцами. Таким образом вы запрещаете своим пользователям выполнять тяжелые запросы.
  • Вы можете использовать одно и то же соединение, если вам не нужны другие конфигурации, например, уровень изоляции транзакции
  • Что касается ошибки БД, просто верните Ответ с кодом 500 - Внутреннее сообщение об ошибке. Также убедитесь, что в журнале stacktrace
  • Django есть инфраструктура кэширования из коробки
  • Celery - хороший выбор, обычно он идет с Redis или RabbitMQ. Эти службы развертываются отдельно от основного Django приложения
  • Django docs , которое должно стать хорошим началом
...