EVE Search - CCP Valar Why MSSQL vs MySQL

All Channels

EVE General Discussion

CCP Valar Why MSSQL vs MySQL

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 2 3 [4] 5 :: one page
Author	Thread Statistics \| Show CCP posts - 1 post(s)
Tara'Quoya Rax Black-Sun	Posted - 2009.06.14 02:50:00 - [91] This entire thread is irrelevant.
Eve Shenanigans	Posted - 2009.06.14 05:10:00 - [92] who cares? the database is not the bottleneck in the system, ffs read the latest dev blog they weren't even capping out current hardware... they made the choice a long time again to go with M$ platforms, why on earth would they even consider changing that after 6+ years? not....going....to....happen.... google the acronym ROI
Eventy One Magellan Exploration and Survey	Posted - 2009.06.14 05:50:00 - [93] Originally by: Tara'Quoya Rax This entire thread is irrelevant. Can't be. It managed to get you to post here.
Phantom Slave JUDGE DREAD Inc.	Posted - 2009.06.14 06:16:00 - [94] Since there's already a thread open talking about CCP's network architecture (to a point), I guess I'll ask my questions here. Has CCP implemented Infiniband? If so, has it been fully integrated?
Eventy One Magellan Exploration and Survey	Posted - 2009.06.14 06:20:00 - [95] Originally by: Phantom Slave Since there's already a thread open talking about CCP's network architecture (to a point), I guess I'll ask my questions here. Has CCP implemented Infiniband? If so, has it been fully integrated? As far as I'm aware they are still working on it. A number of people have asked CCP for updates however. Few have been given - so its still in the works it appears.
KardelSharpeye Gallente Dark Nebula Academy	Posted - 2009.06.14 08:54:00 - [96] Originally by: Agent Known because they love blaming Microsoft for things that go wrong when the server dies. QFT
Lumy Minmatar Sebiestor tribe	Posted - 2009.06.14 09:20:00 - [97] Back on topic: why MSSQL vs MySQL? The answer is really simple. At the time EVE was developed, MySQL was crap. Mega-crap actually. Just look at history of MySQL at wiki. Version 4.0: beta from August 2002, production release March 2003 (unions) (same time EVE was released) Version 4.1: beta from June 2004, production release October 2004 (R-trees and B-trees, subqueries, prepared statements) There is no reason that would justify cost of switching to another DB now. To OP: Are you seriously suggesting to use MyISAM for DB of EVE's size ?!? Joomla! in EVE - IGB compatible CMS.
Jomel Dakos Amarr Dark Sabaoth	Posted - 2009.06.14 09:33:00 - [98] Edited by: Jomel Dakos on 14/06/2009 09:34:52 Originally by: Eventy One Its at microsoft's site - gotta be neutral and objective therefore. Sorry, I prefer 3rd party opinions not associated with MySQL, MSSQL, Oracle etc. If you bother to read it you will find links to many 3rd party opinions. I have read over this thread and have yet to see one decent piece of information why anyone would switch to MySQL. Its all religious nonsense. Dark Sabaoth Recruiting! - Join "Khanid Kingdom" channel.
Shintai Gallente Arx Io Orbital Factories Arx Io	Posted - 2009.06.14 13:23:00 - [99] MySQL is an utter joke in these scales and sizes. MySQL works very fine for small things but thats about it. Basicly there is only 3 options here. MSSQL, Oracle and DB2 I think. -------------------------------------- Abstraction and Transcendence: Nature, Shintai, and Geometry
Hariya	Posted - 2009.06.14 15:51:00 - [100] Originally by: Eventy One 1.5T Pretty small database still. It's pretty common nowadays to be in multi-terabyte range anyways. Tbh mysql is a sick joke. Bad support for more complex sql, doesn't scale up as well to larger databases and hardware, bad online maintenance operations, lack of stuff like multi-dimensional clustered tables, SQL replication for HA, federation features, proper administration tools, automatic monitoring, partitioning, ... I could go on and list hundreds of features that mySQL absolutely ****ing sucks with. mySQL is good for running a forum or something not business critical. When you start doing something serious, get serious tools such as MSSQL, DB2, Oracle, Sybase, etc.
RC Denton	Posted - 2009.06.14 19:35:00 - [101] Originally by: Hariya Originally by: Eventy One 1.5T Pretty small database still. It's pretty common nowadays to be in multi-terabyte range anyways. Tbh mysql is a sick joke. Bad support for more complex sql, doesn't scale up as well to larger databases and hardware, bad online maintenance operations, lack of stuff like multi-dimensional clustered tables, SQL replication for HA, federation features, proper administration tools, automatic monitoring, partitioning, ... I could go on and list hundreds of features that mySQL absolutely ****ing sucks with. mySQL is good for running a forum or something not business critical. When you start doing something serious, get serious tools such as MSSQL, DB2, Oracle, Sybase, etc. Well to be honest I really like MSSQL but federation in MSSQL is a bit of a sick joke also. When Madison comes out then we will see what we will see.
Mioelnir Minmatar Meltd0wn Aggression.	Posted - 2009.06.14 20:17:00 - [102] Originally by: Eventy One Edited by: Eventy One on 11/06/2009 02:31:35 As far as I've seen MySQL 5.x's performance is far better than MySQL 4.x's which would have been around when EVE started. Although MSSQL outperformed MySQL 4, it didn't so by much, but as far as I can tell MySQL 5.x's performance is generally better than MSSQL's especially on 64-bit machines. But with MySQL 5.x ability to change out table formats (MyISAM, BerkeleyDB) gives MySQL 5.x the ability to use MyISAM.... It's really bad style, I know, but that right there is basically where I stopped reading. In a nutshell, MyISAM is a fancy interface to a very tiny perl script and a bunch of textfiles. You simply can't (well, shouldn't) build the core of your enterprise on a storage backend like that. With InnoDB, which is allegedly better - no personal real world experience with that one - we would maybe have a discussion. But seriously, MyISAM? For something like EVE, you want ACID, stored procedures, growable tablespaces, triggers, master/slave mirrors etc. Basically, all the bells and whistles on top of a concrete foundation. Also, because deciding on your database is a long term decision, you want a vendor with a high chance of still being around in 5 years and good support. Having an address that can be sued is also always a plus in the corporate world. Add in the financial limitations of a startup and the database market back then, with the major flagship products running mostly on vendor specifix 64bit risc unix boxes, the field gets slim. Oracle and IBM DB2 might have been a contender (probably hardware issues), PostgreSQL may have been a contender (mirroring was edgy back then), but MySQL certainly was not. In the world of databases, you do a lot of black magic and voodoo, putting your firstborn son into a really undiserable position, but you do not sacrifice correctness for speed if you want to stay around.
Eventy One Magellan Exploration and Survey	Posted - 2009.06.14 23:34:00 - [103] Edited by: Eventy One on 14/06/2009 23:34:08 Originally by: Mioelnir Oracle and IBM DB2 might have been a contender (probably hardware issues), PostgreSQL may have been a contender (mirroring was edgy back then), but MySQL certainly was not. In the world of databases, you do a lot of black magic and voodoo, putting your firstborn son into a really undiserable position, but you do not sacrifice correctness for speed if you want to stay around. From the responses I'm getting here, I'm kind of getting the idea Oracle, and PostgreSQL might have been good contenders. I did consider Postgres, knowing it scales well and had features MySQL didn't see until recently. I'm also aware that alot of Medical dbs that place reliability high on the list of desired features, use Oracle. I'm not sure if CCP has considered reviewing their DB choice in terms of their need for speed. Some people just seem offended at the suggestion CCP should abandon MSSQL (without considering if there are good reasons to do so).
Cassiopeia Draco	Posted - 2009.06.15 11:02:00 - [104] Originally by: Eventy One Edited by: Eventy One on 14/06/2009 23:34:08 Originally by: Mioelnir Oracle and IBM DB2 might have been a contender (probably hardware issues), PostgreSQL may have been a contender (mirroring was edgy back then), but MySQL certainly was not. In the world of databases, you do a lot of black magic and voodoo, putting your firstborn son into a really undiserable position, but you do not sacrifice correctness for speed if you want to stay around. From the responses I'm getting here, I'm kind of getting the idea Oracle, and PostgreSQL might have been good contenders. I did consider Postgres, knowing it scales well and had features MySQL didn't see until recently. I'm also aware that alot of Medical dbs that place reliability high on the list of desired features, use Oracle. I'm not sure if CCP has considered reviewing their DB choice in terms of their need for speed. Some people just seem offended at the suggestion CCP should abandon MSSQL (without considering if there are good reasons to do so). I dont think people are really that bothered what DB is in the backend, as long as its reliable. Unfortuantely MSSQL has now become the proverbial rod for CCP's back, simply because if CCP choose a different provider they face the dilema of migrating all code from MSSQL to whatever other DB they choose, which is not a simple task. Consider that they the only thing they can take from MSSQL is the table structure (even then there are a few tweaks needed) and data, after that everything has to be re-written, and tested thoughly before a go live. Then there are likely to be performance issues as MSSQL execution plans are different to Oracle plans which differ from Postgres etc. To do this your looking at 6-12 months of dedicated time, so simply speaking the Return on Investment to convert to another DB just isnt worth it now. Also you have to consider that doing this could fundamentally break the game all it needs is for a stored proc to be incorrectly re-coded and under stress it breaks.
Dr Slaughter Minmatar Rabies Inc.	Posted - 2009.06.15 14:00:00 - [105] Originally by: Cassiopeia Draco Unfortuantely MSSQL has now become the proverbial rod for CCP's back With the greatest of respect I think the rod they've been beating themselves with for the last five years is the fact that Intel and AMD decided to go multi-core rather than increasing clock speeds. Stackless gave them a fantastic microthreading environment at the time and the assumption was it would get faster as CPU speed increased. When Intel and AMD decided it would be far cheaper for them to go multi-core the only solution for CCP was to start looking at re-writing stackless to handle multiple cores properly. That turned out to be a nightmare. The thing Intel and AMD didn't really seem to take into account is that writing efficient multi-core code is actually very difficult and in some cases pretty much bordering on the impossible (eve's in-space combat loop). So writing efficient multi-core code is, for many developers very difficult and the tools to lower that bar have only really started appearing (cheaply) in the last 2 years. The RAMSAN solves the transaction performance issues CCP had. SQL 2008 will improve performance too. Infiniband connected nodes should improve the speed of moving data between physical servers (and the SOL services) and, possibly, the proxy servers too. But the problem basically keeps coming back to a. 'how do we write services (esp. combat loop) that load balances across cores?' and b. 'how do we write services that take advantage of IB when communicating with each other?' The latter being significantly easier that the former.
ceaon Gallente	Posted - 2009.06.15 14:13:00 - [106] i am not a expert in this but dint oracle buy SUN
Eventy One Magellan Exploration and Survey	Posted - 2009.06.15 14:20:00 - [107] Originally by: ceaon i am not a expert in this but dint oracle buy SUN Something like that.
Kazn Antilli	Posted - 2009.06.15 16:22:00 - [108] Originally by: Korerin Mayul I vote they should get a few Z10's in, nd re-write the whole ting with CICS and DB2. I lawled.
Hariya	Posted - 2009.06.15 17:00:00 - [109] Originally by: Cassiopeia Draco Unfortuantely MSSQL has now become the proverbial rod for CCP's back, simply because if CCP choose a different provider they face the dilema of migrating all code from MSSQL to whatever other DB they choose, which is not a simple task. Yes it is. Simple task. That's what Cobra is going to be for, when it gets released in the next couple weeks.
Kel Nissa	Posted - 2009.06.15 17:56:00 - [110] I would understand a question like: why server side python? (think about stackless python - why did they feel the pressure of such a switch?) But to be honest, trying to switch from mssql to mysql just because you a) hate microsoft or b) have no clue about real databases is simply a joke.
Eventy One Magellan Exploration and Survey	Posted - 2009.06.15 19:28:00 - [111] Originally by: Kel Nissa But to be honest, trying to switch from mssql to mysql just because you a) hate microsoft or b) have no clue about real databases is simply a joke. Except that, no one suggested switching just because Microsoft was detestable. Nor was cluelessness about databases the reason. This thread is about asking CCP to tell us if the need for speed policy has extended as far as DB's or if they've looked at other ones.
Kel Nissa	Posted - 2009.06.15 19:48:00 - [112] Quote: This thread is about asking CCP to tell us if the need for speed policy has extended as far as DB's or if they've looked at other ones. You are a moron when you think that switching the dbms is the correct way to improve database performance.
Dr Chicago	Posted - 2009.06.15 19:52:00 - [113] Sqqqqlllllllllllll...... Until MS releases a security patch that breaks the remote connection capabilities of Mysql, by accident of course, they were just plugging up a security hole ya know. Then there is the migration.... Views, Procs..Buhbye
Dr Slaughter Minmatar Rabies Inc.	Posted - 2009.06.15 20:09:00 - [114] the database is not the problem there is nothing wrong with CCP's using ms-sql the performance 'problems' eve faces are mainly down to re-factoring existing SOL service code to make it more amenable to dealing with stackless's handling of multiple cores and integrating with new hardware features such as IB's RDMA etc. hopefully this thread will have died by the time I get back from holiday and we will have had a HPC Cell update via the community manager. Then again we might still be posting about how to replace the DB with RRDTOOL and re-write the client, proxies and SOL services in Erlang.
B1FF	Posted - 2009.06.15 20:21:00 - [115] Originally by: Eventy One Edited by: Eventy One on 11/06/2009 15:28:00 Anyone who says "MySQL simply isn't fast enough to justify the risks" either hasn't looked at MySQL (recently) or hasn't bench-marked it against other DBs. MySQL is more versatile, and I personally believe more extensible, than MSSQL all while being more efficient. (I should note too - that I didn't raise the idea of Postgres, but ya Postgres would get my vote also) I'm still curious to know what internal discussions the CCP DB folks have on the matter. You hit a key point here, "Recently." EvE is how old? What was the state of MySQL then? Rewriting to use a new DB this late in the game? I'd have to see orders of magnitude of performance increase to even consider it.
Furb Killer Gallente	Posted - 2009.06.15 20:29:00 - [116] Quote: in some cases pretty much bordering on the impossible (eve's in-space combat loop). There is a ****load of stuff going on parallel in eve combat, and additionally it is basicly turn based (with fast turns), so it isnt really border line impossible to multithread it.
Kel Nissa	Posted - 2009.06.15 20:31:00 - [117] Quote: There is a ****load of stuff going on parallel in eve combat, and additionally it is basicly turn based (with fast turns), so it isnt really border line impossible to multithread it. It is already heavily multithreaded. The threads just run on different blades hosting different nodes.
Dr Slaughter Minmatar Rabies Inc.	Posted - 2009.06.16 11:12:00 - [118] Originally by: Kel Nissa Quote: There is a **load of stuff going on parallel in eve combat, and additionally it is basicly turn based (with fast turns), so it isnt really border line impossible to multithread it. It is already heavily multithreaded. The threads just run on different blades hosting different nodes. Various services (space sim, station services, market, etc.) are essentially micro-threaded because that's what stackless is all-about. However stackless only uses one core at a time. So if a service, lets say a solar systems in-space simulation, is running on a node (server blade) in the cluster that has two CPU sockets and multiple cores, that space sim will only be running on one core of one of those servers. So the 'threads' for a service are local to a core and don't run anywhere else. Perhaps reading the infiniband thread I included above would help understanding the architecture and it's inherent problems? Kel Nissa, CCP Lingorm has something to say about the subject of the combat loop, and that is that it's serial. Originally by:** CCP Lingorm OK some general points again Multiple Cores/multi threading can not solve all the problems. Do you really want a multi-threaded combat engine? Your using a more complex setup than me and your hit/damage calculations take longer to perform, than mine on a simpler setup, but because of multi-threading mine are threaded out and complete first so my damage is applied to you first, even though when you damage calculations are completed it turns out I am dead .... not really the situation we want. also with regards why the micro-threading is bound to a single core... Originally by: CCP Lingorm Actually this is a limit of Python. Currently Python is bound to a Single Core (this is called the GIL, Global Interpreter Lock) and it is the centre of a large amount of heated discussion in the Python Community about removing it or keeping it. CCP are trying to move away from having monolithic sol services. The logical conclusion of that process is that they have multiple in-space sims per solar system and each one could sit on a different core. So when there's a big fight at a POS and another at a gate it might be possible for those fights to be processed on different cores. They're not starting with that though, they're starting with splitting out things like station services and so on. Currently to take advantage of all the CPU cores they have on a blade they're loading a solar system onto each core but they can't do any dynamic load balancing. It would be great if when a in-space sim starts to run out of CPU it fragmented into multiple sims, offloading over Infiniban via RDMA to other blades if the local blade was full (that's after shunting the station services elsewhere too).. Anyway...
Kir'ian Minmatar Republic Military School	Posted - 2009.06.16 21:33:00 - [119] I learned a long time ago that statistics are almost meaningless. Even side by side comparisons using different code bases but similiar through put requirements aren't much help. Just too many variables... Soo.... Read your pamplets... flip a coin... sleep on it for a while... and then commit. It is the only viable plan for success. And you might fail. Microsoft, Oracle, MySQL, Postgres, whatever. I remember maintaining a DOS application with B-Trieve and Novell that had better performance than a "identical" fat Delphi app with MSSQL Server, and by an order of magnitude at least. I'm almost sure it had almost nothing to do with MSSQL... I hate Microsoft products to ensure there is always a motivation to look else where and not be sucked into the "EVIL EMPIRE" as I've seen soo many pamphlet readers (aka MANAGEMENT) do. Hurray for MSSQL Server if it is doing well for CCP. And keep them uber techie posts coming... I love 'em.
Sidrat Flush Caldari Life is Experience The Jagged Alliance	Posted - 2009.06.16 23:22:00 - [120] I believe what we all need is a new tech post from CCP direct. List as many variables and tech-statements as possible, and if you feel like being really evil throw in some management speak goblede** too. ANYONE quoting said goblede** you can ignore because they're just clipboard middle-management. Yeah sweeping statement but at least I look things up before assuming I know what acronyms mean.

Pages: 1 2 3 [4] 5 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.