Как лучше поступить в случае, когда намечается огромное количество данных?
Здравствуйте.
Есть СУБД PostgreSQL. Есть также задача собирать статистику с соц. сетей по определенным параметрам (fb, tw, ig и т.п.) и затем высчитывать определенные данные. В перспективе это сотни миллионов, даже миллиарды строк, т.к. сервис большой и серьезный.
В чем вопрос: коллега предложил сделать по одной денормализованной таблице статистики для каждой соцсети, аргументируя это тем, что будет много данных и лучше их разделить на несколько частей. Т.е., например, таблица facebook_stats. Я же ратую за нормализованный и более сложный подход: таблица stats с полем type, и парой других полей для основных данных, к которой затем будут присоединены таблицы с данными, специфичными именно для конкретной соцсети по схеме one-to-one.
На мой взгляд, второе решение красивее и архитектурно более гибкое, в коде работать с ним будет приятнее и легче. Останавливает вопрос нагрузки: если делать так, как предложил коллега, таблицы будут в 4 раза меньше, чем моя таблица stats. Но с другой стороны, в моей таблице будут храниться только основные данные, а дополнительные при необходимости быстро подтянутся за счет foreign keys.
Какой вариант лучше выбрать, когда маячат действительно большие данные? Как их хранят и обрабатывают крупные корпорации? Нужно, чтобы было и красиво, и быстро.
Большие данные измеряются не количеством строк в таблицах, а объёмами этих данных. И пока у вас не петабайты, большими они не являются. И упомянутый вами в тегах highload - это про количество запросов в секунду, а не количество строк в таблицах.
Структуру БД надо подбирать под структуру запросов. Для плоского селекта по индексируемым полям 20-30 миллиардов строк в таблице проблемой не являются.
Буду знать) Действительно, некорректно поставил тэг.
А запросы будут плоскими с максимум одним джойном. Пока самая большая таблица в самой большой БД на моей памяти содержала миллионов 50 строк, и оно подлагивало, хотя там было больше джойнов, чем предполагаем использовать мы.
Средний
