Oracle vs MySQL ?

[ppksp12]

Many large companies or enterprises are using Oracle as their main database platform, whereas MySQL or some other DB solutions are always the sideline. Why is this the case and will there ever be a change of trend ?

 

[ykgoh]

1. Cost (Oracle is always pricier than MySQL)
2. Support (someone to blame when there is a problem)

 

[davidktw]

Many large companies or enterprises are using Oracle as their main database platform, whereas MySQL or some other DB solutions are always the sideline. Why is this the case and will there ever be a change of trend ?

There are a few reasons why Oracle DB is the enterprise choice when it comes to large scale usage

1) Reputation. Oracle has a good product that has infiltrated the enterprise space all these years. If you are a management level person looking for reputable solution, you will certain keep Oracle in mind
2) Oracle DB is actually quite a robust piece of software. It has all along established its soundness in transaction applications as well as data warehousing purpose. When comes to scalability, Oracle RAC is quite a beast and offers really good performance and automation coming to automatic failover with the OTN thick client. You can also design global failover using Dataguard add on.
3) All these while, there are really experienced Oracle DBA trained for the particular product. You do find them in large enterprises. So obviously if you have already invested in the solution and also the human resources, there is little reason to not continue using it for your large scale projects. Moreover, these Oracle DBA will knows and in charge of ensuring proper data security, data backup and restoration process, which is critical to the business continuity of a company
4) Oracle may be expensive, but not to forget Oracle is also smart. When it comes to strategic partners, their price model is quite flexible.
5) There are a whole lot of Oracle suites such as Oracle Identity and Access Management System, GoldenGate, an other middleware which are designed to use Oracle DB, so if you are one of these enterprises who are already using Oracle softares, it's hard to move away.

MySQL todays also comes under Oracle, so really it is a tricky situation. Of course Oracle is not stupid enough as to cannibalise their own flagship. However if you are looking for more innovative options, perhaps you want to look at Percona XtraDB and Facebook MariaDB. These are forks from MySQL AB

There will certainly be changes, but traditionally enterprises move at a slower pace and their market is not really your more vibrant consumer space which uses a lot of MySQL today. It's really hard to tell at this point of time, what will eventually happen to MySQL since there is clearly a conflict of interest within Oracle.

 

[godchuanz]

However if you are looking for more innovative options, perhaps you want to look at Percona XtraDB and Facebook MariaDB. These are forks from MySQL AB

This. If you're considering MySQL as an ACID data storage (InnoDB), you should really take a look at the XtraDB engine offerings instead. In fact, for MariaDB, it's like a drop-in replacement for MySQL, so it's a painless and almost transparent to developers and maybe even administrators for most tasks.

For even innovative options, the TokuDB engine is even more promising. MariaDB includes the option to use ToKuDB if I'm not wrong.

Just by the way, I don't think MariaDB is developed by Facebook. Or did you mean something else?

 

[davidktw]

This. If you're considering MySQL as an ACID data storage (InnoDB), you should really take a look at the XtraDB engine offerings instead. In fact, for MariaDB, it's like a drop-in replacement for MySQL, so it's a painless and almost transparent to developers and maybe even administrators for most tasks.

For even innovative options, the TokuDB engine is even more promising. MariaDB includes the option to use ToKuDB if I'm not wrong.

Just by the way, I don't think MariaDB is developed by Facebook. Or did you mean something else?

My bad, I have mistaken Facebook contributing and using MariaDB as oppose to being the fork starter.

I know about TokuDB for its innovative fractal tree index when I got to know about it months back. Today it has been acquired by Percona.

 

[godchuanz]

Anyway, while we're on DB trends, the NoSQL movement has also been getting a lot of attention. A lot of major companies have actually started using some of these high-speed, designed-to-scale database engines over traditional relational SQL engines. MongoDB and Cassandra are popular choices.

The performance and scalability is definitely enticing, but the lack of full ACID-ity can be a problem. A lot of major companies have held off migrating fully to NoSQL technologies because of this.

In any case, I believe MySQL/MariaDB is perfectly fine for most applications, even the more demanding ones, as long as the data architecture is well thought out and you make use of caching (Redis, Memcache) to reduce load on the DB.

 

[davidktw]

Anyway, while we're on DB trends, the NoSQL movement has also been getting a lot of attention. A lot of major companies have actually started using some of these high-speed, designed-to-scale database engines over traditional relational SQL engines. MongoDB and Cassandra are popular choices.

The performance and scalability is definitely enticing, but the lack of full ACID-ity can be a problem. A lot of major companies have held off migrating fully to NoSQL technologies because of this.

In any case, I believe MySQL/MariaDB is perfectly fine for most applications, even the more demanding ones, as long as the data architecture is well thought out and you make use of caching (Redis, Memcache) to reduce load on the DB.

When it comes to performance, any sane developer would consider the full stack instead of database. The phenomenal is seldom high writes and low read unless for very specific use cases, but I must say at some level the problem can always be mitigated until when you get to the backend database, it becomes something manageable.

These the few I know and will work
1) Usage of CDN
2) Pile stock in memory or higher storage tier(SSD) before write to turn high freq random I/O into low freq and long sequential I/O
3) In memory caching
4) Good application design such as asynchronous update or incremental update
5) Compress sparse data into small compact chunk
6) Use intermediate distributed data structure or architecture for high freq data instead of just merely database
7) Consider sharding data design
8) Usage of N-replicated design to allow asynchronous write back to disk so that it will lower the chance of data lost in the event any of the nodes crash despite in-memory buffering.
9) Using files as intermediate data storage before bulking import into the database

There are plentiful of designs available to really tackle the problem and for really a lot of use cases, the problem get alleviated at the higher level and never get floated down to the ground for the database to choke over.

 

[ppksp12]

Yes, quite agreed. However, the full stack does present it problems..