Add persistent server storage with MongoDB #9
Conversation
This makes some options non-optional -- allowing for a smaller config file. This also removes the X-Sendfile example, bucause the proxy server should handle static files directly and the option is not at all specific to this particular application (and general Flask options aren't documented).
This should be handled at a higher level, such as in NetFilter or the proxy server. I only added this feature because the old server list had it.
There's just not really a compelling reason for this to be configurable.
This is a standard way of indicating requirements for Python projects, since it makes it easy to automatically install all needed packages with the correct versions.
|
Why add another technology on MT components ? Redis could be used there instead of ugly mongo db. MongoDB is overkill and pure shit technology for NoSQL, just useful for devs. |
|
@nerzhul: MongoDB integrates very well with the server list because it's JSON-based. Redis doesn't support multiple indexes AFAIK, and SQL-based databases require schema updates with every new field. |
|
I don't really know which of the two is better, but if mongodb is built for json... why not. |
I'll tell you why not: It's a god damn server list for a few (~150) game servers, we aren't an enterprise that needs any of that NoSQL bullshit to run queries on our 500TB database. Writing a JSON file to disk is completly sufficient and doing anything else is just adding unneeded complexity to an otherwise really simple setup. I don't want to install a database server that uses 20GB of memory just to run server list handling 2KB of data. |
|
@sfan5 thanks, and i have mongodb in my enterprise for 200GB of data and mongodb is just a pain. it's useful for developpers but not for devops or infrastructure engineers. Also mongodb 3.2 switched partially to postgresql + JSONP backend => then lol |
|
It could be saved to a seperate JSON file, but that would require O(N) time for all lookups. At best we could make one type of search run in O(log2(N)) time by sorting the list on that index and using a binary search. This might not be an issue if we only have a few servers -- but remember that they're persisted for a while -- even small temporary servers, so we should plan for around 1000 entries. Also, this will become more painfull if features like centralized player login are added to the master server. I'll take a look at using a single-file based DB. |
|
Why do we need to persist servers at all?
If we add centralized player login to the master server I'll happily use a MySQL database for this. |
Reliable server age Also, this shouldn't persist the whole
It's worth thinking about what happens if a server changes IP and doesn't use a domain name. ie: is it worth adding the ability for server owners to contact sfan5 and have the server address and port changed for a certain entry. Saving to JSON could become a DDoS risk, so would need to have protections. ie: not writing every time the record changes. |
|
just use postgresql, and json field for non structured data if you want it. It's faster than mongodb and more reliable :) |
|
MongoDB is proprietary, and this hasn't been updated in years anyway |
Tested, but still needs some more work.
It would help if there was something to uniqule identify each server -- currently we just have ip and port, but those often change.
Why?: right now mainly just saves extends popularity values, but can be used for things like uptime-as-a-percentage.