ФорумПрограммированиеPHP для идиотов → Профи, обосрались?

Профи, обосрались?

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 7 апреля 2010 г. 9:30, спустя 43 минуты 29 секунд


    В базе перечисляются через запятую айдишники друзей. Запрос делается исходя из отмеченных полей(заметки, события, фотографии…). В чем собственно проблема? Прошу прощения, если я не правильно вас понял) А, пойду посру)
    нагрузку глянь)
    Сапожник без сапог
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 13:32, спустя 4 часа 2 минуты 26 секунд

    мое видение решения задачи
    events

    user_id # кто произвел событие
    event_type # 1 - добавил друга, 2 - откомментировал что-то
    date
    data # json/любая другая структура: кого добавил в друзья, фотографию с каким ID откомментировал


    потом, значит, делаем выборку из этой таблицы, где user_id IN (мои друзья) где event_type IN (список событий, за которыми я слежу)

    тормозить наверно будет. Но можно кешировать (в медленном файловом кеше). Можно наверно переводить на noSQL, какие-то специальные демоны для работы с очередями. Это как было уже замечено к ГО нужно обращаться
  • Frozzeg

    Сообщения: 5641 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 14:01, спустя 28 минут 35 секунд

    еще как вариант написать сервис на сях
    You can be anything you want to be. Just turn yourself into anything you think that you could ever be.
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 7 апреля 2010 г. 14:45, спустя 44 минуты 41 секунду

    си не нужен. скорость выполнения запроса не сильно зависит от клиента. принципиален способ кеширования.

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

    при обновлении чего-либо надо выставлять критерий сброса кеша для всех заинтересованных (подписаных). а строить кеш заново только по запросу от этого заинтересованного.
    ιιlllιlllι унц-унц
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 15:04, спустя 19 минут 5 секунд

    во-во, это я и имел в виду, когда говорил о медленном файловом кеше. Просто интересно: насколько медленно будет делать выборку если у меня 1000 друзей? а если 10 000?
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 7 апреля 2010 г. 15:15, спустя 10 минут 18 секунд

    опять путаница. скорость выборки из кеша или скорость построения кеша? файлы вообщето очень шустро читаются
    ιιlllιlllι унц-унц
  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 15:21, спустя 6 минут 47 секунд


    файлы вообщето очень шустро читаются

    особенно через replace

    во-во, это я и имел в виду, когда говорил о медленном файловом кеше. Просто интересно: насколько медленно будет делать выборку если у меня 1000 друзей? а если 10 000?

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

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 16:35, спустя 1 час 13 минут 34 секунды

    artoodetoo, та не, я акцентировал внимание на медленном файловом кеше потому как наверно не нужно такой информацией забивать быстрый кеш (APC, eAccelerator). Я не говорю, что файлы будут тормозить, просто они изначально медленнее ОЗУшного кеша.

    kostyl, ну меня смущает запрос
    WHERE user_id IN (10 000 IDшников друзей через запятую) AND event_type IN (12 ID через запятую)
  • Givi

    Сообщения: 2284 Репутация: N Группа: Адекваты

    Spritz 7 апреля 2010 г. 17:28, спустя 53 минуты 21 секунду

    Абырвалг, прости, ничего личного, но если у тебя 10 тык друзей, то вы йобнулись что ли столько говнища читать в событиях, которые произошли с ними за день.
    Я тут иногда вконтакте за полусотней наблюдаю (очень редко), так там простынь такая шо ппц, а ты тут о 10 тысячах :)
    Да и вообще, у нормального человека не должно быть 10 тык друзей. Разве что у спамера какого-нить.
  • mario

    Сообщения: 6067 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 17:33, спустя 4 минуты 26 секунд


    Абырвалг, прости, ничего личного, но если у тебя 10 тык друзей, то вы йобнулись что ли столько говнища читать в событиях, которые произошли с ними за день.
    Я тут иногда вконтакте за полусотней наблюдаю (очень редко), так там простынь такая шо ппц, а ты тут о 10 тысячах :)
    Да и вообще, у нормального человека не должно быть 10 тык друзей. Разве что у спамера какого-нить.
    в этом ты заблуждаешься… посмотри на людей из того вконтакте, у них количество друзей это нкий писькомер…
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 17:40, спустя 6 минут 53 секунды

    я это число взял не просто так.


    Нововведения июня
    Павел Дуров 28 июня 2009 в 22:20

    Максимальное количество друзей повышено до 10 000. Это наивысший показатель среди сайтов с настройками приватности.


    такие дела
    Спустя 37 сек.
    и я и ты понимаем, что это бред, но этот бред должен все равно работать и не виснуть
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 7 апреля 2010 г. 17:51, спустя 11 минут 50 секунд

    Я тут иногда вконтакте за полусотней наблюдаю (очень редко), так там простынь такая шо ппц, а ты тут о 10 тысячах :)

    наблюдать за друзьями вконтакте самое бесполезно занятие, хуже телика…

    Да и вообще, у нормального человека не должно быть 10 тык друзей. Разве что у спамера какого-нить.

    да тут похер кому базу вешать…
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 7 апреля 2010 г. 17:58, спустя 6 минут 57 секунд

    Абырвалг, вот вот я тута нужно определиться с функционалом.
    Я бы не делал фильтров по типу события, тобишь event_type вообще не нужен - тупо бы показывал все события и всё
    WHERE user_id IN (10 000 IDшников друзей через запятую) LIMIT 10 OFFSET 0
    а лучше вообще таблица, чтобы user_id был один - того человека, которому показывается лента событий, тогда данные ограничатся на этапе ввода, хотя тогда будет 10000 дублей для одного события как бы! Это можно убить, добавляя строки событий в блоб. Фактически структура таблицы будет иметь вид.
    id int
    user_id int этому пользователю показываем
    events_text blob текст событий
    date_show  int которые ему надо видеть в эту дату
    ну а дальше куча секса с обновлением
  • Givi

    Сообщения: 2284 Репутация: N Группа: Адекваты

    Spritz 7 апреля 2010 г. 17:59, спустя 56 секунд

    Абырвалг, да я так, позаебывать решил :) У меня сегодня мегапозитивное настроение (ну ты ж сам видишь какая за окном погода у нас - солнышко и ветерок дует, пиздато).
    Вообще работать должно, но реализацию в данном случае нужно делать СУГУБО под конкретную задачу, потому как при таких раскладах шаг влево - расстрел (вправо можно).

    mario, мне если уж и брать писькомер какой, то пусть лучше это будет линейка =)))
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 7 апреля 2010 г. 18:12, спустя 12 минут 32 секунды

    WHERE user_id IN (10 000 IDшников друзей через запятую)
    да не будет это тормозить нихуя если индекс сделать нормальный, а фильтровать по евент тайпу я хз стоит ли вообще … думать надо, это можно и на пхп отфильтровать, это не так страшно, но тут думать надо еще раз грю =))
    Сапожник без сапог

Пожалуйста, авторизуйтесь, чтобы написать комментарий!