tag:blogger.com,1999:blog-8899645800948009496.post2835843758882009805..comments2024-03-28T23:50:29.558-07:00Comments on DBMS Musings: Exadata's columnar compressionDaniel Abadihttp://www.blogger.com/profile/16753133043157018521noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8899645800948009496.post-58409958691228152302012-08-02T16:42:12.110-07:002012-08-02T16:42:12.110-07:00If I read the Oracle White Paper correctly, it st...If I read the Oracle White Paper correctly, it states clearly on page 5 <br /><br />".. Note that data remains compress not only on disk, but also remains compressed in teh Exatat Smart Flash Cache, on Infiniband, in the database server buffer cache, as well as doing backups or log shipping to Data Guard."Anonymoushttps://www.blogger.com/profile/12886923590964453012noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-64220918652734800052012-05-24T11:18:47.224-07:002012-05-24T11:18:47.224-07:00I had the doubtful pleasure of working with Greenp...I had the doubtful pleasure of working with Greenplum product. This is one of the worst enterprise products i have ever worked with. The product is immature and doesn't come near the capabilities of Oracle Exadata . Greenplum is where oracle was 15 years ago. EMC will try to sell you an illusion that is it the same and better but they are selling a bad product.<br />The product have a lot of limitations (for example - no ability to connect to external database, no replication capabilities, dependency on the physical infrastructure when performing backup and restore, the development tools are not good and not comfortable and if you read the documentation you will find about 5 pages of limitations two of them are that you can use column-oriented storage option and compression only on append only table – that is right you read well – you can use the strongest features of GP only on tables that you don't perform update or delete. )<br />Since the product is not very popular (at least yet) there will be times that you will experience issues like bugs and behavior not known to anyone else including GreenPlum support and development teams.<br />The knowledgebase doesn't exist on the web and you will be fully dependent on EMC professional team.<br /><br />If you don't believe me – read Greenplum documentation and at least don't pay before you check the product from the inside out.<br /><br />Some of EMC products are good but this is not one of them.rebelliohttps://www.blogger.com/profile/07132995508733152246noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-60214321496503236022012-01-27T11:51:36.827-08:002012-01-27T11:51:36.827-08:00now that you are a CTO of Hadapt, maybe you will s...now that you are a CTO of Hadapt, maybe you will show how Hadapt outperforms say Greenplum during Hadoop meetup?Sam Xhttps://www.blogger.com/profile/06721844153601169137noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-9073914950944303782012-01-27T11:49:25.796-08:002012-01-27T11:49:25.796-08:00Daniel, where would one find direct comparisons of...Daniel, where would one find direct comparisons of Exadata vs Vertica vs Greenplum?<br />or do vendors block the publications of such benchmarks by their clients?<br /><br />SamSam Xhttps://www.blogger.com/profile/06721844153601169137noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-37937716133292974082010-03-22T14:34:04.562-07:002010-03-22T14:34:04.562-07:00very interesting article!
few thoughts ...
1. I ...very interesting article!<br /><br />few thoughts ...<br /><br />1. I think as well that Oracle decompresses the data on OS level before it sends it to oracle database. First the paper somewhat says it, but mostly the fact that this feature is available only on exadata tells me that this is probably on the storage/os level.<br /><br />2. I believe that Teradata adds interesting twist to how they compress data. In general their compression is not as broad and good as oracle, but I like their dictionary approach, it can be very handy in some specific scenarios.<br /><br />3. Oracle whitepaper is (and I'm sorry to say that) a joke. It's more a sales pitch than serious whitepaper about compression. There are not that many different exadata hardware appliances configurations, it should be very easy to run and publish solid accurate stats (not only I/O and space, but also CPU).<br /><br /><br />4. I would like to see (in the oracle whitepaper) where this compression does not work or better where it cannot be implemented. I'm sure there are a lot of exceptions.jirihttps://www.blogger.com/profile/15722884107919365571noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-78360938247051073322010-01-20T20:46:56.218-08:002010-01-20T20:46:56.218-08:00Hi Mark,
I haven't read the Vertica whitepape...Hi Mark,<br /><br />I haven't read the Vertica whitepaper (and wouldn't want to speak for them anyway), but for the C-Store work it was definitely the case that if you had too many updates (or even inserts) then the write-optimized buffer would get too large and slow-down read queries (because read-queries have to go to both the read-optimized buffer and the write-optimized buffer unless the user is willing to receive results from a historical snapshot). So if you want to have optimal performance on read-only queries, you don't want to intermingle too many write queries. The best way to figure out the write load before things go bad is not so much the percentage of queries that are update queries (as in Vertica's "rule of thumb"), but rather the rate with which data is being added to the write buffer. <br /><br />The size of the write buffer is really the only thing that can cause major problems in performance. The stuff you mention --- while accurate --- will cause a factor of 2 slower write performance in the worst case, which one gladly pays for the factor of 10+ in read performance. Hence, usually inserts and updates are not distinguished when talking about write queries since they cause the write buffer to fill up equally fast (even though, as you say, updates are more costly than inserts for other reasons).<br /><br />The main point here is that there is an enormous difference of write performance between column-stores with write-buffers and column-stores without write-buffers, since without write-buffers column-stores have to turn individual tuple inserts into n random writes where n is the number of columns in the tuple. This causes the order of magnitude slowdown that negates much of the benefit of column-stores. Since most column-stores have write-buffers, I believe that people should assume the existence of the write-buffer when discussing column-store write performance.Daniel Abadihttps://www.blogger.com/profile/16753133043157018521noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-176960602002673362010-01-20T09:18:02.431-08:002010-01-20T09:18:02.431-08:00Can you explain why the Vertica white paper states...Can you explain why the Vertica white paper states "a good rule of thumb is that fewer than 1% of the total SQL statements should be DELETEs or UPDATEs".<br /><br />Does the C-Store family solve the IO bottleneck for inserts and updates? Or only for inserts?<br /><br />After re-reading the C-Store overview and Vertica white paper my vague understanding is:<br /><br />1)since updates are done as delete/insert they may require twice the work when merging into the ROS (once to remove, once to add)<br /><br />2) update and delete require random reads from ROS to determine that the rows exist, insert does not<br /><br />What is done for primary key and unique constraints? In that case random reads must also be done during insert.<br /><br />Can we expect a paper on optimizing for IO during the merge process? The LSM paper has many details on that.Mark Callaghanhttps://www.blogger.com/profile/09590445221922043181noreply@blogger.com