Эффективно спроектировать и управлять модулями пользовательских настроек

Question

Не знаю, если этот вопрос уже задан или нет. На самом деле я не знаю, что искать. Я спрашиваю в нужном месте?

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

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

Так что мой вопрос в том, есть ли лучший подход для этого?

Я не знаю, что я здесь чувствую, но я попытался объяснить свой вопрос.

Answer 1

Было бы много условий для оценки, это правильно. Но в заявлении SELECT вы можете легко составить все эти условия в статье WHERE, которая очень эффективна.

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

Answer 2

Данные Facebook хранятся в репозитории документов (Nosql), а эффективная индексация используется для быстрого поиска тегов и поиска. Такой подход поиска и хранения данных заметно отличается от хранения и поиска данных на основе реляционных баз данных.

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

Таким образом, в упрощенных выражениях данные хранятся и индексируются так, как Google индексирует сообщения, только разница в том, что данные также лежат с Facebook.

Связанные технологии: Bigdata, Mongodb, Apache Hadoop. И один из ведущих алгоритмов управления индексами и поиска - Lucene. Apache Elasticsearch - это удобный пакет вокруг Lucene.

Таким образом, facebook рассматривает эти критические меры безопасности как тег (на простом языке) и делает поиск в Google, и представляет вас в приятном интерфейсе, а не в качестве поисковой системы.

При настройке вашей системы вы можете использовать поиск elastics для ускорения поиска. Elasticsearch упрощает реализацию lucene. У него определенно будет определенная кривая обучения. Elasticsearch также можно использовать вместе с rdbms, в этом случае ваши данные сохраняются в базе данных, но индексы также поддерживаются для более быстрого поиска. Определенно, это будет дисковое пространство. Это позволяет иметь множество критериев, но все же позволяет быстрее получить результат.

Быстрый tutorial по эмалистике.

Answer 3

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

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

Это действительно не то, что вы могли бы найти с помощью простого решения, ключ здесь - планирование и планирование. нет ни одного правильного ответа.

Если ваше приложение довольно мало, вы можете просто реализовать его по-своему, тогда вы увидите, что можно обновить. Это в значительной степени ваш единственный путь. (Кстати, это то, что делает большинство статистических данных)

Желаю вам удачи.

Answer 4

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

The power of the graph

Это вывешен Facebook и объясняет, как они управление данными. Они используют и посредством применения graph theory и других сложных алгоритмов и передовые кэширования memoray и обработки данных, они могут эффективно управлять множеством пользовательских данных ..

но относительно Вашего вопроса:
Что бы дизайн базы данных и как им удается скрывать пользовательские обновления на временной шкале друзей, если он решил не показывать свои обновления на этой конкретной временной шкале друзей?

1. Я думаю, что этот пост даст вам некоторое представление о том, какие структуры БД Facebook имеет и то, что бы функциональность этого для каждого пользователя: Social Network Friends Relationship Database Design

2. Обычно скрытие обновлений пользователей на временной шкале ваших друзей, если вы не указали, что ваше обновление для этого конкретного друга управляется путем хранения значений в базе данных .. вы можете создать таблицу view_type в db, и это будет определять, какой вид пользователя может видеть, а затем выдавать where условие в ваших sqls на основе выбранного пользователем пользователя. Есть еще много способов справиться с этим. без обозначения даты хорошей структуры базы данных необходима для этого и планирования курса для хороших и эффективной базы данных является очень важной и строгой процедурой ..