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.8k
NoSQL 大腸花
yunglin
January 17, 2015
Tweet
Share
More Decks by yunglin
See All by yunglin
Manage cloud server with open source tools
yunglin
1
120
Java Developer Day 2013 Scala Future API
yunglin
3
740
Java Developer Day 2012 Introduction to Actor Model
yunglin
1
160
Software Quality Metrics
yunglin
1
100
Other Decks in Technology
See All in Technology
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
20
9.7k
データアナリストからアナリティクスエンジニアになった話
hiyokko_data
2
440
現場で効くClaude Code ─ 最新動向と企業導入
takaakikakei
1
210
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
380
品質視点から考える組織デザイン/Organizational Design from Quality
mii3king
0
190
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
210
機械学習を扱うプラットフォーム開発と運用事例
lycorptech_jp
PRO
0
230
Skrub: machine-learning with dataframes
gaelvaroquaux
0
120
【初心者向け】ローカルLLMの色々な動かし方まとめ
aratako
7
3.4k
AIのグローバルトレンド2025 #scrummikawa / global ai trend
kyonmm
PRO
1
260
EncryptedSharedPreferences が deprecated になっちゃった!どうしよう! / Oh no! EncryptedSharedPreferences has been deprecated! What should I do?
yanzm
0
190
DDD集約とサービスコンテキスト境界との関係性
pandayumi
3
280
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The Invisible Side of Design
smashingmag
301
51k
Faster Mobile Websites
deanohume
309
31k
A designer walks into a library…
pauljervisheath
207
24k
Automating Front-end Workflow
addyosmani
1370
200k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Designing Experiences People Love
moore
142
24k
GraphQLとの向き合い方2022年版
quramy
49
14k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
Facilitating Awesome Meetings
lara
55
6.5k
Practical Orchestrator
shlominoach
190
11k
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) • 對變⾰革的適應能⼒力( 連結外部新來的資料或查 尋)
結語