Comments on: User data vs. raw disk space as a marketing metric http://www.dbms2.com/2009/07/02/daniel-abadi-user-data/ Choices in data management and analysis Wed, 08 Feb 2012 22:51:14 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Curt Monash http://www.dbms2.com/2009/07/02/daniel-abadi-user-data/#comment-128661 Curt Monash Fri, 03 Jul 2009 08:12:26 +0000 http://www.dbms2.com/?p=831#comment-128661 The confuison Aster's marketing sheet was careless, not malicious. The penultimate draft didn't have that weirdness, or else I would have talked them out of it. (Somehow, I doubt they'll mind my bending NDA to say that. :D ) The confuison Aster’s marketing sheet was careless, not malicious. The penultimate draft didn’t have that weirdness, or else I would have talked them out of it.

(Somehow, I doubt they’ll mind my bending NDA to say that. :D )

]]> By: Daniel Abadi http://www.dbms2.com/2009/07/02/daniel-abadi-user-data/#comment-128637 Daniel Abadi Fri, 03 Jul 2009 05:27:24 +0000 http://www.dbms2.com/?p=831#comment-128637 To be honest with you, I do not know a lot about how Vertica or other vendors price their products. It seems to me that if you're buying hardware (i.e. a traditional appliance) it's a little more straightforward to reason about how much space you are actually getting, rather than how much data could theoretically fit into your appliance if your data compresses similarly to how other people's data compresses. On the other hand, if you're buying a software-only solution, then user data is easier to reason about (since there are no fixed hardware limitations). However, I don't really feel strongly about this. I still think it is odd to quote numbers using both methods for different configurations --- to me this is really misleading. But the overall point of my post is that despite playing dumb marketing tricks, the new metrics that Aster Data introduces are the right things to be thinking about in tomorrow's market, where more and more analysis is being pushed into the DBMS. To be honest with you, I do not know a lot about how Vertica or other vendors price their products. It seems to me that if you’re buying hardware (i.e. a traditional appliance) it’s a little more straightforward to reason about how much space you are actually getting, rather than how much data could theoretically fit into your appliance if your data compresses similarly to how other people’s data compresses. On the other hand, if you’re buying a software-only solution, then user data is easier to reason about (since there are no fixed hardware limitations). However, I don’t really feel strongly about this. I still think it is odd to quote numbers using both methods for different configurations — to me this is really misleading. But the overall point of my post is that despite playing dumb marketing tricks, the new metrics that Aster Data introduces are the right things to be thinking about in tomorrow’s market, where more and more analysis is being pushed into the DBMS.

]]> By: Jerome Pineau http://www.dbms2.com/2009/07/02/daniel-abadi-user-data/#comment-128553 Jerome Pineau Thu, 02 Jul 2009 22:08:30 +0000 http://www.dbms2.com/?p=831#comment-128553 To quote from Daniel's post: "If you store a lot of data but don't have the CPU processing power to process it at the speed it can be read off of disk, this is a potential indication of a scalability problem not a scalability success." We've been saying this at XSPRADA for years now. Of course we are currently an SMP/DAS implementation. Either way I always say, the best way to configure our system is have "as many individually addressable drives accessible via I/O providing sufficient bandwidth so that the drives can deliver their peak continuous read/write speeds" -- This means balancing your cores+channels+disks accordingly. To quote from Daniel’s post:
“If you store a lot of data but don’t have the CPU processing power to process it at the speed it can be read off of disk, this is a potential indication of a scalability problem not a scalability success.”

We’ve been saying this at XSPRADA for years now. Of course we are currently an SMP/DAS implementation. Either way I always say, the best way to configure our system is have “as many individually addressable drives accessible via I/O providing sufficient bandwidth so that the drives can deliver their peak continuous read/write speeds” — This means balancing your cores+channels+disks accordingly.

]]>