2012-01-30 6 views
2

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

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

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

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

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

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

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

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

У сеансов влияют на использование памяти (ОЗУ)?

+5

'Мне нужно будет создать таблицу для каждого пользователя Facebook!' - вам не нужно это делать. Если вы считаете, что это так, ваша запланированная схема базы данных имеет недостатки. – DaveRandom

+1

Да, сеансы влияют на использование памяти, поскольку они доступны для php при запуске/чтении. Я бы использовал session_save_handler для хранения сеансов в базе данных. (И если на сеанс хранятся действительно тяжелые данные, вы можете разделить данные в другой таблице, чтобы «обычный» доступ к сеансу и таблица были небольшими). – djot

+1

Пойдите с базой данных, вот для чего. И не думайте, что массивы не будут тяжелыми. Что касается таблицы для каждого человека, не проблема. Вот почему они изобрели запрос создания.Кроме того, вам не обязательно. Храните их в моде, и вы все хорошо. –

ответ

1

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

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

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

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

+0

Кажется, memcached предназначен для «небольших фрагментов данных». Массивы, которые я храню, довольно большие! Это проблема? –

+0

У меня есть объекты размером порядка мегабайт. Тем не менее, вы просто сохраняете часть информации, которую вы получаете от API, поэтому вам не нужно тратить обращения на предметы, которые вы уже загрузили один раз. Скажем, user1 имеет друзей user2, user3, user4. И user5 имеет друзей user2, user6. Поэтому, когда пользователь5 входит в ваше приложение после пользователя1, вам не нужно запрашивать API для информации user2, потому что вы получаете его копию из кеша. Верный? Таким образом, теперь вы можете хранить только идентификатор друга в каждом объекте пользователя (а не полностью раздутый массив пользовательских объектов для друзей). – DMCS

+0

Это не так просто, потому что вы не знаете, дружит ли X с Y, когда они впервые подписываются. Кроме того, memcached хранит эти данные в ОЗУ, которые впоследствии могут иметь неприятные последствия, поскольку в настоящее время я пытаюсь уменьшить потребление ОЗУ на моем сервере. То, что вы предложили, очень полезно, но я не думаю, что это действительно актуально, поскольку оно просто ускоряет запросы, а не эффективно защищает пользователей. –

Смежные вопросы