Предложения по масштабируемой архитектуре для решения проблемы больших данных

Question

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

Приложение имеет объект User.Идея состоит в том, что каждый раз, когда новый пользователь присоединяется к системе, он оценивает «полезность» для всех остальных, основываясь на ряде факторов.Точно так же любой другой пользователь в системе оценивает его / ее.

Однако меня беспокоит значение масштабируемости этого подхода.Например, если 10 000 пользователей присоединяются к системе, мы говорим о 10000 ^ 2 вычислениях, которые будут сохранены в базе данных.Это 100 миллионов записей, что явно становится проблематичным как с точки зрения времени, необходимого для расчета этих рейтингов, так и с точки зрения хранения этого в базе данных.

Таким образом, я ищу помощь / вдохновение:)

Мой опыт работы в java, и я рассматривал hadoop / map-lower как возможный способ параллельного выполнения вычислений, однако я действительно не уверен, применима ли эта проблема к Map Reduce илиЧто касается того, что является лучшим подходом в целом.

Итак, я полагаю, что в моем запросе есть две специфические части ..

1) Чтобы выполнить фактические вычисления, я должен сделать это параллельно, т.е.хороший подход к решению этой проблемы

2) Для хранения ранжирований то, что я должен использовать ... это стандартная реляционная база данных, плохая идея, т. е. ... это не подходит для MySQL.... могу ли я взглянуть на что-то вроде Cassandra, HBase или другого решения NoSQL?

Любая помощь / идеи приветствуются.

ура, Брайан

Answer 1

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

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

Answer 2

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

Answer 3

Я бы предложил хранить только «реальные» значения (введенные пользователем). Таким образом, пользователи ранжируют других пользователей, которые имеют для них ценность, а все остальные считаются «бесполезными»;). Следовательно, вы можете хранить, возможно, пару сотен значений для каждого пользователя. Я предполагаю, что вы не собираетесь заставлять каждого нового пользователя просматривать весь список других пользователей и оценивать их по отдельности, верно?

Вы также можете сократить требования к пространству, создав двунаправленные ассоциации, в которых хранятся оценки обоих пользователей (одна запись связывает пользователя A с пользователем F и отмечает, что A оценивает F как 5, а F оценивает A как 3). Примерно вдвое сокращает ваши требования к пространству, но это все еще много записей. Кроме того, вам понадобятся индексы для обоих пользовательских ключей, поскольку вам придется искать оба, чтобы найти все записи для одного пользователя.