Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Astor Data, Greenplum and GridSQL all allow Massive Parallel Processing of SQL queries. They are also all built around PostgreSQL technology. Is this just because of licensing issues or are there other reasons? To me, it seems like the MyISAM, not being ACID complient and therefore not running into the same issues with MVCC (like seen here) as PostgreSQL is far better suited for building high-performance data warehouses. After all OLAP load does not require transactions as far as I can see.

share|improve this question

4 Answers 4

up vote 11 down vote accepted

It is mostly a license issue. These developments end up patching the code quite heavily, so if you were to deal with MySQL, you'd either have to open-source your code or be at the mercy of MySQL's corporate owner for the life of your business. Some offers for MySQL get around that by implementing their work as a storage engine, but that doesn't offer all the flexibility that they need, and they invariably end up patching the MySQL core as well.

share|improve this answer
    
Not true. You only have to give away the source if you distribute a GPL app as far as I know. If you use it internally, you can keep you changes to yourself. That is why Stallman says SaaS is an end run around the GPL. –  Gaius Feb 7 '11 at 5:49
7  
Gaius: What's your point? The MPP solutions discussed here sell proprietary software that is derived from open-source software. They don't sell their software as a service. –  Peter Eisentraut Feb 7 '11 at 7:32

I can see two reasons:

1) historically, PostgreSQL had better query planner and statistics analyzer. This might be not true now, but few years ago PostgreSQL was much better then MySQL on complex queries, which is OLAP ones.

2) PostgreSQL have better functions/triggers/etc programming support.

share|improve this answer
    
I think it still does. though I can't speak at all for mysql 5.5 –  xenoterracide Feb 6 '11 at 21:43
1  
Well, most of the time, these commercial forks develop their own planner and optimizer to accommodate the distributed or parallel nature of what they are doing. –  Peter Eisentraut Feb 7 '11 at 0:21

I built an MPP system on MySQL and I discarded the system for two reasons:

1) is Oracle

2) is the lack of hash joins - nested loop and index joins do not scale to the level required in a MPP system - again because Oracle inhibited the promised delivery of hash joins in the 5.x code line after it took ownership.

MPP big data systems must have joins that are not of geometric complexity. - Linear or log linear complexity joins must be a strong preference for true big data systems.

I deployed Actian vectorwise instead in the new DeepCloud MPP system while maintaining a drizzle/MySQL compatibility at the user level.

Users wanting fast big-data analytics can download DeepCloud from http://www.deepcloud.co

share|improve this answer
3  
Hi Randolph, and welcome to the site. I'll just encourage you to have glanced over the faq and note the bit about promotions. The users here tend to frown on product placement, but you're doing the right thing and discussing the pros and cons here. It wouldn't hurt to disclose your affiliation with the product in the future, maybe saying "here's a product I work on that does what you need". (PS: Some several people complained that this "feels like an advertisement" but you're actively discussing why the discarding was the valid choice, which is proper) –  jcolebrand Dec 5 '12 at 4:14

As Peter Eisentraut correctly pointed out, first and foremost it's a licensing issue. Postgres is licensed under a BSD-like agreement, which makes it essentially a "free for all", so long as you credit the original developers in your derivative work.

The MVCC vs. locking scheduler debate has been the subject of more than a few 'holy wars' online. The debates over the merits of various storage engines have been equally controversial.

The merits of different row-major (aka row-store) storage engines are IMHO largely irrelevant when it comes to MPP RDBMS built for analytic workloads for two reasons:

  1. While peculiarities of the storage engine are important for processing ACID transactions in OLTP-type workloads, in a typical data warehousing environment, you need to support only one type of "transaction" - a batch load. Ideally it's the batch load that should either succeed entirely or fail completely.
  2. Analytic databases, based on column-store storage engines, will in many cases outperform any row-store implementation. Vertica was a column store from the start, Teradata and Greenplum recently added column-store functionality to their products.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.