Redshift как замена или дополнение
Коллега создал веб-приложение с PHP-фреймворком, в котором мы можем настроить вызовы API для других систем. Они работают ночью, чтобы добавить новые данные в базу данных Postgres. Поскольку Postgres — это база данных OLTP, а не созданная для аналитики, я начал читать о Redshift. Но я просто не могу понять, как все это сочетается.
Да, и для аналитики мы бы посмотрели на PowerBI, который мог бы использовать DirectQuery с Redshift. Но, как я понимаю, для Postgres такого нет.
Так что для моего вопроса я разделю все на четыре части:
- Приложение (логин, интерфейс для настройки вызовов API)
- Данные пользователя для приложения (пользователь, схемы для вызовов API)
- Данные (ответы из API для последующей аналитики)
- Datawarehouse (хранилище для аналитических данных)
Решение | Применение | Данные пользователя | Данные | Datawarehouse -------- | ----------- | ---------- | ------------- | ---------------- Сейчас | PHP | Postgres | Postgres | 1. | PHP | Postgres | Postgres | Redshift 2. | PHP | Postgres | | Redshift 3. | PHP | Redshift | | Redshift
Итак вопрос является: Какое возможное решение является «правильным»? Я мог бы использовать имеющуюся у нас инфраструктуру и просто добавить Redshift. Но тогда я удваиваю стоимость хранения. Я мог бы хранить данные приложения в небольшой базе данных и хранить данные из API непосредственно в Redshift или использовать Redshift в качестве единственной базы данных.
Решение
Обе системы имеют различную внутреннюю инфраструктуру и используются для некоторых весьма специфических целей. Хотя оба они могут использоваться взаимозаменяемо при работе с небольшим объемом данных, но они кардинально изменятся при массовом чтении / записи.
Здесь я предполагаю, что когда вы говорите, что используете Postgres, вы, вероятно, ориентированы на ряд.
Для записи объемных данных предпочтительна строка БД, так как она интенсивно записывается, когда в качестве столбца БД используется, если ваши операции включают запрос нескольких строк (типичное требование для аналитических целей). Наилучшим сочетанием всегда остается хранение транзакционных данных в БД, ориентированных на строки, миграция некоторых таблиц, необходимых для аналитических целей, в столбчатые БД и выполнение там аналитических запросов. Это может показаться абсурдным и дорогостоящим, но именно так и работают некоторые компании, если они не хотят идти на компромисс ни с транзакционными данными, ни с аналитическими данными.
Если ваша компания основана на продуктах, в которых задействованы тяжелые (финансовые) транзакции, и вы также захватили user_persona, разделите их на схемы, ориентированные на строки и столбцы соответственно.
Строка БД интенсивно пишет. Когда приложение делает массовые транзакции
писать заявления, это должно быть написано на таблицах без каких-либо задержек. я
конечно, у вас также будет несколько конфигураций master_slave,
данные должны быть скопированы на рабов, и это тоже, на
в реальном времени
Теперь нужно понимать, что аналитические данные сильно отличаются от транзакционных данных. Транзакционные данные не являются объемными. Допустим, в таблице заказов будет создана строка, которая будет отображаться user_id с некоторыми основными order_details за каждый размещенный заказ; но данные аналитики — шаблоны кликов на экране, подробности отправляемых уведомлений и т. д. генерируются каждый раз, когда пользователь попадает в приложение; является объемным и не может быть сохранен так же, как мы храним транзакционные данные.
Столбчатая ориентация (как в Amazon RS) читается интенсивно — типичное требование для аналитического
данные, так как большое количество строк будет получено для данного
user_set — детали всех отправленных уведомлений или всех экранов
просмотр / клик пользователем. Колонна дБ специально для костюма
такие требования.
Объем записи в столбчатых БД идет медленно; но поскольку в настоящее время он имеет дело главным образом с аналитическими данными, отсутствие данных в реальном времени не является критичным. Аналитика требует времени и данных до current_date-1 или с отставанием n Часы всегда можно отнести к рисованию персонажа пользователя.
Для крупной компании с объемным набором данных необходимо поддерживать компромисс. Я надеюсь, что теперь у вас есть слабое представление о том, как это сделать.
Другие решения
Ваш вопрос не очень ясен о том, как вы собираетесь использовать базы данных, однако лучшая рекомендация — это попробовать и использовать «нормальную» базу данных (в вашем случае PostgreSQL) для всего.
Если вы обнаружите, что ваша аналитика занимает слишком много и у тебя есть миллионы или миллиарды строк в базе данных вы можете также рассмотреть возможность использования Amazon Redshift для более быстрых аналитических запросов. Если ваши запросы доступны только для чтения, вы также можете рассмотреть возможность использования Амазонка Афина, который может читать данные напрямую из файлов, хранящихся в Amazon S3.
Какой цели служит база данных Postgres в этом сценарии?
Я бы предложил записать выходные данные вызовов API непосредственно в S3 и загрузить их в Redshift оттуда.
Если эти ответы API находятся в формате JSON (скорее всего) вы можете добавить их в CSV для загрузки в Redshift. Загрузка JSON в Redshift довольно ограничена.