Вопрос Работа с бд

[johndoe]

Valdemar написал(а):

Что за редиска?
Чтобы контекст понимать)

Нажмите для раскрытия...

Redis - The Real-time Data Platform

Developers love Redis. Unlock the full potential of the Redis database with Redis Enterprise and start building blazing fast apps.

redis.io

А что это такое - уже можно у гпт поспрашивать

 

[aspidemon]

johndoe написал(а):

Брат, давай по порядку)

1. Редис изначально был в бОльшей степени придуман для кэширования запросов (чтобы каждый раз не делать выгрузку из БД - мы результат записываем туда и уже при повторном запросе достаём оттуда данные и отдаем в ответ). Разумеется, распинаться про инвалидацию кэша, ttl и прочего я не буду

2. Кейс с инвентарём. Что тебе мешает при загрузке персонажа выгружать его предметы в инвентарь в память твоего приложения (сервера)? И уже при открытии инвентаря (хоть по тысячу раз в секунду) - отдавать предметы из памяти сервера (которые тебе отдадутся моментально), нежели каждый запуск инвентаря бегать в БД (или редис, кек) и просить предметы? Тут же следом еще один вопрос: что тебе мешает каждое изменение состояния инвентаря пушить в стор на фронт? Чтобы вообще никого не ждать и просто показывать инвентарь?

И снова я вижу сильные пробелы в знаниях, когда говорят что под проект в гта (де факто классическое клиент-серверное приложение) монго (документно-ориентированная) лучше чем реляционная (кек сука )

И вот подобные ответы и аргументы будут всегда, пока люди не поймут достаточно очевидную истину. База данных это про:

Нужны данные?

Что-то поменялось?

Все.

@Inoi где моя плашка "биг хик кодыр" ?

upd: Повторюсь - если в вашем моде вы каждое изменение состояния обновляете в бд моментально (при онлайне 5 человек - ок, при онлайне в 500 - пиздец), то возможно вы что-то делаете неправильно

Нажмите для раскрытия...

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

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

 

[🐝 ubees]

Valdemar написал(а):

Что за редиска?
Чтобы контекст понимать)

Нажмите для раскрытия...

 

[johndoe]

aspidemon написал(а):

Редиска же сохраняет данные на диске в виде файлов

Нажмите для раскрытия...

Друг, редис почему такой быстрый и ахуенный? Потому что он записывает ключи не в физическую память, а в ОЗУ. Отсюда и скорость) БДшки все пишут в условные файлы на жёсткий диск, редис - в ОЗУ

 

[aspidemon]

johndoe написал(а):

Друг, редис почему такой быстрый и ахуенный? Потому что он записывает ключи не в физическую память, а в ОЗУ. Отсюда и скорость) БДшки все пишут в условные файлы на жёсткий диск, редис - в ОЗУ

Нажмите для раскрытия...

Да, но в нем есть возможность делать backup информации на диск, если б читал, что я дальше писал, а не вырывал из контекста, то понял бы

 

[aspidemon]

johndoe написал(а):

Друг, редис почему такой быстрый и ахуенный? Потому что он записывает ключи не в физическую память, а в ОЗУ. Отсюда и скорость) БДшки все пишут в условные файлы на жёсткий диск, редис - в ОЗУ

Нажмите для раскрытия...

Можешь чекнуть видосик, там тебе все нормально обьяснят -
P.S. Специально нашел для тебя!

 

[X-Clusiv]

Valdemar написал(а):

Что за редиска?
Чтобы контекст понимать)

Нажмите для раскрытия...

Redis
На первых парах тебе это не обязательно изучать.
Не распыляй внимание. Почитай про SQL. Лучше с практикой.
Запусти чистый сервачек(рейджа, раз мы тут), через команды сервера сделай авторизацию на сервере(самую элементарную).
Авторизация звучит наверное грозно для тебя, но на самом деле все просто.
При заходе игрока на сервер пиши ему в чат(что-то типо - "Для авторизации введите /auth login password")
В чат вводишь данные на стороне сервера обрабатываешь.
По сути сервер рейджа это приложение на nodeJS(не только, есть и на C# но не будем отвлекаться) поизучаешь заодно и его(js);
Практика ключ к познанию.

 

[Inoi]

johndoe написал(а):

Брат, давай по порядку)

1. Редис изначально был в бОльшей степени придуман для кэширования запросов (чтобы каждый раз не делать выгрузку из БД - мы результат записываем туда и уже при повторном запросе достаём оттуда данные и отдаем в ответ). Разумеется, распинаться про инвалидацию кэша, ttl и прочего я не буду

2. Кейс с инвентарём. Что тебе мешает при загрузке персонажа выгружать его предметы в инвентарь в память твоего приложения (сервера)? И уже при открытии инвентаря (хоть по тысячу раз в секунду) - отдавать предметы из памяти сервера (которые тебе отдадутся моментально), нежели каждый запуск инвентаря бегать в БД (или редис, кек) и просить предметы? Тут же следом еще один вопрос: что тебе мешает каждое изменение состояния инвентаря пушить в стор на фронт? Чтобы вообще никого не ждать и просто показывать инвентарь?

И снова я вижу сильные пробелы в знаниях, когда говорят что под проект в гта (де факто классическое клиент-серверное приложение) монго (документно-ориентированная) лучше чем реляционная (кек сука )

И вот подобные ответы и аргументы будут всегда, пока люди не поймут достаточно очевидную истину. База данных это про:

Нужны данные?

Что-то поменялось?

Все.

@Inoi где моя плашка "биг хик кодыр" ?

upd: Повторюсь - если в вашем моде вы каждое изменение состояния обновляете в бд моментально (при онлайне 5 человек - ок, при онлайне в 500 - пиздец), то возможно вы что-то делаете неправильно

Нажмите для раскрытия...

базу говоришь тоже немного в прикеке с монго-идей
звучит как омегалул

редиска еще очередями управлять кайф.

 

[akudinov28]

aspidemon написал(а):

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

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

Нажмите для раскрытия...

По поводу потери данных в случае краша - автосохранение в базу коллекции раз в n минут. В случае краша у тебя откатится состояние за последние, например, 5 минут. Не страшно. Все крупные проекты именно так и работают.

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

 

[johndoe]

Inoi написал(а):

редиска еще очередями управлять кайф.

Нажмите для раскрытия...

Я же сказал, что в бОльшей части это кэш) С доп. приколами может быть и очередь, да)

 

[aspidemon]

johndoe написал(а):

Я же сказал, что в бОльшей части это кэш) С доп. приколами может быть и очередь, да)

Нажмите для раскрытия...

Ну, вообще-то это NoSQL база данных, просто её используют для кэша в основном, но она спокойно может быть основной базой данных

 

[aspidemon]

akudinov28 написал(а):

По поводу потери данных в случае краша - автосохранение в базу коллекции раз в n минут. В случае краша у тебя откатится состояние за последние, например, 5 минут. Не страшно. Все крупные проекты именно так и работают.

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

Нажмите для раскрытия...

Когда у тебя 500 онлайна - запись такого количества данных через n время приведет к отказу бд, в пример могу привести мод Diamond, там такая же схема использовалась, много проблем из-за этого

Дюпы реальны, в особенности если учитывать, что он пишет, о том, что он хочет сохранить инвентарь на стороне клиента "что б грузилось быстрее" (Читай внимательнее, там буквально так написано):


P.S. В любом случае, редиска будет очень полезна как для SQL так и для NoSQL

 

[johndoe]

aspidemon написал(а):

Ну, вообще-то это NoSQL база данных, просто её используют для кэша в основном, но она спокойно может быть основной базой данных

Нажмите для раскрытия...

Ну так и трактор это по факту тоже техника. Но по городу кататься на работу на нём и по магазинам будет не очень комфортно) Мы с тобой как будто о разных вещах говорим.

Если прям пиздец как банально спуститься, то redis по факту жсовский Map, где есть ключ - значение. Использовать её как хранилище для сервера - шиза, хоть и будет работать (я не спорю), но зачем, а главное нахуя использовать его как основное хранилище

 

[johndoe]

aspidemon написал(а):

Когда у тебя 500 онлайна - запись такого количества данных через n время приведет к отказу бд, в пример могу привести мод Diamond, там такая же схема использовалась, много проблем из-за этого

Дюпы реальны, в особенности если учитывать, что он пишет, о том, что он хочет сохранить инвентарь на стороне клиента "что б грузилось быстрее" (Читай внимательнее, там буквально так написано):
Посмотреть вложение 22148

P.S. В любом случае, редиска будет очень полезна как для SQL так и для NoSQL

Нажмите для раскрытия...

Брат, если ты перед тем, как ЧТО ЛИБО сделать от команды клиента не валидируешь на сервере - мои соболезнования. Есть ебейшее и золотое правило: НИКОГДА НЕ ВЕРЬ КЛИЕНТУ.

Хочет переместить айтем - делаешь внутренние проверки. Ты не знаешь что вызвал это действие: обычный игрок или Вася из 2Г класса, скачавший две минуты назад экзекьютер

Я видел кейсы когда инвентарь был онли на клиентской части, так и ебучий даймонд у которого очень много логики было на клиенте. Это не говорит о том, что "вот, я видел такой кейс, это хуево, идем хранить данные в редис". Это говорит о том, что даймонд писал ебанат, который почему то решил что инъектнуться в клиент очень сложно.