И еще немного о ленте избранного

[Diary Spirit]

Кому интересно - формирование ленты происходит примерно так.



Идет обращение к базе - выбирается группа тех, кто есть в избранном у данного пользователя (с проверкой права на доступ к дневнику). Причем проверка шарашит по всей базе пользователей.

Затем у обнаруженных избранных выбираются записи, сделанные после даты Х. При этом проверяется еще и право доступа к кажой конкретной записи.

Наконец все это разбивается на страницы (учитывая выбранное число вывода для конкретного юзера).



В часы пик сервер, мягко скажем, не радуется.



Если у кого-то есть внятные мысли по поводу оптимизации запросов - будем рады выслушать.

Comments

Причем проверка шарашит по всей базе пользователей.

а зачем по всей-то?

[Lady_Hella]

.silent

Опередил с вопросом.

Насколько я понимаю, у каждого дайри есть уникальный идентификатор. Чем шарить по всей базе, нельзя ли переадресовать его к свойствам пользователя, где-то ведь прописаны эти самые избранные, которые потом выводятся списком на страницы?

[rushills]

Мысль - не надо строить все. Достраивайте асинхронно порциями.

Это не колебания воздуха, мы пишем софт для обслуживания большого (хоть и не такого как у вас) количества пользователей, но с гораздо большим количеством самих записей - сотни тысяч- миллионы на одного пользователя, права учитываются, статусы записей и прочее. Просто не надо делать все сразу. Пусть клиентский комп тоже напрягается - сделайте ему хороший javasсriрt.

[Griffon]

вот.вот. юзер посылает на сервер запрос - избранное (свое или чужое). Есть же список избранных. к примеру к юзеру номер 376 избранными являются юзера 678, 3469, 53479 и тд. зачем же шерстить всю базу?

[th]

складывать записи за последние N дней (N=1...7?) в табличку recent_posts и в три часа ночи мёржить её с остальной базой? с перестроением индексов итп.

и побить базу на таблички по месяцам.

[Deo]

может вам нужна помощь в программировании... а?

[sese]

th , а дневники, поди, на SQL сервере лежат?

[Firesong]

А нельзя сделать показ ф-ленты с "момента последнего посещения"? Нечто подлобное делается на том же job.ru, например, где объем инфы всяко больше...

[Loss]

несколько глупых идей:

от лица человека, несколько раз в час обновляющего страницу избранного



1. Идет обращение к базе - выбирается группа тех, кто есть в избранном у данного пользователя (с проверкой права на доступ к дневнику).

Не совсем понятна фраза «Причем проверка шарашит по всей базе пользователей». Индекса нет, что ли?

список избранных - в куку. 7 символов на человека => 4 Кб хватит примерно так на 500 избранных.



2. Затем у обнаруженных избранных выбираются записи, сделанные после даты Х. При этом проверяется еще и право доступа к кажой конкретной записи.

Объясните глупому сакральный смысл даты Х, а то никаких мыслей по этому поводу



3. Наконец все это разбивается на страницы (учитывая выбранное число вывода для конкретного юзера).

Опять-таки, число вывода - в куку (-1 запрос)

На страницы разбивать перед вторым шагом (уверен, что так и делается, только криво сформулировано)

[Firesong]

Кстати, а сделать стандартное число вывода для всех юзеров? Чтобы вообще убрать этот шаг? Конечно, тоже будут возмущаться, но... главное взять не слишком большое для удобства тех, у кого медленный диал-ап. Либо просто выбрать среднее по дайри, если это не слишком геморно.

[rushills]

И еще одно - опубликуйте официальный интерфейс (API) обязательно! Ваши почитатели вас порадуют, право же.

[Караидель]

Кукисы не спасут отца русской демократии. За время прошедшее после последнего сохранения, пользователь мог стереть или изменить запись. Показывать её в первоначальном виде - наршать права писавшего и вводить в заблуждение смотрящего.

[Marrble]

Возможно "шарить по всей базе пользователей" станет проще, если ее предварительно отфильтровать по признаку "были записи за последние Х дней".

[Loss]

Караидель а в куках хранить только список избранных. 111,222,333 - и т.д. естественно, если нет куки - впаять, если выкинул кого из избранного или добавил - перепаять. в большинстве случаев минус запрос.



одно но: всё портит функция «выкинуть себя из чужого избранного», это надо как-то бороть

кстати, вопрос. чем же будет отличаться так нагрузка при пользовании программой от простого серфинга?



да и ведь в настройках дайрика можно сделать такой пункт - количество дней для показа избранного, а то и вообще количество страниц избранного с жестким максимумом. Причем новичкам сделать минимальное, а если надо больше - пусть идут в настройки. Вроде идея неплохая. нет?



А насчет пользователей - что-то мне кажется что пользователи ищутся не по ключу, а по нику. Ведь мы вводим в черно-белые листы именно ники, хотя должны бы были выбирать пользователя, а храниться все должно было по первичному ключу...

Могу ошибаться, конечно.

[Сетанта]

.silent ето уже сделали. с месяц назад.

[tven]

Встречный вопрос по кукам: а как быть тем, у кого они отключены. У меня они не отключены, но есть же персонажи с отключёнными куками...

2Администрация: хотя бы приблизительно структуру базы пользователей можно? Проще было бы понять, в каком направлении можно провести оптимизацию...

[Караидель]

.silent

Ники уникальны - значит, тоже могут быть ключом.

А можно вообще френд ленту сделать по принципу "прочитал/не прочитал", тогда будут показываться только те записи, что не прочел еще пользователь. Разве не удобно?

Продумывать такой вариант, конечно, долго надо...

[rushills]

Караидель не очень хорошее решение - ники меняются, а ключит не должен бы по идее.

[нос]

Пишите, пишите. Мы все передадим кому следует.



tven, здесь таких пользователей нет, кроме "гостей". Если куки отключены, то вообще нельзя работать в дневниках.

[Loss]

tven а как они на дневник свой с отключенными куками зайдут-то?



.silent ... и добавится время на обработку флага прочитал/не прочитал, да? а если к тому же с первого раза не понять? лучше подсветку сделать.



Караидель что-то мне подсказывает, что по шестизначному цифровому айдишнику индекс побыстрее будет, чем по варчару...

[Завулон]

rushills

у каждого пользователя есть номер- уникальный идентификатор, смена ника на него никак не обображается.



Хотелось бы знать какая есть уже система индексирования , ибо меня тоже сильно напугала фраза про поиск по всей базе.



Связь "Избранные - Записи" - типовое M к N - разводится введение дополнительной сущности. в которуй атрибутами станут уникальные идентификаторы с первого и второго, если и дополнять сразу полем "открыта" с соответствующими параметрами, то поиск уже будет далеко не по всей базе, а разбит только вот в такие подиндексные блоки.

[Argent Beast]

Хм.



1) добавляем табличку с содержимым типа ID UID MSGID TIME

ID - ид записи, UID - ид усера, чью френдленту собираем, MSGID - ид какой-то мессаги (как у вас посты хранятся, я не знаю. если может быть сообщение с одинаковым идом у двух разных усеров, можно добавить PID - Poster ID).



Френдленту собираем из нее простым поднятием сообщений по MSGID (и, возможно, PID).



Посты в табличку заносятся при посте - проверяется, кто читает запостившего, и добавляются соответствующие записи согласно прав. Та же операция происходит при смене списка избранных и при смене прав доступа на дневник/пост/самилучшезнаетечто.



2) вешаем периодический процесс, который регулярно бьет из таблички старые записи по TIME.



3) (опционально) Выносим ее на отдельный сервер, куда по вкусу можно скинуть что-нибудь еще - например, тяжелое, но редкотаскаемое.



Как насчет такого варианта?

[Deo]

А не пробовали замерять по времени, на что уходит больше всего?



1. Выбор группы избранных.

2. Выбор записей, сделанных после даты Х.

3. Разбивка на страницы.

[Amber Night]

Если все дело в sql-запросе, тогда я не понимаю, как клиент решит эту проблему?

или вы расчитываете таким образом уменьшить количество народа пользующего эту функцию?

но ведь это не решение проблемы, это опять же уход от нее.

[Kroko.Dil]

Как хранятся данные? Применяется ли индексация?

[rushills]

Завулон, я и писал о его логичной выделенности, если Вы заметили .

[Караидель]

А если держать базу записей за последние сутки? Можно же автоматизировать удаление из неё старых записей. И вести поиск только по ней. Да, жёсткое ограничение глубины, но насколько уменьшится время поиска!

Да хотя бы держать список тех, кто обновлял дневник за последние Х дней - уже даст хороший прирост скорости, учитывая тонны мёртвых дневников.

[aldarion]

А еще хорошо бы портировать будущую программу сразу на JME(2) платформу, чтобы можно было @дневниками с телефонов пользоваться. Ибо сколько ни пробовал, ни через один мобильный эмулятор или веб-браузер нельзя залогиниться на дневники. Это все куки. На софтинах пишут, что есть поддержка кук, а вот фиг.