Topic: Oracle gets to kill MySQL

[toasty0]

Hope the SFC4 database is not based upon MySql as some argued to do. If what the article below alledges is true then all that is left is for the MySql corpse to decompse into legacy.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Updated: Oracle said Monday that it will buy Sun Microsystems for $9.50 a share in cash, or about $5.6 billion excluding debt, in a deal that plunges Larry Ellison & Co. into the hardware market. The company added that the acquisition of Java “is the most important software Oracle has ever acquired.”

Sun Chairman Scott McNealy (left) with Oracle chief Larry Ellison.
With the move- valued at $7.4 billion including Sun’s debt - Oracle also becomes a full-fledged hardware player. Oracle has been dabbling with the storage appliance with HP, but the acquisition of Sun puts the company in an entirely different realm. Oracle and Sun have been long-time partners.

On a conference call with analysts, Ellison said that Oracle’s acquisitions to date have been market leaders - PeopleSoft, Hyperion and Siebel. With Sun, Oracle said Java and Solaris are the keepers in the deal.

“More Oracle databases run on the Solaris Sparc than any other system,” said Ellison, noting Linux was second. “We’ll engineer the Oracle database and Solaris operating system together. With Sun we can make all components of the IT stack integrated and work well.”

Regarding Java, Ellison said it wanted Sun so it could own the building blocks for its middleware.  Oracle’s middleware is built on Java and the applications giant said it will continue to invest in the software.

Ellison said in a statement:

“The acquisition of Sun transforms the IT industry, combining best-in-class enterprise software and mission-critical computing systems. Oracle will be the only company that can engineer an integrated system – applications to disk – where all the pieces fit and work together so customers do not have to do it themselves. Our customers benefit as their systems integration costs go down while system performance, reliability and security go up.”

That pitch sort of sounds like Apple’s approach on the consumer side. Apple’s strategy is to integrate hardware and software to make things easy. Oracle with Sun appears to be the Apple of the enterprise. Indeed, Oracle President Charles Phillips noted that the company is looking to offer everything from apps to the disk.

The data center gets (more) interesting
It’s clear that Oracle is targeting the next generation data center—as is the rest of the industry. Here’s the list of tech titans looking to remake the data center:

IBM;
HP;
Cisco;
Dell;
Oracle;
And a bevy of other players—Juniper, EMC, VMware—from various angles.
The technical side of this Oracle-Sun deal also is notable. Oracle’s stack of IT stuff now includes:

Java;
Solaris;
Enterprise applications ranging from CRM to ERP to business intelligence;
The database (Oracle and MySQL);
The middleware;
The storage hardware;
Cloud computing services;
And servers.
Oracle’s initial game plan is to focus on existing joint customers. That base represents a large data center pie. My hunch is that Ellison saw the possibilities of integrating hardware and software with Oracle’s Exadata database machine. Ellison boasted that the Exadata machine has seen strong demand on Oracle’s earnings conference call.

In the end, Oracle’s acquisition of Sun won’t change the company’s overall game plan: Offer the customer a lot of product—apps, languages, middleware, databases—lock that enterprise in and collect the dough.

The art of war
So what does Oracle really want with Sun?

If you subscribe to the art of war approach to the tech sector, Ellison’s move to buy Sun makes a lot of sense. To wit:

Oracle gets to annoy IBM—and own Java—over a few pennies a share more than Big Blue was willing to pay.
Oracle gets to kill MySQL. There’s no way Ellison will let that open source database mess with the margins of his database. MySQL at best will wither from neglect. In any case, MySQL is MyToast.
Sun has a big installed base. All the better to upsell applications into.
Oracle’s database runs on Solaris systems. Oracle fine tunes the systems, charges a premium and ditches the low-margin hardware.
And speaking of hardware. Sun’s manufacturing is outsourced so there isn’t a lot of baggage—real estate, equipment and labor—to worry about. If Oracle decides to milk then wind down the hardware business it’s relatively easy.
And Sun was relatively cheap compared to Oracle’s other acquisitions. The price was above the Hyperion buyout but below PeopleSoft and Siebel.
Making Sun more efficient
As with Oracle’s other acquisitions, Ellison plans to make its target more efficient and squeeze better profits. Oracle said the Sun deal will add at least 15 cents a share in non-GAAP earnings in the first year of the deal closing. That equates to $1.5 billion in Oracle’s non-GAAP earnings. Oracle president Safra Catz said the Sun deal will “be more profitable in per share contribution in the first year than we had planned for the acquisitions of BEA, PeopleSoft and Siebel combined.”

Catz said Oracle will fund the Sun purchase with a mix of cash and debt. Catz added that Oracle will “run Sun at substantially higher margins.”

That statement is pretty heady given that Sun is losing money

For Sun, Oracle provides an exit from troubled negotiations with IBM. Big Blue was interested in Sun but bailed when the two sides couldn’t agree on price. Oracle stepped up and was willing to pay the $9.50 a share Sun wanted. Meanwhile, regulatory concerns won’t be much of an issue since Oracle hasn’t been a hardware player—until now.

In addition, Oracle saves Sun management from what could have been a complete debacle following the IBM takeover talks. The Sun board had been split on the IBM deal. Today, it’s all roses. Sun Chairman Scott McNealy said the Oracle-Sun marriage was a “natural evolution” and noted he was “thrilled” about the deal. Sun CEO Jonathan Schwartz added that the Oracle takeover will advance innovation in the marketplace.

It’s needless to say, but Sun’s board approved the Oracle purchase unanimously. The deal is expected to close in the summer.
http://blogs.zdnet.com/BTL/?p=16598

[Bonk]

No decision there, not even discussed. The flatfile will most likely remain.

MySQL is GPL(v2). (see attached files from the root of the 5.1.34 source tree) Sun cannot take it away from the OSS community.

http://dev.mysql.com/downloads/mysql/5.1.html#source

I'll download a few of the source branches today to be sure, in case they yank them.

This cannot mean the end of MySQL. Worst case: fork => mysql-free.

Unless I am missing something....

[Nemesis]

Hope the SFC4 database is not based upon MySql as some argued to do. If what the article below alledges is true then all that is left is for the MySql corpse to decompse into legacy.

Open Source.  It may well continue regardless of the wishes of Oracle.

Oracle gets to annoy IBM—and own Java—over a few pennies a share more than Big Blue was willing to pay.

Oracle gets to kill MySQL

IBM canceling was over antitrust issues not merely money.  They didn't want to have this hanging in limbo for the next year or two only to find out they can't make the purchase after spending a fortune to set it up.

[Nemesis]

Link to site

MySQL - already forked and has a new home.

MariaDB 5.1 is based on MySQL 5.1.

MariaDB will be kept up to date with the latest MySQL release from the same branch.

In most respects MariaDB will work exactly as MySQL; all commands, interfaces, libraries and APIs that exist in MySQL also exist in MariaDB.

[toasty0]

No decision there, not even discussed. The flatfile will most likely remain.

Interesting choice. The files must not be very big if you guys are willing to incur the overhead a flatfile creates.

[Bonk]

Link to site

MySQL - already forked and has a new home.

Interesting. It looks like "Monty" knew this was coming since at least Feb 21st. 

No decision there, not even discussed. The flatfile will most likely remain.

Interesting choice. The files must not be very big if you guys are willing to incur the overhead a flatfile creates.

Again, it has not been discussed or decided.  That said, the performance of the flatfile will always be superior to any external DBMS regardless of database size (further explanation on request). The advantage to using an external db is the ability to edit the data while the server is running (with limitations). However, equivalent functionality could be achieved with the flatfile by adding functions to edit the flatfile directly from the running kit console. Make sense?

All that said...

Looks like it might be time to move to postgresql all around. In general the OSS community opinion is that it is a superior DBMS anyway. SMF can connect to postgre and I expect the modifications to the OP serverkit to connect to postgre would not be that difficult. (mainly just query compatibility - since it would still be going along the same path ADO->ODBC->DBMS) Though down the road I would like to drop ADO/ODBC altogether and use DBMS client libraries directly (be they MySQL or postrgresql) - licensing being the complication in that case - MySQL's FOSS exception covered it - I wonder if postgresql has a similar exception for the use of client libs in a proprietary app (the op serverkit)?.

[toasty0]

I can see going with the flatfile DBMS when working within the game framework/executable as the number of assets cannot be all that great that a RDBMS would show a measurable enough improvement in performance to offset any overhead of the system itself. But for for a Dynaverse-like player system? Am I missing something?

[Bonk]

Here's my thinking (feel free to poke holes in it):

1) There is a near complete dbms in the serverkit code itself (the flatfile "engine").
2) Currently the MySQL storage functionality uses MS-ADO->ODBC->MySQL
3) When it comes down to it MySQL (or Oracle or Postgre...) do the same thing as the internal flatfile engine: store data on disk in files.
3) How can it be faster to send the data to another application (especially as currently through ADO/ODBC)?

The only benefit is the ability to edit the db outside the running server (with knowledge of what edits are possible) e.g. the OCI.

Look at it this way:

You could run the serverkit with no persistent storage to disk (all in memory). Of course that would suck as progress would be lost on crashes, power outages etc... OK, so we need to dump the key parts of working memory necessary to restore the server to a particular state providing persistent storage. It does not make sense to me to store that data via a database layer to an external database application for performance reasons when you can periodically dump it to disk in its "native" format just like that.

The reasons to use an external database application are not performance related.

Make sense in that context?

[toasty0]

Here's my thinking (feel free to poke holes in it):

1) There is a near complete dbms in the serverkit code itself (the flatfile "engine").

Near complete is not complete. I thought that Josh (I think it was Josh) said the hooks had been coded in for an external/internal  RDBMS.

2) Currently the MySQL storage functionality uses MS-ADO->ODBC->MySQL

This is an issue?

3) When it comes down to it MySQL (or Oracle or Postgre...) do the same thing as the internal flatfile engine: store data on disk in files.

It is how quickly the data/table is read from and written to that matters. With a flatfile each transaction requires a complete read of each table in its entirety to retrieve, update, delete or insert data. With an RDBMS that time can be significantly less due to how the data is…well…related in the database.

3) How can it be faster to send the data to another application (especially as currently through ADO/ODBC)?

The only benefit is the ability to edit the db outside the running server (with knowledge of what edits are possible) e.g. the OCI.

Look at it this way:

You could run the serverkit with no persistent storage to disk (all in memory). Of course that would suck as progress would be lost on crashes, power outages etc... OK, so we need to dump the key parts of working memory necessary to restore the server to a particular state providing persistent storage. It does not make sense to me to store that data via a database layer to an external database application for performance reasons when you can periodically dump it to disk in its "native" format just like that.

The reasons to use an external database application are not performance related.

Make sense in that context?

Yes and no. If I understand your structure correctly, right now you’re loading the whole database, then every time there is a unit move, resources consumed, a map hex flips, or a battle resolution the whole database is being updated with a complete table/database scan (remember: that is the only way a flatfile can be updated) to find the appropriate record to update. Then this change has to be pushed out to each player. Get a game with 6+ players moving rapidly through a Dynaverse, missions being assigned, collecting and updating battle results and I see a serious lot of downside to continuing with the flatfile system and the longer disk scans.
Of course YMMV.

[Bonk]

No, no.. you're still missing it.

The "flatfile" (it is not actually flat) database engine in the OP serverkit is quite well developed. It makes up the bulk of the serverkit code actually. Stored procedures.. the works, all written by Taldren. It all works in memory and is periodically dumped to disk (a gf setting of every so many turns and on shutdown). When using the "flatfile", queries are not made against the file on disk, but the active data in RAM

Later, (around EAW 2036) MagnumMan tacked on an ADO interface to a mysql database for the persistent storage. Which by definition will be slower but offers the ability to edit the live db. That which need not persist still runs as if it were on the "flatfile".

I think calling the binary database dump format of the serverkit the "flatfile" might be what is misleading here.

EDIT: have a look at the db structure from the .sql file in the serverkit and compare that to the source to EDDBEDIT and you will start to get the idea.

[marstone]

EDIT: have a look at the db structure from the .sql file in the serverkit and compare that to the source to EDDBEDIT and you will start to get the idea.

a little interjection on the EDDBEDIT was looking at it, and seen you have some area of data on the ships that isn't figured out yet.  Was wondering if you guys might think that ship crew might still be in the game but dereferenced so you can't mess with it.  would make sense as you would have had to rewrite alot of the code to pull it out, but almost none to just take the UI part away so it falls into the background.

If that is right, adding back crew would be easy.  Still looking into this part also.

[Bonk]

Dave (AKA: Evil Dave [ED], NuclearWessels) is the author of EDDBEDIT and can best answer for the few holes in his decoding.

However the officers have been played with. Myself, I have not noticed any effects of modifying the crew of a human piloted ship (but I did not test very thoroughly at all), but I know Karnak knows the ins and outs of the effects of AI crew in mission scripts.

If I recall correctly I could put crew into the OCI and then we can test its effects (if any) on human piloted ships. (note also with the OCI we can fly fleets of more than three (but still can only supply three in game - no OCI supply yet, but it is totally doable)

OK, I need to get an SQL server up and running again. I have a few missions from Karnak and Dave to test, but I really will not have much energy for it until the end of the month.... hmmm.. or maybe I need the distraction.

I think some older OCI code is in the ftp downloads here somewhere... (The OCI being mine, but I used Dave's work and the help of some others in decoding the blobs (flatfile remnants/structs stored in the MySQL db as blobs).

Um, what was the question? I think that might answer it.

P.S. The big story here is really that Oracle bought Sun, scooping IBM. I'm not really worried about the future of open source database software, it will live on.

[Lepton]

Not to interject my totally novice information, but I am aware that Cryptic in developing a database for their MMO engine decided that SQL was too inefficient for their needs and designed their own database engine that I think may be object-oriented.  SQL is not the end-all, be-all it would seem.

[toasty0]

No, no.. you're still missing it.

The "flatfile" (it is not actually flat) database engine in the OP serverkit is quite well developed. It makes up the bulk of the serverkit code actually. Stored procedures.. the works, all written by Taldren. It all works in memory and is periodically dumped to disk (a gf setting of every so many turns and on shutdown). When using the "flatfile", queries are not made against the file on disk, but the active data in RAM

Ok, I get it now. You're misusing the term flatfile which was sending me off on a wild goode chase, after a red herring so to speak. FWIW, and it ain't all that important, when data is kept in RAM/Memory it is called the cache--but I think you knew that already.

Later, (around EAW 2036) MagnumMan tacked on an ADO interface to a mysql database for the persistent storage. Which by definition will be slower but offers the ability to edit the live db. That which need not persist still runs as if it were on the "flatfile".

I think calling the binary database dump format of the serverkit the "flatfile" might be what is misleading here.

EDIT: have a look at the db structure from the .sql file in the serverkit and compare that to the source to EDDBEDIT and you will start to get the idea.

Oh darn, you're going to make me do that.

[toasty0]

Not to interject my totally novice information, but I am aware that Cryptic in developing a database for their MMO engine decided that SQL was too inefficient for their needs and designed their own database engine that I think may be object-oriented.  SQL is not the end-all, be-all it would seem.

 

 

[Nemesis]

Near complete is not complete.

A simple observation.  Not every use of a piece of software requires all of its features.  The "flatfile" may not include all the features of a full function database while still including all that the authors thought needed for the use they intended. 

Full feature would of course allow the system to adapt far more easily to usages that were not originally seen as desirable.

[Lepton]

Not to interject my totally novice information, but I am aware that Cryptic in developing a database for their MMO engine decided that SQL was too inefficient for their needs and designed their own database engine that I think may be object-oriented.  SQL is not the end-all, be-all it would seem.

 

 

http://www.scribd.com/doc/3546675/SQL-Considered-Harmful

http://channel9.msdn.com/posts/Dan/Shannon-Posniewski-SQL-Considered-Harmful-for-MMOs/

Presented at GDC 2008.  I think I'll take the word of experienced game designers and programmers over some wanna-be any day, thank you very much.

[toasty0]

Not to interject my totally novice information, but I am aware that Cryptic in developing a database for their MMO engine decided that SQL was too inefficient for their needs and designed their own database engine that I think may be object-oriented.  SQL is not the end-all, be-all it would seem.

 

 

http://www.scribd.com/doc/3546675/SQL-Considered-Harmful

http://channel9.msdn.com/posts/Dan/Shannon-Posniewski-SQL-Considered-Harmful-for-MMOs/

Presented at GDC 2008.  I think I'll take the word of experienced game designers and programmers over some wanna-be any day, thank you very much.

Do you understand why Shannon's presentation and conclusion is flawed?

Fwiw, please tell me the name of the world's largest Online Game and then tell me which db server product they use. It is Eve Online. It is SQL Server. They know wth they're doing and how to properly use a RDBMS correctly.

[Lepton]

I understand that they tested it, made various attempts at optimization, and found it lacking.  Not much more to say than that.  I know I lack the expertise to evaluate the "truthiness" of those claims, but they are made and I'll take their word for it over your vague assertions.

[toasty0]

I understand that they tested it, made various attempts at optimization, and found it lacking.  Not much more to say than that.  I know I lack the expertise to evaluate the "truthiness" of those claims, but they are made and I'll take their word for it over your vague assertions.

Vague? Telling you that Eve Online uses a SQL Server backend is vague? What is vague about that?

"For the great majority of mankind are satisfied with appearances,
as though they were realities, and are often more influenced
by the things that seem than by those that are." --Niccolo Machiavelli