#database #mongodb #postgresql #time-series
Вопрос:
мне нужно оптимизировать базу данных для вставки/чтения большого объема
у меня есть необработанные данные таблицы postgress около 9 миллионов строк.
Строка, состоящая из 2 столбцов: , ; данные сортируются по времени timestamp string value
Единственный запрос, который я использую для этого csv, — это:
select * where unixtimestamp between 1600000 and 1700000
после получения данных из необработанной таблицы я применяю некоторую функцию к результату. и кэшировать обработанные данные в другую таблицу для более быстрых будущих запросов
Я попробовал монго с коллекцией временных рядов, но все равно было лучше ~ 25 секунд для извлечения; а вставка еще длиннее.
Постгресс был лучшим временем для извлечения: но попытка вставить 500 тысяч строк сразу заняла бы целую вечность.
До сих пор лучшим способом, который я нашел, был анализ csv-файлов в виде строк и использование двоичного поиска для выбора строк
Я думаю, что мои индексы неверны, и это главная проблема
Итак, каковы ваши предложения по сохранению данных временных рядов, в которых мне нужна только операция, чтобы попасть в зону действия
уточните вопрос ПРАВКА1:
- у меня есть необработанные данные из 9 миллионов строк.
- пользователь может запросить данные из api, используя один из 20 примеров формулы агрегации
api/get?formula=1amp;from=2019amp;to=2021 - поэтому я проверяю, есть ли у меня кэш для
formula=1этого диапазона дат - если нет, то мне нужно загрузить необработанные данные для этого диапазона дат, применить формулу, которую запросил пользователь (результат обычно составляет 1 тыс. строк на каждые 1 млн или необработанные данные), затем я кэширую агрегированные данные для последующих запросов.
я не могу предварительно обработать данные для всех формул в системе; потому что у меня более 2000 датчиков (каждый из которых имеет свои собственные необработанные данные 9 млн); результат составит более 2 ТБ пространства.
Комментарии:
1. С учетом таких ограничений производительности, я думаю, вам следует рассмотреть возможность хранения данных в памяти с возможным автономным резервным копированием.
2. Я не могу понять, связана ли проблема с количеством времени, которое требуется для загрузки данных в базу данных, или с производительностью запроса для извлечения данных из нее. Как часто вы хотите загружать данные? Сколько строк вы ожидаете, что ваш запрос будет извлекаться каждый раз?
3. См. также lmax-exchange.github.io/disruptor
4. Вам нужно использовать КОПИЮ для импорта.
5. @TheImpaler я получаю данные не так часто, потому что эта таблица содержит необработанный журнал, как только пользователь запрашивает определенный диапазон дат, я кэширую агрегированные данные в другой таблице (это api json, используемый пользовательским интерфейсом панели мониторинга для рисования диаграмм) . но иногда пользователь запрашивает критерии агрегации, которые еще не кэшированы, тогда мне приходится запрашивать у raw ~500 тыс. строк для их обработки и кэширования