Какие существуют стратегии для эффективного хранения большого количества данных (миллионы строк) в Postgres?

Question

Я размещаю популярный веб-сайт и хочу хранить определенные пользовательские события для последующего анализа.Такие вещи, как: нажатие на элемент, добавление в корзину, удаление из корзины и т. Д. Я предполагаю, что около 5 000 000+ новых событий будут приходить каждый день.

Моя основная идея - взять событие и сохранить его в строке в Postgres вместе с уникальным идентификатором пользователя.

Какие существуют стратегии для обработки такого большого количества данных?Я не могу представить, что один гигантский стол реалистичен.У меня была пара людей, которые рекомендуют такие вещи, как: выгрузка таблиц в Amazon Redshift в конце каждого дня, Snowflake, Google BigQuery, Hadoop.

Что бы вы сделали?

Answer 1

У нас похожий вариант использования с PostgreSQL 10 и 11. Мы собираем различные показатели с веб-сайтов клиентов.

У нас есть несколько секционированных таблиц для разных данных, и вместе мы собираем в день более 300 миллионов строк, то есть ежедневно 50-80 ГБ данных.В некоторые особые дни даже в 2–3 раза больше.

Сбор базы данных хранит данные за текущий и последний день (потому что, особенно около полуночи, может быть большой беспорядок с метками времени из разных уголков мира).

В предыдущих версиях PG 9.x мы передавали данные 1 раз в день в нашу основную базу данных PostgreSQL Warehouse DB (в настоящее время 20+ ТБ).Теперь мы реализовали логическую репликацию из сбора базы данных в хранилище, потому что в последнее время синхронизация целых разделов была очень тяжелой и продолжительной.

Кроме того, мы ежедневно копируем новые данные в Bigquery для действительно тяжелой аналитической обработки, которая в PostgreSQL занимает около 24 часов (реальные результаты - поверьте мне).На BQ мы получаем результаты в считанные минуты, но иногда платим за это много ...

Таким образом, ежедневные разделы - разумная сегментация.Особенно с логической репликацией вам не нужно беспокоиться.Исходя из нашего опыта, я бы рекомендовал не делать экспорт в BQ и т. Д. Из базы данных.Только со склада.

Answer 2

Я бы разделил таблицу, и как только вам не понадобятся подробные данные в работающей системе, отсоедините раздел и экспортируйте его в архив и / или объедините и поместите результаты в хранилище данных для анализа..