Four thousand words that distill what you really need to understand to build scalable multiuser servers: Server Design by Jeff Darcy.

Tim O'Reilly talks about how Google bets big on HTML5. Sadly, without Internet Explorer support, a lot of this talk is moot to me. Not to say that I wouldn't salivate over using the new HTML5 canvas element. We draw a lot of flow charts graphics and it needs to run on as many browsers as possible. We don't use flash, we use Walter Zorn's excellent jsgraphics library. It's not very fast, but hey, that's why we have multi-gigahertz PCs on our desktops and on our laps.

Recently I read in AnandTech a good article on Solid State Devices (SSD). It certainly blew away many misconceptions I had about SSD.

From a professional point of view, my main interest would be how databases are affected by the following characteristics of SSD:

• Both sequential and random reads are fast with a granularity of 4K. In other words, to modify 1 byte, you still have to write 4K.
• Writes require the block to be erased first. A block is typically 512K. That means if there are no erased (also called trimmed) blocks, you need to erase, and it is a s-l-o-w operation.
• You can only erase a block 10,000 times before it stops working.
• Good quality SSD controllers with onboard caches and highly parallel architectures make a big difference.

From this summary, it appears that the SSD is ideal for relatively static data, and we can selectively put certain parts of the database on SSD. Examples include:

1. The typical publishing web-site, where articles and messages are rarely edited more than a few times.
2. Systems with large amounts of static data, eg. multi-player online games such as the EVE Online case-study.

For transaction processing systems it depends on the usage. Assuming the blocks in a table are updated 10,000 times a day, the data distribution of updates is even across all records, and the table fits into 100 512K blocks, then the lifetime of the SSD for those blocks would be 100 days (this might be acceptable if SSD was sufficiently cheap). And even for data warehouse applications with relatively static data, B-tree index rebalancings will cause the frequent rewrites of indexes.

It also appears that operations characterized by sequential writes such as transaction logging should continue to be placed on hard disks.

For some information on potential database performance, see these articles testing SSD with mysql, DB2 and PostgreSQL. Also see Windows 7 Support and Q&A for Solid-State Drives.