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
84
Designing APIs for Data Driven Systems
tareqabedrabbo
0
64
Things I wish I'd known before I started with Microservices
tareqabedrabbo
0
690
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
1
490
The 7 Deadly Sins of Microservices
tareqabedrabbo
7
1.3k
The Ubiquitous Graph
tareqabedrabbo
0
230
The 7 Deadly Sins of Microservices
tareqabedrabbo
0
640
Building a Scalable Event Service with Cassandra: Design to Code
tareqabedrabbo
0
110
Time Series and Events: Storage and Querying Strategies with Cassandra
tareqabedrabbo
0
340
Other Decks in Technology
See All in Technology
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
670
複数プロダクト組織のAIネイティブ化における戦略 / AICon2026_kude
rakus_dev
0
230
「早く出す」より「事業に効く」 ── 顧客の業務サイクルから逆算するAI時代の二重ループ開発と「変化の設計者」 / devsumi2026
rakus_dev
1
480
Amplify Gen2でbackend.tsにCDKを定義する/しない事によるCDKの挙動の違いとユースケース
smt7174
1
440
AI Coding Agent時代のcdk-nagガードレール 〜組織ルールを強制CIで守り抜く設計の挑戦〜
mhrtech
3
450
Copilot / Claude Code 両方で使えるスキル・ハーネスの紹介 - Claude Codeスキル・ハーネス社内勉強会
colopl
0
110
10年目を迎えた「ABEMA」がどのように AI 活用を推進して、AI 駆動開発にシフトしているのか / How ABEMA, entering its 10th year, is promoting the use of AI and shifting toward AI-driven development
miyukki
0
310
AI時代の開発生産性は、個人技からチーム設計へ
moongift
PRO
4
2.4k
インシデント事例と パッケージの全量解析に学ぶ ソフトウェアサプライチェーンの守り方 / supply-chain-attack-defense
flatt_security
0
250
2年前に削除したPHPクラスが、 ある日突然決済をエラーにした
ykagano
1
550
Type-safe IaC for Dart
coborinai
0
170
変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則
kawauso
1
360
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
180
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
56k
How to train your dragon (web standard)
notwaldorf
97
6.7k
ラッコキーワード サービス紹介資料
rakko
1
4M
Speed Design
sergeychernyshev
33
1.9k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
430
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
270
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.9k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
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!