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
0
200
Surviving Data in Large Doses
NoSQL Search Roadshow London 2013
Tareq Abedrabbo
November 20, 2013
Tweet
Share
More Decks by Tareq Abedrabbo
See All by Tareq Abedrabbo
Not a SO(A) Trivial Question!
tareqabedrabbo
0
49
Designing APIs for Data Driven Systems
tareqabedrabbo
0
53
Things I wish I'd known before I started with Microservices
tareqabedrabbo
0
650
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
1
450
The 7 Deadly Sins of Microservices
tareqabedrabbo
7
1.2k
The Ubiquitous Graph
tareqabedrabbo
0
190
The 7 Deadly Sins of Microservices
tareqabedrabbo
0
590
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
0
60
Time Series and Events: Storage and Querying Strategies with Cassandra
tareqabedrabbo
0
270
Other Decks in Technology
See All in Technology
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
17
6.8k
データマネジメントのトレードオフに立ち向かう
ikkimiyazaki
6
1k
エンジニアの育成を支える爆速フィードバック文化
sansantech
PRO
3
1.1k
インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
nwiizo
5
2.6k
Developer Summit 2025 [14-D-1] Yuki Hattori
yuhattor
19
6.2k
CZII - CryoET Object Identification 参加振り返り・解法共有
tattaka
0
380
Cloud Spanner 導入で実現した快適な開発と運用について
colopl
1
710
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
410
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
AndroidデバイスにFTPサーバを建立する
e10dokup
0
250
白金鉱業Meetup Vol.17_あるデータサイエンティストのデータマネジメントとの向き合い方
brainpadpr
6
760
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
19
7.8k
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
74
9.2k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Rails Girls Zürich Keynote
gr2m
94
13k
Building Applications with DynamoDB
mza
93
6.2k
GraphQLとの向き合い方2022年版
quramy
44
13k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
240
RailsConf 2023
tenderlove
29
1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
550
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Code Reviewing Like a Champion
maltzj
521
39k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
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!