Beyond Relational Databases: MongoDB, Redis and ClickHouse

1 . Beyond Relational Databases: MongoDB, Redis & ClickHouse Marcos Albe - Principal Support Engineer @ Percona 1 © 2019 Percona 

2 .Introduction MySQL everyone? 2 © 2019 Percona 

3 .Introduction Redis? Memcached? 3 © 2019 Percona 

4 . Image credits: 451 Research (https://451research.com/state-of-the-database-landscape) 4 © 2019 Percona 

5 .Agenda ▪ Introduction ▪ Why not Relational Databases? ▪ Redis: Key-Value ▪ MongoDB: Document ▪ ClickHouse: Columnar 5 © 2019 Percona 

6 .Why not Relational Databases? 6 © 2019 Percona 

7 .Why not Relational Databases? ▪ General purpose but not optimal for all purposes ▪ Impedance mismatch with developers ▪ ACID/locking induced latency ▪ Storage architecture not optimal for big data 7 © 2019 Percona 

8 .Agenda ▪ Introduction ▪ Why not Relational Databases? ▪ Redis: Key-Value ▪ MongoDB: Document ▪ ClickHouse: Columnar 8 © 2019 Percona 

9 .9 © 2019 Percona 

10 .10 © 2019 Percona 

11 .Redis highlights ▪ Fast… very fast. ▪ Mature / large community ▪ Many data structures ▪ Advanced features ▪ Horizontally scalable / built-in HA (Sentinel / Cluster) ▪ BSD license / Commercial licenses available ▪ Client libraries for about every programming language 11 © 2019 Percona 

12 .Redis data types ▪ Lists ▪ Sets ▪ Sorted sets ▪ Hashes ▪ Bitmaps ▪ Geohash 12 © 2019 Percona 

13 .Redis good use cases ▪ Lots of data ▪ High concurrency ▪ Massive small-data intake ▪ Simple data access patterns ▪ Session Cache / Full page cache ▪ Counters / Leaderboards ▪ Queues 13 © 2019 Percona 

14 .Redis bad Use Cases ▪ Durability and consistency ▪ Complex data access patterns ▪ Non-PK access ▪ Security concerns 14 © 2019 Percona 

15 .PROs CONs ▪ Fast ▪ Lower durability ▪ Highly scalable/available ▪ Limited access patterns ▪ Simple access patterns ▪ Lack of security ▪ Advanced data types ▪ No secondary keys ▪ Advanced features for KV store ▪ Cache invalidation is hard Atomic operations ▪ Ubiquitous / large community 15 © 2019 Percona 

16 .Agenda ▪ Introduction ▪ Why not Relational Databases? ▪ Redis: Key-Value ▪ MongoDB: Document ▪ ClickHouse: Columnar 16 © 2019 Percona 

17 .17 © 2019 Percona 

18 .MongoDB Flexible Schema 18 © 2019 Percona 

19 .MongoDB Flexible Schema 19 © 2019 Percona 

20 .MongoDB Flexible Schema ▪ Embedded in blogpost document (natural case) ▪ Embedded in user document (bad idea) ▪ Denormalize and keep duplicate data (VERY bad idea) ▪ Apply normalization and user lookup() (JOIN equivalent) 20 © 2019 Percona 

21 .21 © 2019 Percona 

22 .Document Stores: Flexible Schema 22 © 2019 Percona 

23 .Document Stores: Flexible Schema 23 © 2019 Percona 

24 .MongoDB highlights ▪ Sharding and replication for dummies! ▪ Flexible schema ▪ Multi-document transactions (new in 4.0) ▪ Pluggable storage engines for distinct workloads. ▪ Excellent compression options with PerconaFT, RocksDB, WiredTiger ▪ On disk encryption (Enterprise Advanced) ▪ Connectors for all major programming languages ▪ Sharding and replica aware connectors ▪ Geospatial functions ▪ Aggregation framework 24 © 2019 Percona 

25 .MongoDB good use cases ▪ Catalogs ▪ Analytics/BI (BI Connector on 3.2) ▪ Time series ▪ Metadata repositories ▪ Prototype Development 25 © 2019 Percona 

26 .MongoDB bad use cases ▪ Recursiveness ▪ Multiple views of the data ▪ Developer comfort 26 © 2019 Percona 

27 .PROs CONs ▪ Fast ▪ Inefficiency for JOINs ▪ Easy sharding ▪ Still immature internally ▪ Simple access patterns ▪ Attribute names bloat space ▪ Rich feature set ▪ MMAP db-level locking ▪ Async connectors ▪ Flexible schema 27 © 2019 Percona 

28 .Agenda ▪ Introduction ▪ Why not Relational Databases? ▪ Redis: Key-Value ▪ MongoDB: Document ▪ ClickHouse: Columnar 28 © 2019 Percona 

29 .29 © 2019 © 2019 Percona Percona