-
-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: daily metrics db migration #5791
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
feature_name VARCHAR(255), | ||
app_name VARCHAR(255), | ||
environment VARCHAR(100), | ||
timestamp TIMESTAMP WITH TIME ZONE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking about using date here since we don't want the time section
feature_name VARCHAR(255), | ||
app_name VARCHAR(255), | ||
environment VARCHAR(100), | ||
timestamp TIMESTAMP WITH TIME ZONE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, date not time
feature_name VARCHAR(255), | ||
app_name VARCHAR(255), | ||
environment VARCHAR(100), | ||
date DATE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is deliberately date not timestamp as the original hourly table
exports.up = function (db, cb) { | ||
db.runSql( | ||
` | ||
CREATE TABLE IF NOT EXISTS client_metrics_env_daily ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copy of client_metrics_env but with date instead of timestamp
no INTEGER DEFAULT 0, | ||
PRIMARY KEY (feature_name, app_name, environment, date) | ||
); | ||
CREATE TABLE IF NOT EXISTS client_metrics_env_variants_daily ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copy of metrics_env_variants but with date instead of timestamp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
About the changes
Business problem: we want to store up to 3 months of metrics data. Hourly storage is not feasible, so we go for the daily storage above 2 days.
Technical solution:
Adding 2 new tables to simulate time series DB in postgres. The idea is to store data in high resolution initially (the original tables) and then aggregate it to a lower resolution as it ages (2 new tables).
The original metrics tables contain hourly data, the new tables will contain daily data. The structure is the same except from the timestamp column changing to date column.
Calculations for 90 days of data: https://gist.github.com/kwasniew/864bb6e5111b7de516b6e4454963d2d4#data-requirements-for-the-extended-90-days-scenario. New table should take twice as much space as the hourly table.
In the next PR I will create a scheduler that uses those tables for aggregation: #5804
Important files
Discussion points