2. Database Landscape
Response time: Hours, Minutes
TB to PB
Compute Intensive
TRANSACTIONS
(OLTP)
Response time: Seconds
Gigabytes of data
Balanced Reads/Writes
ANALYTICS (OLAP)
STRUCTURED
DATA
Response time: Seconds
Terabytes of data
Read Intensive
BIG DATA ANALYTICS
Real-time Transactions
Response time: < 10 ms
1-20 TB
Balanced Reads/Writes
24x7x365 Availability
UNSTRUCTURED
DATA
REAL-TIME BIG DATA
9. Tricks
• Use standard instances
• Balances network & CPU
• Use taskset and leave out 1 or 2 cores
• Result
• Latencies improve
• Throughput marginally improved
• Less CPU going to system
14. Live Migrations : Implications
• Blackout period depends on workload
• Higher the memory dirty rate, longer the blackout
• Timeouts in application code will get triggered
• Effects clustering based solutions (Aerospike,…)
• Missing heartbeats
• Clocktimes of VMs jump
• Implications on any code tightly dependent on clocktime
15. Live Migrations : Handling
• Write better code
• Scheduling policy offered by GCE
• onHostMaintenance : Migrate/Terminate
• automaticRestart : True/False
• Since June 2016 : Live migrate notification
• 60 seconds prior intimation
• Via metadata server
• MIGRATE_ON_HOST_MAINTENANCE
• SHUTDOWN_ON_HOST_MAINTENANCE
16. Local SSDs
• Similar to ephemeral SSDs in AWS (non persistent)
• Not to be confused with persistent SSD (network attached)
• Good cost alternative for RAM
• Can be attached to any instance types
• Spec
• NVMe / SCSI options
• Available in chunks of 375GB
• ~1ms latency
• 680k Read IOPS
• 360K Write IOPS
18. Local SSD with Aerospike
• Use shadow device
configuration in Aerospike
• All reads are from local SSD
• All writes (buffered) go to
both Local SSD & persistent
HDD/SSD (network
attached)
• Bcache is no longer
recommended by Aerospike
• Saw some kernel level
implementation bugs
• Saw drive lockups in rare
occurences
Local
SSD
Network
storage
Aerospike