У нас на проекте я отвечаю за базы головой. Поэтому последнее слово за мной :) Это правда не исключает дискуссий и меня можно переубедить, что многим удавалось. :) В целом, мы по умолчанию пытаемся разложить всё в таблички. Если не получается или видим, что это будет плохо — думаем. Критериев формальных конечно же нет. Формализм зло.
Hibernate работает медленнее, чем JDBC, но т.к. latency одной датабазной бизнес операции находится в нужных нам пределах, мы на этом не заморачиваемся. Если что-то начинает тормозить, то это разве что из-за некорректно сгенерённого запроса. В этом случае мы запрос просто переписываем руками.
Решение переходить или не переходить на JSON определялось трейдофами между компактностью хранения и удобством в разработке. Понятное дело, что где-то кто-то в этом трейдофе выбрал JSON. Вопрос был в том, подходит ли это нам.
Кстати немного про скорость. Меня могут закидать помидорами, но я не считаю что скорость это так уж важно. Важен throughput и latency не более чем ХХХ. Если для игры/для игрока скорость (latency) хорошие, то я не пытаюсь сделать ещё лучше. Я пытаюсь улучшить throughput и сделать так, чтобы эта latency выполнялась для бОльшего количества игроков.
Ну например hibernate медленнее, чем прямой jdbc. Но его использование позволяет экономить время и потратить его на более лучшее масштабирование. В некотором смысле тоже самое верно и для JSON.
1. немного хитрее, но, как я уже говорил, тут я лучше промолчу чтоб случайно не нарушить NDA.
2.
>> Один сервер игровой логики обслуживает одну локацию?
несколько.
>>На какое количество игроков расчитан этот сервер?
NDA
>>Обмениваются ли эти сервера друг с другом информацией? Какой именно? Или обмен происходит через базу?
Инфрмацией они не обмениваются. Между собой они взаимодействуют косвено, через общие сервисы.
3. Да, это проблема. Для подобных случаев мы не делаем распределённую транзакцию на 20 серверов, это слишком. Мы делаем кастомный алгоритм с eventual consistency. К счастью таких случаев мало.
Много маленьких это несколько десятков. Пока число не окончательное.
У нас и так в каждой базе много таблиц. Неудобно дробить каждую табличку ещё на несколько, а потом что-то думать как сделать между ними всеми foreign-key-и.
Я думаю, при наших объёмах, автоакуум будет успевать. Если нет, то «маленькая база» всё равно ведь будет гигабайта 2-3-4. Сделать полный вакуум всей базе это полчаса максимум. Так что всё будет хорошо :)
Мне подобный вопрос уже задавали в личке, так что отвечу и тут.
Мы не рассматриваем платные и проприетарные базы. Цена для нас имеет значение. А то можно было бы и oracle прикупить, он тоже умеет в NOSQL режиме работать, вот только стоить он будет больше, чем наша серверная ферма :)
— Меряли. Получалось что распределённая транзакция в несколько (3-5-10 в зависимости от кол-ва баз) раз медленнее чем обычная.
— Без них можно обойтись дизайном, так чтобы все взаимодействия были максимально локальными. Или иeventual consistency.
— Атомикос пробовал, не взлетел. Пришлось его выпилить и вместо него взять BTM. Атомикос не работал из коробки, пришлось ручками подписывать что-то в коде, а код там ужасен. Он даже не отформатирован. Кроме того там полно багла, и ему надо явно говорить «а вот эта транзакция будет распределённой и в ней будет 2 вот такие вот базы». BTM умеет сам это понимать. В целом Атомикос удалось заинтегрить за 2 недели, а потом я выпилил его нафиг и заменил на BTM за 2 дня.
Кто персистентней тот и главней :)
База у нас главная, конечно же. И схема, которую я показал, немного упрощена. Часть запросов на аватара идёт не с механики, где он бегает. Да и вообще у нас иногда бывают операции по аватарам, которые не загружены.
Вот только повторные проверки на сервере исполнения транзакций проводить всё равно надо. Представьте что вам подряд придёт две операции «поднять предмет», при том что у вас в сумке только 1 свободный слот. Гейм механика их пропустит, потому что на момент проверки второй операции она ещё не получила update от базы.
Hibernate работает медленнее, чем JDBC, но т.к. latency одной датабазной бизнес операции находится в нужных нам пределах, мы на этом не заморачиваемся. Если что-то начинает тормозить, то это разве что из-за некорректно сгенерённого запроса. В этом случае мы запрос просто переписываем руками.
Ну например hibernate медленнее, чем прямой jdbc. Но его использование позволяет экономить время и потратить его на более лучшее масштабирование. В некотором смысле тоже самое верно и для JSON.
corp.mail.ru/career/vacancies?dir=0&spec=0&prj=349&city=0
www.ozon.ru/context/detail/id/2354011/
www.ozon.ru/context/detail/id/6851442/
www.ozon.ru/context/detail/id/6573935/
highscalability.com
www.highload.ru/
2.
>> Один сервер игровой логики обслуживает одну локацию?
несколько.
>>На какое количество игроков расчитан этот сервер?
NDA
>>Обмениваются ли эти сервера друг с другом информацией? Какой именно? Или обмен происходит через базу?
Инфрмацией они не обмениваются. Между собой они взаимодействуют косвено, через общие сервисы.
3. Да, это проблема. Для подобных случаев мы не делаем распределённую транзакцию на 20 серверов, это слишком. Мы делаем кастомный алгоритм с eventual consistency. К счастью таких случаев мало.
У нас и так в каждой базе много таблиц. Неудобно дробить каждую табличку ещё на несколько, а потом что-то думать как сделать между ними всеми foreign-key-и.
Я думаю, при наших объёмах, автоакуум будет успевать. Если нет, то «маленькая база» всё равно ведь будет гигабайта 2-3-4. Сделать полный вакуум всей базе это полчаса максимум. Так что всё будет хорошо :)
Мы не рассматриваем платные и проприетарные базы. Цена для нас имеет значение. А то можно было бы и oracle прикупить, он тоже умеет в NOSQL режиме работать, вот только стоить он будет больше, чем наша серверная ферма :)
— Без них можно обойтись дизайном, так чтобы все взаимодействия были максимально локальными. Или иeventual consistency.
— Атомикос пробовал, не взлетел. Пришлось его выпилить и вместо него взять BTM. Атомикос не работал из коробки, пришлось ручками подписывать что-то в коде, а код там ужасен. Он даже не отформатирован. Кроме того там полно багла, и ему надо явно говорить «а вот эта транзакция будет распределённой и в ней будет 2 вот такие вот базы». BTM умеет сам это понимать. В целом Атомикос удалось заинтегрить за 2 недели, а потом я выпилил его нафиг и заменил на BTM за 2 дня.
База у нас главная, конечно же. И схема, которую я показал, немного упрощена. Часть запросов на аватара идёт не с механики, где он бегает. Да и вообще у нас иногда бывают операции по аватарам, которые не загружены.
Вот только повторные проверки на сервере исполнения транзакций проводить всё равно надо. Представьте что вам подряд придёт две операции «поднять предмет», при том что у вас в сумке только 1 свободный слот. Гейм механика их пропустит, потому что на момент проверки второй операции она ещё не получила update от базы.
Т.к. у нас не одна большая база, а много маленьких, то, если всё будет плохо, мы сможем делать вакуум фулл по очереди… по 5 баз за профилактику :)
Ответ есть, но я не знаю попадает ли он под NDA или нет, так что промолчу. Сорри :)