Я изо всех сил пытаюсь найти правильный способ объединения больших объемов данных. Рассматривая базу данных со средней загруженной входящей нагрузкой около 200 (500 пиков) новых рядов в секунду, мы достигнем одной строки биллиона в течение первых трех месяцев. Ожидается, что данные будут храниться не менее 10 лет. Таблица будет довольно статичной, без UPDATE, без DELETE, просто INSERT. Можно ли ожидать, что сервер PostgreSQL (с соответствующим оборудованием и конфигурацией) будет управлять такими большими объемами данных для запроса или это плохая идея?Агрегирование больших (биллионов строк) наборов данных по базе данных PostgreSQL
Теперь требование состоит в том, что каждый клиент сможет создавать агрегированные отчеты для своих транзакций (может быть десятки или даже сотни миллионов, в зависимости от его критериев), в том числе недавно добавленные.
Я могу придумать несколько теоретических соображений, таких как взгляды, материализованные представления, прямые запросы, предварительное вычисление с помощью триггеров в другую таблицу. Каждый из них имеет свои воздействия, положительные стороны, негативы. Например, я даже не могу представить освежающие материализованные взгляды.
У кого-нибудь есть опыт работы с такими задачами? Любое понимание оценено. Даже советы по инфраструктуре, инструменты сторонних разработчиков, что-то полезное. Моя самая большая проблема сейчас - это программное решение для создания, а не масштабирования HW.
Cheers.
При скорости 200 записей в секунду у вас будет 63 миллиарда строк за 10 лет. Через 10 лет вы, вероятно, будете заботиться об уровне детализации транзакций? По крайней мере вам нужно будет использовать [partitioning] (http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html), чтобы отделить ваши данные, 63 миллиарда строк неуправляемы в одном разделе. Таким образом, размер вашего раздела будет составлять c.535m строк, который, хотя и много, будет легче управлять, чем один раздел. – GarethD
Далее вы хотите рассмотреть среду OLAP. Если вам, скорее всего, потребуется отчет на достаточно высоком уровне, тогда сохраните данные на высоком уровне, объедините их с вашими разделами, например, если вы введете данные в хронологическом порядке, разделите свои данные на месяц, а затем, как только раздел будет завершен (в начале следующего месяца), добавьте резюме своего предыдущего месяца на склад. Если вам нужно до второй точной отчетности, вы можете комбинировать запросы со своего склада, чтобы получить исторические данные, и только ваш последний раздел для более свежих данных. – GarethD
Согласен, разбиение является обязательным. Первой идеей мы разделили на недавнюю и историческую часть. Теперь мы обсуждаем возможности использования Solr поверх нашей базы данных и перемещения всей описанной отчетности в Solr и простое использование роли базы данных в качестве простого хранилища, предоставляющего исходные данные для Solr. К сожалению, у нас пока нет большого опыта в решениях Solr. – Kousalik