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

nl2_query_results table gets huge #2179

Open
Derkades opened this issue Feb 25, 2021 · 16 comments
Open

nl2_query_results table gets huge #2179

Derkades opened this issue Feb 25, 2021 · 16 comments
Assignees
Labels

Comments

@Derkades
Copy link
Member

Derkades commented Feb 25, 2021

hundreds of megabytes (grows infinitely?)

IMPORTANT also causes other issues: #2179 (comment)

@Derkades Derkades added the bug label Feb 25, 2021
@tadhgboyle
Copy link
Member

I feel like this could be handled similar to update check (cache last update check time, check if last time was more than x minutes ago, then check again).

We need to decide how many rows to keep max, and then delete oldest rows every x number of minutes

@partydragen
Copy link
Member

well cannot be rows as its depends on how many servers you have and interval, should be a own option that delete older than interval, 0 to disable for them who wish to keep the data

@partydragen
Copy link
Member

its not really a bug either as all data was to be keeped, also used to be a graph where you could go back in time

@Derkades
Copy link
Member Author

Derkades commented Feb 25, 2021

EDIT: THESE ARE NOT INSTRUCTIONS. Do not do this if you are a NamelessMC user

  • Remove "extra" column. If data from this becomes useful in the future, add a specific column for only that value.
  • Remove "groups" column, create nl2_server_groups where a list of groups is stored by server id. Group history is not necessary
  • Delete everything with timestamp < (now - 7d). This is a slow O(n) operation because the timestamp column is not indexed, don't run very often (how? does namelessmc have a "jobs" system?)

This will reduce a row from ~1KB to ~20 bytes. 1MB per server max instead of +60MB per server, per week, infinitely (for 5 servers 1GB/mo!)

@partydragen
Copy link
Member

well was never designed for every 10 sec, but every 10 mins++

Also the player stats graphs, now for every 10 sec it will need to load ALLOOOT of data

@Derkades
Copy link
Member Author

Derkades commented Feb 26, 2021

The website is free to only store a new row if the timestamp of the old row < (now - 1h) for example. Fast updates are convenient for group sync but storing every ping is not necessary.

@Derkades Derkades added this to the 2.0.0-pr10 milestone Mar 23, 2021
@Derkades
Copy link
Member Author

Derkades commented Mar 23, 2021

Removing the extra column is also important because it would lift the limit on the request sent by the plugin. Currently rank sync does not work for the majority of users because the column is too small. (it already breaks with more than a single player online most of the time)

@Derkades Derkades modified the milestones: 2.0.0-pr10, 2.0.0-pr11 Jun 13, 2021
@samerton
Copy link
Member

Extra column removed in 6dcecef

Further improvements will be added in a future release

@samerton samerton modified the milestones: 2.0.0-pr11, 2.0.0-pr12 Aug 24, 2021
@Derkades Derkades modified the milestones: 2.0.0-pr12, 2.0.0 Oct 5, 2021
@Derkades Derkades removed this from the 2.0.0-pr13 milestone Apr 16, 2022
@tadhgboyle tadhgboyle added this to the 2.0.0 milestone Jun 4, 2022
@tadhgboyle
Copy link
Member

tadhgboyle commented Jun 9, 2022

Do we want/need to keep the player_count column - it's not used by anything internally anymore?

If not, we may as well move the MC group storage to a different table as Derkades mentioned, and dump the query_results table:

server_id (FK) groups
1 {"admin", "mod", "member"}
2 {"admin", "mod", "member", "helper"}

@partydragen
Copy link
Member

Player graph etc will still be added back at somepoint

@tadhgboyle
Copy link
Member

Okay, we can maintain this table layout, but instead we can compare the values of the groups and player_count rows and only insert new data if they are different. How does this sound?

@Derkades
Copy link
Member Author

Derkades commented Jun 9, 2022

When players graphs are added back eventually ™️ you could always create a new table to keep track of player count. I like the idea of removing nl2_query_results and creating a new table with just groups by server id instead.

I'm not sure if the difference check is necessary, I'd use a query like the following:

With server_id marked as UNIQUE:

INSERT INTO nl2_server_groups (server_id, groups) VALUES (?, ?) ON DUPLICATE KEY UPDATE groups = ?

@tadhgboyle
Copy link
Member

tadhgboyle commented Jun 9, 2022 via email

@partydragen
Copy link
Member

The table should stay keeping data is always good atleast the playercount and the player graph have been added and removed multiple times xD anyways can be used for alot more than just graph

Just make that new table instead and keep this

@tadhgboyle tadhgboyle self-assigned this Jun 11, 2022
@tadhgboyle
Copy link
Member

INSERT INTO nl2_server_groups (server_id, groups) VALUES (?, ?) ON DUPLICATE KEY UPDATE groups = ?

Realizing this now, how will this work for displaying group sync options?
Should it only get groups for the default server, or should it collect all of the groups and display all of them as options in the dropdown?

@tadhgboyle
Copy link
Member

Continuing the push back of this issue 😛

@tadhgboyle tadhgboyle removed this from the 2.0.0 milestone Jun 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants