Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Surviving Data in Large Doses
Search
Tareq Abedrabbo
November 20, 2013
Technology
240
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Surviving Data in Large Doses
NoSQL Search Roadshow London 2013
Tareq Abedrabbo
November 20, 2013
More Decks by Tareq Abedrabbo
See All by Tareq Abedrabbo
Not a SO(A) Trivial Question!
tareqabedrabbo
0
90
Designing APIs for Data Driven Systems
tareqabedrabbo
0
72
Things I wish I'd known before I started with Microservices
tareqabedrabbo
0
700
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
1
510
The 7 Deadly Sins of Microservices
tareqabedrabbo
7
1.3k
The Ubiquitous Graph
tareqabedrabbo
0
230
The 7 Deadly Sins of Microservices
tareqabedrabbo
0
650
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
0
120
Time Series and Events: Storage and Querying Strategies with Cassandra
tareqabedrabbo
0
350
Other Decks in Technology
See All in Technology
Bet AI Day 2026丨バクラク Autopilot、業務システムの再設計
layerx
PRO
2
1.6k
作り直せるコードは迅速に 作り直せないDBは慎重に - AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話
kinosuke01
0
270
データエンジニアリングワークショップ:Auto LoaderとSparkで学ぶデータパイプライン構築
databricksjapan
PRO
0
210
【視聴者参加型!】AWSセキュリティアンチパターンクイズ
syoshie
0
450
AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI era
yokawasa
1
160
コスト最適化の「めんどくさい」を AWS FinOps Agent でチョット楽にする
classmethod_kaz
0
270
IoTハンズオンの舞台裏
shirouz
2
160
Bet AI Day 2026丨How We Bet AI: AIとともに働く場をつくる
layerx
PRO
2
2.8k
AI時代におけるプロダクト横断勉強会の設計
zozotech
PRO
0
170
「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―
go0517go
PRO
0
260
Azure Cost Management の FOCUS コストデータを迷わず読むための“3つの軸”
tetsuyaooooo
0
150
AIとペアプロを始める。人とのペアプロをやめる。ペアプロの良さを改めて知る。もっと好きになった。 / Rediscovering Pair Programming
honyanya
1
280
Featured
See All Featured
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
230
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.7k
Design in an AI World
tapps
1
310
Everyday Curiosity
cassininazir
0
310
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
76k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
970
4 Signs Your Business is Dying
shpigford
187
23k
First, design no harm
axbom
PRO
2
1.3k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
How STYLIGHT went responsive
nonsquared
100
6.3k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3k
Why Our Code Smells
bkeepers
PRO
340
58k
Transcript
Surviving Data in Large Doses Tareq Abedrabbo NoSQL Search Roadshow
London 2013
About me • CTO at OpenCredo • Delivering large-scale data
projects in a number of domains • Co-author of Neo4j in Action (Manning)
What this talk is about…
Supermarkets
Meanwhile, in DevLand
Bob is an application developer
Bob wants to build an application. Bob knows that a
relational database is definitely not the right choice for his application
Bob chooses a NoSQL database because he likes it (he
secretly thinks it’s good for his CV too).
Bob goes for a three-tier architecture. It’s separation of concerns.
It’s best practice.
Bob builds an object model first. It’s Domain Driven Design.
It’s best practice.
Bob uses an object mapping framework. Databases should be hidden
behind layers of abstraction. It’s best practice.
Bob hopes for the best!
What challenges is Bob facing?
Suitability of the data model
Suitability of the architecture and the implementation
Ability to meet new requirements
Being able to use the selected technology to the best
of its ability
Performance
A number of applications built on top of NoSQL technologies
end up unfit for purpose
How did we get ourselves into such a mess?
• Technical evangelism • Evolution in requirements • Unthinking decisions
• Ill-informed opinions
Common problem: there is focus on technology and implementation, not
on real value
So what’s the alternative?
Separation of concerns based on data flow
Data flow
• Lifecycle • Structure • Size • Velocity • Purpose
How?
Identify the concerns: what do I care about?
Identify the locality of these concerns: where are the natural
boundaries?
Build focused specialised models
Compose the models into a complete system
Computing is data structures + algorithms
If we accept that separation of concerns should be applied
to algorithms, it is appropriate to apply the same thinking to data
The real value of this form of separation of concerns
is true decoupling
What’s out there
CQRS
Polyglot Persistence
How do I apply it?
It depends on the data flow :)
For general-purpose data platforms, micro services work well
Build micro services that are closer to the natural underlying
model
Other strategies are possible, for example if the data is
highly volatile, consider in-memory grids
There are practical considerations - obviously
Don’t start with 10 different databases because you think you
might eventually need all of them
How would that impact support and operations?
There is potential for simplification based on clearly targeted usage
Links • Twitter: @tareq_abedrabbo • Blog: http://www.terminalstate.net • OpenCredo: http://www.opencredo.com
Thank you!