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
670
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
Reconciling Everything
andrewgodwin
1
410
Django Through The Years
andrewgodwin
0
340
Writing Maintainable Software At Scale
andrewgodwin
0
550
A Newcomer's Guide To Airflow's Architecture
andrewgodwin
0
430
Async, Python, and the Future
andrewgodwin
2
760
How To Break Django: With Async
andrewgodwin
1
840
Taking Django's ORM Async
andrewgodwin
0
870
The Long Road To Asynchrony
andrewgodwin
0
780
The Scientist & The Engineer
andrewgodwin
1
870
Other Decks in Programming
See All in Programming
The Rails Doctrine Decade
koic
2
500
GemmaをJevのように使ってみる / Use Gemma like Jev
kishida
5
680
技術的負債を組織課題として解く-増えすぎたマイクロサービスとの戦い-
reimaru
1
2.8k
Androidだけじゃない、DroidKaigiで広がった私の技術スタック
akkeylab
0
120
AI Agent時代のリアーキテクチャ戦略と実践
hokaccha
9
5.4k
Agentic Software Factoryに、すごく賢いIF文を。 / super smart IF statement into the Agentic Software Factory.
rkaga
7
1.8k
iOSDC2026登壇資料.pdf
riofujimon
0
210
見えないものを探る要求要件定義に必要な基本的思考 / invisible-requirement-thinking
minodriven
13
6.6k
contenteditable と日本語入力に向き合う
colorful12
0
120
JAWS-UG 東京支部が始める、JAWS-UG支部コラボ / JAWS-UG lunchtime LT Collaboration
y0hgi
0
180
設計次第でAIコードの読む量は減らせる / designing-for-code-reading
minodriven
34
15k
ハーネス設計入門 〜 基礎知識の整理から実務へのステップアップ 〜
kinopeee
20
21k
Featured
See All Featured
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
250
Documentation Writing (for coders)
carmenintech
77
5.6k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
68
58k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
35
2.9k
For a Future-Friendly Web
brad_frost
183
10k
Designing Powerful Visuals for Engaging Learning
tmiket
1
590
What's in a price? How to price your products and services
michaelherold
247
13k
Building the Perfect Custom Keyboard
takai
2
890
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
580
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
790
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