@NickBor
Добрый день! Помогите ответить на такой вопрос связанный с базами данных. Планируется создать базу данных объемом порядка 100-300 Гб (Если говорить о строках, то несколько миллиардов строк в таблице). Например, данные с множества датчиков, которые поступают каждый час на протяжении годы, и потом нужно работать с этими данными. Необходимо делать запросы для выгрузки данных. Как лучше поступить, организовать базу данных с кластеризацией этих данных и использовать PostgreSQL или применять какие-либо методы работы с BigData? Если PostgreSQL, то какие порядки по времени обработки запроса могут быть осуществимы? (допустим нужно выгрузить таблицу на 100 000 строк)? Спасибо за советы!
Решения вопроса 0
Ответы на вопрос 6
@sergey-gornostaev
Конкретный ответ на ваш вопрос в данной формулировке дать нельзя. Многое зависит от структуры БД, от сценариев работы с ней, интенсивности запросов, соотношения запросов на чтение к запросам на запись и т.д. и т.п. Вероятнее всего, это вопрос не к СУБД, а к архитектуре вашего приложения. В целом, у меня в одном из проектов запросы на чтение по индексу из таблицы с 23 миллиардами записей укладывались в десятки миллисекунд при стандартных настройках и не особо мощном сервере.
@fox_12
Если у вас большой объем показаний датчиков с временными метками — то стоит присмотреться к специализированным БД
@ky0
Огромные таблицы однотипных и упорядоченных по времени данных — это моветон. Партиционирование таблиц по дням/месяцам и схлопывание старых данных в агрегаты должны помочь — именно так, например, происходит в БД Заббикса.
@saboteur_kiev
Вряд ли скажут точно.
Скорость запроса зависит от всего. От размера конкретной таблица, от того какие данные, причем важно и тип и их схожесть, чтобы было проще индексы строить.
И от скорости ssd
Но я бы сказал, что 100-300 гб это далеко не бигдата. Это просто большая база, с которой справится и mysql и postgres, тем более что взяв сервер с 128гб оперативки, почти треть можно в памяти кешировать.
Скорость запроса зависит от всего. От размера конкретной таблица, от того какие данные, причем важно и тип и их схожесть, чтобы было проще индексы строить.
И от скорости ssd
Но я бы сказал, что 100-300 гб это далеко не бигдата. Это просто большая база, с которой справится и mysql и postgres, тем более что взяв сервер с 128гб оперативки, почти треть можно в памяти кешировать.
В вашем случае — без перфоманс тестов никто не скажет даже примерный порядок.
P.S. И да, если ваши данные в основном числа (таймстамп и числовые показатели, то time series data bases могут с этим справиться лучше). С другой стороны они не так популярны и возможно не так развиты.
@2ord
Попробуйте одну из TSDB, как указал Владимир Куц .
В частности, хранилище VictoriaMetrics. В качестве языка запросов применяется PromQL.
Возможность использования в качестве долговременного хранилища данных, подключенного к Prometheus и Grafana.
Что касается преимуществ по отношению с другими, то сходите по ссылке выше.
@rozhnev
Если Вы уже работаете с PostgreSQL, то я могу посоветовать использовать Timescale: PostgreSQL for time‑series