Хранение больших сеансов замедляет время отклика и сервера

Question

Я нахожусь в процессе создания приложения Facebook для своего веб-сайта, которое включает в себя функции, требующие списка друзей пользователей.

Найти друзей не проблема, я пытаюсь решить, как их хранить.

1. Вариант 1 - Храните пользователей в моей базе данных MySQL, я решил не делать этого, поскольку моя база данных станет очень тяжелой, очень быстро. Кроме того, мне нужно будет создать таблицу для каждого отдельного пользователя Facebook!
2. Вариант 2 - Сохраните массив друзей Facebook в сеансе, который обновляется каждые полчаса, чтобы обеспечить включение новых друзей. Не обращайте внимания на тот факт, что сеанс обновляется каждые полчаса, Это плохая идея для хранения, что может быть очень большим массивом в сеансе?

Скорее всего, веб-сайт будет получать большие объемы трафика и поэтому будет хранить большое количество этих сеансов.

Несмотря на то, что я опытный разработчик, я не слишком опытен в таких ситуациях. Я просто хотел бы знать, является ли это плохой идеей?

Просто чтобы дать вам небольшую информацию о типичном массиве друзей:

1. Каждый массив является многомерным в формате {0 [uid: 1, name: Jo Bloggs, картинка: test.jpg], 1 ...}
2. Список друзей обычно варьируется от 100 до 5000 предметов, хотя в среднем составляет около 700. Они не маленькие!

Если это плохой способ хранения друзей, какие еще варианты (кроме MySQL) есть?

Влияет ли сессия на использование памяти (RAM)?

Answer 1

Для ваших требований я настоятельно рекомендую установить MemCacheD на ваш сервер.См. http://memcached.org/ для получения дополнительной информации.

Сессия предназначена только для текущего пользователя, вошедшего в систему, поэтому обмен информацией между сеансами будет затруднен.Также, когда сеанс завершается, пользовательские данные тоже.

Для memcached данные хранятся в парах ключ / значение.

Таким образом, для ключа можно использовать идентификатор Facebook, а для значения - сериализованный объект пользовательских данных.