shardlab

NoSQL ve
MongoDB

Bugün neler konuşacağız?

  1. 01Büyük veri ve veri bilimindeki yeri
  2. 02İlişkisel veritabanları neden zorlandı?
  3. 03NoSQL'in kısa tarihi
  4. 04NoSQL türleri ve teorisi
  5. 05MongoDB nasıl çalışır?
  6. 06Projemiz: ölçümler ve canlı uygulama

Veri bilimi, verinin nerede durduğuyla başlar.

1

Topla

Uygulama, sensör, log

2

Sakla

Veritabanı

3

Temizle

Hatalı kaydı ayıkla

4

Analiz et

Özet, grafik

5

Modelle

Tahmin, karar

Bu sunum ikinci adımla ilgili: veri büyüyünce onu nerede ve nasıl saklarız?

Dünyadaki veri 15 yılda 90 kat büyüdü.

2 ZB2010
15,5 ZB2015
64,2 ZB2020
~181 ZB2025 (tahmin)

1 zettabayt = 1 milyar terabayt · Kaynak: IDC, Statista

Bir şehir, bir ay: 3 milyon yolculuk.

Volume2,96M

Ocak 2024'te sadece New York sarı taksileri

Velocity66/dk

Gece gündüz durmadan yeni kayıt

Variety19

Zaman, konum, mesafe, ücret, ödeme…

Veracity%4,2

Hatalı kayıt. Negatif ücretler bile var

Value18:00

En yoğun saat. Talep tahmini buradan çıkar

Veri o kadar büyüdü ki geleneksel sistemler zorlanmaya başladı.

1970: Veriyi tablolara koymak.

EFC

Edgar F. Codd

IBM · 1970

"A Relational Model of Data for Large Shared Data Banks" makalesiyle ilişkisel modeli tanımladı. 1981 Turing Ödülü.

Donald Chamberlin

Donald Chamberlin

IBM · 1974

Raymond Boyce ile birlikte SEQUEL'i, bugünkü SQL'in atasını tasarladı.

Satır, sütun, şema ve JOIN.

idkalkışvarışücret
1042JFKManhattan$99.40
1043HarlemBronx$18.20
1044SoHoJFK$72.10
TabloSatırSütunŞemaJOIN

SQL neden 50 yıl dayandı?

1986

Standart dil

ANSI standardı. Bir kez öğren, her veritabanında kullan.

ACID

Güvenilir

Para transferi yarıda kalmaz.

JOIN

İlişki kurar

Dağınık veriyi tek sorguda birleştirir.

50+

Olgun

Oracle, MySQL, PostgreSQL. Yıllarca test edildi.

Veri büyüyünce tablolar zorlanıyor.

34 sn

Katı şema

Yeni bir sütun eklemek, 2,8 milyon satırı tek tek güncellemek demek. Bizim ölçümümüz.

↑

Dikey ölçekleme

Yük artınca daha güçlü sunucu alırsın. Pahalı, ve bir tavanı var.

⋈

JOIN maliyeti

Tablolar farklı makinelere bölününce JOIN ağ üzerinden yapılır.

{ }

Yapısız veri

Log, JSON, sensör verisi: her kaydın şekli farklı.

Tek sunucunun bir tavanı var.

Fiyat

İki kat güçlü sunucu, iki kattan çok daha pahalı.

Sınır

Bir makineye takılabilecek işlemci ve bellek sınırlı.

Tek hata noktası

O sunucu düşerse her şey durur.

1998

"NoSQL" kelimesi ilk kez kullanılıyor.

CS

Carlo Strozzi

İtalya · 1998

SQL arayüzü olmayan küçük bir ilişkisel veritabanına "NoSQL" adını verdi. Bugünkü anlamıyla ilgisi yoktu; terim 11 yıl sonra geri dönecekti.

2004 – 2006

Google bütün interneti tek makineye sığdıramıyordu.

Jeff Dean

Jeff Dean

Google

Sanjay Ghemawat ile MapReduce (2004) ve Bigtable (2006) makalelerini yazdı.

Bigtable · 2006

Binlerce ucuz sunucuya dağılan dev bir tablo.

HBase ve Cassandra'ya ilham verdi.

2007

Amazon: "Sepete ekle" butonu asla hata vermemeli.

Werner Vogels

Werner Vogels

Amazon CTO

Ekibiyle Dynamo makalesini yayınladı.

Dynamo · 2007

Tutarlılıktan biraz vazgeç, her zaman yazılabilir ol.

Bir sunucu çökse bile müşteri sepetine ürün ekleyebilmeli.

2008 – 2009

Fikirler açık kaynağa dönüştü, isim yerleşti.

2008

Cassandra

Facebook, Dynamo + Bigtable fikirleri

2009

MongoDB

10gen, doküman veritabanı

2009

Redis

Bellekte anahtar-değer

Haz 2009

#nosql

Johan Oskarsson'un San Francisco buluşması; terim yayılır

Web 2.0Sosyal medyaAkıllı telefonIoT

Not Only SQL.

SQL'in rakibi değil, tamamlayıcısı.

01

Esnek şema

Her kayıt kendi alanlarını taşır.

02

Yatay ölçekleme

Yük artınca makine eklenir.

03

Dağıtık yapı

Veri birçok sunucuya bölünür.

Esnek şema: aynı koleksiyon, farklı kayıtlar.

{
  pickup:  "JFK Airport",
  fare:    52.3,
  passengers: 1
}
{
  pickup:  "Harlem",
  fare:    18.2,
  passengers: 2,
  weather: "yağmurlu",
  nickname: "Emir"
}

İkinci kayıtta iki yeni alan var. Tabloyu değiştirmeye gerek yok.

Tek bir NoSQL yok. Dört farklı model var.

Document

MongoDB

Ürün kataloğu, içerik

Key-Value

Redis

Önbellek, oturum, sepet

Column-Family

Cassandra

IoT, zaman serisi, log

Graph

Neo4j

Sosyal ağ, öneri sistemi

Doküman ve anahtar-değer.

Document · MongoDB
{ _id: 1042,
  name: "Kulaklık",
  price: 899,
  specs: { kablosuz: true, pil: "30 saat" } }

Her ürün kendi özelliklerini taşır. Ayakkabının bedeni, laptopun RAM'i.

Key-Value · Redis
session:4821→{ user: "emir", sepet: 3 }
views:urun:1042→15 208
kur:USD→41,2

Anahtarı bil, değeri milisaniyede al. Önbellek ve oturum için.

Geniş sütun ve graf.

Column-Family · Cassandra
sensor:İST-07
09:00 → 21,4°09:01 → 21,5°09:02 → 21,7°…

Bir satır anahtarının altında binlerce sütun. Sürekli yazılan sensör ve log verisi için.

Graph · Neo4j

İlişkinin kendisi veri. "Arkadaşımın arkadaşı kim?" sorusu anında cevaplanır.

SQL ve NoSQL, yan yana.

SQLNoSQL
Veri modeli

Tablo, satır, sütun

Doküman, anahtar-değer, sütun, graf

Şema

Sabit, önceden tanımlı

Esnek

Ölçekleme

Dikey: daha güçlü sunucu

Yatay: daha çok sunucu

Sorgu dili

Standart SQL

Veritabanına özgü

Tutarlılık

ACID

BASE, ayarlanabilir

Tipik kullanım

Banka, muhasebe, ERP

Katalog, IoT, log, analitik

Ağ koptuğunda bir seçim yapmak zorundasın.

Tutarlılık · Erişilebilirlik · Bölünme toleransı

Eric Brewer

Eric Brewer · 2000

UC Berkeley. Dağıtık sistemde üçü aynı anda olmaz.

CP · tutarlı kal

Gerekirse bekle ya da hata ver. MongoDB

AP · cevap ver

Veri birkaç saniye eski olabilir. Cassandra

ACID ve BASE: iki farklı söz.

ACID · SQL

Banka transferi

  • Atomicity: ya hepsi ya hiçbiri
  • Consistency: kurallar hep geçerli
  • Isolation: işlemler birbirini görmez
  • Durability: yazılan kaybolmaz
BASE · çoğu NoSQL

Beğeni sayacı

  • Basically Available: her zaman cevap ver
  • Soft state: durum değişebilir
  • Eventual consistency: sonunda herkes aynı sayıyı görür

Büyütmek mi, bölmek mi?

Dikey

Tek makineyi büyüt.

Yatay

Yeni makine ekle.

Sharding

Veriyi böl: her sunucu farklı bir parçayı tutar.

Replication

Veriyi kopyala: her sunucu aynısını tutar.

MongoDB: humongous, yani devasa.

Dwight Merriman

Dwight Merriman

Kurucu

Eliot Horowitz

Eliot Horowitz

Kurucu, CTO

200710gen kuruldu
2009MongoDB açık kaynak oldu
2013Şirketin adı MongoDB Inc.

Veri MongoDB'de nasıl durur?

Databasenyc
Collectiontrips
Document{ pickup: …, fare: … }
Fieldfare.total: 99.4

Kayıtlar BSON olarak saklanır: tarih ve sayı tiplerini de taşıyan ikili JSON.

Aynı yolculuk: üç tablo ya da tek doküman.

tripsid · pu_zone_id · do_zone_id · total · payment_id1042 · 132 · 236 · 99.40 · 1
zonesid · zone · borough132 · JFK Airport · Queens
payment_typesid · name1 · card

SELECT … JOIN zones … JOIN zones … JOIN payment_types

{
  pickup:  { zone: "JFK Airport", borough: "Queens" },
  dropoff: { zone: "Upper East Side", borough: "Manhattan" },
  passengers: 1,
  fare: { total: 99.4, payment: "card" }
}

Göm mü, referans mı ver?

Gömme (embedding)
{ zone: "JFK Airport",
  borough: "Queens" }

Ne zaman: Birlikte okunan, az değişen veri. Okuma tek seferde.

Bedeli: aynı bilgi binlerce kez tekrarlanır.

Referans
{ zone_id: 132 }   // zones koleksiyonunda

Ne zaman: Çok büyüyen ya da sık değişen veri. $lookup ile birleştirilir.

Bedeli: okurken ikinci bir sorgu.

Kural: "Birlikte okunan birlikte saklanır." · Bir doküman en fazla 16 MB

Aynı iş, iki dil.

Ekle
INSERT INTO trips … VALUES (…)
db.trips.insertOne({ … })
Bul
SELECT * FROM trips WHERE total > 50
db.trips.find({ "fare.total": { $gt: 50 } })
Güncelle
UPDATE trips SET tip = 10 WHERE …
db.trips.updateOne({ … }, { $set: { … } })
Sil
DELETE FROM trips WHERE …
db.trips.deleteMany({ … })

GROUP BY'ın karşılığı: bir boru hattı.

Hangi ilçede kartla ödeyenler daha çok bahşiş bırakıyor?

Başlangıç2.839.623

yolculuk

$match2.275.575

kartla ödenen

$group6

ilçe

$sort
  1. Manhattan %23,9
  2. Queens %20,5
  3. Staten Island %13,0

Doğru indeks: 70 kat fark.

COLLSCAN · indeks yok1.903 ms

2.839.623 doküman tek tek okundu

IXSCAN · indeks var27 ms

sadece 2.343 doküman okundu

Sorgu: 15 Ocak, 08:00–09:00 arası yolculuklar · demoda canlı

Replica set: bir sunucu düşse de sistem ayakta.

Primaryokur, yazarSecondarykopyaSecondarykopya

1 Her yazma primary'ye gider.

2 Secondary'ler değişiklikleri oplog üzerinden kopyalar.

3 Primary düşerse kalanlar oylar, yeni primary saniyeler içinde seçilir.

Sharding: veriyi sunuculara bölmek.

Uygulama
↓
mongosyönlendirici
config serverhangi veri nerede?
Shard Averinin bir parçası
Shard Bverinin bir parçası
Shard Cverinin bir parçası
Shard key var

Sorgu tek sunucuya gider · 45 ms

Shard key yok

Sorgu her sunucuya gider · 100 ms

Shard key seçimi en kritik karar.

Bizim verimizin dağılımı

Shard A%36,2
Shard B%40,8
Shard C%23,0

Eşit değil, çünkü Manhattan bölgeleri çok yoğun.

İyi bir shard key

  • Çok farklı değer alır
  • Yükü eşit dağıtır
  • Sorgularda sık kullanılır

Kötü bir shard key

  • Sürekli artan değer (tarih, sıra no)
  • Tüm yeni kayıtlar tek sunucuya: hot shard

Ne zaman MongoDB, ne zaman değil?

Uygun

  • İçerik yönetimi
  • Ürün kataloğu
  • IoT ve log
  • Gerçek zamanlı analitik
  • Mobil uygulama arka ucu

Dikkat

  • Bankacılık, muhasebe
  • Çok tablolu sıkı tutarlılık
  • Yoğun JOIN'li raporlar

MongoDB 4.0'dan beri çok dokümanlı ACID transaction da var.

Büyük veri ekosisteminde nerede duruyor?

1

Toplama

Uygulama, IoT, Kafka

2

Depolama

MongoDB, veri gölü

3

Özetleme

Aggregation

4

Analiz

pandas, Spark

5

Sonuç

Model, dashboard

Spark Connector ile Hadoop/Spark'a bağlanır · Kafka Connector ile akan veriyi alır

Biz ne yaptık?

01

Veriyi aldık

NYC TLC, Ocak 2024: 2.964.624 yolculuk

02

Temizledik

Python ile 125.001 hatalı kayıt ayıklandı

03

Dağıttık

MongoDB, 3 shard; şimdilik tek bilgisayarda simüle

04

Ölçtük

Aynı veri PostgreSQL'de de: 9 farklı test

05

Uygulama yaptık

Canlı panel, sorgu laboratuvarı, telefondan veri ekleme

2,8 milyon yolculuk, 3 shard, 1 bilgisayar.

Routermongos + config server + uygulama
Shard ADocker konteyneri 11.027.896
Shard BDocker konteyneri 21.159.122
Shard CDocker konteyneri 3652.608
shard key: pickup.zone_id (hashed)Lokal simülasyon: her shard ayrı bir mongod süreciGerçek dağıtımda her biri ayrı sunucu

Ölçtük: kim, nerede hızlı?

NoSQL, SQL'in yerine geçmez.
Onu tamamlar.

01

NoSQL ölçek sorunundan doğdu.

02

JOIN'de SQL, esnek veri ve yatay ölçekte MongoDB.

03

Dağıtmak güç verir ama bir bedeli var.

Şimdi sıra sizde.

QR'ı okutun, bir taksi yolculuğu ekleyin. Kaydınızın üç sunucudan hangisine gittiğini göreceksiniz.

Toplam2.839.623
Sizin eklediğiniz0

Kahoot!

10 soru, 20'şer saniye.

kahoot.it · PIN— — — — — —

Teşekkürler. Sorular?

  • Codd, A Relational Model of Data…, 1970 · Chamberlin & Boyce, SEQUEL, 1974
  • Dean & Ghemawat, MapReduce, 2004 · Chang ve ark., Bigtable, 2006
  • DeCandia ve ark., Dynamo, 2007 · Brewer, CAP, 2000
  • Kleppmann, Designing Data-Intensive Applications, 2017
  • IDC / Statista veri hacmi tahminleri · MongoDB Docs · NYC TLC Trip Record Data
  • Fotoğraflar: Wikimedia Commons · Cmichel67 (CC BY-SA 4.0), Raysonho (CC0), Vera de Kok (CC BY-SA 4.0), Megaltoid (CC BY-SA 3.0), Collision Conf (CC BY 2.0), Dicklyon (CC BY-SA 4.0)
Kaynak kod
Canlı uygulama