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

Possible switch to a client-server NoSQL database #14

Open
MinoMino opened this issue May 13, 2015 · 2 comments
Open

Possible switch to a client-server NoSQL database #14

MinoMino opened this issue May 13, 2015 · 2 comments
Assignees

Comments

@MinoMino
Copy link
Owner

Just thought I'd put this as a sort of warning, if you will. It's very likely I'll switch to a client-server NoSQL database when the Steam exclusive update hits. Why? Primarily for the following reasons:

  • Being able to run multiple servers using the same database. Obviously that would work with any client-server SQL database too, but see below.
  • Dynamic schemas. It's just so much nicer to be able to change schemas on the fly. This is why I'm leaning towards NoSQL and not just MySQL or something like that.
  • The data in the current SQLite databases will be useless due nicknames not being unique identifiers, making this the perfect opportunity to make this change.
  • NoSQL tends to fall short when it comes to complex queries. The bot uses extremely simple queries, so that's not an issue either.
  • I've been looking into ways to reduce both CPU and GPU load of QL to make it more viable to run multiple clients without having it hog resources unneccesarily on bot users who don't use it to play on, and I've had some success doing so, so that's even more reason to have a client-server database.

At the time of writing, I'm leaning towards MongoDB, as I've worked with it before, has a first-party Python driver and has good documentation.

@MinoMino MinoMino self-assigned this May 13, 2015
@MinoMino MinoMino changed the title Possible switch to a NoSQL database Possible switch to a client-server NoSQL database May 13, 2015
@WalkerY
Copy link

WalkerY commented May 20, 2015

"The data in the current SQLite databases will be useless due nicknames not being unique identifiers, making this the perfect opportunity to make this change."

Why do you think so? I guess nicknames might not be 'main' unique identifier but I think they will be unique even after migration to steam exclusive. Also do you really think that current nicknames will be abandoned? Imo they will be migrated. It would be enough for current database to add new column with id.

Imho, saying current databases will be useless is far-fetched.

@MinoMino
Copy link
Owner Author

I guess nicknames might not be 'main' unique identifier but I think they will be unique even after migration to steam exclusive. Also do you really think that current nicknames will be abandoned?

Yes, I do think so. That's standard practice for well-integrated Steam games. The nickname will likely be whatever nickname you use on Steam. Not to mention, the little teaser sponge gave the other day:

Steam nicknames support unicode (and as opposed to the current system, whitespaces can be used freely), so that's likely the motivation for implementing that.

Imho, saying current databases will be useless is far-fetched.

Personally, I'd say thinking otherwise is far-fetched when it's clear they're looking to integrate the game with Steam and move away from their shitty infrastructure as much as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants