Comments 62
Получается MongoDB это идеальная база данных для MMO?
{ user_id: 12,spells: [1,2,3,4,5], items_in_backpack: [11,21,22,33...], items_on_body: [121,221,222,233...]}
{ user_id: 12,spells: [1,2,3,4,5], items_in_backpack: [11,21,22,33...], items_on_body: [121,221,222,233...]}
все зависит, каким способом решаешь задачу, можно авторизацию на memcachedb замудрить так, что она будет медленнее мускульной.
если на мускуле эта задача будет решаться быстрее- то я буду только рад.
если на мускуле эта задача будет решаться быстрее- то я буду только рад.
А вообще я благодарен идеи — на досуге надо проверить на memcachedb.
но достоинство MongoDb в возможности репликации.
но достоинство MongoDb в возможности репликации.
«цепочки для 300к пользователей» = цепочки, в которой от А до B — 300к человек?
Юмор оценен, держи 5
Я к тому, что 0,3 — 0,5 секунд на построение цепочки это очень много, ведь такие цепочки нужно строить в реальном времени. Вы совсем не описали, как производили измерения. Если A и B в первом-втором круге друг у друга — цепочка должна получаться мгновенно.
это время затраченное на поиск за 5-м-6-м кругом,
конечно смешно искать в цепочке во втором круге.
Несомненно, если A и B в первом-втором круге друг у друга — цепочка получается мгновенно.
весь поик осуществляется онлайн, есть место для оптимизации кода. На тестовом сервере цепочка получается почти мгновенно.
конечно смешно искать в цепочке во втором круге.
Несомненно, если A и B в первом-втором круге друг у друга — цепочка получается мгновенно.
весь поик осуществляется онлайн, есть место для оптимизации кода. На тестовом сервере цепочка получается почти мгновенно.
Как хорошо, что начали писать статьи про объектные БД!) побольше б таких статей.*ушел писать доклад*
А можно вписать тот момент, где мы увидим все таки, что key-value сливают монго? Вы про какие именно key-value? Memcache, Redis, Cassandra, Riak? И главное — в чем слив? Попрошу memcache в качестве примера не приводить, это не БД, это кеш все таки.
Еще бы хотелось увидеть не рыбу поста, а такой пост, чтобы его можно было понять. Я вот ваш алгоритм не понял, по нему выходит, что мы сравниваем первые круги, потом вторые круги, потом третьи :) А если id у одного в третьем, а другого во втором?
Вот еще, их текста:
Еще бы хотелось увидеть не рыбу поста, а такой пост, чтобы его можно было понять. Я вот ваш алгоритм не понял, по нему выходит, что мы сравниваем первые круги, потом вторые круги, потом третьи :) А если id у одного в третьем, а другого во втором?
Вот еще, их текста:
Попробую объяснить. Если ни A ни B не «состоят между собой в дружбе,» то мы сравниваем вначале первые «круги» друзей пользователей A и B. Если в их первых кругах есть хотя бы один общий id (то есть id, который встречается и в первом круге пользователя A и в первом круге пользователя B) — это означает, они соеденены через одного пользователя. (Возможно таких пользователей несколько, но это, думаю, не так важно.)
Если ни одного общего id в их первых кругах нет, то нужно сравнить «вторые круги». Что такое второй круг друзей пользователя A? Это все друзья пользователя A, и все друзья его друзей. То есть, если у A есть друг Q, у которого есть друг W, то во втором кругу пользоватля A (массив ffriends в статье) будут id как пользователя Q так и пользователя W.
Сравнивая последовательно круги их друзей можно найти объеденяющий набор пользователей, через которых они между собой «знакомы» (пользователь A знает пользователя Q, который знает пользоватля W, который знает пользователя B)
Общая идея понятна? Если нет, то могу попробовать объяснить по другому. Но тогда желательны конкретные вопросы — что именно не понятно.
Если ни одного общего id в их первых кругах нет, то нужно сравнить «вторые круги». Что такое второй круг друзей пользователя A? Это все друзья пользователя A, и все друзья его друзей. То есть, если у A есть друг Q, у которого есть друг W, то во втором кругу пользоватля A (массив ffriends в статье) будут id как пользователя Q так и пользователя W.
Сравнивая последовательно круги их друзей можно найти объеденяющий набор пользователей, через которых они между собой «знакомы» (пользователь A знает пользователя Q, который знает пользоватля W, который знает пользователя B)
Общая идея понятна? Если нет, то могу попробовать объяснить по другому. Но тогда желательны конкретные вопросы — что именно не понятно.
Проблема не в том, что я не понимаю алгоритма, проблема в том, что вы так торопились его опубликовать, что не сделали вычитку. Из вашего текста алгоритм выходит очень кривым, но если конечно догадываться, то можно ваш и не читать.
И главный вопрос — при чем тут MongoDB? Вы считаете, что в key-value базах нельзя хранить списки? Да даже множества можно, Redis вот например. Для друзей операции со множествами это самое очевидное решение, так что на Redis это вообще все решается элементарно.
И главный вопрос — при чем тут MongoDB? Вы считаете, что в key-value базах нельзя хранить списки? Да даже множества можно, Redis вот например. Для друзей операции со множествами это самое очевидное решение, так что на Redis это вообще все решается элементарно.
А по-моему, проблема в том, что вы так торопились обличить автора, что даже не глянули что он это не я :)
Насчёт _моего_ мнения по поводу применения mongodb к этой проблеме: думаю практически любое key-value хранилище справилось не хуже бы. Думаю прийдёт автор и объяснит почему было выбрано mongo, и почему он считает что другое хранилище было бы хуже.
Насчёт _моего_ мнения по поводу применения mongodb к этой проблеме: думаю практически любое key-value хранилище справилось не хуже бы. Думаю прийдёт автор и объяснит почему было выбрано mongo, и почему он считает что другое хранилище было бы хуже.
Вы хорошо мимикрировали, и явно не поняли моего комментария, иначе не стали бы мне рассказывать этот алгоритм. Ведь там была явная просьба привести топик в нормальный вид.
Прокрутить страницу вверх довольно просто. Проще, чем понять, что [Я вот ваш алгоритм не понял, по нему выходит, что мы сравниваем первые круги, потом вторые круги, потом третьи :) А если id у одного в третьем, а другого во втором?] это фраза в комментарии просто так, и само по себе содержание вас не интересует.
Мне жаль, что я потратил на объяснение время, и это оказалось не нужно.
Мне жаль, что я потратил на объяснение время, и это оказалось не нужно.
tasman спасибо за поддержку
согл: практически любое key-value хранилище справилось не хуже бы
выбор за MongoDB:
— масштабируемость
— возможность репликации
— планируем использовать для других данных
согл: практически любое key-value хранилище справилось не хуже бы
выбор за MongoDB:
— масштабируемость
— возможность репликации
— планируем использовать для других данных
В редисе вполне можно хранить списки, но эта задача явно не для редиса. Можно использовать для этой задачи вполне можно использовать и key/value,
хранить всю информацию в том же JSON,
ключ user_id_12
lданные { friends: [1,2,3,4,5], ffriends: [11,21,22,33...], fffriends: [121,221,222,233...]}
если использовать списки редися — то дубет очень накладно.
будет время, попробую это на memcachedb, это я озвучил в своем втором посте этой темы.
хранить всю информацию в том же JSON,
ключ user_id_12
lданные { friends: [1,2,3,4,5], ffriends: [11,21,22,33...], fffriends: [121,221,222,233...]}
если использовать списки редися — то дубет очень накладно.
будет время, попробую это на memcachedb, это я озвучил в своем втором посте этой темы.
То есть не для редиски, я для мемкеша вполне? О мой бог!
ну я про А ты про Бэ…
можно и в редиске, но в том же формате, что и в memcachedb
по этому выигрыша абсолютно ни какого.
списки редиса здесь никаким боком не засунешь, а если и засунешь, то только огребешь лишнюю головную боль и тормоза.
замечу что мемкеш и memcachedb — это все же разные системы хранения данных.
можно и в редиске, но в том же формате, что и в memcachedb
по этому выигрыша абсолютно ни какого.
списки редиса здесь никаким боком не засунешь, а если и засунешь, то только огребешь лишнюю головную боль и тормоза.
замечу что мемкеш и memcachedb — это все же разные системы хранения данных.
Вот еще, из текста:
[проверяем, нет ли данных id в массивах friends.]
У меня вопрос — откуда взялись те id, которые мы тут проверяем?
[проверяем, нет ли данных id в массивах friends.]
У меня вопрос — откуда взялись те id, которые мы тут проверяем?
[Делаем запрос на профиль А и В (А — это профиль нашей анкеты — его данные уже могут как-то использоваться, B — это профиль просматриваемого пользователя). Нужно построить цепочку друзей.
проверяем, нет ли данных id в массивах friends.]
Вполне логично предположить, что проверяемые id принадлежат пользователям A и B.
проверяем, нет ли данных id в массивах friends.]
Вполне логично предположить, что проверяемые id принадлежат пользователям A и B.
Вполне. Но из текста это должно следовать, а вы ведь даже не удосужились перечитать, и поправить, и это печалит меня.
Ответил вам выше. Я не автор, я просто пытался внести ясность, думая, что вам интересен алгоритм. А вам оказалось интересно погнобить автора за сумбурный топик.
Итог — мне надоело открывать пост в надежде прочесть пост профессионала, со светлой головой, в которой сидят упорядоченные мысли, да на интересную тему. А там блин как всегда.
{ user_id: 12, friends: [1,2,3,4,5], ffriends: [11,21,22,33...], fffriends: [121,221,222,233...]}
Что-то не понял, разве эти данные нельзя хранить в таблице обычной реляционной БД (на пример MySQL) в строковых полях? В чём прикол объектной БД тут?
Что-то не понял, разве эти данные нельзя хранить в таблице обычной реляционной БД (на пример MySQL) в строковых полях? В чём прикол объектной БД тут?
зачем же в строковых, у postgresql есть массивы например www.postgresql.org/docs/8.4/interactive/arrays.html на которые, кстати, можно класть индексы, и производить с ними всякие операции, в том числе overlap www.postgresql.org/docs/8.4/interactive/functions-array.html
ну, это я так. но мне тоже показалось, что преимущества mongodb в статье совсем не освещены. да и при чем тут вообще бд, когда описывается достаточно абстрактный алгоритм?
ну, это я так. но мне тоже показалось, что преимущества mongodb в статье совсем не освещены. да и при чем тут вообще бд, когда описывается достаточно абстрактный алгоритм?
преимущество в скорости извлечения
А вы меряли?
В posgresql массивы можно пересечь на базе, не гоняя данные по сети. Тем более — третьи круги. Для пользователя, у которого всего лишь 50 контактов третий насчитывает уже тысячи (и чем выше связность сети — тем больше)
В posgresql массивы можно пересечь на базе, не гоняя данные по сети. Тем более — третьи круги. Для пользователя, у которого всего лишь 50 контактов третий насчитывает уже тысячи (и чем выше связность сети — тем больше)
с постргесом нет, с мускулем мерил
сколько займет время пересечения?
один такой умник (архитектор tradebox), чтоб не гонять данные по сети, решил большую часть логики впихнуть в БД в ввиде хранимых процедур. В результате когда вышли на реальную нагрузку база просела, мощный сервер просто не стал справляться.
так что надо соизмерять что можно делать при нагрузках, а что нельзя.
один такой умник (архитектор tradebox), чтоб не гонять данные по сети, решил большую часть логики впихнуть в БД в ввиде хранимых процедур. В результате когда вышли на реальную нагрузку база просела, мощный сервер просто не стал справляться.
так что надо соизмерять что можно делать при нагрузках, а что нельзя.
«база просела» и «использовать хранимые процедуры» — вещи никак не связанные. с таким же успехом можно написать запросы, которые не попадут в индекс и база так же просядет, так что это не аргумент.
вот эти патчи dklab.ru/lib/dklab_postgresql_patch/ делают пересечение очень быстро.
вот эти патчи dklab.ru/lib/dklab_postgresql_patch/ делают пересечение очень быстро.
конечно, я не спорю — ты хороший специалист по постгесу
но, очевидно, с высоконагруженными системами ты не работал.
но, очевидно, с высоконагруженными системами ты не работал.
lol. вообще, я разрабатываю тот самый мой круг, который ты упомянул в суе в своем посте.
супер!
есть у кого проконсультироваться!
так вы там на постгресе делаете пересечения?
а как дела обстят с шардингом? или всю «дружбу» сливают в одну центральную БД.
у меня почему такая архитектура: потому что все профили пользователей разбиты по мускульным шардам, а всю дружбу решили загнать в монго.
есть у кого проконсультироваться!
так вы там на постгресе делаете пересечения?
а как дела обстят с шардингом? или всю «дружбу» сливают в одну центральную БД.
у меня почему такая архитектура: потому что все профили пользователей разбиты по мускульным шардам, а всю дружбу решили загнать в монго.
пересекаем в базе, да.
а по-поводу дружбы — почему не держать друзей в тех же шардах? ведь списки друзей всё равно дублируются для каждого пользователя — список друзей можно строить по тому же шарду, где и храниться профиль.
да, при этом не получится строить список за 5-м звеном. но, честно говоря, 5й круг не несет уже вообще никакого business value — там уже совсем незнакомые люди.
а по-поводу дружбы — почему не держать друзей в тех же шардах? ведь списки друзей всё равно дублируются для каждого пользователя — список друзей можно строить по тому же шарду, где и храниться профиль.
да, при этом не получится строить список за 5-м звеном. но, честно говоря, 5й круг не несет уже вообще никакого business value — там уже совсем незнакомые люди.
у нас дружба шла отдельной таблицой, которая шардится по user_id. таким образом — был построен только первый круг. Построение второго круга оказалась довольно-таки трудоемкая процедура, по этому решили вынести всех «друзей» в центральное хранилище.
но, с другой стороны, всякому будет интересно, через каких друзей он связан с Дмитрием Котеровым.
но, с другой стороны, всякому будет интересно, через каких друзей он связан с Дмитрием Котеровым.
на чем основано это мнение?
вот тут например недавно был пост, показывающий, что скорость селекта монгодб по большому счету примерно равен mysql.
вот тут например недавно был пост, показывающий, что скорость селекта монгодб по большому счету примерно равен mysql.
можно, прикол в скорости извлечения.
сколько приблизительно запросов надо сделать на создание цепочки?
сколько приблизительно запросов надо сделать на создание цепочки?
Автор, хоть шаги и расписаны подробно, но все равно в них трудно ориентироваться, не хватает иллюстраций и примеров что ли. Может быть лучше кодом? :) Это конечно ИМХО, но код легче понять когда излагаются подобные мысли.
Пост рассказывает о том, как сделать нечто на MongoDB, но, к сожалению, не дает никакого сравнения с альтернативами и преимуществах MongoDB хотя бы на примере данной задачи. Увы, складывается впечатление, что сравнение разных технологий проведено и не было. Жаль, это ведь как раз то, что всем хотелось бы узнать, тем более что сама тема очень интересная.
согл, чтоб сделать сравнение, надо тоже самое реализовать на другой технологии. Я сейчас это отлажываю. По крайней мере преимущество с RMBD — в скорости извлечения.
Как я замечал выше, возможно использовть на memcachedb (или редис но первое надежнее и быстрее)
но мы еще планируем Mongodb под др задачи.
Как я замечал выше, возможно использовть на memcachedb (или редис но первое надежнее и быстрее)
но мы еще планируем Mongodb под др задачи.
Вопрос может быть немного отвлеченный, но скажите вы пользовались map-reduce в mongodb? Если да расскажите ваши впечатления. Спасибо.
по вопросу выбора языка:
выбран C++, так как скриптовые языки требуют много памяти под выделяемые хешмассивы.
2-круг есть пользователи более 400 друзей, третий от 1200 друзей. Хотелось бы все вычисления делать быстро в онлайн.
приложение реализовано как fcgi модуль, проксируется через nginx
выбран C++, так как скриптовые языки требуют много памяти под выделяемые хешмассивы.
2-круг есть пользователи более 400 друзей, третий от 1200 друзей. Хотелось бы все вычисления делать быстро в онлайн.
приложение реализовано как fcgi модуль, проксируется через nginx
Приходите на DEVCONF 2010 — пофлудим… мы планируем собрать все noSQL БД!
Мы продлили прием заявок на доклады… до 12 апреля…
Уже 215 участников успели зарегистрироваться…
devconf.ru/offers/
Мы продлили прием заявок на доклады… до 12 апреля…
Уже 215 участников успели зарегистрироваться…
devconf.ru/offers/
Sign up to leave a comment.
Chain Friends by MongoDB