Модель диаграммы Neo4j для социальной сети

Question

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

ПРИМЕЧАНИЕ. Обновления статуса и узлы активности/отношения связаны списками - с новейшими элементами, постоянно размещаемыми в верхней части список.

1. Связанные списки позволяют для генерации подачи новостей, но могут быть сотни записей для каждого пользователя - Я полагаю, предел условие не является достаточным, даже если данные в порядке убывания по дате. Должен ли я иметь отдельный связанный список, который будет содержать только самые последние 10 обновлений статуса/активности) и постоянно заменять голову в этом списке, чтобы получить лучшую подачу фида активности, или один список будет правильно отсортирован и выполнить задание (с предельная оговорка)

2. Эти узлы имеют свойства (данные json с контентом, идентификаторы и т. д.) - как здесь действуют здесь «глобальные» индексы, так что я могу найти, например, пользователей, которые любят Depeche Mode, не дожидаясь ожидания продолжительность жизни для результатов? Я знаю, как добавить узел в индекс, просто интересно, не хватает ли здесь части изображения.

3. Безопасность - логины и пароли .. Я бы предположил, что база данных графов может их хранить, но я предположим, что это угроза безопасности на данный момент - было бы лучше сохранить это в postgres и т. д.?

4. Как вы бы улучшить эту модель для масштабирования? Представьте себе, что на это ушло 20 миллионов пользователей.

5. Представьте, что 40 миллионов пользователей - что случилось с этой моделью, когда дело доходит до масштабируемости?

Answer 1

Часть 1.

Вы можете написать Cypher или Gremlin запросы, которые делают то, что вы хотите. Помните, что вы можете перемещаться вперед и назад по краям. Учитывая пользователя, всегда должно быть относительно постоянное время, чтобы поднять последние десять вещей, которые они сделали.

Часть 2.

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

Часть 3.

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

часть 4/5.

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

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

Когда у вас есть сто тысяч, беспокойтесь о следующем миллионе.

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

Пока у вас есть не менее 0,1% пользователей/томов, на которые вы хотите масштабировать, это умственная мастурбация, чтобы попытаться задать вопросы о масштабировании до определенного размера.