Transcript
Page 1: Data antipatterns NYC Devops - 2014

ANTI PATTERNS

DATA

Updated!

Page 2: Data antipatterns NYC Devops - 2014

ines @ Engine Yard.com @Randommood

And I’m a happy dog!

I N E SS O M B R A

I work with Databases

Page 3: Data antipatterns NYC Devops - 2014
Page 4: Data antipatterns NYC Devops - 2014

I can get a little ragey

sometimes

Disclaimer #1

Page 5: Data antipatterns NYC Devops - 2014

I’m sorry.!

Ask me to slow down.

Disclaimer #2

Page 6: Data antipatterns NYC Devops - 2014

ZOMG, the horror!

Page 7: Data antipatterns NYC Devops - 2014

.BACKUPSyes, we are going there

Page 8: Data antipatterns NYC Devops - 2014

“I know you. You know you. And I know you

know that I know you”

White Goodman

Page 9: Data antipatterns NYC Devops - 2014

Boring Definition #1

Backups

Copy and archiving of data

Goal is to restore the state of a DB

Many types - blah

Page 10: Data antipatterns NYC Devops - 2014

Anti-Pattern #1

Taking too many

backups

Not free, they requires resources

Full backup every hour, really? What about backup retention?

Page 11: Data antipatterns NYC Devops - 2014

Anti-Pattern #2

Taking too few

backups

Enough to minimize the risk of data loss due to corrupted backup files

yes,����������� ������������������  this����������� ������������������  totes����������� ������������������  happens!

Page 12: Data antipatterns NYC Devops - 2014

The untested backup

Anti-Pattern #3

Page 13: Data antipatterns NYC Devops - 2014

Doing backups right

Logically test

backups

Errorless restore is not enough. Test logical data too

Page 14: Data antipatterns NYC Devops - 2014

Doing backups right

Know your types &

tools

Take logical and binary backups

Continuous archiving & hot backup utilities

Page 15: Data antipatterns NYC Devops - 2014

Doing backups right

Practice restores

Backups alone do not constitute DR. Have a plan & practice it

Server extensions and configuration matter when restoring

Page 16: Data antipatterns NYC Devops - 2014

“I want a ridiculously

good looking

Database” Derek Zoolander

(honestly, Ben Stiller rules)

Page 17: Data antipatterns NYC Devops - 2014

Obvious statement #1

Many DB choices

Page 18: Data antipatterns NYC Devops - 2014

Cargo culting your

database

Anti-Pattern #4Failure to understand use case, strengths & weaknesses of a new database

Page 19: Data antipatterns NYC Devops - 2014

RDBMS for Session

Data

Anti-Pattern #5 Often means at least one write per request

Any DB issue/task may cause app to hang

Tables have a tendency to bloat

Page 20: Data antipatterns NYC Devops - 2014

Modeling, it’s all the same

Anti-Pattern #6

Page 21: Data antipatterns NYC Devops - 2014

Data Model

Consistency needs

Availability needs

Scaling needsOperational story & cost

Doing it right

Know your needs

Page 22: Data antipatterns NYC Devops - 2014

Doing it right

Spike it, forealsies

Spike it with your data and traffic. Best way to gain operational experience

Page 23: Data antipatterns NYC Devops - 2014

Doing it right

Leverage new

features

Relational databases are getting quite versatile

Evaluate clustered MySQL options

Page 24: Data antipatterns NYC Devops - 2014

Are we doing

ok?

Page 25: Data antipatterns NYC Devops - 2014

We have a cloud deployment!Happy team on shipping day, lmfao if you don’t celebrate like this

Page 26: Data antipatterns NYC Devops - 2014

Cloud-based databases,

they are real

Obvious statement #2 Databases can live in the cloud quite well

Many IaaS, PaaS, & DBaaS options

Easy to get started & may be economical

Page 27: Data antipatterns NYC Devops - 2014

Where did my instance go?

Anti-Pattern #7

Page 28: Data antipatterns NYC Devops - 2014

Anti-Pattern #8

Cloud, it’s just like

hardware

It’s not. Cloud resources are virtualized

Capacity planning and monitoring matter. A lot

Page 29: Data antipatterns NYC Devops - 2014

Anti-Pattern #9

Shit doesn’t happen

You are not immune to infrastructure failures. Plan for it

Page 30: Data antipatterns NYC Devops - 2014

Anti-Pattern #10

Storage is the same

Instance storage is not persisted (unless you use EBS)

Data locality matters

Don’t run your cloud DBs too hot!

Page 31: Data antipatterns NYC Devops - 2014

Doing cloud right

Know your cloud

deployments

Replication in the cloud is a must-have

Put DB master & replicas in different AZs

Page 32: Data antipatterns NYC Devops - 2014

Doing cloud right

Learn high availability &

disaster recovery

Get good at replica promotions (some work involved)Understand and invest in DR/HA. Know your options

Page 33: Data antipatterns NYC Devops - 2014

Doing cloud right

Know your system

Invest in monitoring

Know your data distribution & querying patterns

Know baseline behavior

Page 34: Data antipatterns NYC Devops - 2014

And there’s more!

Page 35: Data antipatterns NYC Devops - 2014

Boring Definition #2

Indexes(or indices, I prefer indexes)

Improves speed of data retrieval

Used in random & ordered lookups

Imply additional writes & storage

Page 36: Data antipatterns NYC Devops - 2014

Anti-Pattern #12

Too few Indexes

Room for query optimization & increased speed

Analyze, slow logs & monitoring tools are your friends

Page 37: Data antipatterns NYC Devops - 2014

Anti-Pattern #13

Too many Indexes

They are not free. Your DB maintains them.

Too many will impact your write throughput.

Page 38: Data antipatterns NYC Devops - 2014

Doing Indexes right

Many index types

Many types. Learn how your DB does them.

You want the right amount.

Page 39: Data antipatterns NYC Devops - 2014

Doing Indexes right

Postgres Indexes

summarized

B - T R E E S D E F A U LT. N U M E R I C , T E X T , N U L L H A S H E Q U A L I T Y . D O N ’ T U S E

G I N A R R AY V A L U E S & F T S G I S T G E O M E T R I C D AT A & F T S

They Can Be Created Concurrently!

Page 40: Data antipatterns NYC Devops - 2014

Doing Indexes right

Postgres Indexes are more baller

P A R T I A L I N D E X E S I N D E X + W H E R E C L A U S E E X P R E S S I O N I N D E X E S M AT C H O N F U N C T I O N / M O D I F I C AT I O N

U N I Q U E I N D E X E S P R E V E N T S D U P E S S O R T E D I N D E X E S A LT E R B - T R E E F R O M A S C T O D E S C

Page 41: Data antipatterns NYC Devops - 2014

Prioritize them, take them regularly. For the love of

sweet baby jesus routinely test them

Backups Know a DBs use case,

strengths, & weaknesses How well does it fit your

needs?

Choices

tl;dr;

Have the right amount. Properly maintain them.

DB IndexesNot the same as real hardware. Plan for

failures.

The Cloud

Page 42: Data antipatterns NYC Devops - 2014

QuestionsThank you!

I’m @randommood on the twitters .


Top Related