Skip to content
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

Merged
merged 4 commits into from
Jan 9, 2024
Merged

feat: daily metrics db migration #5791

merged 4 commits into from
Jan 9, 2024

Conversation

kwasniew
Copy link
Contributor

@kwasniew kwasniew commented Jan 8, 2024

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

Copy link

vercel bot commented Jan 8, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
unleash-monorepo-frontend ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 9, 2024 9:38am
1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
unleash-docs ⬜️ Ignored (Inspect) Visit Preview Jan 9, 2024 9:38am

feature_name VARCHAR(255),
app_name VARCHAR(255),
environment VARCHAR(100),
timestamp TIMESTAMP WITH TIME ZONE,
Copy link
Contributor Author

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,
Copy link
Contributor Author

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,
Copy link
Contributor Author

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 (
Copy link
Contributor Author

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 (
Copy link
Contributor Author

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

Copy link
Contributor

@andreas-unleash andreas-unleash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kwasniew kwasniew merged commit 99b1657 into main Jan 9, 2024
13 checks passed
@kwasniew kwasniew deleted the daily_metrics_db_migration branch January 9, 2024 10:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants