+ All Categories
Home > Documents > Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi...

Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi...

Date post: 11-Aug-2020
Category:
Upload: others
View: 3 times
Download: 0 times
Share this document with a friend
34
MongoDB ve Diğer Veritabanlarında Sharding
Transcript
Page 1: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

MongoDB ve Diğer Veritabanlarında Sharding

Page 2: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Who the f**k is talking?

● Emir Karaburçak○ [email protected]○ @kinchil

● SPP42 de Yazılım Geliştirme Uzmanı

● Python, Django, Java, JBoss Seam, Play

● MongoDB, PostgreSQL, Hibernate

Page 3: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Konular

● Sharding Nedir?○ Problem○ Çözüm○ Shard

■ Veriyi Bölmek■ Veriyi Dağıtmak

○ Chunk○ Cluster○ Shard Key

Page 4: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Veritabanları

● MongoDB● CouchDB● Neo4j● MySQL

Page 5: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Problem

● Flickr - 10milyar fotoğraf

● Instagram - Android uygulamasında ilk 12 saatte 1milyon yeni kullanıcı

Page 6: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Çözüm

● Dikey Ölçeklendirme

● Yatay Ölçeklendirme

Page 7: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Sharding Nedir?

● Basit olarak büyük bir collectionı birkaç sunucu (cluster) arasında bölmek

● Sharding > Partitioning

● Her işlem otomatik

Page 8: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Shard nedir?

● Bir clusterdaki verinin bir alt kümesinden sorumlu 1 veya daha fazla sunucu

● Eğer 1den fazla sunucu varsa, hepsi aynı veriye sahiptir (replica set)

Page 9: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Veriyi Bölmek

● Matematiksel olarak; ['a', 'h')

● 'a' dahil olmak üzere 'a' dan başlayarak 'h' dahil olmamak üzere 'h' ye kadar

● Belirli bir aralığa 'chunk' denir

Page 10: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Veriyi Dağıtmak

● 1 shard 1 aralıktan sorumludur

● Sorunlu bir yöntem

['a', 'f') ['f', 'j') ['j', 'o') ['o', '{')

Shard 1 Shard 2 Shard 3 Shard 4

Birinci Yöntem

Page 11: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

['a', 'f') ['a', 'f')['f', 'j')

['f', 'j')['j', 'o') ['o', '{')

Shard 1 Shard 2 Shard 3 Shard 4

Veriyi Dağıtmak

● 1 shard 1 veya daha fazla aralıktan sorumludur

● MongoDB'nin kullandığı yöntem

İkinci Yöntem

Page 12: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

● Aralıkları belirlemek için bir key gereklidir.● Bu key in adı "shard key"dir● Shard key her bir alan veya alanlardan

oluşabilir.● Her chunk 200mb dır, yeni bir shard

yaratılması için 1 shardın diğerlerinden +9 chunk a sahip olmalıdır

Chunklar Nasıl Yaratılır?

Page 13: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

● Her chunkın aralığı distinct olmalıdır● Herhangi 2 chunk kesişen aralığa sahip

olamaz● Her chunk bir sonraki chunkin aralığını

tatmin etmelidir

● null < numbers < strings < objects < arrays < binary data < ObjectIds < booleans < dates < regular expressions

Page 14: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Balancer

● Chunkları bir sharddan diğerine taşır● Otomatik balancing● Veriyi eşit olarak dağıtmakla ve

olabildiğince az veri taşımakla yükümlüdür

Page 15: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

mongos

● Kullanıcı ve cluster arasında köprü● Tüm read/write lar mongos a gider● Özellikle belirtilmediği takdirde shardlara

direkt ulaşılmaz● Sharda direkt ulaşmak için query de shard

key kullanılır(targeted query)● Eğer query de shard key yoksa query tüm

shardlara gönderilir(spewed query)

Page 16: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Config Server

● Config Serverlar, özel mongod lardır● Clusterların açıklayıcı bilgilerini tutar● Veri taşıma için tüm config serverların

ayakta olması gereklidir

Page 17: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Özet Olarak Cluster

● Veri depolama için; Shard a● İstek yönelendirme için; mongos a● Durum bilgileri için; Config Server a

İhtiyaç duyar

Page 18: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Shard Key

● Kötü shard key = kötü sharding● Shard Key belirlerken en önemli nokta

kardinalite● Eğer bir shard key in N kadar değeri varsa,

en fazla N kadar chunk ve N kadar shard olabilir

Page 19: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Shard Key hakkında Önemli Noktalar

● Devamlı artan bir shard key iyi bir key değildir

● Shard Key belirlerken kardinalite en önemli unsurdur

● Rastgele değerlere sahip bir shard key iyi bir key değildir

● Coarsely ascending key + search key

Page 20: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Hatalı Shard Key

● 2010 Foursquare olayı

● 17 saatlik downtime

● 3M kullanıcı, 200M checkin, günde 18K yeni checkin

Page 21: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

CouchDB

● Lounge○ dumbproxy

basit requestler (get/put)

○ smartproxy

CouchDB requestleri (mapping/reducing)

Page 22: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

CouchDB Lounge

● Hashed DocIDSharding için kullanılan key

● KeyspaceHer node üstünde hashed key için

ayrılmış alan

Page 23: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Node Ring

Page 24: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Neo4j

● Graph Veritabanlarında sharding kolay bir işlem değildir

● Neo4j High Availability

● Veri yerine işyükünü ölçeklendirme

● Apache ZooKeeper

Page 25: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler
Page 26: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Sharding Neden Kolay Değil?

● Çok değişken bir yapıya sahip olması

● Dolaşım performansı vs. Fazla veri yüklemesi

Page 27: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Dolaşım Performansı

Page 28: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler
Page 29: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler
Page 30: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

● Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

● Insert time algorithm ve periyodik re-balancing

Page 31: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

Cache Sharding

● Sharding olmayan sharding?● İş yükünü ölçeklendirmek● Warm Cache

Page 32: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

İş Yükünü Ölçeklendirme

● Her sunucu aynı dataya sahiptir● master + slave

Page 33: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

MySQL

● MySQL Cluster kullanır

● MySQL Cluster = MySQL server + Ndb(Network Database) cluster

Page 34: Veritabanlarında Sharding MongoDB ve DiğerDolaşım performansı vs. Fazla veri yüklemesi Dolaşım Performansı Graphlar runtime da çok çabuk ve beklenmedik şekilde değişirler

MySQL Cluster

● Hashed Primary Key● Primary + Secondary Fragments


Recommended