LevelDB player data storage

[dktapps]

Introduction

This PR implements a LevelDB player data storage provider.

Relevant issues

I previously wrote about this in #4077, including its advantages and disadvantages.

Changes

API changes

No public APIs were changed by this PR. However, a new class LevelDBPlayerDataProvider has been added to the pocketmine\player namespace.

Behavioural changes

• player.default-data-format is added to pocketmine.yml, with options leveldb and datfile.
• leveldb is now used by default for new servers. Servers with existing data will continue to automatically use the old datfile storage provider unless they delete their pocketmine.yml or add the new player.default-data-format option to their pocketmine.yml.

Backwards compatibility

No backwards compatibility issues currently known.

Follow-up

Convert data from the datfile storage system to leveldb. This would require some kind of format detection to enable this.

Tests

Tested locally using both datfile and leveldb configuration options. Everything seems to work as expected.

[IvanCraft623]

No migrator?

[dktapps]

See follow-up section.

[dktapps]

Main problem with this PR is that it's not possible to delete a specific player's data. The PlayerDataProvider interface would need to be changed to permit this. This isn't a big deal since the interface is de facto internal right now anyway (considering there's no way to provide a custom provider to the Server right now anyway), but this should be addressed before merging the PR.

[dktapps]

Closing this as I don't think it's worth the migration effort.

Between key ordering, and storing values in the same place as keys (requiring rewriting of values on DB sort), LevelDB is really poorly suited to any form of blob data storage, as we've seen with the performance issues of large worlds.

Considering that player data total size could easily reach multiple GB on highly active servers, this change would likely cause paying a large compaction performance hit. Again, this would be for data ordering which we don't even want anyway.

It may still be worth keeping a LevelDB in the playerdata to allow mapping player identifiers to the files their data are stored in, e.g. LevelDB containing maps of:

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

This would allow solving some old issues with player data identification.

However, putting the data in LevelDB directly is likely to cause performance degradation for large servers.

An alternative like RocksDB's BlobDB would be much better suited to a task like this.