Myrlin wrote:I want to be optimistic and say that KK planned out item tracking properly and that having a separate database means that they won't have any performance degredation, but honestly I can't. KK's track record has been pretty bad so far.
My only comment to this has to be one of perspective. Compared to other MMORPGs who have done a good job of providing a stable client with fast databases and servers for a game that is tick-based, yes KK doesn't have a great track record. However, when you consider that NC is not tick-based, it's a nearly-real-time FPS with many more updates between the client and server every couple of seconds than any other MMORPG in existence I would say KK has done a fantastic job.
The fact that a small company could produce a product that has all of the unique groundbreaking features that NC has is pretty amazing to me. How many other MMORPGs have successfully balanced FPS combat that takes skills into account?
Ok, so KK hasn't done everything with NC they could have. They've fallen short in the past, but let's give them at least some of their props for what they have done.
Myrlin wrote:Looking at this from a technical side, since I know you know IT stuff Lynx
Yes, I'm a capacity planner. It's my job to take these things into account, but I have a lot bigger budget.
Myrlin wrote:a separate database is great for queries, but something has to put that data in there. That means that every action in the current database needs to trigger an update in the new tracking database. These new triggers means processing for the current database (even if it's just a miniscule amount for each transaction) that didn't exist previously. It also means LAN traffic between the database servers that didn't exist previously. I wouldn't be surprised if item-tracking introduced some odd bugs because some action is waiting on a query of the new database and that query was slowed down because it bumped into traffic between the servers. It's a situation that they could plan for and yet still have problems with because they can't test with the thousands of users they will have at retail.
I have to agree with you to some extent, but you're missing something I think. First, it's been stated that there is an item tracking database for each server cluster, not one for all server clusters.
Disclaimer: I have no knowledge of the servers and how they are configured, this is pure speculation.
Let's say we have a cluster of servers, each with their own "function". For the purposes of illustration, let's say we have three types of servers. The game server, the database server, and the item tracking server.
I think of the item tracking database like a log file. It primarily receives and logs what happens to a particular item. In other words, it's primarily update-only. GMs and KK would be able to use tools to query the history of a particular item, but regular players don't interact with item tracking.
The game server receives an event that affects inventory. It fires off an "update" query to both the database server updating the players current inventory (or gogo or cabinet or whatever) and item tracking database server in parallel. It must must wait for the database to say "ok, update received and here's the new inventory". For item tracking database, however, it just needs a confirmation that the event was stored succesfully.
Done this way, you may have a slight degradation in performance from the game servers, but it doesn't put an extra load on the existing database server. The item tracking database doesn't need to know anything about what kind of item it is, just what's happened to it. A simple query could tie the unique item number in the item tracking database with the unique item number in the inventory database, no?
At any rate, that's how I'd implement item tracking.
