展开查看详情
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
热门城市
