If you are a xenophobe or an ostrich with your head in the sand I encourage you not to watch this video.
DISCLAIMER
I work for Amazon Web Services. The opinions I share in this blog are my own. I'm *not* communicating as a spokesperson for Amazon.
In other words, I work at Amazon, but this is my own opinion.
Pages
- About
- Index of Posts
- Misc
- Papers, Webcasts, etc
- SLOB Resources
- Little Things Doth Crabby Make
Blogroll
- AWS Database Blog
- Bart Sjerps
- Beat Ramseier
- Bertrand Drouvot's blog
- Daniel Westermann
- flashdba
- Franck Pachot
- Frits Hoogland
- Gokhan Atil
- James Morle
- Jan Karremans Blog (Johnnyq72)
- Jason Arneil
- Jonathan Lewis
- Luca Canali's Blog
- Mahmoud Hatem Blog
- Mark Smith
- Martin Bach
- Mauro Pagano
- Nikolay Savvinov
- Noons
- Pardy DBA
- Real World Technologies
- StorageIOblog (Greg Shulz)
- THE ORACLE ALCHEMIST
- The SQL Herald
- Tim Hall
Click It
Recent Posts
- So pgio Does Not Accurately Report Physical I/O In Test Results? Buffering Buffers, and Baffles.
- Announcing pgio (The SLOB Method for PostgreSQL) Is Released Under Apache 2.0 and Available at GitHub
- Announcing SLOB 2.5 for Download at Github.
- Accurately Interpreting Real Application Clusters IOPS with Automatic Workload Repository. So Easy to Get So Wrong.
- No /proc/diskstats Does Not Track **Your** Physical I/O Requests
- SLOB Chewed Up All My File System Space and Spit It Out. But, Why?
- Sneak Preview of pgio (The SLOB Method for PostgreSQL) Part IV: How To Reduce The Amount of Memory In The Linux Page Cache For Testing Purposes.
- Sneak Preview of pgio (The SLOB Method for PostgreSQL) Part III: Link To The Full README file for Beta pgio v0.9.
- Sneak Preview of pgio (The SLOB Method for PostgreSQL) Part II: Bulk Data Loading.
- Sneak Preview of pgio (The SLOB Method for PostgreSQL) Part I: The Beta pgio README File.
Recent Comments
Fond Memories
11.2.0.4
Automatic Workload Repository
AWR
columnar database
column projection
DBaaS
Exadata
Exadata benchmarks
Exadata ERP
Exadata OLTP
Exadata Storage Grid
Exadata Xeon 5600 Datawarehousing
HP Oracle Database Machine
Netezza
Netezza Oracle
NUMA
numactl
OOW12
OpenWorld
OpenWorld 2011
Oracle
Oracle Database performance XtremIO flash
Oracle Exadata Storage Server
Oracle Exadata Storage Server Software
Oracle I/O Performance
Oracle Performance
Oracle Programmable Storage Server
predicate offload processing
Random I/O
Sandy Bridge
SLOB
SLOB Testing
SUMA
Teradata
whitepaper
X2-2 vs X2-8
Xeon E5
Xeon E5-2600
Xeon E7 Performance
XtremIO
Copyright
All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.
The part about this that doesn’t excite me is that the population of China has been approximately 4x that of the USA in the same time period for at least the last 60 years. It is harder to tell how long some of the other trends like the rate of information generation have been going on, but I bet that it is a lot longer than one might think. And in-demand job _titles_ may change, but I suspect that the same (meta) skill set would provide for success in both 1950 and 2007. And 1950 or now, it still remains that a law degree can’t hurt!
John,
Thanks for comment. I too think the numbers are questionable, but the topic is interesting…
Kevin,
It certainly got me thinking! I always feel that things stay the same more than they change–and I have enjoyed your recent posts on topics like shell script portability or the importance of having more spindles, which suggest that this is usually true. But at the same time, when real change happens (I bet that a lot of people reading this blog remember staring at NCSA Mosaic and thinking, hey, this www thing could really work), you had better be ready!