/images/head.jpg

AWS re:Invent 2018 tidbits

Amazon RDS PostgreSQL

  • 2 flavors.
    • Open-source PostgreSQL on top of EBS
    • Aurora PostgreSQL on top of Aurora Storage (better performance)
  • Supports Postgre 9.6/10
  • Aurora Postgres supports one RW master node and many read replicas. A read replica will be promoted to the master node when the original master node fails.
  • Aurora Postgres supports fast clones. Only need to pay for the storage of changed data.
  • Will support logical replication by introducing the logical decoding plugin which converts physical changes to SQL statements. The logical decoding plugin can also be used as the event source for publish/subscribe.
  • Aurora Postgres bypasses filesystem page cache and manages its memory directly (more memory as the shared buffer). Aurora Postgres supports survivable cache: the shared buffer will survive postgres process crashes. This enable faster performance recovery.

S3: Simple Storage Service

  • AWS S3 team: ~1000 engineers
  • When a bucket is created, it will be assigned one initial partition. Each partition can support up to 3,500 PUTs or 5,500 GETs. This means you either get 3,500 PUTs and 0 GET tps or 0 PUTs and 5,500 GET tps.
    • 50% PUT and 50% GET = (0.5 * 3,500) + (0.5 * 5,500) = 4,500 tps combined
    • 30% PUT and 70% GET = (0.3 * 3,500) + (0.7 * 5,500) = 4,900 tps combined.
  • In the backend, they detect access load on a partition. When a partition becomes hot, they will split the partition based on object prefix. They do the re-partition only when the load is consistently high for at least half an hour. They do not support auto scale-down for now.

ML frameworks

  • MXnet: efficient distributed training; portability; efficient inference; inference on edge
  • Gluon: easy coding; easy debugging; toolkits for rapid prototyping
  • SageMaker: end-2-end platform; zero setup; distributed training; AB/testing; scalable endpoints; automatic model tuning

DynamoDB Deep Dive

  • why choose NoSQL?
    • SQL: optimized for storage
      • Normalized/relational
      • Ad hoc queries
      • Scale vertically
      • Good for OLAP
    • NoSQL: optimized for compute
      • Denormalized/hierarchical
      • Instantiated views
      • Scale horizontally
      • Built for OLTP at scale
  • Partition key
    • Large number of distinct values
    • Items are uniformly requested and randomly distributed
  • Sort key
    • Efficient/selective patterns
    • Leverage range queries
  • 1 application service = 1 table
    • Reduce round trips
    • Simplify access patterns
    • Inside Amazon, they have managed to support ~40 different queries with one table.

Lambda/Serverless

  • One function per one microVM
  • No orchestration code in a Lambda function. Retry/error handling should be done using Step functions.
  • Should avoid monorepo for functions: one repo per function. This simplifies permissions and keeps each function small (minimize dependency for each function and use less memory).
  • Four stages in the function lifecycle
    1. Download your code (cold start)
    2. Start new execution environment (cold start)
    3. Bootstrap the runtime (Partial cold start)
    4. Start your code (Warm start)
  • Use AWS X-Ray for instrumenting Lambda functions
  • CPU is proportional to memory size: increase the memory size will make a function run much faster and in some cases, could save the cost as well.
    • < 1.8 GB: single core
    • 1.8 GB: 2 cores

AWS re:Invent 2018

I attended the AWS re:Invent at Las Vegas the week after Thanksgiving. It was a great week there, learning AWS technologies while also having fun. The keynotes given by Andy Jassy and Werner Vogels were always exciting: they covered important new services that were launched during this event. Other sessions shared best practices in using AWS services and infrastructure. They also had music bands playing live music at the site and provided great lunches and snacks during the morning and afternoon breaks. Besides, we can come and pick up a swag every day. This year, more than 50,000 people attended the conference and you can see lots of people walking around. This is by far the largest conference I have ever attended and I was amazed by how well they managed to organize it.

Systems and services built on top of postgreSQL

It is surprised to come across several systems/services that happen to built on top of postgreSQL. Here is a quick summary of these.

Systems/services Type
AWS Redshift data warehousing
TimeScale time series database
openGauss/GaussDB distributed relational db, by Huawei
  • AWS Redshift: Redshift is a data warehousing service offered by AWS. It is built on postgreSQL, with a new columnar storage engine. The use of columnar storage is expected to provide better query performance and better compression.

Lines of Code for Various Software

Just out of curiosity, I wanted to know how many lines of code for various software that I am interested in (mostly, file systems and key-value stores). ext4 is the newer version for ext2, mainly added with the journaling mechanism to provide data consistency for crashes. The number of codes for ext4 is 5 times more than ext2. f2fs is a new file system that is optimized for flash devices while nova is a new file system that is optimized for persistent memory. Both of them are in the order of 30,000 lines of code. I also looked at leveldb and rocksdb, which are key-value stores. rocksdb is derived from leveldb and has gained great popularity in recent years. While rocksdb focked from leveldb, as we can see, the number of lines of code in rocksdb is >10 times more than leveldb. Maybe, we should really consider rocksdb as a different key-value store. While key value stores are supposed to be more performant and provide simple APIs, it is interesting to see that rocksdb has grown to be even more complex (4 times more in lines of code) than an actual relational database: postgreSQL.

SPDK on Intel Optane and Samsung ZSSD

Finally got some time to test out Intel Optane SSD and Samsung ZSSD with SPDK. Once again, I compared performance numbers from SPDK with Linux block device. Here are some numbers. The experiments were run in a Ubuntu14.04 server and we tested 4KiB random read performance.

Intel Optane SSD

Metric SPDK /dev/nvme1n1
IOPS 150 K 66.1 K
slat 0.13 usec 2.8 usec
clat 6.2 usec 11.4 usec
lat 6.35 usec 14.32 usec

Samsung ZSSD

Metric SPDK /dev/nvme0n1
IOPS 73.9 K 46.2 K
slat 0.14 usec 3.2 usec
clat 13.0 usec 17.4 usec
lat 13.12 usec 20.73 usec

slat: average submission latency
clat: the time between submission to the kernel and when the IO is complete
lat: total IO latency

Install hotCRP at a Ubuntu 14 Machine

  1. Update packages

     sudo apt-get update
    
  2. Install php7. The default php coming with Ubuntu 14 is 5.5.9 while hotCRP prefers 5.6 and later.

    1. Install the software-properties-common package to get the add-apt-repository command.

       sudo apt-get install software-properties-common
      
    2. Add php7 ppa and do an update

       sudo add-apt-repository ppa:ondrej/php	
       sudo apt-get update
      
    3. Install php7

       sudo apt-get install php7.2 php7.2-mysql
      
  3. Install other required packages

     sudo apt-get install git apache2 mysql-server zip poppler-utils sendmail
    
  4. Get hotCRP source code