Beyond Relational Databases

关于作者
Marcos Albe
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?

3.Introduction Redis?

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

9.

10.

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

17.

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)

21.

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

29.