<-> kullanıcı ilişkisi hep Facebook arkadaşı tasarlanmış merak etmişsinizdir.
Ben kullanıcı tablosu böyle birşey olduğunu düşünürler:
user_email PK
user_id PK
password
Ben (ben varsayılabilir kullanıcı e-posta yoluyla bağlanan cinsiyet, yaş vb), kullanıcının veri ile tablo anlamaya.
Nasıl bu kullanıcıya tüm arkadaşlar bağlanır?
Böyle bir şey?
user_id
friend_id_1
friend_id_2
friend_id_3
friend_id_N
Muhtemelen değil. Kullanıcı sayısı bilinmemektedir ve genişleyecektir çünkü.
Büyük ihtimalle birçok ilişki bir çoğu var:
Friendlist (tablo)
user_id -> users.user_id
friend_id -> users.user_id
friendVisibilityLevel
DÜZENLE
Kullanıcı tablosu muhtemelen bir olarak PK user_email yoktur muhtemelen ama benzersiz bir anahtar olarak.
Kullanıcıların (tablo)
user_id PK
user_email
password
Daha sonra kullanıcı kimliği ve arkadaşının KullanıcıKimliği tutan bir arkadaşı tablo tutun (biz FriendId arayacak). Her iki sütun geri Kullanıcılar masaya yabancı anahtarları olacaktır.
Biraz yararlı örnek:
Table Name: User
Columns:
UserID PK
EmailAddress
Password
Gender
DOB
Location
TableName: Friends
Columns:
UserID PK FK
FriendID PK FK
(This table features a composite primary key made up of the two foreign
keys, both pointing back to the user table. One ID will point to the
logged in user, the other ID will point to the individual friend
of that user)
Örnek kullanım:
Table User
--------------
UserID EmailAddress Password Gender DOB Location
------------------------------------------------------
1 bob@bob.com bobbie M 1/1/2009 New York City
2 jon@jon.com jonathan M 2/2/2008 Los Angeles
3 joe@joe.com joseph M 1/2/2007 Pittsburgh
Table Friends
---------------
UserID FriendID
----------------
1 2
1 3
2 3
Bu Bob Jon ve Joe hem arkadaş olduğunu gösterecektir ve Jon da Joe ile arkadaş olduğunu. Bu örnekte, bu arkadaşlığın her zaman iki yol olduğunu varsayalım, bu yüzden onlar zaten diğer yönde temsil edildiği çünkü bir tür (2,1) olarak tablodaki satır veya (3,2) gerek olmazdı. dostluk veya diğer ilişkiler açıkça iki yönlü olmayan örnekler için ayrıca iki yönlü ilişkiyi belirtmek için bu satırları olması gerekir.
Benim iyi bahis onlar yarattı olmasıdır grafik yapısı . Düğümler kullanıcı ve "dostluklar" dir kenarları vardır.
, Kullanıcılardan biri tablosunu tutun kenarlarının başka tablo tutun. Sonra vb "onaylanmış statü" "gün onlar arkadaş oldu" gibi kenarları ilgili verileri saklamak ve edebilirsiniz
Sen yabancı anahtarlar için arıyoruz. o, bu kendi tablosunu sahip olmadıkça Temelde bir veritabanında bir dizi olamaz.
Kullanıcılar Tablo
userID PK
diğer veri
Arkadaş Tablo
userID - Bir arkadaşı var kullanıcıyı temsil eden kullanıcıların masasına FK.
FriendId - arkadaşının kullanıcı kimliği temsil eden Kullanıcıların tabloya FK veritabanı tabloları dikey (daha fazla satır) büyümek için tasarlanmıştır unutmayın, yatay olarak değil (daha fazla sütun)
LinkedIn ve Digg nasıl yapıldığına açıklayan bu makalelere bir göz atın:
aynı zamanda "Büyük Veri: Facebook Veri Ekibi Viewpoints" Orada yararlı olabilir:
Ayrıca, sigara ilişkisel veritabanları ve nasıl bazı şirketler tarafından kullanılan konum bahsediyor bu yazı var:
http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php
Sen bu şirketlerin çoğumuzun günlük olarak başa hiç olmamasından veri ambarları, bölümlenmiş veritabanları, veri önbelleğe alma ve diğer üst düzey kavramlarla ilgileniyor olduğunu göreceksiniz. Ya da en azından, belki yaptıklarımız bilmiyoruz.
Size biraz daha fazla fikir vermelidir ilk iki maddeler üzerinde bağlantıların bir yeri vardır.
GÜNCELLEME 2014/10/20
Murat Demirbaş bir özet yazdım
http://muratbuffalo.blogspot.com/2014/10/facebooks-software-architecture.html
HTH
Kullanıcı kimliklerinin bağlayan 2 32 bitlik tam sayılar varsa, bir çok-çok sayıda tablonun performansını ilgili olarak, 200 arkadaşlar ortalama 200.000.000 kullanıcılar için temel veri depolama tanesi sadece 300GB altındadır.
Açıkçası, bazı bölümleme ve indeksleme gerekir ve tüm kullanıcılar için bellekte tutmak için gitmiyoruz.
Aşağıdaki veritabanı şeması bir göz, mü Anatoly Lubarsky tarafından ters mühendislik :
Bu Facebook'tan karma veritabanı (hayır SQL) kullanarak bu uygulamaya ve Cassandra denilen veritabanını opensourced nedenle daha fazla yarım milyar sabit bir zamanda çapraz veriler için kullanıcı arkadaş veriler için RDBMS veri almak mümkün değildir.
Böylece her kullanıcı kendi anahtarı vardır ve arkadaşlar kuyrukta ayrıntıları; cassandra çalışmaları bu nasıl baktığınıza bilmek:
Grafik veritabanının Onun bir türü: http://components.neo4j.org/neo4j-examples/1.2-SNAPSHOT/social-network.html
Onun İlişkisel veritabanlarının ilgili olmayan.
grafiği veritabanları için Google.
alanlar 'user_id', 'frnd_id' olan "frnd_list" demek, kullanıcı ilişkisi - <> Muhtemelen arkadaşı depolayan bir tablo vardır.
Bir kullanıcı arkadaş olarak başka bir kullanıcı ekler zaman, iki yeni satırlar oluşturulur.
Örneğin, benim id varsayalım 'deep9c' ve benim arkadaş olarak bir kullanıcı sahip kimliği 'akash3b' eklemek, sonra da iki yeni satırlar değerleri ( 'deep9c', 'akash3b') ve ( 'akash3b ile masaya "frnd_list" oluşturulur ', 'deep9c').
belirli bir kullanıcıya arkadaş-listesini gösteren Şimdi, basit bir sql bunu yapabilir: "frnd_list dan frnd_id seçmek nerede user_id =" giriş yapmış olan kullanıcının (bir oturum-niteliği olarak saklanan) kimliği olduğu.
Bu son Haziran 2013 sonrası bazı veri türleri için derneklerle nesnelere ilişki veritabanlarından geçişi açıklayan içine biraz ayrıntılı anlatır.
https://www.facebook.com/notes/facebook-engineering/tao-the-power-of-the-graph/10151525983993920
Daha uzun bir kağıt kullanılabilir https://www.usenix.org/conference/atc13/tao-facebook's-distributed-data-store-social-graph de var
TL; DR:
Onlar kendi yığının MySQL alt yukarıda her şey için önbelleğe alınan grafikler ile bir yığın yapısı kullanabilirsiniz.
Uzun cevap:
Onlar veri onların büyük miktarda işlemek ve hızlı bir şekilde nasıl arama Merak ettim çünkü ben bu kendimi biraz araştırma yaptım. İnsanların kullanıcı tabanı büyüdükçe yavaş olma özel yapılmış sosyal ağ komut şikayet gördüm. Bazı kendimi kıyaslama yaptım sonra sadece 10k kullanıcı ve 2,5 milyon arkadaş hatta grup izinleri ve beğeni ve duvar mesajlar hakkında rahatsız çalışmıyorum - - bağlantıları hızla bu yaklaşım kusurlu olduğu ortaya çıktı. Bu yüzden daha iyi nasıl yapılacağına ilişkin web'de arama biraz zaman geçirdim ve bu resmi Facebook makalesinde rastladım ettik:
Ben gerçekten önce okumaya devam yukarıdaki ilk bağlantının sunumunu izlemek için tavsiye ederiz. Muhtemelen FB bulabilirsiniz perde arkasında nasıl çalıştığını iyi açıklama bu.
Video ve makale birkaç şey söyler:
en, arkadaş bağlantıları sol üst olan bu bir göz atalım:
De, bu bir grafiktir. :) O size değil nasıl SQL inşa etmek, orada bunu yapmak için çeşitli yollar vardır ama bu site farklı yaklaşımların iyi bir miktarda vardır. Dikkat: Bir ilişkisel veritabanı bunun ne olduğunu düşünün: Bu normalize verileri değil, bir grafik yapısı saklamak için düşünülüyor. Bu yüzden özel bir grafik veritabanı kadar iyi bir performans göstermez.
Ayrıca çevresindeki tüm yerleri filtrelemek istediğinizde örneğin arkadaş sadece arkadaş daha karmaşık sorgular, yapmak zorunda olduğunu düşünün bir koordinat verilen sen ve benzeri arkadaş arkadaşların. Bir grafik Burada mükemmel bir çözümdür.
Ben nasıl iyi bir performans böylece inşa etmek söyleyemem ama açıkça bazı deneme yanılma ve kıyaslama gerektirir.
İşte benim olduğunu hayal kırıklığı testi sadece arkadaş bulgular arkadaşlar:
DB Şema:
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;
Arkadaş Sorgu arkadaşları:
(
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
)
Gerçekten en az 10k kullanıcı kayıtları ile bazı örnek verileri oluşturmak için tavsiye ve bunların her en az 250 arkadaş bağlantısı olan ve daha sonra bu sorguyu çalıştırın. Benim makine (i7 4770k, SSD 16GB RAM) sonucu ~ 0.18 saniye konusu sorgu için. Belki de, bir DB deha değilim optimize edilebilir (öneriler bekliyoruz). 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 hala ~ 100k kullanıcıları için OKish ses ama arkadaş sadece getirilen arkadaşları ve yapmadığı düşünebilirsiniz "gibi herhangi bir daha karmaşık sorgu + I izin veya DEĞİL ediyorsam izni kontrolü yapmak izin arkadaşların arkadaşları bana göstermek Yalnızca yayınlar bunlardan bazılarını görmek için + ben hiçbirini sevdim kontrol etmek için bir alt sorgusu yapmak ". Sen zaten ya da değil bir yazı beğendiği veya kodda yapmanız gerekecek eğer DB çek üzerinde yapalım istiyoruz. Ayrıca, bu çalıştırmak sadece sorgu olmadığını düşünün ve sizin bir az ya da çok popüler sitesinde aynı anda etkin kullanıcıdan daha fazla olduğunu.
Ben cevabım Facebook çok iyi onların arkadaşları ilişki tasarlanan nasıl soru cevaplar düşünüyorum ama ben nasıl hızlı çalışacak şekilde bunu uygulamaya söyleyemem üzgünüm. IMHO - bir sosyal ağ uygulama kolay ama iyi performans açıkça olmadığından emin yapıyor.
Ben grafik-sorguları yapmak için OrientDB deneme ve altta yatan DB SQL benim kenarlarını haritalama başladık. Şimdiye kadar alırsanız ben bu konuda bir makale yazacağım yapılır.