Future Prospects of Scalable Cloud Computing

Transcription

1 Future Prospects of Scalable Cloud Computing Keijo Heljanko Department of Information and Computer Science School of Science Aalto University /17

2 Future Cloud Topics Beyond MapReduce Pig (Scripting language for MapReduce) Hive (SQL engine for Hadoop) PACT (MapReduce, Joins, ++) Spark (Berkeley, iterative algorithms) Future of Storage Technologies - Disk, Flash & DRAM Cloud Databases - BigTable & HBase Distributed Databases with Transactions - Google Percolator (used for Google s new search engine) 2/17

3 Flash Storage Currently one of the trends is the introduction of Flash memory SSDs (solid state disks) are replacing hard disks in many applications Flash capacity per Euro is increasing faster than hard disk capacity per Euro Random SSD read (and often also write) IOPS are more than 100 those of high end hard disk read and write IOPS 3/17

4 Sustained Flash Write Performance Because of the write leveling algoritms, the sustained Flash memory write speeds are often hard to benchmark and need long test runs to saturate the SSD: http: // Intel_X25-E_G1_vs_Intel_X25-M_G2.htm 4/17

5 Optimizing for Flash One should minimize the number of bytes written to Flash Less bytes written means less wear and longer lifetime expectancy of Flash Less bytes written means less frequent slow block erases, and this improves the overall Flash IOPS Heavy sequential write workloads (e.g., database logs) can be efficiently handled by arrays of hard disks without any problems with write endurance Operating systems support such as the TRIM command which tells to the SSD which data blocks can be safely discarded is very useful 5/17

6 Future of Storage Technologies A mantra from Jim Gray of Microsoft in his 2006 presentation gray/talks/flash_is_good.ppt: Tape is Dead Disk is Tape Flash is Disk RAM Locality is King 6/17

7 Jim Gray on Disks (in 2006) Disk are cheap per capacity Sequential access full disk reads of take hours Random access full disk reads take weeks Thus most of disk should be treated as a cold-storage archive 7/17

8 Jim Gray on Flash (in 2006) Lots of IOPS Expensive compared to disks (but improving) Limited write endurance Slow to write (compared to reading) 8/17

9 Jim Gray on RAM (2006 numbers) Flash/disk is cycles away from the CPU RAM is 100 cycles away from the CPU Thus Jim Gray concludes that main memory databases are going to be common 9/17

10 Some Rule of Thumb Numbers for Flash For a single random access read, the following rules of thumb numbers apply: Main memory reference: 100 ns Flash drive access: ns (1000x slower than memory) Disk seek: ns ( x slower than memory) 10/17

11 RAMCloud John K. Ousterhout, Parag Agrawal, David Erickson, Christos Kozyrakis, Jacob Leverich, David Mazires, Subhasish Mitra, Aravind Narayanan, Diego Ongaro, Guru M. Parulkar, Mendel Rosenblum, Stephen M. Rumble, Eric Stratmann, Ryan Stutsman: The case for RAMCloud. Commun. ACM 54(7): (2011). Facebook in 2009 has been running in 2009 with enough RAM to fit 75% of their dataset (not counting images or video) in RAM If they would use enough RAM cache to hit 99% of the dataset, the random disk seek latency would still kill their average latency performance: (99% 100 ns + 1% ns) = ns, which is way more that 100ns! 11/17

12 RAMCloud - Discussing the Numbers With Flash disks and 99% cache hit rate we get latencies: (99% 100 ns + 1% ns) = 1099 ns, which is still 10x more that 100ns. The above concerns only average latency, not throughput, but similar reasoning also applies to aggregate IOPS numbers of RAM, Flash, and Disk If a system can have enough memory to have 100% of the working set in RAM, instead of Flash / Hard disk, way more IOPS can be served with the same number of servers. 12/17

13 RAMCloud - Limiting Factors The main problem in RAMcloud style designs to guarantee data persistence in case of power failure + quick recovery in case of server crash / power outage The second problem is to have enough low latency networking hardware and OS to keep RAM busy 13/17

14 RAM vs Flash vs Disk The RAMCloud paper has the following diagram adapted from the paper: Andersen, D., Franklin, J., Kaminsky, M., et al., FAWN: A Fast Array of Wimpy Nodes, Proc. 22nd Symposium on Operating Systems Principles, 2009: 14/17

15 BigTable Described in the paper: Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Michael Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber: Bigtable: A Distributed Storage System for Structured Data. ACM Trans. Comput. Syst. 26(2): (2008) A highly scalable consistent and partition tolerant datastore Implemented on top of the Google Filesystem (GFS) GFS provides data persistence by replication but only supports sequential writes BigTable design does no random writes, only sequential writes are used Open source clone: Apache HBase 15/17

16 BigTable Recall that sequential writes are much faster than random writes BigTable is a write optimized design: Writes are optimized over reads The random reads that miss the DRAM cache used are slower than in traditional RDBMS - Most active data should be in DRAM! The design also minimizes the number of bytes written by using efficient logging and compression of data. Also a good design principle for Flash SSD use 16/17

17 BigTable Summary BigTable is a scalable write optimized database design It uses only sequential writes for improved write performance For read intensive workloads BigTable can be a good fit if most of the working set fits into DRAM For read intensive working sets much larger than DRAM, traditional RDBMS systems are still a good match BigTable also has an impressive data scan speed, so scan based workloads (getting MapReduce input data from BigTable) are a good match for its performance Some optimizations such as agressive compression and use of Bloom filters are only viable because SSTables are immutable data objects 17/17