Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Small Data: Storage For The Rest Of Us
Search
Andrew Godwin
May 26, 2015
Programming
680
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Small Data: Storage For The Rest Of Us
A talk I gave at PyWaw Summit 2015.
Andrew Godwin
May 26, 2015
More Decks by Andrew Godwin
See All by Andrew Godwin
Working With Risk: Lessons From Mountain Rescue
andrewgodwin
1
26
Reconciling Everything
andrewgodwin
1
420
Django Through The Years
andrewgodwin
0
350
Writing Maintainable Software At Scale
andrewgodwin
0
560
A Newcomer's Guide To Airflow's Architecture
andrewgodwin
0
440
Async, Python, and the Future
andrewgodwin
2
770
How To Break Django: With Async
andrewgodwin
1
860
Taking Django's ORM Async
andrewgodwin
0
880
The Long Road To Asynchrony
andrewgodwin
0
790
Other Decks in Programming
See All in Programming
SODA - FACT BOOK(JP)
sodainc
1
40k
SODA - FACT BOOK(EN)
sodainc
1
200
Performance Optimization With LLMs
xleitix
0
230
React Native에 현대적인 빌드 도구 더하기: Rollipop 구현기
leegeunhyeok
0
170
クラウドゲーミングのパフォーマンス最適化に挑む / Cloud Gaming Performance Tuning
vivion
0
310
GraphQL の onError と Nullability のこれから
quramy
0
200
[Dev Group Paris Octobre 26] Agentforce, SIforce, Claudeforce, Slackbot… on s'y retrouve ?
nabondance
0
120
私なりのハーネスエンジニアリング ~独自の言語処理系の開発を通して~
seosoft
0
160
dotNET_vulnclicker_intro.pdf
deka_morita
0
160
LLM 101
dalinaum
0
430
Railsバージョンを4倍にした話
optim
0
900
flutter_test のその先へ — Flutter アプリの LLM 機能に「評価」という品質保証を
kosukesaigusa
0
160
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
18k
Mobile First: as difficult as doing things right
swwweet
225
10k
Are puppies a ranking factor?
jonoalderson
2
4.1k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
33
5.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
How to build a perfect <img>
jonoalderson
1
6.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
What's in a price? How to price your products and services
michaelherold
247
13k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
660
Embracing the Ebb and Flow
colly
88
5.2k
Transcript
Andrew Godwin @andrewgodwin SMALL DATA STORAGE FOR THE REST OF
US
Andrew Godwin Hi, I'm Django Core Developer Senior Engineer at
Far too many hobbies
BIG DATA What does it mean?
BIG DATA What does it mean? What is 'big'?
1,000 rows? 1,000,000 rows? 1,000,000,000 rows? 1,000,000,000,000 rows?
Scalable designs are a tradeoff: NOW LATER vs
Small company? Agency? Focus on ease of change, not scalability
You don't need to scale from day one But always
leave yourself scaling points
Rapid development Continuous deployment Hardware choice Scaling 'breakpoints'
Rapid development It's all about schema change overhead
Explicit Schema ID int Name text Weight uint 1 2
3 Alice Bob Charles 76 84 65 Implicit Schema { "id": 342, "name": "David", "weight": 44, }
Silent Failure { "id": 342, "name": "David", "weight": 74, }
{ "id": 342, "name": "Ellie", "weight": "85kg", } { "id": 342, "nom": "Frankie", "weight": 77, } { "id": 342, "name": "Frankie", "weight": -67, }
Continuous deployment It's 11pm. Do you know where your locks
are?
Add NULL and backfill 1-to-1 relation and backfill DBMS-supported type
changes
Hardware choice ZOMG RUN IT ON THE CLOUD
VMs are TERRIBLE at IO Up to 10x slowdown, even
with VT-d.
Memory is king Your database loves it. Don't let other
apps steal it.
Adding more power goes far Especially with PostgreSQL or read-only
replicas
Scaling Breakpoints
Sharding point Datasets paritioned by primary key
Vertical split Entirely unrelated tables
Denormalisation It's not free!
Consistency leeway Can you take inconsistent views?
Load Shapes
Read-heavy Write-heavy Large size
Read-heavy Write-heavy Large size Wikipedia TV show website Minecraft Forums
Amazon Glacier Eventbrite Logging
Read-heavy Write-heavy Large size Offline storage Append formats In-memory cache
/ flat files Many indexes Fewer indexes
Extremes
Extreme Reads Heavy Replication Extreme Writes Sacrifice ordering or consistency
Extreme Size Sacrifice query time
Extreme Longevity Flash in cold storage Extreme Survivability Rad-hardened Flash
Extreme Auditability True append only storage
SSDs Magnetic Tape Hard Drives Consumer Flash CDs/DVDs Long-life Flash
Metal-Carbon DVDs 3-6 months 5-10 years 3-5 years 100+ years Approximate time to bit flip, unpowered at room temperature
Big Data isn't one thing It depends on type, size,
complexity, throughput, latency...
Focus on the current problems Future problems don't matter if
you never get there
Efficiency and iterating fast matters The smaller you are, the
more time is worth
Good architecture affects product You're not writing a system in
a vacuum
Thanks. Andrew Godwin @andrewgodwin