Top Banner
MongoDB ve Diğer Veritabanlarında Sharding
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

Aug 11, 2020

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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