• 26-08-2026, 18:43:17
    #1
    Selamlar,

    Örneğimiz dua lipa üzerinden olsun.
    Varsayalım ben dua lipa'yı takip ettim ve dualipa'nın instgram sayfasına gittiğimde "followers count" değerini nasıl hesaplıyor bunu anlamaya çalışıyorum.
    Şimdi 2 farklı ihtimalimiz var.

    1. ihtimal dua_lipa_followers_ids adında bir tablo var ve dua lipa'nın kendisine ait bir satırı var ve o satırda dua lipayı takip eden herkesin userid'si var ve buradaki sayıya göre hesaplıyor. Bu en hızlı yöntem olarak duruyor.
    2. İhtimal "Dua lipayı kimler takip ediyor?" diye bütün data içerisinden yani 500m kullanıcısı varsa 500m kullanıcı içerisinden arıyor ve dua lipa'nın follows içerisinde geçenleri followers count +1 yapıyor ama bu çok saçma çünkü bütün database'yi taramak hele ki 500m'lık users'dan oluşan kısımda saçma.

    Eğer ki dua lipayı takip ettiğimde followers_ids kısmında yer alıyorsa ortalama 100 mb tutar ve mantıklıdır ama bu sefer de bunun mantıksız olduğunu düşünüyorum çünkü olası bir veri eklemede boş yere yük oluşacak.
    Buradaki Sql şeması nasıl olabilir?
  • 26-08-2026, 19:21:31
    #2
    soylenmezsmt adlı üyeden alıntı: mesajı görüntüle
    Selamlar,

    Örneğimiz dua lipa üzerinden olsun.
    Varsayalım ben dua lipa'yı takip ettim ve dualipa'nın instgram sayfasına gittiğimde "followers count" değerini nasıl hesaplıyor bunu anlamaya çalışıyorum.
    Şimdi 2 farklı ihtimalimiz var.

    1. ihtimal dua_lipa_followers_ids adında bir tablo var ve dua lipa'nın kendisine ait bir satırı var ve o satırda dua lipayı takip eden herkesin userid'si var ve buradaki sayıya göre hesaplıyor. Bu en hızlı yöntem olarak duruyor.
    2. İhtimal "Dua lipayı kimler takip ediyor?" diye bütün data içerisinden yani 500m kullanıcısı varsa 500m kullanıcı içerisinden arıyor ve dua lipa'nın follows içerisinde geçenleri followers count +1 yapıyor ama bu çok saçma çünkü bütün database'yi taramak hele ki 500m'lık users'dan oluşan kısımda saçma.

    Eğer ki dua lipayı takip ettiğimde followers_ids kısmında yer alıyorsa ortalama 100 mb tutar ve mantıklıdır ama bu sefer de bunun mantıksız olduğunu düşünüyorum çünkü olası bir veri eklemede boş yere yük oluşacak.
    Buradaki Sql şeması nasıl olabilir?
    Örneğimiz Dua Lipa üzerinden gidersek, Instagram gibi büyük bir platformda followers_count değerini hesaplamak için 500 milyon kullanıcının tamamını taramak mantıklı değildir. Bunun yerine genellikle kullanıcılar arasındaki takip ilişkileri ayrı bir follows tablosunda tutulur. Örneğin users tablosunda Dua Lipa'nın id değeri 12345 olsun; sen Dua Lipa'yı takip ettiğinde follows tablosuna follower_id = senin kullanıcı ID'n ve following_id = 12345 şeklinde tek bir kayıt eklenir. Dua Lipa'yı takip eden diğer herkes için de aynı şekilde ayrı bir kayıt bulunur. following_id sütununa index verilirse sistem, 500 milyon kullanıcının tamamını taramak yerine doğrudan Dua Lipa'nın takipçi ilişkilerine ulaşabilir. Teorik olarak SELECT COUNT(*) FROM follows WHERE following_id = 12345 sorgusuyla takipçi sayısı bulunabilir. Ancak milyonlarca takipçisi olan popüler hesaplarda bu COUNT işlemini her profil açılışında yapmak yerine users tablosunda ayrıca followers_count ve following_count gibi sayaçlar tutulabilir. Bir kullanıcı Dua Lipa'yı takip ettiğinde hem follows tablosuna yeni ilişki eklenir hem de Dua Lipa'nın followers_count değeri +1 artırılır. Böylece profil açıldığında milyonlarca ilişkiyi tekrar saymak yerine doğrudan followers_count okunur. Bu nedenle dua_lipa_followers_ids gibi tek satır içerisinde milyonlarca kullanıcı ID'si tutmak yerine, ilişkileri satır bazında follows tablosunda tutmak daha ölçeklenebilir bir SQL tasarımıdır. Büyük sistemlerde bunun üzerine cache, transaction, partitioning/sharding gibi ek optimizasyonlar da uygulanabilir.
  • 26-08-2026, 22:54:33
    #3
    Instagram'ın altyapısı, saniyeler içinde milyarlarca isteği milisaniyelik gecikmelerle karşılayabilmek adına uçtan uca yatay ölçeklenebilirlik, mikroservis mimarisi ve dağıtık veri tabanı modelleri üzerine kuruludur. Sistem trafiği karşılandığı ilk andan itibaren coğrafi olarak en yakın noktalardaki Anycast DNS yönlendirmeleriyle işlenmeye başlar. İstekler NGINX ve Envoy proxy havuzlarında sonlandırılırken, iç ağdaki mikroservisler arası iletişimde düşük gecikme sağlamak amacıyla gRPC ve HTTP/2 protokolleri tercih edilir.
    Veri tabanı tarafında tek bir devasa yapının oluşturacağı darboğazları aşmak için uygulama seviyesinde sharding uygulanır ve veriler bağımsız PostgreSQL kümelerine dağıtılır. Bu shard'lar arasında çakışmaları önlemek adına zaman damgası ve shard ID barındıran 64-bitlik benzersiz ID'ler üreten merkezi olmayan bir Snowflake yapısı kullanılır. Okuma ve yazma işlemlerini dengelemek amacıyla Memcached ve Redis tabanlı bellek içi önbellekleme katmanları devreye sokulur; sosyal grafik verileri doğrudan RAM üzerinden servis edilerek disk maliyetleri minimuma indirilir.
    Fotoğraf yükleme, filtreleme veya bildirim gönderme gibi ağır I/O operasyonları ana akışı bloke etmemek için Kafka veya RabbitMQ gibi dağıtık mesaj kuyruklarına aktarılarak asenkron worker havuzlarında çözümlenir. Son olarak, petabaytlarca medya verisi dağıtık nesne depolama sistemlerinde tutulurken, statik varlıklar coğrafi olarak dağıtık CDN node'ları üzerinden kullanıcılara sunularak ana veri merkezinin yükü tamamen hafifletilir.