програмирование покера

[in4core]

А есть для чего ещё уместны сокет-серверы?

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

[mikhailk]

Redis – это не совсем БД в том понимании. Или ты не сравнивал mongo vs redis, а просто константировал что тебе понравилось?

Да. Не сравнивал.

Надо понимать, что где использовать. Schemaless DB хороши для тех мест, где эта самая схема мешает. Она удобна для быстрого прототипирования

Я за свою жизнь видел неподъемную кучу баз данных (застал еще ADABAS, не путать с адидасом , и прочие дореляционные СУБД ). Могу сказать точно, для простых приложений документо-ориентированная база данных - это просто песня. У меня сейчас три коллекции с JSON-объектами (BSON, естественно, но не суть), которые описывают весь основной функционал. В реляционной СУБД у меня уже было бы минимум пятнадцать таблиц и я бы уже во всю джойнил их направо и налево.

[Sync]

Сообщение от mikhailk

Могу сказать точно, для простых приложений документо-ориентированная база данных - это просто песня. У меня сейчас три коллекции с JSON-объектами (BSON, естественно, но не суть), которые описывают весь основной функционал. В реляционной СУБД у меня уже было бы минимум пятнадцать таблиц и я бы уже во всю джойнил их направо и налево.

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

[mikhailk]

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

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

Впрочем, что касается непосредственно MongoDB, есть хорошая книжка Кайл Бэнкер "MongoDB в действии". Там все прекрасно написано и про плюсы и про минусы.

[caseyryan]

Для чатов каких нить, для мультиплееров простых игр...

Ок, а для сложных тогда что?

[Psycho Tiger]

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

Ну возьми не дистинкт, а джоины. Я про другое.

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

Ну, я бы не рисковал. В монгу можно записать неправильно, и это порой очень беда. Но вообще, если работаешь на чем-то вроде RoR, т.е. в работе используется ORM (я про MDD, когда работаешь с моделями, а не с какими-то-там-таблицами), то можешь попробовать. В случае чего, полностью переехать на другую СУБД будет делом пары часов.

[mikhailk]

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

Вот очень простой пример с профилем пользователя в какой-нубудь ферме или ходилке-бродилке:

{
  "name": "Pedro",
  "xp": "1200",
  "itemsInBag": [
     {"slot":1, "catalogID": "11", "count": "5"},
     {"slot":2, "catalogID": "12", "count": "10"},
     {"slot":3, "catalogID": "13", "count": "5"}
  ]
}

В реляционной БД тут две очевидные таблицы (есть, конечно, вариант с сериализацией содержимого itemsInBag и записью в текстовое поле, но в большинстве случаев это именно две таблицы). Допустим, по итогам действия перса ему начислилось 30xp и израсходовались 3 айтема из первого слота. Что мы имеем в реляционной БД? Два апдейта, причем, в определенных условиях еще и объединенных транзакцией. А в документарной БД - одна атомарная операция с документом, причем, его не надо таскать из базы целиком, а достаточно просто указать, какие части документа и как изменить. Т.е., даже на таком банальном примере видно, что количество обращений к БД, как минимум, разное. А если профиль собран, скажем, не из двух, а из пяти таблиц? Например, у пользователя еще есть подарки, производства, скиллы, ученики-последователи, привилегии и пр.?

Совершенно очевидно, что если проектировать документарную БД по правилам реляционной (1 таблица = 1 коллекция), то это будет алес капут и эффективно работать не сможет. Поэтому для документарных баз, например, принципиален сознательный отказ от 100%-ой нормализации (что, конечно, плохо ложится в голову после работы с реляционными БД). Есть еще некоторое количество отличий, все описано в той книге, которую я выше указал.

Сорри за оффтоп.

[Psycho Tiger]

Согласен. Я что-то с головой ушел в веб и подзабыл, что речь может идти и про игрули )

[in4core]

Ок, а для сложных тогда что?

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

[Котяра]

Многопоточные Медиа серверы

А они по нуль-пространственному телепатическому коридору работают..
Ага.