Comments on: Stunning Performance from Fusion-io http://www.thehotaisle.com/2009/03/06/stunning-performance-from-fusion-io/ Fresh Thinking on IT Operations Mon, 06 Feb 2012 16:02:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Stunning Performance from Fusion-io « Enterprise Strategy Group http://www.thehotaisle.com/2009/03/06/stunning-performance-from-fusion-io/comment-page-1/#comment-7240 Stunning Performance from Fusion-io « Enterprise Strategy Group Tue, 12 Jan 2010 21:38:54 +0000 http://www.thehotaisle.com/?p=1205#comment-7240 [...] Read the entire blog entry here >> All views and opinions expressed in ESG blog posts are intended to be those of the post's author and do not necessarily reflect the views of Enterprise Strategy Group, Inc., or its clients. ESG bloggers do not and will not engage in any form of paid-for blogging. Click to see our complete Disclosure Policy. For important information about using this content, please review our Terms & Conditions Tags: data warehouse, Fusion-io, iops, it leadership [...] [...] Read the entire blog entry here >> All views and opinions expressed in ESG blog posts are intended to be those of the post's author and do not necessarily reflect the views of Enterprise Strategy Group, Inc., or its clients. ESG bloggers do not and will not engage in any form of paid-for blogging. Click to see our complete Disclosure Policy. For important information about using this content, please review our Terms & Conditions Tags: data warehouse, Fusion-io, iops, it leadership [...]

]]> By: CL http://www.thehotaisle.com/2009/03/06/stunning-performance-from-fusion-io/comment-page-1/#comment-2680 CL Mon, 05 Oct 2009 21:27:45 +0000 http://www.thehotaisle.com/?p=1205#comment-2680 I think that the area of i/o performance is becoming a fascinating one with several competing approaches and technological rates of change opening new possibilities and creating new bottlenecks, reducing some costs and increasing others. The key, and it creates a major issue in data centre, is to understand the current and projected business needs so that the performance/cost/flexibility requirements can be tracked from the lob application portfolio down to how this is supported by the assets and operational costs.<br><br>In principle, the best bang for buck for I/O performance comes from reducing the amount of I/O: change the application level software, change the dbms products, change configurations and/or throw in-server RAM at the DBMS cache. Then you can throw SSD at the problem. The counter problems then come from re-use of storage assets and network contention (either in the IP network or the storage network), and the corresponding increases in operational processes/technical skills required.<br><br>At the simplistic economic model of price /GB of various types of storage, SSD's dropping faster than server RAM, and the technology gives you a much higher total capacity, which is crucial if you go beyond the RAM limits of your servers. I didn't get a view of the size of the DW data set, but for standard rdbms, you can get very large storage needs (see tpc.org's tpc H results, where 70-128x query set to total storage ratios are typical in the 3TB dataset datawarehouse range.) That pumps up the bill if you have to make it all SSD. (say, 20usd per GB gives a storage bill of 70x60k=4M2 usd for the storage - comparable to the 5M4 usd 5yr cost of ownership of an IBM solution at this scale.) Using a specialised DW dbms could drop this by an order of magnitude, but that still looks like it would need more work to get the solution into the business case. <br><br>Getting anything like optimal takes a lot of effort to get the business to agree what parameters it's happy to sign up to for all business applications and then to engage the whole IT/IS development and operations groups aligned around these parameters. I think that the area of i/o performance is becoming a fascinating one with several competing approaches and technological rates of change opening new possibilities and creating new bottlenecks, reducing some costs and increasing others. The key, and it creates a major issue in data centre, is to understand the current and projected business needs so that the performance/cost/flexibility requirements can be tracked from the lob application portfolio down to how this is supported by the assets and operational costs.<br><br>In principle, the best bang for buck for I/O performance comes from reducing the amount of I/O: change the application level software, change the dbms products, change configurations and/or throw in-server RAM at the DBMS cache. Then you can throw SSD at the problem. The counter problems then come from re-use of storage assets and network contention (either in the IP network or the storage network), and the corresponding increases in operational processes/technical skills required.<br><br>At the simplistic economic model of price /GB of various types of storage, SSD’s dropping faster than server RAM, and the technology gives you a much higher total capacity, which is crucial if you go beyond the RAM limits of your servers. I didn’t get a view of the size of the DW data set, but for standard rdbms, you can get very large storage needs (see tpc.org’s tpc H results, where 70-128x query set to total storage ratios are typical in the 3TB dataset datawarehouse range.) That pumps up the bill if you have to make it all SSD. (say, 20usd per GB gives a storage bill of 70x60k=4M2 usd for the storage – comparable to the 5M4 usd 5yr cost of ownership of an IBM solution at this scale.) Using a specialised DW dbms could drop this by an order of magnitude, but that still looks like it would need more work to get the solution into the business case. <br><br>Getting anything like optimal takes a lot of effort to get the business to agree what parameters it’s happy to sign up to for all business applications and then to engage the whole IT/IS development and operations groups aligned around these parameters.

]]> By: timcoote http://www.thehotaisle.com/2009/03/06/stunning-performance-from-fusion-io/comment-page-1/#comment-1319 timcoote Mon, 09 Mar 2009 13:09:08 +0000 http://www.thehotaisle.com/?p=1205#comment-1319 Steve<br>I like the "Green IT through Discipline" panel set. Have you tried to push the efficiency incentives back up the IT supply chain into application development? As things stand, new software will soak up any capacity that's available, and there's a tendency at each stage of an application's life to over-estimate and provision, with no closed loop process that I've seen to measure actual resource use against business benefit over the lifecycle.<br>Tim Steve
I like the “Green IT through Discipline” panel set. Have you tried to push the efficiency incentives back up the IT supply chain into application development? As things stand, new software will soak up any capacity that's available, and there's a tendency at each stage of an application's life to over-estimate and provision, with no closed loop process that I've seen to measure actual resource use against business benefit over the lifecycle.
Tim

]]> By: timcoote http://www.thehotaisle.com/2009/03/06/stunning-performance-from-fusion-io/comment-page-1/#comment-1318 timcoote Mon, 09 Mar 2009 12:50:56 +0000 http://www.thehotaisle.com/?p=1205#comment-1318 I think that the area of i/o performance is becoming a fascinating one with several competing approaches and technological rates of change opening new possibilities and creating new bottlenecks, reducing some costs and increasing others. The key, and it creates a major issue in data centre, is to understand the current and projected business needs so that the performance/cost/flexibility requirements can be tracked from the lob application portfolio down to how this is supported by the assets and operational costs.<br><br>In principle, the best bang for buck for I/O performance comes from reducing the amount of I/O: change the application level software, change the dbms products, change configurations and/or throw in-server RAM at the DBMS cache. Then you can throw SSD at the problem. The counter problems then come from re-use of storage assets and network contention (either in the IP network or the storage network), and the corresponding increases in operational processes/technical skills required.<br><br>At the simplistic economic model of price /GB of various types of storage, SSD's dropping faster than server RAM, and the technology gives you a much higher total capacity, which is crucial if you go beyond the RAM limits of your servers. I didn't get a view of the size of the DW data set, but for standard rdbms, you can get very large storage needs (see tpc.org's tpc H results, where 70-128x query set to total storage ratios are typical in the 3TB dataset datawarehouse range.) That pumps up the bill if you have to make it all SSD. (say, 20usd per GB gives a storage bill of 70x60k=4M2 usd for the storage - comparable to the 5M4 usd 5yr cost of ownership of an IBM solution at this scale.) Using a specialised DW dbms could drop this by an order of magnitude, but that still looks like it would need more work to get the solution into the business case. <br><br>Getting anything like optimal takes a lot of effort to get the business to agree what parameters it's happy to sign up to for all business applications and then to engage the whole IT/IS development and operations groups aligned around these parameters. I think that the area of i/o performance is becoming a fascinating one with several competing approaches and technological rates of change opening new possibilities and creating new bottlenecks, reducing some costs and increasing others. The key, and it creates a major issue in data centre, is to understand the current and projected business needs so that the performance/cost/flexibility requirements can be tracked from the lob application portfolio down to how this is supported by the assets and operational costs.

In principle, the best bang for buck for I/O performance comes from reducing the amount of I/O: change the application level software, change the dbms products, change configurations and/or throw in-server RAM at the DBMS cache. Then you can throw SSD at the problem. The counter problems then come from re-use of storage assets and network contention (either in the IP network or the storage network), and the corresponding increases in operational processes/technical skills required.

At the simplistic economic model of price /GB of various types of storage, SSD's dropping faster than server RAM, and the technology gives you a much higher total capacity, which is crucial if you go beyond the RAM limits of your servers. I didn't get a view of the size of the DW data set, but for standard rdbms, you can get very large storage needs (see tpc.org's tpc H results, where 70-128x query set to total storage ratios are typical in the 3TB dataset datawarehouse range.) That pumps up the bill if you have to make it all SSD. (say, 20usd per GB gives a storage bill of 70x60k=4M2 usd for the storage – comparable to the 5M4 usd 5yr cost of ownership of an IBM solution at this scale.) Using a specialised DW dbms could drop this by an order of magnitude, but that still looks like it would need more work to get the solution into the business case.

Getting anything like optimal takes a lot of effort to get the business to agree what parameters it's happy to sign up to for all business applications and then to engage the whole IT/IS development and operations groups aligned around these parameters.

]]>