Use a LevelDB to store playerdata NBT instead of flat files

[dktapps]

Description

The server should store players' data in a LevelDB database instead of dumping them into lots of .dat files on the disk.

Justification

The current system of playerdata storage uses flat .dat NBT files on the disk. This is horribly inefficient for several reasons:

• Player .dat files are typically very small (a couple of kb). Considering that typical filesystems use a 4KB allocation unit size, this means that a significant percentage of disk space gets wasted (e.g. a 6KB data file occupies 2 sectors, totalling 8KB)
• No readahead is possible with many flat files, so the data can't be cached in memory, leading to longer I/O wait times.
• Compression has reduced efficiency. Considering that player.dat files contain a lot of common data (mostly NBT keys), compressing them in batch would produce better compression ratios, saving more space.
• It's difficult to remove playerdata on Linux when the playerdata file count gets too big (e.g. rm -f players/*.dat doesn't work anymore).
• Trying to open a directory with thousands of files in it on Windows lags Explorer to death.
• On some filesystems, the playerdata file count may reach or exceed the maximum files per directory limit.
• Players' usernames are used as data keys, so player usernames are constrained by the valid characters which can appear in a filename (e.g. they can't contain / \ " . and so on).

However, it does have the following advantages which would be lost:

• It's currently easy to delete a specific player's data. A tool would need to be provided to do this if LevelDB were used for storage.

Alternative methods

I've also considered SQLite3, but since PM4 already depends on LevelDB (and LevelDB supports binary data, unlike SQLite3), LevelDB appears to be the better option.

[dhdjSYS]

After some testing it seems like leveldb won't support WSL 1 (maybe due to filesystem?). This may cause a compatibility issue.
However no one uses wsl1 anymore. That's the good news.

[dktapps]

WSL is Microsoft's attempt to simulate Linux within Windows. The only reason to use it is for development. I personally don't use it and we don't lose much if it's not supported anyway.

[ghost]

It's a great idea, but I recommend using the xuid as the key for the user data.

Player can change gametag. This is a big problem, because the player loses all his data

[ColinHDev]

The XUID? What if xbox.auth is disabled?

[ghost]

Oh, sorry..I hadn't thought of that.

Maybe add the ability to choose the type of key?

[ColinHDev]

That would cause compatibility issues once the setting would be changed

[ColinHDev]

For backwards compatibility we should stick with the name or at least use the UUID

[UnknownOre]

use uuid, if xbox-auth is disabled use the name

[ColinHDev]

If we would resolve #4076 we could just use uuids for both

[dktapps]

This issue is not a debate about whether to use UUIDs, names or anything else as data keys. That's a topic for another discussion since it involves API changes as well as storage system changes.

[dktapps]

Turns out this was a really bad idea, because LevelDB is really poorly suited to storing any kind of large data. The compactions and subsequent key sorting cause lots of unwanted I/O. We see this issue in large worlds in PM4 and up too (see #6580). This is compounded by the fact that LevelDB stores values in-line next to keys, so sorting keys also entails moving (potentially very large) blob data around.

To solve some of the issues mentioned here about player identification, we could use a LevelDB to store a simple map like:

• player name -> .dat file name
• UUID -> .dat file name
• XUID -> .dat file name

This would be very light on data, require minimal I/O, and solve the problem around players' usernames being restricted by filename allowed characters, as well as allowing various other changes like identifying playerdata by UUID or XUID.

If we want to explore putting playerdata into a DB in the future to save space and get around other filesystem limitations, an unordered K/V database would be preferred, or something like RocksDB's BlobDB which stores values separately from keys to minimize I/O costs of sorting keys.