Marcos Albe has been doing web development for over ten years, providing solutions for various media and technology companies of different sizes. He is now Regional a member of the Percona Support Team Born and raised in the city of Montevideo, Uruguay, he became passionate about computers at the age of 11, when he got a 25Mhz i386-SX. Some ten years later, he became one of the pioneers in telecommuting in Uruguay while leading the IT efforts for the second largest newspaper in the country.
1.Beyond Relational Databases: MongoDB, Redis & ClickHouse Marcos Albe - Principal Support Engineer @ Percona
2.Introduction MySQL everyone?
4. OLAP -vs- OLTP Image credits: 451 Research (https://451research.com/state-of-the-database-landscape)
5.Agenda ● Introduction ● Why not Relational Databases? ● Redis: Key-Value ● MongoDB: Document ● ClickHouse: Columnar
6.Why not Relational Databases?
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
8.Agenda ● Introduction ● Why not Relational Databases? ● Redis: Key-Value ● MongoDB: Document ● ClickHouse: Columnar
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
12.Redis data types ● Lists ● Sets ● Sorted sets ● Hashes ● Bitmaps ● Geohash
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
14.Redis bad Use Cases ● Durability and consistency ● Complex data access patterns ● Non-PK access ● Security concerns ● Operations
15.PROs CONs ● Fast ● Lower durability ● Highly scalable/available ● Operational complexities ● Simple access patterns ● Limited access patterns ● Advanced data types ● Lack of security ● Advanced features for KV store ● No secondary keys ○ Atomic operations ● Ubiquitous / large community
16.Agenda ● Introduction ● Why not Relational Databases? ● Redis: Key-Value ● MongoDB: Document ● ClickHouse: Columnar
18.MongoDB Flexible Schema
19.MongoDB Flexible Schema
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)
22.Document Stores: Flexible Schema
23.Document Stores: Flexible Schema
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
25.MongoDB good use cases ● Catalogs ● Analytics/BI (BI Connector on 3.2) ● Time series ● Metadata repositories ● Prototype Development
26.MongoDB bad use cases ● Recursiveness ● Multiple views of the data ● Developer comfort
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
28.Agenda ● Introduction ● Why not Relational Databases? ● Redis: Key-Value ● MongoDB: Document ● ClickHouse: Columnar