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
NoSQL 大腸花
Search
yunglin
January 17, 2015
Technology
27
3.7k
NoSQL 大腸花
yunglin
January 17, 2015
Tweet
Share
More Decks by yunglin
See All by yunglin
Manage cloud server with open source tools
yunglin
1
110
Java Developer Day 2013 Scala Future API
yunglin
3
720
Java Developer Day 2012 Introduction to Actor Model
yunglin
1
120
Software Quality Metrics
yunglin
1
89
Other Decks in Technology
See All in Technology
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
230
AGIについてChatGPTに聞いてみた
blueb
0
130
EventHub Startup CTO of the year 2024 ピッチ資料
eventhub
0
120
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
440
[CV勉強会@関東 ECCV2024 読み会] オンラインマッピング x トラッキング MapTracker: Tracking with Strided Memory Fusion for Consistent Vector HD Mapping (Chen+, ECCV24)
abemii
0
230
飲食店データの分析事例とそれを支えるデータ基盤
kimujun
0
170
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
4
230
組織成長を加速させるオンボーディングの取り組み
sudoakiy
2
220
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
【令和最新版】AWS Direct Connectと愉快なGWたちのおさらい
minorun365
PRO
5
760
Lexical Analysis
shigashiyama
1
150
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
arthur1
5
490
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Embracing the Ebb and Flow
colly
84
4.5k
4 Signs Your Business is Dying
shpigford
180
21k
Bash Introduction
62gerente
608
210k
RailsConf 2023
tenderlove
29
900
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Scaling GitHub
holman
458
140k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
How to Ace a Technical Interview
jacobian
276
23k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Into the Great Unknown - MozCon
thekraken
32
1.5k
Transcript
NoSQL ⼤大腸花 何永琳 ⼯工頭 @ Fliptop
議程 • NoSQL 經驗 • MongoDB 2.2, 2.4, 2.6 •
CouchDB 1.2 • Cassandra 0.6, 0.7, 1.0 • Riak 1.?
其實我只是想幹樵 MongoDB
NoSQL 前世今⽣生
No SQL Not Only SQL
為什麼 SQL 變成 DB 的代名詞?
第⼀一次 DB ⼤大戰 1960s~1970s
參戰國 • Hierarchical model • Network model • Relational model
戰勝國 • Edgar F. Codd: I don't use database often,
but when I do, I always use RDBMS.
Relational Model
RDBMS/SQL • Atomicity • Consistency • Isolation • Durability
RDBMS 的問題 • 不是所有資料都是 Relational Model • Schema Migration: 會把整個
Table/DB 鎖住 • Hard to Scale Write.
中間(沒⼈人理的)戰爭 2000~? ObjectDB, XmlDB
第⼆二次 DB ⼤大戰 2009~ 未完
前期參戰國 • Dynamo DB • Google AppEngine Datastore • Cassandra
• CouchDB • MongoDB http://thechangelog.com/18/
• Amazon SimpleDB • Redis • Neo4j 前期參戰國
盟國 • Column Store: Cassandra, HBase • Document Store: CouchDB,
MongoDB • Key-Value Store: DynamoDB, Redis, Riak • Graph Store: Neo4J
CAP
⼝口號: BASE • Basically Available • Soft State • Eventual
consistency
好話說完了,要開幹了
Eventual Consistency? • Eventual inconsistency!! • ⼀一個確認的 Write 可能最終會消失!!
Eventual Consistency? • Eventual inconsistency!! • ⼀一個確認的 Write 可能最終會消失!! •
⼀一個確認失敗的 Write 可能會跑出來!!
https://aphyr.com/posts/284-call-me-maybe-mongodb
⼤大家都說不會掉資料 • 實測結果 • MongoDB: 47% Acked Data Lost! •
Riak: 91% Ack lost!, 0.3% Unack found! • Cassandra: 28% Ack lost! Cassandra/CRDT: 0% lost
發⽣生了什麼事?! • Failover Strategy: MongoDB. • When Primary down, the
secondary will become new Primary. When old Primary is back online, it will replay the op-log on old Primary. But it won’t most of time !!!
發⽣生了什麼事?! • Failover Strategy: Riak. • 由下 N 個結點接收 Write.
如果 N 個寫⼊入成功, 就會回傳成功,但是回傳失敗,即使只有⼀一個 成功,最終,這⼀一個 Write 會被寫到 N 份去。 • Conflict Resolution: 如果對同⼀一個 Key 的寫⼊入有 衝突,Riak會回傳多個值,由 Client 來判斷怎麼 取捨 http://blog.monitis.com/20123/14/an-overview-of-riak-an-open-source-nosql-database/
發⽣生了什麼事?! • Failover Strategy: Cassandra. • 由下 N 個結點接收 Write.
如果 N 個寫⼊入成功,就會 回傳成功,但是回傳失敗,即使只有⼀一個成功,最終, 這⼀一個 Write 會被寫到 N 份去。 • Conflict Resolution: 如果對同⼀一個 Key 的寫⼊入有衝突, Timestamp 最⼤大的會獲勝. • Timestamp 是個不可靠的數值,因為你不能保證 Cluster 中所有機器的時間都是同步的。 http://blog.monitis.com/20123/14/an-overview-of-riak-an-open-source-nosql-database/
教訓 • 不要對同⼀一值重覆寫⼊入。 • 使⽤用 Commutative Replicated Data Type, Command
Query Responsibility Segregation Pattern 來寫程式
教訓 • 不要對同⼀一值重覆寫⼊入。 • 使⽤用 Commutative Replicated Data Type, Command
Query Responsibility Segregation Pattern 來寫程式
CRDT • Bank never deletes anything • https://www.youtube.com/watch?v=BGxnjKd4MFQ
Scalability? • 所有的 DB 都是實作⼀一樣的 Journal DB 機制。 • 所以所有的
DB 在 EC2 m1.large 上,都是 11,000 write/sec. (Riak: 我只有 4000w/s)
Scale Read • Shading. • Replication. • ⼤大家都做得很好.
Scale Write • MongoDB: 請叫我廢柴,無論開多少台,都是笑 能。
Scale Write - Cassandra http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
Schema-less • Schema 真的是問題嗎?請再問你⾃自⼰己三遍 http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
Schema-less • Schema 真的是問題嗎?請再問你⾃自⼰己三遍 • Schema 的危害是,Migrate 時可能會把 DB 鎖住,
造成 Downtime • Schema-less 要做 migration ,是在 code 中做 read-repair. • 所以說你的程式碼中要⼀一直有有 V1->V2, V2->V3, V3->V4…. 的 migration code. http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
Schema-less • Dynamic Language ⽤用起來很爽 • var tweets = db.find(….)
for tweet in tweets: print tweet.text
Schema-less • Dynamic Language ⽤用起來很爽 • var tweets = db.find(….)
for tweet in tweets: print tweet.text • 可是我們是寫 Java 的
Model class is Schema @Entity("employees") class Employee { // auto-generated,
if not set (see ObjectId) @Id ObjectId id; // value types are automatically persisted String firstName, lastName; // only non-null values are stored Long salary = null; // by default fields are @Embedded Address address;
Schema-less • ⼤大多數時間造成的是危害不是好處
AdHoc Query • SQL 中好好⽤用。 • MongoDB 中可以⽤用 • Cassandra,
Riak 中.... • CouchDB 有 MapReduce 可⽤用
MapReduce?! • 把資料庫的所有物件,⼀一個個的拿出來看 • 挑想要的資料,佔存在 “某個地⽅方” • 然後再來 Reduce(Aggregate)
MapReduce?! • 把資料庫的所有物件,⼀一個個的拿出來看 • 挑想要的資料,佔存在 “某個地⽅方” • 然後再來 Reduce(Aggregate) •
所以 MongoDB 會要個 Write Lock !! 把 DB 鎖死
MapReduce • Not Production Ready.
2nd Index. • Cassandra, Riak 對 AdHoc Query 的回應 •
每個結點⾃自⼰己 Index ⾃自⼰己的資料。 • 所以 Index 的⼤大⼩小是無限的。
2nd Index. • Cassandra, Riak 對 AdHoc Query 的回應 •
每個結點⾃自⼰己 Index ⾃自⼰己的資料。 • 所以 Index 的⼤大⼩小是無限的。 • 結果變成能夠承受的 Query 總量,是固定的。
ACID 好好⽤用 • counter + 1 (NoSQL開始提供對單⼀一欄位操作) • 資料正確性 vs
Availability. • Transaction • Data Consistency
MongoDB • 最熱⾨門的 NoSQL • ⽀支援 AdHoc Query • ⽀支援
Index on any field • ⽀支援 Sharding, Replication
MongoDB 缺點 • ⽂文件的 Size • Index 的 Size 驚⼈人
• 被 Index 有欄位⼤大⼩小的限制(1024 bytes) • 對變⾰革的適應能⼒力( 連結外部新來的資料或查 尋)
結語