TL; DR:
Yığının altındaki MySQL'in üstündeki her şey için önbelleğe alınmış grafiklere sahip bir yığın mimarisi kullanırlar.
Uzun cevap:
Bu konuda kendim biraz araştırma yaptım çünkü büyük miktarda veriyi nasıl işlediklerini ve hızlı bir şekilde nasıl aradıklarını merak ediyordum. Kullanıcı tabanı büyüdükçe özel hazırlanmış sosyal ağ betiklerinin yavaşladığından şikayet eden insanlar gördüm. Sadece 10.000 kullanıcı ve 2,5 milyon arkadaş bağlantısıyla kendimi bir miktar kıyaslama yaptıktan sonra - grup izinleri, beğenileri ve duvar gönderileri hakkında endişelenmeye bile çalışmadan - bu yaklaşımın kusurlu olduğu hemen ortaya çıktı. Bu yüzden, nasıl daha iyi yapılacağına dair internette biraz araştırma yaptım ve şu resmi Facebook makalesine rastladım:
Ben gerçekten önce okumaya devam yukarıdaki ilk bağlantının sunumunu izlemek için tavsiye ederiz. FB'nin bulabileceğiniz perde arkasında nasıl çalıştığına dair muhtemelen en iyi açıklama budur.
Video ve makale size birkaç şey anlatıyor:
- Yığının en altında MySQL kullanıyorlar
- Yukarıda DB SQL önbelleğe alma en az iki düzeylerini içerir ve bağlantıları tanımlamak için grafikler kullanan Tao tabakası vardır.
- Önbelleğe alınmış grafikleri için gerçekte hangi yazılımı / DB'yi kullandıkları hakkında hiçbir şey bulamadım
Şuna bir bakalım, arkadaş bağlantıları sol üstte:
Bu bir grafik. :) Size SQL'de nasıl inşa edileceğini anlatmıyor , bunu yapmanın birkaç yolu var ama bu site pek çok farklı yaklaşıma sahip. Dikkat: İlişkisel bir DB'nin ne olduğunu düşünün: Bir grafik yapısı değil, normalleştirilmiş verileri depoladığı düşünülmektedir. Bu nedenle, özel bir grafik veritabanı kadar iyi performans göstermez.
Ayrıca, arkadaşlarınızın arkadaşlarından daha karmaşık sorgular yapmanız gerektiğini de göz önünde bulundurun, örneğin, belirli bir koordinat çevresindeki tüm konumları sizin ve arkadaşlarınızın beğendiği tüm konumları filtrelemek istediğinizde. Burada bir grafik mükemmel çözümdür.
İyi performans göstermesi için nasıl inşa edileceğini size söyleyemem ama açıkça biraz deneme yanılma ve kıyaslama gerektiriyor.
İşte sadece arkadaşların arkadaşları için hayal kırıklığı yaratan testim :
DB Şeması:
CREATE TABLE IF NOT EXISTS `friends` (
`id` int(11) NOT NULL,
`user_id` int(11) NOT NULL,
`friend_id` int(11) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
Friends of Friends Sorgusu:
(
select friend_id
from friends
where user_id = 1
) union (
select distinct ff.friend_id
from
friends f
join friends ff on ff.user_id = f.friend_id
where f.user_id = 1
)
En az 10 bin kullanıcı kaydı olan ve her birinin en az 250 arkadaş bağlantısı olan bazı örnek veriler oluşturmanızı ve ardından bu sorguyu çalıştırmanızı gerçekten tavsiye ederim. Makinemde (i7 4770k, SSD, 16gb RAM) sonuç bu sorgu için ~ 0.18 saniyeydi . Belki optimize edilebilir, ben bir DB dehası değilim (önerilere açığız). Ancak, eğer bu ölçekler doğrusal sadece 100k kullanıcıları, 1.000.000 kullanıcıları için 18 saniye boyunca 1.8 saniyeye zaten.
Bu, ~ 100.000 kullanıcı için yine de kulağa hoş geliyor olabilir, ancak arkadaşlarının arkadaşlarını yeni getirdiğini ve " bana yalnızca arkadaşların arkadaşlarından gelen gönderileri göster + izin ver izin ver, izin verilmediğini kontrol et bazılarını görmek için + alt sorgu yaparak bunlardan herhangi birini beğenip beğenmediğimi kontrol edin ". Bir gönderiyi beğenip beğenmediğinizi DB'nin kontrolü yapmasına izin vermek istersiniz, yoksa kod içinde yapmanız gerekir. Ayrıca bunun çalıştırdığınız tek sorgu olmadığını ve aynı anda az ya da çok popüler bir sitede birden fazla aktif kullanıcınız olduğunu unutmayın.
Cevabımın Facebook'un arkadaş ilişkilerini nasıl tasarladığı sorusuna cevap verdiğini düşünüyorum ancak bunu hızlı çalışacak şekilde nasıl uygulayacağınızı size söyleyemediğim için üzgünüm. Bir sosyal ağ uygulamak kolaydır, ancak iyi performans gösterdiğinden emin olmak kesinlikle değildir - IMHO.
Grafik sorgularını yapmak ve kenarlarımı temeldeki SQL DB ile eşleştirmek için OrientDB ile deneyler yapmaya başladım. Eğer bitirirsem, bunun hakkında bir makale yazacağım.
