Оптимизируете затраты Firestore для данных временных рядов?

Я использую Postgres для хранения данных датчиков временных рядов, но я взвешиваю стоимость использования Firestore, потому что предпочитаю бессерверный характер Firestore. Меня беспокоит только стоимость Firestore, потому что я плачу за каждое чтение. Я хочу иметь возможность отображать информацию об этом датчике в моем веб-приложении. Теперь я беру данные каждые 10 секунд, и есть более 400 сенсорных точек (400 столбцов в строке в моей таблице postgres).

В настоящее время, если пользователь запрашивает данные за неделю, это около 60 000 строк данных, но я оптимизирую его, просто беря каждое n-е значение, чтобы «растушевать» данные. Таким образом, взяв, например, каждую 20-ю строку, я уменьшил возвращение данных до 3000 строк, что вполне управляемо, и все же диаграмма показывает четкую тенденцию.

Я хочу иметь возможность сделать это в Firestore, чтобы сэкономить на расходах, потому что, если пользователь запрашивает данные за неделю, я плачу за 60000 чтений документов, которые в любом случае не могу отобразить все эти точки данных в веб-приложении. Я попытался найти способы запросить firestore для получения N-й строки данных, но не нашел никаких конкретных решений.

Есть ли у кого-нибудь рекомендации, как я могу оптимизировать свои затраты Firestore для данных временных рядов или, возможно, любых других дешевых бессерверных методов управления этими данными?


person limjix    schedule 08.05.2020    source источник


Ответы (1)


Как вы говорите, Firestore не предлагает никакого способа «удалить» данные из запросов. Вместо этого вы можете поместить целое число в каждый документ, описывающее его «N-е» значение, а затем запрашивать только те «N», которые вам нужны.

person Doug Stevenson    schedule 08.05.2020
comment
Но для ввода целого числа, описывающего каждое N-е значение, я должен отслеживать текущий номер в скрипте, который загружает данные в Firestore, но, безусловно, это вносит некоторые сложности и негибкость, если текущий номер каким-то образом испорчен из-за потери данных или если ему нужно быть повторно загруженным - person limjix; 08.05.2020
comment
Я уверен, что эти икоты можно игнорировать, если они случаются нечасто или их можно обойти. Я не могу придумать другого варианта. Я считаю, что вам придется решать это на клиенте. - person Doug Stevenson; 08.05.2020
comment
Хорошо, честно. Спасибо за совет! :) - person limjix; 08.05.2020