Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Amazon DynamoDB vs Couchbase vs ... для async multiplayer игры (2 стр)

Amazon DynamoDB vs Couchbase vs ... для async multiplayer игры (2 стр)

Поделиться
Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 Следующая

kFkПостоялецwww16 мая 201713:03#15
9К720
> Альтернатива простая
Да уж, простецкая)) Хорошо, тогда вопрос в другой плоскости - с 13+ лет опыта в С++/... и геймдеве, но минимальным опытом в server-side (был работающий сервер для подобной игры на Node.JS+Couchbase, но не уверен насколько там все было корректно) - реально ли самому за пару месяцев освоить эту тему и реализовать хорошее решение для коммерческого проекта (без учета написания игровой логики)? Или нереально и сразу надо искать отдельного спеца под это?
graphITПостоялецwww16 мая 201713:55#16
Есть конкретные требования то? Что нужно хранить, что читать, какая нагрузка ожидается, нужна ли масштабируемость.
Почему SQL база не подходит?
kFkПостоялецwww16 мая 201714:16#17
graphIT
Требования как у игры аналога Clash of Clans. Хранить данные юзера, всякие там таблицы рекордов, инфу для матчмейкинга и прочее.
Нагрузка не самая минимальная, т.к. предполагается рекламный бюджет, т.е. аудитория на старте какая никакая, а будет. Но в rps точно сказать не могу. Масштабируемость нужна, естественно горизонтальная.
SQL, как понимаю, завязан на четкую структуру. В этом проекте есть элемент research, т.е. многое может меняться в процессе разработки и нужна гибкость. (Плюс.. почему те же supercell и подобные используют nosql? Ответ правильный не знаю, но наверное в этом есть смысл).
9К720Участникwww16 мая 201715:32#18
kFk
> SQL, как понимаю, завязан на четкую структуру. В этом проекте есть элемент
> research, т.е. многое может меняться в процессе разработки и нужна гибкость.
Ну бери и меняй. В процессе разработки.

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

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

kFk
> Плюс.. почему те же supercell и подобные используют nosql?
Возможно потому что у них были какие-то критерии. Ты их до сих пор сформулировать не можешь.

> знаю, но наверное в этом есть смысл
Если все в окно выпрыгнут, ты тоже выпрыгнешь?
Странно слышать подобные вещи от человека с 13-летним опытом. Это реально 13 летний коммерческий опыт, или "я начал изучать программирование в 10 лет и сейчас я 23-летний синьор с 13-летним опытом"? Судя по ответам и по вопросам второе.

>Нагрузка не самая минимальная, т.к. предполагается рекламный бюджет, т.е. аудитория на старте какая никакая, а будет.
>Но в rps точно сказать не могу. Масштабируемость нужна, естественно горизонтальная.
О как. Тогда тебе надо кого поопытнее искать для сервера. Сам ты не сделаешь этого, твой 13 летний опыт на крестах, даже если он реален, здесь совершенно нерелевантен.

Впрочем, с вероятностью 99,9 процентов никакой аудитории не будет.

Правка: 16 мая 2017 15:32

kvakvsПостоялецwww16 мая 201716:33#19
Morpheuz
> > 4. В остальное время доступ к БД и диску запрещается. Работаем только через
> > память.
> Это сколько игроков онлайн нужно иметь, что бы так извращаться с оптимизацией?
Не вижу извращения. Матчмейкинг работает с теми юзерами кто уже онлайн, а раз он онлайн значит его можно найти в своей памяти или в памяти на соседнем сервере кластера. Посылаешь туда запрос вот и всё, одна миллисекунда ответ готов. Диск трогать дорого, сотни миллисекунд. Код остаётся простым.

> 10К - так, тогда проще сервачек помощнее взять.
> При том, что оно и так будет в кэше. Благо сейчас сервера не дорогие с 128 ГБ ОЗУ
Производительность не измеряется размерами ОЗУ.
Я прикасался к серверам с 2 ТБ. ОЗУ. Но быстро они работают не поэтому, а потому что диск трогают редко.

graphITПостоялецwww16 мая 201716:37#20
kFk
> Масштабируемость нужна, естественно горизонтальная.
Нужно понимать что у масштабируемости довольно высокая цена, горизонтальная масштабируемость означает распределенную  систему, а распределенная noSQL система это CAP теорема с необходимостью выбора какого-то одного аспекта между консистентностью и доступностью, чтоб сделать этот выбор нужно понимать требования. Плюс довольно дорогая разработка и поддержка, так как, скорее всего, фильтрации, агрегации, соблюдение целостности данных придется реализовывать на уровне самого приложения.


kFk
> SQL, как понимаю, завязан на четкую структуру. В этом проекте есть элемент
> research, т.е. многое может меняться в процессе разработки и нужна гибкость.
Как написал 9К720 структура так или иначе будет. На мой взгляд, явную схему бд проще контролировать особенно когда проект уже на продакшене, плюс для SQL баз есть проверенные временем технологии миграции.
Schemaless бд  удобны на этапе прототипирования.

Но не все nosql базы schemaless, и подкидывают сложностей на этапе проектирования больше чем sql.
По моему опыту с Cassandra (подозреваю что для DynamoDB это тоже актуально) нужно не только знать структуру данных, но и хорошо понимать, как они физически будут хранится, сколько места занимать, и, самое главное, на этапе проектирования нужно знать какие запросы на чтение данных должны поддерживаться. Это самый сложный этап и не всегда реализуемый.

DynamoDB, Couchbase и другие noSql имеют очень узкую сферу применения, и нужно действительно понимать почему именно эта база и какие у нее узкие места, что она может, а главное что не может.
Я бы выбор noSQL  начал с ответа, почему SQL не подходит.

kvakvsПостоялецwww16 мая 201716:41#21
Масштабирование БД очень дорогая операция.
Не нужно этого делать заранее.
Если жахаться с кластерами БД без понимания сути, то за три года не останется времени игру написать )
Или можно без данных легко остаться.
Или тормозить будет.
Понимать надо, что делается и зачем, а не потому что услышал модный термин где-то и решил себе сделать так же.
MiraПостоялецwww16 мая 201718:02#22
мне лично реляционность понравилась. удалил персонажа, и все связанные с ним записи удалились
правда не знаю на сколько это оверхедно для базы.
а в остальном да, не суть. один фиг из базы только загружаются игровые сущности, и в ней сохраняются при выходе (или ответственные моменты).
в прочем определенная нагрузка на базу все же есть. каждый новый предмет в мире у меня создает новую запись в БД с своим уникальным индексом, а предметы могут исчезать и появляться пачками

Правка: 16 мая 2017 18:02

kvakvsПостоялецwww16 мая 201720:39#23
Mira
> мне лично реляционность понравилась. удалил персонажа, и все связанные с ним
> записи удалились
В серьёзной ММО это так не работает.
Удалил персонажа - тикет в службу поддержки - Аааа я что-то нажал и всё пропало, рыдают братья, рыдает мама, рыдает бабушка и папа сидит пиво не может пить от печали, верните мне мой аккаунт.
Извините у нас реляционная БД поэтому при удалении персонажа всё удалилось и вернуть нельзя )
MiraПостоялецwww16 мая 201721:35#24
kvakvs
в серьезных ММО так то на удаление дается прилично времени, и за это врмя можно еще передумать и отменить.
кроме того есть логи, и бекапы на край. а вообще , если ты за 1-2 недели не прочухал что у тебя персонаж на удалении и не снял оттуда - значит какие претензии то?
batmentПостоялецwww16 мая 201722:49#25
Если такой вопрос возникает, лучше взять PostgreSQL, и использовать его, пока не станет узким местом. Он в последние годы старается быть качественным многофункциональным комбайном, поэтому и NoSQL там какой-то можно сделать, если сильно припрет.

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

batmentПостоялецwww16 мая 201723:02#26
Ну и вообще, на первое время лучше весь бэкенд наговнокодить за неделю на Django REST Framework или еще чем-то простом и вообще о нем забыть, пока не перестанет хватать микроинстанса на амазоне. Иначе есть риск потратить все силы на воображаемые проблемы, до того как появятся реальные.
BishopПостоялецwww17 мая 20171:28#27
kvakvs
> Диск трогать дорого, сотни миллисекунд.
Разве для БД под нагрузкой ещё кто-то HDD использует? Просто нормальный SSD это ~50мкс.

graphIT
> Нужно понимать что у масштабируемости довольно высокая цена, горизонтальная
> масштабируемость означает распределенную систему, а распределенная noSQL
> система это CAP теорема с необходимостью выбора какого-то одного аспекта между
> консистентностью и доступностью, чтоб сделать этот выбор нужно понимать
> требования. Плюс довольно дорогая разработка и поддержка, так как, скорее
> всего, фильтрации, агрегации, соблюдение целостности данных придется
> реализовывать на уровне самого приложения.
Кстати очень умные слова. Если задачу можно решить одним сервером, пусть и ценой 8-ми сокетного сервера и хорошего кода на С, то стоит так и сделать. В распределённые системы лезть только тогда, когда выбора уже 100% нет.

Mira
> правда не знаю на сколько это оверхедно для базы.
А ведь именно с этого надо и начинать.

9К720Участникwww17 мая 20171:32#28
Mira
> мне лично реляционность понравилась. удалил персонажа, и все связанные с ним
> записи удалились
> правда не знаю на сколько это оверхедно для базы.
Ни на сколько.  Потому что так не делается, delete cascade на все дерево никогда не делается, я ни  разу не видел. Удаление сущностей и связей это очень простая операция, и закодит ее любой джун за полдня, ты не там преимущества ищешь.

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

Правка: 17 мая 2017 1:33

9К720Участникwww17 мая 20171:36#29
Bishop
> Если задачу можно решить одним сервером, пусть и ценой 8-ми сокетного сервера и
> хорошего кода на С, то стоит так и сделать.
Если есть понимание что расширяться когда нибудь придется, то надо брать не самый быстрый С, а то на чем удобно будет писать распределенную систему - джаву, скалу, эрланг и т.д.

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

Правка: 17 мая 2017 1:39

Страницы: 1 2 3 Следующая

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр