ФорумСообществоФлейм → Как гугл плюс устроен внутри?

Как гугл плюс устроен внутри?

  • mario

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

    Spritz 11 декабря 2011 г. 16:36, спустя 8 минут 10 секунд


    хм, ну там же есть какие-то ограничения, на длину запроса, например? Не могу нагуглить их.

    Не может же быть такого, что WHERE IN (…) будет нормально работать при любом кол-ве аргументов
    разбить на части
    http://www.php.net/manual/en/sphinxclient.addquery.php
    Спустя 162 сек.


    хм, ну там же есть какие-то ограничения, на длину запроса, например? Не могу нагуглить их.

    Не может же быть такого, что WHERE IN (…) будет нормально работать при любом кол-ве аргументов
    разбить на части
    http://www.php.net/manual/en/sphinxclient.addquery.php
    а хотя нет, у тебя пых долго будет обрабатывать такой массив…
    Тогда лучше в евентс добавлять users, в нем хранить все id юзеров, которые должны увидеть эту запись. В общем стоит покрутить. Самое главное не зацикливайся на том, что структура индекса не обязательна должна повторять структуру базы/приложения
  • mario

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

    Spritz 11 декабря 2011 г. 16:46, спустя 9 минут 48 секунд

    хм, ну там же есть какие-то ограничения, на длину запроса, например?

    http://sphinxsearch.com/docs/2.0.2/conf-max-packet-size.html
    Спустя 27 сек.
    http://sphinxsearch.com/docs/2.0.2/conf-max-filters.html
    Спустя 8 сек.
    http://sphinxsearch.com/docs/2.0.2/conf-max-filter-values.html
    Спустя 25 сек.
    max_filter_values
    …Optional, default is 4096
    Спустя 22 сек.
    так что со стороны сфинкса ты вложишься. А вот со стороны пыха, я хз… :)
  • Абырвалг

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

    Spritz 11 декабря 2011 г. 16:51, спустя 4 минуты 52 секунды

    так тогда будет несколько разных результатов, которые нужно будет объединить и отсортировать заново
    Тогда лучше в евентс добавлять users, в нем хранить все id юзеров, которые должны увидеть эту запись

    это то же самое, что таблица events2users, которую затратно обрабатывать.

    Самое главное не зацикливайся на том, что структура индекса не обязательна должна повторять структуру базы/приложения

    ок
  • kostyl

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

    Spritz 11 декабря 2011 г. 16:54, спустя 3 минуты 20 секунд

    mario, хорошо, пусть канал основная сущность, на сколько важно валит событиЕ в разные каналы? Возможно можно сделать cannel_id в events ?

  • mario

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

    Spritz 11 декабря 2011 г. 17:18, спустя 23 минуты 27 секунд

    так тогда будет несколько разных результатов, которые нужно будет объединить и отсортировать заново

    я вот сейчас найти не могу, но вроде бы
    это то же самое, что таблица events2users, которую затратно обрабатывать.

    для сфинкса не затратно. А в базе храни так как тебе удобно уже, т.к. с базой ты будешь работать только для вставки (благо innodb нормальный в этом плане) и переиндексации.
  • Абырвалг

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

    Spritz 11 декабря 2011 г. 17:28, спустя 10 минут 6 секунд

    Возможно можно сделать cannel_id в events

    никак не получится, некоторые события вещают в несколько каналов одновременно
    Спустя 79 сек.
    вот создал человек топик в блоге какого-то района (ЦАО - Арбат). Этот топик должны увидеть в ленте те, кто живет в этом районе (подписаны на канал района) и друзья того, кто написал
  • kostyl

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

    Spritz 12 декабря 2011 г. 1:47, спустя 8 часов 19 минут 24 секунды

    а нельзя ли денормализовать по записям событий. т.е. запись о событии так и находится в таблице событий и все остальное точно так же. Но есть доп таблица где хранятся события для конкретных пользователей с группой, текстом, каналом и т.п, т.е. для показа пользователю ленты необходимо сделать выборку из одной таблицы-агрегата, включающей в себя записи типа
    id, event_id, user_id, even_group, channel_id, channel_name, date и т.д., то есть все необходимые данные, которые нужны для показа событий пользователю со всех каналов на которые он подписан, данные для адресации события или чего то там, где оно возникло, например в блоге как ты говоришь, данные для сортировки по каналам, по пользователям и т.д. Тебе же нужна производительная выборка. Апдейт, конечно немного может тормозить, но он будет реже выборки, а выборка реально может быть быстрая. Тем более если такую таблицу впиздячить в noSQL - вообще будет летать, а апдейты в noSql-ях на сколько я знаю, если поразбираться с конкретными решениями могут быть тоже довольно быстрыми. Например мы на mongodb нагибали mssql напрочь… даже памяти меньше жрали.
  • Абырвалг

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

    Spritz 12 декабря 2011 г. 3:06, спустя 1 час 18 минут 16 секунд

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

    типа как тут http://highload.com.ua/index.php/2010/04/24/%D0%B4%D0%B5%D0%BB%D0%B0%D0%B5%D0%BC-%D0%BB%D0%B5%D0%BD%D1%82%D1%83-%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9-%D0%BD%D0%B0-mongodb-php/ ? рассматриваю такое решение тоже, но тут нужно за многим следить, это затратно.


    просто если делать на монго - то можно вообще не одну таблицу аггрегирующую а по таблице (коллекции) на каждого пользователя, выборки вообще взлетят тогда. Но проблему апдейтов никто не отменял.
  • artoodetoo

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

    Spritz 12 декабря 2011 г. 8:43, спустя 5 часов 37 минут 2 секунды

    Теперь объясните простыми словами, пожалуйста, почему MongoDB имеет преимущества в данной задаче.
    ιιlllιlllι унц-унц
  • Абырвалг

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

    Spritz 12 декабря 2011 г. 13:20, спустя 4 часа 37 минут 44 секунды

    числом inserts per second?, что особенно актуально для такой задачи

    map-reduse. Я писал, что нужно группировать события. К примеру пользователь отметился на 20 фотках, а вывести нужно только 5. Или к примеру создание встречи, комментирование, присоединение к ней - это все одна группа, вывести нужно по одному типу для каждого вида, в пагинации эти 3 вида идут как один (пагинация по группе считается)

    просто хочется попробовать эту технологию
  • phpdude

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

    Spritz 12 декабря 2011 г. 13:47, спустя 26 минут 32 секунды

    просто хочется попробовать эту технологию

    да не особо больше плюсов то она дает по отношению к реляционным базам и group by :-)
    Сапожник без сапог
  • kostyl

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

    Spritz 12 декабря 2011 г. 21:37, спустя 7 часов 49 минут 45 секунд

    не знаю как с mysql, но мы тестили как раз инсерты в монго и в mssql, он что жрал памяти больше и дольше вставлял, причем дольше больше чем на порядок за единицу времени. Тогда мы выкинули нахуй ms sql сервер и подняли все на монго ))
  • phpdude

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

    Spritz 12 декабря 2011 г. 22:06, спустя 29 минут 23 секунды


    не знаю как с mysql, но мы тестили как раз инсерты в монго и в mssql, он что жрал памяти больше и дольше вставлял, причем дольше больше чем на порядок за единицу времени. Тогда мы выкинули нахуй ms sql сервер и подняли все на монго ))
    у меня на ноуте выдерживало скорость порядка 15-20 мбайт в секунду данных на инсерт. там есть фишка хуевая (и хорошая одновременно) - как он файлы юзает. он сначала резервирует место. а я для тестов погонять хотел 100 млн строк. в данных это порядка 100 гбайт на одну таблицу. забил в общем)) мне она по другому поводу не подошла. к той задаче все еще присматриваюсь на CouchDB
    Сапожник без сапог
  • kostyl

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

    Spritz 12 декабря 2011 г. 22:15, спустя 9 минут 7 секунд

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

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

    Spritz 12 декабря 2011 г. 22:25, спустя 9 минут 48 секунд

    ну вот такая тема, что по коллекции (== по таблице) на пользователя - это нормально ваще?

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