TL; DR:
Вони використовують архітектуру стека з кешованими графіками для всього, що знаходиться внизу MySQL внизу їх стеку.
Довга відповідь:
Я провів кілька досліджень з цього приводу, тому що мені було цікаво, як вони обробляють величезну кількість даних і швидко шукають їх. Я бачив, як люди скаржаться на замовлення сценаріїв соціальних мереж, які стають повільними, коли зростає база користувачів. Після того, як я здійснив порівняльний аналіз із лише 10-тисячними користувачами та 2,5 мільйонами друзів, навіть не намагаючись перейматися груповими дозволами та лайками та повідомленнями на стінах - швидко виявилося, що такий підхід є недоліком. Тому я витратив деякий час на пошук в Інтернеті, як зробити це краще, і натрапив на цю офіційну статтю у Facebook:
Я дуже рекомендую вам переглянути презентацію першого посилання вище, перш ніж продовжувати читати. Це, мабуть, найкраще пояснення того, як ФБ працює за кадром, який ви можете знайти.
Відео та стаття розповідають про декілька речей:
- Вони використовують MySQL в самому дні їхнього стека
- Над БД SQL є шар TAO, який містить щонайменше два рівні кешування і використовує графіки для опису з'єднань.
- Я нічого не міг знайти, яке програмне забезпечення / БД вони фактично використовують для кешованих графіків
Давайте подивимось на це, дружні з'єднання вгорі зліва:
Ну, це графік. :) Це не говорить вам про те, як побудувати його в SQL, є кілька способів це зробити, але на цьому сайті є безліч різних підходів. Увага: Поміркуйте, що реляційна БД є такою, якою вона є: Вважається, що зберігати нормалізовані дані, а не структуру графіків. Таким чином, воно не буде настільки добре, як спеціалізована база даних графіків.
Також врахуйте, що вам потрібно робити більш складні запити, ніж просто друзі друзів, наприклад, коли ви хочете відфільтрувати всі місця навколо заданої координати, що вам і вашим друзям друзів подобається. Графік - ідеальне рішення тут.
Я не можу сказати вам, як побудувати його так, щоб він працював добре, але це, очевидно, вимагає певних проб, помилок та порівняльного аналізу.
Ось мій невтішний тест на лише знахідки друзів друзів:
Схема БД:
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;
Запит друзів друзів:
(
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
)
Я дійсно рекомендую створити вам декілька зразкових даних, що містять щонайменше 10 тис. Записів користувачів, і кожен з них має принаймні 250 друзів, а потім запустити цей запит. На моїй машині (i7 4770k, SSD, 16 Гб оперативної пам’яті) результат склав ~ 0,18 секунди для цього запиту. Можливо, це можна оптимізувати, я не геній БД (пропозиції вітаються). Однак якщо ця масштабність лінійна, ви вже за 1,8 секунди для лише 100 тис. Користувачів, 18 секунд - для 1 млн користувачів.
Це все ще може звучати добре для ~ 100k користувачів, але врахуйте, що ви просто зібрали друзів друзів і не зробили жодного складнішого запиту, наприклад " показувати мені лише повідомлення від друзів друзів + робити дозвіл перевірити, чи мені це дозволено чи НЕ дозволено щоб побачити деякі з них + зробити підзапит, щоб перевірити, чи мені сподобався хтось із них ". Ви хочете дозволити БД перевіряти, чи сподобалась вам публікація вже чи ні, або вам доведеться це робити в коді. Також врахуйте, що це не єдиний запит, який ви запускаєте, і що у вас є більш ніж активний користувач одночасно на більш-менш популярному сайті.
Я думаю, що моя відповідь відповідає на питання, як Facebook дуже добре розробив стосунки своїх друзів, але мені шкода, що я не можу сказати, як це реалізувати так, щоб це швидко працювало. Реалізувати соціальну мережу досить просто, але переконатися, що вона працює добре, очевидно, немає - IMHO.
Я почав експериментувати з OrientDB, щоб робити графічні запити та відображати мої краї до базової бази даних SQL. Якщо я коли-небудь закінчу це, я напишу про це статтю.
