Thiết kế cơ sở dữ liệu Facebook?

Tôi đã luôn tự hỏi làm thế nào Facebook thiết kế mối quan hệ người dùng <->.

Tôi nghĩ bảng người dùng là như thế này:

user_email PK
user_id PK
password 

Tôi hình bảng với dữ liệu của người dùng (giới tính, tuổi, vv được kết nối qua email người dùng mà tôi sẽ giả sử).

Làm thế nào để nó kết nối tất cả bạn bè với người dùng này?

Một cái gì đó như thế này?

user_id
friend_id_1
friend_id_2
friend_id_3
friend_id_N 

Chắc là không. Bởi vì số lượng người dùng không xác định và sẽ mở rộng.

Giữ một bảng bạn giữ ID người dùng và sau đó là ID người dùng của bạn bè (chúng tôi sẽ gọi đó là FriendID). Cả hai cột sẽ là khóa ngoại trở lại bảng Người dùng.

Một số ví dụ hữu ích:

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)

Cách sử dụng ví dụ:

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

Điều này sẽ cho thấy Bob là bạn của cả Jon và Joe và Jon cũng là bạn với Joe. Trong ví dụ này, chúng tôi sẽ cho rằng tình bạn luôn có hai cách, vì vậy bạn sẽ không cần một hàng trong bảng như (2.1) hoặc (3.2) vì chúng đã được thể hiện theo hướng khác. Đối với các ví dụ trong đó tình bạn hoặc các mối quan hệ khác không rõ ràng theo hai chiều, bạn cũng cần có các hàng đó để biểu thị mối quan hệ hai chiều.

Hãy xem sơ đồ cơ sở dữ liệu sau đây, được thiết kế ngược bởi Anatoly Lubarsky :

TL; DR:

Họ sử dụng một kiến ​​trúc ngăn xếp với các biểu đồ được lưu trong bộ nhớ cache cho mọi thứ phía trên đáy của ngăn xếp của họ.

Câu trả lời dài:

Tôi đã thực hiện một số nghiên cứu về điều này bởi vì tôi tò mò về cách họ xử lý lượng dữ liệu khổng lồ của họ và tìm kiếm nó một cách nhanh chóng. Tôi đã thấy mọi người phàn nàn về các tập lệnh mạng xã hội tùy chỉnh trở nên chậm chạp khi cơ sở người dùng phát triển. Sau khi tôi thực hiện một số điểm chuẩn cho bản thân chỉ với 10 nghìn người dùng và 2,5 triệu kết nối bạn bè - thậm chí không cố gắng bận tâm về quyền và nhóm thích và bài đăng trên tường - nó nhanh chóng nhận ra rằng phương pháp này là thiếu sót. Vì vậy, tôi đã dành thời gian tìm kiếm trên web về cách làm nó tốt hơn và tìm thấy bài viết chính thức này của Facebook:

• TAO: Kho lưu trữ dữ liệu phân tán của Facebook cho biểu đồ xã hội
• TAO: Sức mạnh của đồ thị .

Tôi thực sự khuyên bạn nên xem phần trình bày của liên kết đầu tiên ở trên trước khi tiếp tục đọc. Đây có lẽ là lời giải thích tốt nhất về cách FB hoạt động đằng sau hậu trường bạn có thể tìm thấy.

Video và bài viết cho bạn biết một số điều:

• Họ đang sử dụng MySQL ở cuối ngăn xếp của họ
• Phía trên SQL DB có lớp TAO chứa ít nhất hai cấp bộ đệm và đang sử dụng biểu đồ để mô tả các kết nối.
• Tôi không thể tìm thấy bất cứ điều gì trên phần mềm / DB mà họ thực sự sử dụng cho các biểu đồ được lưu trong bộ nhớ cache của họ

Chúng ta hãy xem điều này, các kết nối bạn bè ở trên cùng bên trái:

Vâng, đây là một biểu đồ. :) Nó không cho bạn biết cách xây dựng nó trong SQL, có một số cách để làm điều đó nhưng trang web này có một số cách tiếp cận khác nhau. Chú ý: Hãy xem xét rằng một DB quan hệ chính là nó: Nó được cho là lưu trữ dữ liệu chuẩn hóa, không phải là một cấu trúc biểu đồ. Vì vậy, nó sẽ không hoạt động tốt như một cơ sở dữ liệu đồ thị chuyên dụng.

Cũng xem xét rằng bạn phải thực hiện các truy vấn phức tạp hơn chỉ là bạn bè của bạn bè, ví dụ như khi bạn muốn lọc tất cả các vị trí xung quanh tọa độ đã cho mà bạn và bạn bè của bạn thích. Một đồ thị là giải pháp hoàn hảo ở đây.

Tôi không thể cho bạn biết cách xây dựng nó để nó hoạt động tốt nhưng rõ ràng nó đòi hỏi một số thử nghiệm và lỗi và điểm chuẩn.

Đây là tôi thất vọng thử nghiệm cho chỉ phát hiện bạn của bạn bè:

Lược đồ DB:

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;

Truy vấn bạn bè:

(
        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
    )

Tôi thực sự khuyên bạn nên tạo cho bạn một số dữ liệu mẫu có ít nhất 10 nghìn hồ sơ người dùng và mỗi người trong số họ có ít nhất 250 kết nối bạn bè và sau đó chạy truy vấn này. Trên máy của tôi (i7 4770k, SSD, RAM 16gb) kết quả là ~ 0,18 giây cho truy vấn đó. Có lẽ nó có thể được tối ưu hóa, tôi không phải là thiên tài DB (đề xuất được chào đón). Tuy nhiên, nếu tỷ lệ này tuyến tính, bạn đã ở mức 1,8 giây cho chỉ 100 nghìn người dùng, 18 giây cho 1 triệu người dùng.

Điều này có thể vẫn nghe có vẻ ổn đối với ~ 100 nghìn người dùng nhưng hãy cân nhắc rằng bạn chỉ tìm nạp bạn bè của bạn bè và không thực hiện bất kỳ truy vấn phức tạp nào như "chỉ hiển thị cho tôi các bài đăng từ bạn bè của bạn + kiểm tra quyền nếu tôi được phép hoặc KHÔNG được phép để xem một số trong số họ + thực hiện một truy vấn phụ để kiểm tra xem tôi có thích ai trong số họ không ". Bạn muốn để DB thực hiện kiểm tra xem bạn có thích một bài đăng hay không hoặc bạn sẽ phải làm bằng mã. Cũng xem xét rằng đây không phải là truy vấn duy nhất bạn chạy và bạn có nhiều hơn người dùng hoạt động cùng một lúc trên một trang web phổ biến hơn hoặc ít hơn.

Tôi nghĩ rằng câu trả lời của tôi trả lời câu hỏi làm thế nào Facebook thiết kế mối quan hệ bạn bè của họ rất tốt nhưng tôi xin lỗi vì tôi không thể cho bạn biết cách triển khai nó theo cách nó sẽ hoạt động nhanh. Việc triển khai một mạng xã hội là dễ dàng nhưng đảm bảo rằng nó hoạt động tốt rõ ràng là không - IMHO.

Tôi đã bắt đầu thử nghiệm với OrientDB để thực hiện các truy vấn biểu đồ và ánh xạ các cạnh của tôi tới SQL DB bên dưới. Nếu tôi hoàn thành nó tôi sẽ viết một bài báo về nó.

Đặt cược tốt nhất của tôi là họ đã tạo ra một cấu trúc đồ thị . Các nút là người dùng và "tình bạn" là các cạnh.

Giữ một bảng người dùng, giữ một bảng cạnh khác. Sau đó, bạn có thể giữ dữ liệu về các cạnh, như "ngày họ trở thành bạn bè" và "trạng thái được phê duyệt", v.v.

Đó rất có thể là mối quan hệ nhiều đến nhiều:

Danh sách bạn bè (bảng)

user_id -> users.user_id
friend_id -> users.user_id
friendVisibilityLevel

BIÊN TẬP

Bảng người dùng có thể không có user_email dưới dạng PK, có thể là một khóa duy nhất.

người dùng (bảng)

user_id PK
user_email
password

Hãy xem những bài viết này mô tả cách LinkedIn và Digg được xây dựng:

• http://hurvitz.org/blog/2008/06/linkedin-arch architecture
• http://highscalability.com/scaling-digg-and-other-web-appluggest

Ngoài ra còn có "Dữ liệu lớn: Quan điểm từ Nhóm dữ liệu Facebook" có thể hữu ích:

http://developer.yahoo.net/bloss/theater/archives/2008/01/nextyahoonet_big_data_viewpoint_from_the_fac.html

Ngoài ra, có bài viết này nói về cơ sở dữ liệu không liên quan và cách chúng được sử dụng bởi một số công ty:

http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php

Bạn sẽ thấy rằng các công ty này đang xử lý kho dữ liệu, cơ sở dữ liệu được phân vùng, bộ đệm dữ liệu và các khái niệm cấp cao hơn so với hầu hết chúng ta không bao giờ xử lý hàng ngày. Hoặc ít nhất, có lẽ chúng ta không biết rằng chúng ta làm.

Có rất nhiều liên kết trên hai bài viết đầu tiên sẽ cung cấp cho bạn một cái nhìn sâu sắc hơn.

CẬP NHẬT 20/10/2014

Murat Demirbas đã viết một bản tóm tắt về

• TAO: Kho lưu trữ dữ liệu phân tán của Facebook cho biểu đồ xã hội (ATC'13)
• F4: Hệ thống lưu trữ BLOB ấm áp của Facebook (OSDI'14)

http://muratbuffalo.blogspot.com/2014/10/facebooks-software-arch architecture.html

HTH

Không thể truy xuất dữ liệu từ RDBMS cho dữ liệu bạn bè của người dùng cho dữ liệu vượt quá nửa tỷ đồng một lúc vì vậy Facebook đã triển khai việc này bằng cơ sở dữ liệu băm (không có SQL) và họ đã mở cơ sở dữ liệu có tên Cassandra.

Vì vậy, mỗi người dùng có khóa riêng và các chi tiết bạn bè trong hàng đợi; để biết làm thế nào cassandra làm việc này nhìn vào điều này:

http://prasath.posterous.com/cassandra-55

Bài đăng gần đây vào tháng 6 năm 2013 này đi sâu vào một số chi tiết để giải thích sự chuyển đổi từ cơ sở dữ liệu quan hệ sang các đối tượng có liên kết cho một số loại dữ liệu.

https://www.facebook.com/notes/facebook-engineering/tao-the-power-of-the-graph/10151525983993920

Có một bài báo dài hơn có sẵn tại https://www.usenix.org/conference/atc13/tao-facebook's-distribution-data-store-social-graph

Bạn đang tìm chìa khóa nước ngoài. Về cơ bản, bạn không thể có một mảng trong cơ sở dữ liệu trừ khi nó có bảng riêng.

Lược đồ ví dụ:

    Bảng người dùng
        người dùng PK
        dữ liệu khác
    Bảng bạn bè
        userID - FK tới bảng của người dùng đại diện cho người dùng có bạn bè.
        friendID - Bảng FK to Users 'đại diện cho id người dùng của bạn bè

Đây là một loại cơ sở dữ liệu đồ thị: http://components.neo4j.org/neo4j-examples/1.2-SNAPSHOT/social-network.html

Nó không liên quan đến cơ sở dữ liệu quan hệ.

Google cho cơ sở dữ liệu đồ thị.

Hãy nhớ rằng các bảng cơ sở dữ liệu được thiết kế để phát triển theo chiều dọc (nhiều hàng hơn), không theo chiều ngang (nhiều cột hơn)

Về hiệu suất của một bảng nhiều-nhiều, nếu bạn có 2 int 32 bit liên kết ID người dùng, thì bộ lưu trữ dữ liệu cơ bản của bạn cho 200.000.000 người dùng trung bình 200 người bạn mỗi người chỉ dưới 300 GB.

Rõ ràng, bạn sẽ cần một số phân vùng và lập chỉ mục và bạn sẽ không giữ nó trong bộ nhớ cho tất cả người dùng.

Có lẽ có một bảng lưu trữ mối quan hệ người dùng <->, nói "frnd_list", có các trường 'user_id', 'frnd_id'.

Bất cứ khi nào người dùng thêm người dùng khác làm bạn bè, hai hàng mới sẽ được tạo.

Ví dụ: giả sử id của tôi là 'deep9c' và tôi thêm người dùng có id 'akash3b' làm bạn của tôi, sau đó hai hàng mới được tạo trong bảng "frnd_list" với các giá trị ('deep9c', 'akash3b') và ('akash3b ',' Deep9c ').

Bây giờ khi hiển thị danh sách bạn bè cho một người dùng cụ thể, một sql đơn giản sẽ thực hiện điều đó: "select frnd_id từ frnd_list trong đó user_id =" trong đó id của người dùng đã đăng nhập (được lưu dưới dạng thuộc tính phiên).