games647
Reduce data storage
Is your feature request related to a problem? Please describe.
On large server, each time a players logs-in first time it's recorded onto fastlogin database. This is fine, but when thousands of players (or millions when you may receive a bot attack) you have a large database with a good size (uuids, lastip, lastlogin and the database index) for storing premium=false records.
Describe the solution you'd like
Since each time a player logs-in a "select" is queried for checking if the player is premium, it wouldn't be problem if the player is no-premium and it doesn't have a stored value. This will prevent having large databases and will be more efficient since there are less records to check.
Describe alternatives you've considered
A toggleable option to prevent storing non-premium players for people who doesn't want to have tons of irrelevant data (and people who may be interested in lastip and lastdate being able to keep that).
Well it's required for the auto premium check, because we can otherwise only make a decision based if the name is premium. A wrong decision could lead to kicking a cracked player. The following alternatives would also be possible:
- Use a more optimized table structure. Currently we use UTF-8 (1-2 bytes per character) for text, which is not really required (1 byte is enough). Furthermore some data can be saved in binary rather than text for example the IP address. It was used, because it makes the data more readable for the end user.
This would result in the following ignoring the indices.
| Field | Bytes |
|---|---|
| UserId | 4 |
| UUID | 16 |
| Name | <17 |
| Premium | 1 |
| LastIP | 4 (IPv4) or 16 (IPv6) |
| LastLogin | 4 |
Considering IPv4 and 8 characters for the name
=> 4+16+9+1+4+4=38 bytes per entry
-
Deleting old or inactive data. Players/Bots who only joined once could be deleted from the table.
-
Using an additional table, where we only save the result of the check. On player connect request we could make a join over both tables to still make a single request. However this leads to data across over two tables.
I didnt consider that because im not using autopremium check. What about consider adding the suggestion but not being able to enable the option id that feature is enabled? It would be something like
if (!doNotSave && autopremium) saveData()