Сабж. Нигде не могу нагуглить как он хранит эти свои круги, как дробит информацию по кругам, приватность вся эта и тд.

я думаю навряд ли они уже опубликовали такую инфу. Так что думаю нужно ждать, пока на какой либо конференции кто нибудь расскажет )

Абырвалг, а свои мысли у тебя есть как это могло бы быть сделано?

artoodetoo, вряд ли, в книжках про такое не написали =))

artoodetoo

Абырвалг, а свои мысли у тебя есть как это могло бы быть сделано?

есть, но это не будет работать на таких объемах.

Givi

artoodetoo, вряд ли, в книжках про такое не написали =))

а я до сих пор ни одной книжке по программингу и не прочитал, кстати. тупобаран

— Папа, а почему солнышко утром выходит, а вечером заходит?
— Сынок, работает — и хрен с ним!

так просто эти его технологии можно применить для моей новостной ленты

Ну а если тупо:
далее везде "кто" и "кого" - это id в таблице "чуваки".
- таблица "лента". {кто, текст}
- таблица "круги" с {кто, название, читать}
- таблица "отношения" {кто, круг, кого}
 
SELECT лента.*
FROM
 лента INNER JOIN
 чуваки ON чуваки.ид=лента.кто INNER JOIN
 отношения ON отношения.кто=Я AND чуваки.идлента.кто=отношения.кого INNER JOIN
  круги ON круги.кто=Я AND отношения.кого=лента.кто
WHERE
  круги.читать=1
 
 
не?
 
P.S. НЕ, говно. но что-то типа. надеюсь ты разовьешь мысль ;)

artoodetoo, кто кого - звучит весело :)

artoodetoo

"кто" и "кого"

"Связь": NoSQL-решение с одним ключом hash, которое равно md5(кто+кого). Базе остается проверять есть ли такой ключ.
"Друзья": key-value [user_id => friends]. В качестве friends можно хранить json с перечислением "уникальных ключей" друзей ( md5(id + email + дата регистрации) )
"Друзья" обновляются после каждого изменения/закругления или кроном из "генератора" (например, таблицы с тремя ключами - hash, user, friend) "Уникальные ключи" друзей нужны для безопасности приватных настроек пользователей, если ты выстраиваешь клиентской частью отображение, потому что тупо id можно подменить, а ключи почти невозможно

Ivan

потому что тупо id можно подменить, а ключи почти невозможно

ну давай, сессионный ID подмени :-)

Посмотрите исходный код страницы https://plus.google.com/
Там к сожалению не клиентом работа ведется. Там страница наполняется AF_initDataQueue.push() с параметрами в виде объектов жсона: имя фамилия, 6 рандомных друзей из рандомных кругов пользователя, первые N постов его ленты, путь к фотке, и тд

artoodetoo, да на уровне мускла такое замутить не сложно, проблема в другом: тормозить будет. Джоин-переджоин - слишком много фильтровать всего. У нас такой же паб-саб в ленте и на локалке вообще не можем читать уже эту ленту, только на продакшене вот то, что Ivan описывает - интереснее, но я пока не могу въехать что это он такое пишет

Ну так давай упрощать. Чем проще схема тем быстрее. Ivan вроде пытается, только непонятно )))

секрет производительности в сокращении числа запрашиваемых источников. причем неважно SQL или noSQL. в случае SQL это позволяет избавиться от каких-то джойнов или вложенностей.
 
если я правильно понял Ivan-а, он предлагает формировать таблицу "друзей" при изменении "кругов". ведь состав кругов изменяются редко. это та избыточность, которая позволяет упростить запрос по ленте на один уровень. may be, may be…
 
типичная операция для g+ назначение видимости для поста: кнопка Share. можно добавлять из списка: круг1, круг2, …, мои круги, расширенные круги. как то не вырисовывается эффективная схема.
опять же неизвестно поведение g+ если я выбрал для поста "мои круги", а потом завел себе новый круг  и кого-то туда добавил.
в доступе фиксируется список кругов на момент Share? или список их пользователей? или буквально "все кто в текущий момент в кругах"? — это надо проверить эскрементально