|
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. |
On October 04 2013 09:10 Frigo wrote:Show nested quote +On October 04 2013 08:50 berated- wrote: So, umm? You are able to use these fancy Component Based Entities without classes and objects? Sounds pretty hard... that's a lot of functions... How do you even pass around that much data? It is pretty easy, you just have to eat your veggies and then you can do it too. Show nested quote +While his response was quite baiting, it is completely true that OOP != inheritence. Just because you use an OOP language doesn't mean you have to be an idiot and only use inheritance. Favoring composition ( has a ) over inheritance (is a) generally works for the better anyways. Mixins, aka composition based reuse without inheritance, still does not solve the problem of dynamic component addition and removal, neither the runtime change of the "class" of an entity. Close but no cigar.
You're speaking gibberish. Just stop referring to what you're comparing to as OOP. It's not OOP. Its over using inheritance when you shouldn't, a lot of people who use OOP agree with you.
|
@Frigo: All I'm asking is for you to take a little bit of humble pie. I don't think I should have to bring out my rapsheet to share my opinion and state a couple facts.
|
Firaxis must be clueless, since they don't always use component-based systems.
|
On October 04 2013 01:22 Tobberoth wrote: How is learning OOP and design patterns a substitute for learning about data structures? How will your knowledge of how a hashtable works help when you need the observer pattern? How will your knowledge of a linked list help you when you need the factory pattern?
Those things are not comparable at all. OOP and design patterns are on a completely different level than data structures. heh, I think you kind of sidestepped what i was saying there. my frustration is that people use OOP and Design Patterns as a substitute for understanding data structures. data structures and algorithms are much more fundamental tools, and are practically always used in programming. OOP is more situational, and it's debatable whether learning & thinking in canonical design patterns is even helpful at all. in plenty of situations, it is completely nonessential to know either of these things. like anything else in programming, knowing them will enrich your ability as a computer programmer because they will give you a better understanding of programming culture & the available programming techniques. but they are far from the essential tools they're made out to be by the software engineering gurus. what i am saying is that focusing on them at the expense of learning to design data structures and algorithms is a mistake. unless you want to write only enterprise java, in which case disregard everything i have said.
|
On October 03 2013 22:25 darkness wrote:Show nested quote +On October 03 2013 15:58 sluggaslamoo wrote:Problems such as over-using OOP concepts, you learn by experience, it's not really something you have to be taught. Well just by looking at this thread I'd say 90% of people who seriously studied OO have fallen victim to it and haven't learned. Could you specify why?
I don't know... I don't know how normal peoples brains work so I can't really say why people do it.
But a great example would be discussions right above this post. Typically the discussion relates only to Stroustrup based OOP languages, because other OO languages blur the lines between composition and inheritance so there is no black and white.
|
On October 04 2013 09:48 bigglesbiggles wrote:Show nested quote +On October 04 2013 01:22 Tobberoth wrote: How is learning OOP and design patterns a substitute for learning about data structures? How will your knowledge of how a hashtable works help when you need the observer pattern? How will your knowledge of a linked list help you when you need the factory pattern?
Those things are not comparable at all. OOP and design patterns are on a completely different level than data structures. heh, I think you kind of sidestepped what i was saying there. my frustration is that people use OOP and Design Patterns as a substitute for understanding data structures. data structures and algorithms are much more fundamental tools, and are practically always used in programming. OOP is more situational, and it's debatable whether learning & thinking in canonical design patterns is even helpful at all. in plenty of situations, it is completely nonessential to know either of these things. like anything else in programming, knowing them will enrich your ability as a computer programmer because they will give you a better understanding of programming culture & the available programming techniques. but they are far from the essential tools they're made out to be by the software engineering gurus. what i am saying is that focusing on them at the expense of learning to design data structures and algorithms is a mistake. unless you want to write only enterprise java, in which case disregard everything i have said.
What the hell? That's like saying people use aircraft as a substitute for using hammers. They are completely different aspects of programming and its physically impossible to substitute data-structures with design patterns, it doesn't even make any sense.
OOP and Design Patterns are tried and tested solutions for designing layouts, like having a factory which instantiates your objects. Data-structures and algorithms are "design patterns" for performance and data manipulation, like Big-O notation and Sorting. You can't write an insertion sort using a design pattern, and you can't use data-structures and algorithms to design a layout.
|
On October 04 2013 09:17 berated- wrote:Show nested quote +On October 04 2013 09:10 Frigo wrote:On October 04 2013 08:50 berated- wrote: So, umm? You are able to use these fancy Component Based Entities without classes and objects? Sounds pretty hard... that's a lot of functions... How do you even pass around that much data? It is pretty easy, you just have to eat your veggies and then you can do it too. While his response was quite baiting, it is completely true that OOP != inheritence. Just because you use an OOP language doesn't mean you have to be an idiot and only use inheritance. Favoring composition ( has a ) over inheritance (is a) generally works for the better anyways. Mixins, aka composition based reuse without inheritance, still does not solve the problem of dynamic component addition and removal, neither the runtime change of the "class" of an entity. Close but no cigar. You're speaking gibberish. Just stop referring to what you're comparing to as OOP. It's not OOP. Its over using inheritance when you shouldn't, a lot of people who use OOP agree with you.
Please do not confuse gibberish (e.g. your post) with concepts you are ignorant of. I see a recurring pattern there. Mixins are a valid way to solve a few problems associated with inheritance. However, the problem of game objects are not one of them.
I'm well aware you are under the impression that I am confusing OOP with inheritance, however this is simply not true.
To quote Wikipedia:
Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.
Component based entities are not objects. They are identities with associated components. Component based entities do not have fields. They have dynamic components which are quite unlike fields. Component based entities do not have methods. They have associated processing systems doing bulk updates on all entities they can actually process. Systems communicate via asynchronous message passing, not methods, their "call order" is breadth-first, not depth-first. Component based entities do not have classes. They do not need any arbitrary static categorization, not even one-level inheritance. They might have an originating prototype they were cloned from to help with rapid content creation. Or tag components to help with looking up particular entities, but it should be used sparingly and should not be used as an indicator of the "type" of the entity. Component based entities are not instances of classes. They are identities with associated components. Component based entities do not necessarily have to be implemented with classes, objects, or any OOP concepts. For example there is an MMORPG implementing component based entities in a relational database with strict concurrency guarantees and a nice ability to scale. Can you say the same thing about OOP based solutions? OOP based solutions can not be stored in arbitrary storages, they do not scale. Component based entities do not interact directly. Only the associated processing systems interact, and even then only via asynchronous message passing.
What remaining part of OOP is present in ECS according to your understanding, hm?
On October 04 2013 09:18 CecilSunkure wrote: @Frigo: All I'm asking is for you to take a little bit of humble pie. I don't think I should have to bring out my rapsheet to share my opinion and state a couple facts.
Yes please, I'm very curious for what bugs and maintenance issues you are responsible because of using the wrong tool for the task.
User was warned for this post
|
What the hell? That's like saying people use aircraft as a substitute for using hammers. They are completely different aspects of programming and its physically impossible to substitute data-structures with design patterns, it doesn't even make any sense.
OOP and Design Patterns are tried and tested solutions for designing layouts, like having a factory which instantiates your objects. Data-structures and algorithms are "design patterns" for performance and data manipulation, like Big-O notation and Sorting. You can't write an insertion sort using a design pattern, and you can't use data-structures and algorithms to design a layout.
lol!
how time works: u can spend time learning one thing or spend time learning another thing. people learn charlatan software engineering buzzthought. they'd be better off learning programming. if they want to do programming.
"layout": i assume you mean program structure. if you didn't think about your data structures and algorithms when you're doing this then what are you even doing.
|
Your point would get across much more clearly if you weren't such a fuckhead when you post. Stop attacking the person and behave like a decent human being if that isn't too difficult. Thanks.
|
On October 04 2013 10:45 Blisse wrote: Your point would get across much more clearly if you weren't such a fuckhead when you post. Stop attacking the person and behave like a decent human being if that isn't too difficult. Thanks. I'm not very tolerant of retarded one-liners ignoring or deliberately misinterpreting my argument and then cracking a joke about how crap my point is and how stupid I am. So naturally I give them the same respect.
|
On October 04 2013 11:02 Frigo wrote:Show nested quote +On October 04 2013 10:45 Blisse wrote: Your point would get across much more clearly if you weren't such a fuckhead when you post. Stop attacking the person and behave like a decent human being if that isn't too difficult. Thanks. I'm not very tolerant of retarded one-liners ignoring or deliberately misinterpreting my argument and then cracking a joke about how crap my point is and how stupid I am. So naturally I give them the same respect.
No, but you respond to people who actually criticize you decently in the same manner soo... I kind of tend to believe you're just a dick
|
On October 04 2013 11:06 Cyx. wrote:Show nested quote +On October 04 2013 11:02 Frigo wrote:On October 04 2013 10:45 Blisse wrote: Your point would get across much more clearly if you weren't such a fuckhead when you post. Stop attacking the person and behave like a decent human being if that isn't too difficult. Thanks. I'm not very tolerant of retarded one-liners ignoring or deliberately misinterpreting my argument and then cracking a joke about how crap my point is and how stupid I am. So naturally I give them the same respect. No, but you respond to people who actually criticize you decently in the same manner soo... I kind of tend to believe you're just a dick I don't think berated-'s post was a legitimate one, it sounded more like he was deliberately misinterpreting ECS?
|
On October 04 2013 11:16 Frigo wrote:Show nested quote +On October 04 2013 11:06 Cyx. wrote:On October 04 2013 11:02 Frigo wrote:On October 04 2013 10:45 Blisse wrote: Your point would get across much more clearly if you weren't such a fuckhead when you post. Stop attacking the person and behave like a decent human being if that isn't too difficult. Thanks. I'm not very tolerant of retarded one-liners ignoring or deliberately misinterpreting my argument and then cracking a joke about how crap my point is and how stupid I am. So naturally I give them the same respect. No, but you respond to people who actually criticize you decently in the same manner soo... I kind of tend to believe you're just a dick I don't think berated-'s post was a legitimate one, it sounded more like he was deliberately misinterpreting ECS? All berated was doing is pointing out how you're assuming whenever someone says OOP that they are using inheritance. He was also saying that the points regarding composition vs inheritance are agreed upon from many people, including many who use OOP.
Really, your problem Frigo is that you're all hyped about the idea of an ECS and you keep trying to shove it down everyone's throat. ECSs are a subset of data oriented design. This means they are useful for either simplifying design problems, or optimizing operations into cache friendly data transformations. That's it. The reason ECSs are hype is because of diehards like yourself throwing around the term as a buzzword.
Taking on portions of a game engine with data oriented design is a more broad pragmatic approach than subscribing religiously to any one pattern subset.
Data oriented design lets performance sensitive areas gain large performance benefits, along with a great simplification of data dependencies. This further allows optimization beyond cache utilization into the realm of threading. Not only does it help threading, but makes it trivial. The organization of data (and its dependencies) is why an ECS can be useful in a game engine.
Usually what strict and gung-ho ECS enthusiasts fail to realize is that various portions of a game engine are best completed with different design patterns, as an ECS does not provide much flexibility. Often times flexibility and generality matter, whereas performance does not.
Apply patterns when needed, and don't try to shove buzzwords at everyone.
Edit: Also people will respond to you better if you don't act like you're holier than thou.
|
On October 04 2013 10:34 Frigo wrote: For example there is an MMORPG implementing component based entities in a relational database with strict concurrency guarantees and a nice ability to scale. Can you say the same thing about OOP based solutions? OOP based solutions can not be stored in arbitrary storages, they do not scale.
I don't know what paradigms have to do with database performance.
However you should look at CouchDB which is a document oriented database (as opposed to a relational database) which scales much better than RDBMS through replication and the fact that it doesn't use tables. Especially for games, relational databases are an inferior solution even just performance wise, not to mention how much easier it is to maintain code-wise.
For the record you normally use an ODM with CouchDB which is object oriented.
|
On October 04 2013 12:16 sluggaslamoo wrote:Show nested quote +On October 04 2013 10:34 Frigo wrote: For example there is an MMORPG implementing component based entities in a relational database with strict concurrency guarantees and a nice ability to scale. Can you say the same thing about OOP based solutions? OOP based solutions can not be stored in arbitrary storages, they do not scale.
I don't know what paradigms have to do with database performance. However you should look at CouchDB which is a document oriented database (as opposed to a relational database) which scales much better than RDBMS through replication and the fact that it doesn't use tables. Especially for games, relational databases are an inferior solution even just performance wise, not to mention how much easier it is to maintain code-wise. For the record you normally use an ODM with CouchDB which is object oriented.
CouchDB would be a terrible choice for an MMO unless you want your latency to go through the roof. CouchDB does a fsync on each database write which reduces your database performance to disk IO, crippling your ability to leverage public and private cloud infrastructure. It also uses HTTP for database communication which has relatively high overhead and does just in time index calculation which can bring your database to a standstill - i.e your performance is going to be extremely variable. Finally, CouchDB handles write conflicts through versioning, which has the potential to introduce serious bugs into your MMO (think item cloning etc). The main company/creators behind CouchDB realised these issues and are currently working on a successor, CouchBase, but it's not stable yet.
A better choice would be something like Redis which is a simple, atomic key-value store that keeps all data in RAM. Funnily enough, neither CouchDB nor Redis are particularly OO, they're simple data structure oriented instead. As it turns out, simple data structures map nicely into pretty much everything, so I agree with that guy above that you should spend more time learning about how to use those and algorithms effectively rather than learning something like "design patterns" and OO, because the reality is that different paradigms are good for different problems but they all involve data structures and algorithms. I've read a fair chunk of "Coders at Work" which includes interviews with a whole bunch of notable hackers and coders and the vast majority of them agree with this sentiment, so there is definitely some merit to it.
|
On October 04 2013 13:03 drafael wrote:Show nested quote +On October 04 2013 12:16 sluggaslamoo wrote:On October 04 2013 10:34 Frigo wrote: For example there is an MMORPG implementing component based entities in a relational database with strict concurrency guarantees and a nice ability to scale. Can you say the same thing about OOP based solutions? OOP based solutions can not be stored in arbitrary storages, they do not scale.
I don't know what paradigms have to do with database performance. However you should look at CouchDB which is a document oriented database (as opposed to a relational database) which scales much better than RDBMS through replication and the fact that it doesn't use tables. Especially for games, relational databases are an inferior solution even just performance wise, not to mention how much easier it is to maintain code-wise. For the record you normally use an ODM with CouchDB which is object oriented. CouchDB would be a terrible choice for an MMO unless you want your latency to go through the roof. CouchDB does a fsync on each database write which reduces your database performance to disk IO, crippling your ability to leverage public and private cloud infrastructure. It also uses HTTP for database communication which has relatively high overhead and does just in time index calculation which can bring your database to a standstill - i.e your performance is going to be extremely variable. Finally, CouchDB handles write conflicts through versioning, which has the potential to introduce serious bugs into your MMO (think item cloning etc). The main company/creators behind CouchDB realised these issues and are currently working on a successor, CouchBase, but it's not stable yet. A better choice would be something like Redis which is a simple, atomic key-value store that keeps all data in RAM. Funnily enough, neither CouchDB nor Redis are particularly OO, they're simple data structure oriented instead. As it turns out, simple data structures map nicely into pretty much everything, so I agree with that guy above that you should spend more time learning about how to use those and algorithms effectively rather than learning something like "design patterns" and OO, because the reality is that different paradigms are good for different problems but they all involve data structures and algorithms. I've read a fair chunk of "Coders at Work" which includes interviews with a whole bunch of notable hackers and coders and the vast majority of them agree with this sentiment, so there is definitely some merit to it.
1 posts... and biggles has 5...
Are you the same poster as the above guy you agree with?
CouchDB latency is low, due to replication, compared to an RDMS. Sure if you don't replicate, you might have issues when you have a large player base, but THAT'S WHY YOU REPLICATE.
Second of all he mentioned "Scalability", CouchDB scales much better than any RDMS, also unsurprisingly, due to replication. There's also nothing stopping you from using a RAM based middleware between CouchDB and the Server.
Thirdly I said RDMS's are an inferior solution, which implies that Redis and other no-SQL databases are also a better alternative.
Fourthly every game isn't an MMO. In any case, you are definitely not going to store an MMO's worth of data all in RAM, eventually some data is going to be stored on the disk, you are going to have the exact same problems in RDMSs, except worse because of locking and lack of support for concurrency.
Fifthly you are straw-manning, I'm not disagreeing with your point, I'm saying your argument doesn't make any sense. They are mutually exclusive concepts, you can't substitute one for the other. Someone who doesn't learn both will just be a bad programmer. If you learn only data-structures and algorithms, you will write bad code, if you learn only OO and Patterns, you will write bad code.
|
lollllll, i'm not that petty. is your last paragraph directed at me?
assuming it is, my argument does make sense because there are other programming paradigms than OO / Design Patterns, and plenty of OO programmers don't use the popular/named design patterns at all or even like them. there are problem domains in which you don't need object orientation or design patterns. there are approaches to programming that are alternative to them. there is good programming that is not object oriented programming. do you know who donald knuth is? do you understand how the linux kernel works? it is ignorant to say that oo/patterns are essential to being a good programmer.
|
On October 04 2013 13:18 sluggaslamoo wrote:
1 posts... and biggles has 5...
Are you the same poster as the above guy you agree with?
CouchDB latency is low, due to replication, compared to an RDMS. Sure if you don't replicate, you might have issues when you have a large player base, but THAT'S WHY YOU REPLICATE.
Second of all he mentioned "Scalability", CouchDB scales much better than any RDMS, also unsurprisingly, due to replication. There's also nothing stopping you from using a RAM based middleware between CouchDB and the Server.
Thirdly I said RDMS's are an inferior solution, which implies that Redis and other no-SQL databases are also a better alternative.
Fourthly every game isn't an MMO. In any case, you are definitely not going to store an MMO's worth of data all in RAM, eventually some data is going to be stored on the disk, you are going to have the exact same problems in RDMSs, except worse because of locking and lack of support for concurrency.
Fifthly you are straw-manning, I'm not disagreeing with your point, I'm saying your argument doesn't make any sense. They are mutually exclusive concepts, you can't substitute one for the other. Someone who doesn't learn both will just be a bad programmer. If you learn only data-structures and algorithms, you will write bad code, if you learn only OO and Patterns, you will write bad code.
Wow, sorry for triggering a nerve. No, I'm a different person, and replication will only get you so far with write heavy applications, same as middleware - the problem isn't read performance, it's write. I do agree that for low write applications where write latency doesn't matter, CouchDB is a nice technology, and that you could potentially partition or structure your code around multiple databases - e.g high read/write to redis, medium-low read/low write to Couch. Trying to do everything with Couch is just going to cost you a bunch and not perform as well - the thing about the newer generation of databases is that they are designed for specific requirements rather than being a drop-in do-everything-averagely type technology like the traditional SQL ones. I agree that for games RDMS are probably almost never going to be the optimal solution, but depending on requirements, some NoSQL databases will likely actually be a worse choice, so I don't think you can really make such a sweeping statement. For example, what you said about storing an MMO's worth of data in RAM - if your data set is simply too big to do this cost effectively, then redis is probably a worse choice than an RDMS, if that makes sense. RAM is cheap though, especially on the public cloud, and you can quite easily set up 256GB+ (or more!) redis clusters if you want.
Some online games are going to be low write I guess, but I'm not sure that an MMO is one of these. I realise that every game isn't an MMO, but as the person you were replying to was talking about an MMO and you suggested looking at CouchDB, I'm sure you can understand why I continued in the same vein. To give you an idea of some numbers, as part of my work I actually did a bunch of testing on a massive CouchDB cluster managed by Cloudant. Here is a chart of latency:
(can't use the img tag sadly: http://s24.postimg.org/crrbcddb9/julep.png )
Now if 200 - 600+ ms latency is acceptable for your game/mmo/whatever, go for it. Admittedly, this is a _really_ heavily used cluster, and maybe even an MMO wouldn't use it so heavily. But even best case, we found 50~100ms database latency.
To address your last point, I agree with you - a good programmer should expose themselves to a variety of paradigms, learning and immerse themselves in general. I was just commenting on the relative importance.
|
On October 04 2013 14:08 drafael wrote:Show nested quote +On October 04 2013 13:18 sluggaslamoo wrote:
1 posts... and biggles has 5...
Are you the same poster as the above guy you agree with?
CouchDB latency is low, due to replication, compared to an RDMS. Sure if you don't replicate, you might have issues when you have a large player base, but THAT'S WHY YOU REPLICATE.
Second of all he mentioned "Scalability", CouchDB scales much better than any RDMS, also unsurprisingly, due to replication. There's also nothing stopping you from using a RAM based middleware between CouchDB and the Server.
Thirdly I said RDMS's are an inferior solution, which implies that Redis and other no-SQL databases are also a better alternative.
Fourthly every game isn't an MMO. In any case, you are definitely not going to store an MMO's worth of data all in RAM, eventually some data is going to be stored on the disk, you are going to have the exact same problems in RDMSs, except worse because of locking and lack of support for concurrency.
Fifthly you are straw-manning, I'm not disagreeing with your point, I'm saying your argument doesn't make any sense. They are mutually exclusive concepts, you can't substitute one for the other. Someone who doesn't learn both will just be a bad programmer. If you learn only data-structures and algorithms, you will write bad code, if you learn only OO and Patterns, you will write bad code. Wow, sorry for triggering a nerve. No, I'm a different person, and replication will only get you so far with write heavy applications, same as middleware - the problem isn't read performance, it's write. I do agree that for low write applications where write latency doesn't matter, CouchDB is a nice technology, and that you could potentially partition or structure your code around multiple databases - e.g high read/write to redis, medium-low read/low write to Couch. Trying to do everything with Couch is just going to cost you a bunch and not perform as well - the thing about the newer generation of databases is that they are designed for specific requirements rather than being a drop-in do-everything-averagely type technology like the traditional SQL ones. I agree that for games RDMS are probably almost never going to be the optimal solution, but depending on requirements, some NoSQL databases will likely actually be a worse choice, so I don't think you can really make such a sweeping statement. For example, what you said about storing an MMO's worth of data in RAM - if your data set is simply too big to do this cost effectively, then redis is probably a worse choice than an RDMS, if that makes sense. RAM is cheap though, especially on the public cloud, and you can quite easily set up 256GB+ (or more!) redis clusters if you want. Some online games are going to be low write I guess, but I'm not sure that an MMO is one of these. I realise that every game isn't an MMO, but as the person you were replying to was talking about an MMO and you suggested looking at CouchDB, I'm sure you can understand why I continued in the same vein. To give you an idea of some numbers, as part of my work I actually did a bunch of testing on a massive CouchDB cluster managed by Cloudant. Here is a chart of latency: (can't use the img tag sadly: http://s24.postimg.org/crrbcddb9/julep.png ) Now if 200 - 600+ ms latency is acceptable for your game/mmo/whatever, go for it. Admittedly, this is a _really_ heavily used cluster, and maybe even an MMO wouldn't use it so heavily. But even best case, we found 50~100ms database latency. To address your last point, I agree with you - a good programmer should expose themselves to a variety of paradigms, learning and immerse themselves in general. I was just commenting on the relative importance.
Thing is MMO's have hardly any write compared to corporate business apps. The only time you are writing to the database is when the player leaves or the server shuts down, all player instances are stored in memory. 800ms is nothing when the only time you get it is during the login phase, at almost every other point in the game the database isn't even being accessed.
There may be instances where back ups are done, but this is where replication is perfect, you now have so much redundancy, if a server goes down, it doesn't even matter, and you have a system which is designed for replication, rather than having to do it manually.
There is a ton of read however, from players looking up profiles of other players, this can't be done through the currently connected server instance for obvious reasons and would require a read from the database through the primary cluster.
Compare this to a site like Amazon or Reddit where people are constantly writing reviews and posting. You also need a ton of indexing and sorting capability, games don't need that nearly as much. Replicated NoSQL databases are a perfect fit for MMOs and all genres of games.
Some AAA titles use BLOBs to get around the issues associated with SQL, when they could just use document oriented DBs which are basically like using blobs except much more useful.
|
Before you select a database tech, you have to have fairly good ideas about what you need in terms of
#1 most important: what is actually being stored?
then: read latency (random) read latency (for lots of shit) write latency (random) write latency (for lots of shit) read throughput write throughput consistency level of the above operations (do you want to offer really fast not-terribly-consistent reads, or really slow consistent reads? or both?) how conflicts between machines/replicas/clients/whatever are handled for writes what happens when one of your db machines takes a shit and dies what happens when an individual machine doing a read or write query decides that it's cool to suddenly take forever to do disk i/o
etc etc
Before you actually settle on what your actual requirements are, discussing individual db choice is a pointless endeavor.
For example:
for an mmo, maybe it's ok to store most things in a very fast inmemory cache. Things like, "where is this dude standing?, where is that dude standing? what is dude1 doing? what is dude2 doing?"
Maybe then things that are more static (what is each person carrying?) can be stored off the individual server, on some shared db. That db might have much less stringent requirements for latency & throughput. Maybe you only write to this every so often, instead of every action.
But then we're still leaving unanswered what happens if an individual server that has your inmemory cache of stuff-that's-going-on dies, starts being slow like a bitch, or w/e. Who knows? Do we just drop it and say "oops sorry, machine error, all that shit you just did disappeared"? I've played games that do that. It kinda sucks.
There's just too many open questions to have a serious discussion about "what db to use for an mmo." It's just silly to talk about it in this format.
|
|
|
|