Короткий зміст : Для близько 1 мільйона активних користувачів та 150 мільйонів збережених дій я просто кажу:
- Використовуйте реляційну базу даних для зберігання унікальних дій (1 запис на діяльність / "те, що трапилося") Зробіть записи максимально компактними. Структуруйте так, щоб ви могли швидко схопити пакет дій за ідентифікатором діяльності або за допомогою набору ідентифікаторів друга з обмеженнями часу.
- Публікуйте ідентифікатори активності Redis щоразу, коли створюється запис про активність, додаючи ідентифікатор до списку "Потік активності" для кожного користувача, який є другом / підписником, який повинен бачити активність.
Запросіть Redis, щоб отримати потік активності для будь-якого користувача, а потім захопити відповідні дані з db за потреби. Повертайтеся до запиту на db час, якщо користувачеві потрібно переглядати далеко назад у часі (якщо ви навіть пропонуєте це)
Я використовую звичайну стару таблицю MySQL для роботи з близько 15 мільйонами діяльності.
Це виглядає приблизно так:
id
user_id (int)
activity_type (tinyint)
source_id (int)
parent_id (int)
parent_type (tinyint)
time (datetime but a smaller type like int would be better)
activity_typeповідомляє мені тип діяльності, source_idповідомляє мені запис, з яким пов’язана діяльність. Отже, якщо тип активності означає "додане вибране", то я знаю, що source_id посилається на ідентифікатор улюбленої записи.
parent_id/parent_type Корисні для мого програми - вони кажуть мені , що діяльність пов'язана с. Якщо книгу було вибрано, тоді parent_id / parent_type скаже мені, що діяльність стосується книги (типу) із заданим первинним ключем (id)
Я індексую (user_id, time)і запитую для тих дій, які є user_id IN (...friends...) AND time > some-cutoff-point. Викидання ідентифікатора та вибір іншого кластерного індексу може бути хорошою ідеєю - я не експериментував з цим.
Досить основні речі, але це працює, це просто, і з ним легко працювати, як змінюються ваші потреби. Крім того, якщо ви не використовуєте MySQL, ви можете зробити кращі показники.
Для швидшого доступу до останніх заходів я експериментував з Redis . Redis зберігає всі свої дані в пам’яті, тому ви не можете розмістити всю свою діяльність там, але ви можете зберегти достатньо для більшості часто вражаючих екранів на вашому сайті. Найновіші 100 для кожного користувача чи щось подібне. З Redis в поєднанні це може працювати так:
- Створіть свій запис про діяльність MySQL
- Для кожного друга користувача, який створив діяльність, натисніть ідентифікатор до їх списку активностей у Redis.
- Обріжте кожен список до останніх X елементів
Redis швидкий і пропонує спосіб передачі команд через одне з'єднання - тому висування активності до 1000 друзів займає мілісекунди.
Більш детальне пояснення того, про що я говорю, див. Приклад Redis у Twitter: http://redis.io/topics/twitter-clone
Оновлення лютого 2011 року У мене наразі 50 мільйонів активних заходів, і я нічого не змінив. Одна приємна річ, щоб зробити щось подібне до цього, це те, що вона використовує невеликі невеликі рядки. Я планую внести деякі зміни, які б передбачали ще багато заходів та більше запитів щодо цих заходів, і я, безумовно, буду використовувати Redis для того, щоб все було швидко. Я використовую Redis в інших областях, і він дійсно добре справляється з певними проблемами.
Оновити липень 2014 року. Ми нараховуємо близько 700 тис. Активних користувачів щомісяця. Останні кілька років я використовував Redis (як описано в маркованому списку) для зберігання останніх 1000 ідентифікаторів активності для кожного користувача. Зазвичай у системі є близько 100 мільйонів записів про діяльність, і вони все ще зберігаються в MySQL і все ще мають однаковий макет. Ці записи дозволяють нам позбутися меншої кількості пам'яті Redis, вони служать записом даних про діяльність, і ми використовуємо їх, якщо користувачам потрібно переглядати сторінку ще в часі, щоб щось знайти.
Це не було розумним чи особливо цікавим рішенням, але воно мені добре послужило.