I’m online over the holidays but everyone’s so busy there isn’t much point in blogging during this period. More important things dominate so I won’t be posting until early January.
Have a great holiday.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201
Yesterday Nanosolar announced it has started to sell cheap solar panels at a materials cost of roughly $1/W and a finished panel cost of ~$2/W: http://www.reuters.com/article/technologyNews/idUSN1846022020071218. As a reference point, coal powered electricity is about $1/W when considering the fully burdened cost of the plant and operations. When a new technology is within a factor of two of an old, heavily invested technology, I get excited. This is getting interesting.
Nanosolar was founded in 2002 and has plants in San Jose, CA and another near Berlin, Germany. They received $20M from Mohr Davidow Ventures. Other investors include Sergey Brin and Larry Page.
More articles on Nanosolar: http://www.nanosolar.com/articles.htm. Thanks to Will Whitted for directing me to Nanosolar.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
This note on the Google infrastructure was sent my way by Andrew Kadatch (Live Search) by way of Sam McKelvie (Cloud Infrastructure Services). It’s not precise in all dimensions, but it does a good job of bringing together the few facts that have been released by Google, and it points to its references if you are interested in a deeper dive.
The infrastructure summary is at: http://highscalability.com/google-architecture. No new data here, but a good summary if you haven’t read all the direct sources from which the summary was drawn.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-C/1279, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
Last week Google announced their Renewable Energy Cheaper than Coal (RE<C) initiative. This is a two pronged effort combining external investment with internal Google research. The external investments include $10M in Makani Power, a startup aiming to harness high altitude winds. Makani explains that high altitude winds have the highest energy density of any renewable energy source. Google also invested in eSolar as part of this program. eSolar is a startup aiming to produce utility scale solar energy farms ranging from 25MW to 500MW.
More detail on:
· Makani: http://www.google.com/corporate/green/energy/makani.pdf
· eSolar: http://www.google.com/corporate/green/energy/esolar.pdf
In addition to the external investments, Google is staffing a team with a mission of assembling 1 Gigawatt of renewable energy capacity that is cheaper than coal. More detail at: http://www.google.com/corporate/green/energy/index.html.
It’s hard to argue with the “cheaper than coal” target. If renewable resources actually could be less expensive than coal, they would be used without social pressure, government subsidies, or other external tweaks to the market. Looking at the business side, this looks like a good marketing investment for Google as well. Google’s datacenter footprint continues to grow at an unprecedented pace while, at the same time, datacenter power consumption is becoming an social concern and attracting regulatory attention. This investment is clearly a well timed and well thought through business investment as well.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
The number 1 Amazon AWS requirement just got met: structured storage. Amazon announced SimpleDB yesterday although it’s not yet available for developers to play with. I’m looking forward to being able to write a simple application against it – I’ve had fun with S3. But, for now, the docs will have to do.
In the announcement (http://aws.amazon.com/simpledb), it’s explained that SimpleDB is not a relational DB. AWS notes that some customers run relational DBs in EC2 and, those that need complex or strictly enforced schema, will continue to do this. Others that only need a simple structured store with much less administrative overhead will use SimpleDB. AWS explains that they will make it increasingly easy to do both.
The hard part of running a RDBMS in EC2 is that there is no data protection. The EC2 local disk is 100% ephemeral. Some folks are using block replicators such as DRBD (http://www.drbd.org/) to keep two MySQL systems in sync. It’s kind of a nice solution but requires some skill to set up. When AWS says “make it easier” I suspect they are considering something along these lines. A block replicator would be a wonderful EC2 addition. However, for those that really only need a simple structured store, SimpleDB is (almost) here today.
My first two interests are data model and pricing. The data model is based upon domains, items, attributes and values. A domain roughly corresponds to a database and you are allowed up to 100 domains. All queries are within a domain. Within a domain, you can create items. Each item has an ID (presumably unique). Every Item has attributes and attributes have values. You don’t need to (and can’t) declare the schema of an item and any item can have any number of attributes up to 256 per item. Attributes have values and the values can repeat. So a given item may have an attribute or may not and it can have the attribute more than once. Attributes have values and value are simple UTF-8 strings limited to 1024 bytes. All attributes are indexed.
The space overhead gives a clue to storage format:
· Raw byte size (GB) of all item IDs + 45 bytes per item +
· Raw byte size (GB) of all attribute names + 45 bytes per attribute name +
· Raw byte size (GB) of all attribute-value pairs + 45 bytes per attribute-value pair
The storage format appears to be a single ISAM index of (item, attribute, value). It wouldn’t surprise me if the index used in SimpleDB is the same code that S3 uses for metadata lookup.
The query language is respectable and includes: =, !=, <, > <=, >=, STARTS-WITH, AND, OR, NOT, INTERSECTION AND UNION. Queries are resource limited to know more than 5 seconds of execution time.
The storage model, like S3, is replicated asynchronously across data centers with the good and the bad that comes with this approach: the data is stored geo-redundantly which is wonderful but it is possible to update a table and, on a subsequent request, not even see your own changes. The consistency model is very weak and the storage reliability is very strong. I actually like the model although most folks I talk to complain that it’s confusing. Technically this is true but S3 uses the same consistency model. I’ve spoken to many S3 developers and never heard a complaint (admittedly some just don’t understand it).
Pricing was my second interest. There are three charges for SimpleDB:
· Machine Utilization: $0.14/machine hour
· Data Transfer:
o $0.10 per GB - all data transfer in
o $0.18 per GB - first 10 TB / month data transfer out
o $0.16 per GB - next 40 TB / month data transfer out
o $0.13 per GB - data transfer out / month over 50 TB
· Structured Storage: $1.50 GB/month
$1.50 GB/month or $18 GB/year is 10x the $1.80 GB/year charged by S3. Fairly expensive in comparison to S3 but a bargain compared to what it cost to manage an RDBMS and the hardware that supports it.
More data on SimpleDB from AWS: http://aws.amazon.com/simpledb.
Sriram Krishnan has an excellent review up at: http://www.sriramkrishnan.com/blog/2007/12/amazon-simpledb-technical-overview.html
Thanks to Sriram Krishnan (Develop Division) and Dare Obasanjo (WinLive Platform Services) for sending this one my way. I’m really looking forward to playing with SimpleDB and seeing how customers end up using it. Overall, I find it tastefully simple and yet perfectly adequate for many structured storage tasks.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
SpecPOWER is the first industry standard benchmark that evaluates power and performance characteristics of high volume servers. Yesterday the final spec was released (see below thanks to Kushagra Vaid of GFS H/W Architecture & Standards).
I have quibbles with this benchmark but they really are mostly quibbles. Generally, I’m thrilled to see a benchmark out there that shines a light on server power consumption. The entire industry needs it. Benchmarks drive action and we have lots of low hanging fruit to grab when it comes to server power/performance.
The press release is up at: http://www.spec.org/power_ssj2008/ and early results are at http://www.spec.org/power_ssj2008/results/power_ssj2008.html.
I remember working on IBM DB2 years back when we first ran TPC-A. Prior to the benchmark we had a perfectly good database management system that customers were using successfully to run some very large businesses. When we first ran TPC-A, let’s just say we didn’t like what we saw. We got to work and ended up improving DB2 by a full factor of 10 in that release and then went on and improved by a further factor of 4 in the next release. Yes I know the only way to improve that much is to start off REALLY needing it. That’s my point. As a direct result of the benchmark giving us and customers increased visibility into OLTP performance, the product improved 40x in less than 5. Customers gained, the product got better, and it gave the engineering team good goals to rally around. Benchmarks help customers.
As benchmarks age, it’s harder to find the big differentiating improvements. Once the easy changes are found and even the more difficult improvements have been worked through, benchmark specials typically begin to emerge. Companies start releasing changes that help the benchmarks and do nothing and, in rare cases, can even hurt real customer workloads. Eventually, this almost always happens and causes industry veterans, myself included, to distrust benchmarks. We forget that in the early years of most benchmarks, they really did help improve the product and delivered real value to customers.
I’m very happy to see SPEC release a benchmark that measures power and I’m confident that it will help drive big power efficiency gains. Sure, we’ll eventually see the game playing benchmark specials but, for now, I predict many of the improvements will be real. This will help the industry evolve more quickly. Now can someone please start working on a data center efficiency benchmark? Huge innovations are waiting in data center design and even more in how existing designs are deployed.
--jrh
From: osgmembers-request@spec.org [mailto:osgmembers-request@spec.org] On Behalf Of Alan Adamson
Sent: Tuesday, December 11, 2007 8:44 AM
To: osgmembers@spec.org
Subject: (osgmembers-363) SPECpower benchmark availability
I am delighted to announce the public availability of the initial SPECpower benchmark, SPECpower_ssj2008 - you can find the initial press release here http://www.spec.org/power_ssj2008/ , and see initial results here :
http://www.spec.org/power_ssj2008/results/power_ssj2008.html
This benchmark release is the result of a long and strenuous process (I cannot recall a committee meeting four days a week for several hours each day), needed partly because of the new ground being plowed.
I expect that all forthcoming benchmark development groups will be thinking about how to incorporate power measurements, and that the power committee will be looking at extending the scope of its workloads, and also helping other committees learn from their experience.
And now, on to several other benchmarks in or heading for general membership review. This is a pretty exciting time for the OSG!
My thanks and congratulations to those who worked so hard on this initial SPECpower benchmark.
Alan Adamson 905-413-5933 Tieline 969-5933 FAX: 905-413-4854
OSG Chair, SPEC Internet: adamson@ca.ibm.com
Java Technology Centre
IBM Toronto Lab
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
Google announced a project in October 2006 to install 9,212 solar panels on the roof of its headquarters complex. Currently over 90% of these panels are installed and active. They expect the installation will produce 30% of the peak power requirements of the headquarters buildings. For example, as I post this, they report 0.6 MW have been produced over the last 24 hour period. The roughly ½ megawatt is arguably in the noise when compared with the Google total data center power consumption which remains a carefully guarded secret. With high 10’s of data centers world-wide each consuming in the 10WM range, the 0.6 produced on the roof of the HQ building is a very small number. Nonetheless, 0.6MW is MUCH better than nothing and it’s great to see these resources committed to making a difference.
The real time power production report for this installation can be found at: http://www.google.com/corporate/solarpanels/home. Thanks to Lewis Curtis for sending this my way.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
I’ve long argued that the firm and clear division between development and operations common in many companies is a mistake. Development doesn’t feel the pain and understand what it takes to make their services more efficient to operate. Operations tends to hire more people to deal with the mess. It doesn’t work, it isn’t efficient, and it’s slow. The right model has the development/ops line very blurred. The Amazon model takes this to an extreme with essentially a “you wrote it, you run it” approach. This is nimble and delivers the pain right back where it can be most efficiently solved: development. But it can be bit tough on the engineering team. The approach I like most is a hybrid, where we have a very small tier 1 support team operations with everything else going back to development.
However, if I had to err to one extreme or the other, I would head down the Amazon path. A clear division between ops and dev leads to an over-the-wall approach that is too slow and too inefficient. What’s below is more detail on the Amazon approach, not so much because they do it perfectly but because they represent an extreme and therefore are a good data point to think though. Also note the reference to test-in-production found in the last paragraph. This is 100% the right approach in my opinion.
--jrh
When I was at Amazon (and I don’t think anything has changed) services were owned soup to nuts by the product team. There were no testers and no operations people. Datacenter operations, security, and operations were separate, centralized groups.
So ‘development’ was responsible for much of product definition and specification, the development, deployment and operation of services. This model came down directly from Jeff Bezos; his intention was to centralize responsibility and take away excuses. If something went wrong it was very clear who was responsible for fixing it. Having said that, Amazon encouraged a no-blame culture. If things went wrong the owner was expected to figure out the root cause and come up with a remediation plan.
This had many plusses and a few negatives. On the positive side:
· Clear ownership of problems
· Much shorter time to get features into production. There was no hand-off from dev to test to operations.
· Much less requirement for documentation, (both a plus and a minus)
· Very fast response to operational issues, since the people who really knew the code were engaged up-front.
· Significant focus by developers on reliability and operability, since they were the people responsible for running the service
· Model works really well for new products
Negatives:
· Developers have to carry pagers. On-call rotations, with people on-call required to respond to a sev-1 within 15 minutes of being paged 24 hours a day. Could lead to burn-out.
· Ramp up curve for new developers is extremely steep because of the lack of documentation and process
· For some teams the operations load completely dominated, making it very difficult to tackle new features or devote time to infrastructure work.
· Coordinating large feature development across multiple teams is tough.
The one surprise in this is that in my opinion code quality was as good as or better than here, despite having no testers. People developed an approach of deploying to a few machines and observing their behavior for a few days before starting a large roll out. Code could be reverted extremely quickly.
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
Michael Hunter, who authors the Testing and Debugging blog at Dr. Dobb’s Journal, asked me for an interview on testing related topics some time back. I’ve long lamented that, industry-wide, there isn’t nearly enough emphasis on test and software quality assurance innovation. For large projects, test is often the least scalable part of the development process. So, when Michael offered me a platform to discuss test more broadly, I jumped on it.
Michael structures these interviews, and his subsequent blog entry, around five questions. These ranged from where I first got involved in software testing, through the most interesting bug I’ve run into, what has most surprised me about testing, what’s the most important thing for a tester to know, and what’s the biggest challenge facing the test discipline over the next five years.
Michael’s interview is posted at: http://www.ddj.com/blog/debugblog/archives/2007/12/five_questions_39.html.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
Amazon doesn’t release much about its inner workings which is unfortunate in that hey do some things notably well and often don’t get credit. My view is that making some of these techniques more public would be a great recruiting tool for Amazon but I understand the argument for secrecy as well.
Ronny Kohavi recently pointed me to this presentation on A/B testing at Amazon. It’s three years old but still well worth reading. Key points from my perspective:
· Amazon is completely committed to A/B testing. In past Bezos presentations he’s described Amazon as a “data driven company”. One of the key advantages of a service is you get to see in real time how well it’s working. Any service that doesn’t take advantage of this and is just making standard best guess or informed expert decisions, is missing a huge opportunity and hurting their business. The combination of A/B testing and cycling through ideas quickly does two wonderful things: 1) it makes your service better FAST, and 2) it takes the politics and influence out of new ideas. Ideas that work win and, those that don’t show results, don’t get used whether proposed by a VP or the most junior web designers. It’s better for the service and for everyone on the team.
· The infrastructure focus at Amazon. Bezos gets criticized by Wall Street analyst for over investing in infrastructure but the infrastructure investment gives them efficiency and gives them pricing power which is one of their biggest assets. The infrastructure investment also allows them to host third parties which gives Amazon more scale in a business where scale REALLY matters and it gives customers broader selection which tends to attract more customers. Most important, it gives Amazon, the data driven company, more data and this data allows them to improve their service rapidly and give customers a better experience: “customers who bought X…”
· Negative cost of capital: Slide 8 documents how they get a product on day 0, sell it on day 20, get paid on day 23, and pay the supplier on day 44.
· Slide 7 shows what can be done with a great infrastructure investment: respectable margins and very high inventory turn rates.
The presentation is posted: http://ai.stanford.edu/~ronnyk/emetricsAmazon.pdf.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh
Some months back I finished a paper with Joe Hellerstein and Michael Stonebraker scheduled to be published in the next issue of Foundations and Trends of Databases. This paper is aimed at describing how current generation database management systems are implemented. I’ll post a reference to it here once it is published.
As very small part of this paper, we cover the process model used by Oracle, DB2, MySQL, SQL Server, and PostgreSQL. A process model is how a database maps the work it’s doing on behalf of multiple concurrent users onto operating system processes and/or threads. This is an important design choice in that it has fundamental impact on the number of concurrent requests that can be supported, development costs, maintainability, and code base portability amongst other issues.
These same design choices are faced by most high scale server designers and is equally applicable to mail servers, web servers, app servers, and any other application needing to service large numbers of requests in parallel. Given the importance of the topic and it’s applicability to all multi-user server systems, it’s worth covering separately here. I find it interesting to note that three of the leading DBMSs support more than one process model and one supports four variants. There clearly is no single right answer.
Summarizing the process models supported by IBM DB2, MySQL, Oracle, PostgreSQL, and Microsoft SQL Server:
1. Process per DBMS Worker: This is the most straight-forward process model and is still heavily used today. DB2 defaults to process per DBMS worker on operating systems that don’t support high quality, scalable OS threads and thread per DBMS worker on those that do. This is also the default Oracle process model but they also supports process pool as described below as an optional model. PostgreSQL runs the Process per DBMS Worker model exclusively on all operating system ports.
2. Thread per DBMS Worker: This an efficient model with two major variants in use today:
a. OS thread per DBMS Worker: IBM DB2 defaults to this model when running on systems with good OS thread support. This is the model used by MySQL as well.
b. DBMS Thread per DBMS Worker: In this model DBMS Workers are scheduled by a lightweight thread scheduler on either OS processes or OS threads both of which are explained below. This model avoids any potential OS scheduler scaling or performance problems at the expense of high implementation costs, poor development tools and debugger support, and substantial long-standing maintenance costs. There are two sub-categories of this model:
i. DBMS threads scheduled on OS Process: a lightweight thread scheduler is hosted by one or more OS Processes. Sybase uses this model and began with the thread scheduler hosted by a single OS process. One of the challenges with this approach is that, to fully exploit shared memory multi-processors, it is necessary to have at least one process per processor. Sybase has since moved to hosting DBMS threads over potentially multiple OS processes to avoid this limitation. When DBMS threads within multiple processes, there will be times when one process has the bulk of the work and other processes (and therefore processors) are idle. To make this model work well under these circumstances, DBMSs must implement thread migration between processes. Informix did an excellent job of this starting with the Version 6.0 release. All current generation systems supporting this model implement a DBMS thread scheduler that schedules DBMS Workers over multiple OS processes to exploit multiple processors.
ii. DBMS threads scheduled on OS Threads: Microsoft SQL Server supports this model as a non-default option. By default, SQL Server runs in the DBMS Workers multiplexed over a thread pool model (described below). This SQL Server option, called Fibers, is used in some high scale transaction processing benchmarks but, otherwise, is in very light use.
3. Process/Thread Pool: In this model DBMS workers are multiplexed over a pool of processes. As OS thread support has improved, a second variant of this model has emerged based upon a thread pool rather than a process pool. In this later model, DBMS workers are multiplexed over a pool of OS threads:
a. DBMS workers multiplexed over a process pool: This model is much more efficient than process per DBMS worker, is easy to port to operating systems without good OS thread support, and scales very well to large numbers of users. This is the optional model supported by Oracle and the one they recommend for systems with large numbers of concurrently-connected users. The Oracle default model is process per DBMS worker. Both of the options supported by Oracle are easy to support on the vast number of different operating systems they target (at one point Oracle supported over 80 target operating systems).
b. DBMS workers multiplexed over a thread pool: Microsoft SQL Server defaults to this model and well over 99% of the SQL Server installations run this way. To efficiently support 10’s of thousands of concurrently connected users, SQL Server optionally supports DBMS threads scheduled on OS threads.
Most current generation commercial DBMSs support intra-query parallelism, the ability to execute all or parts of query in parallel. Essentially, intra-query parallelism is the temporary assignment of multiple DBMS workers to execute a SQL query. The underlying process model is not impacted by this feature other a single client connection may, at times, have more than a single DBMS worker.
Process model selection has a substantial influence on DBMS scaling and portability. As a consequence, three of the most successful commercial systems each support more than one process model across their product line. From an engineering perspective, it would clearly be much simpler to employ a single process model across all operating systems and at all scaling levels. But, due to the vast diversity of usage patterns and the non-uniformity of the target operating systems, however, each DBMS has elected to support multiple models.
--jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com
H:mvdirona.com | W:research.microsoft.com/~jamesrh | Msft internal blog: msblogs/JamesRH |