интересно откуда такая информация, если нет констрейнта, то удаление происходит практически так же как и UPDATE (иногда кстати даже быстрее), плюс выборки при использовании такого метода - логично будут идти медленнее (индексы то всё равно распухшие), если правильно указывать типы данных, и верно отправлять запросы, то никаких проблем с этим не будет.Вот смотри, я сделал к примеру с предметами так, у меня каждый предмет это отдельная строка в БД, там меняется идентификатор владельца, если передаю скажем эго, если я эго удаляю с инвентаря или выкидываю, просто меняется идентификатор владельца в БД на NULL, тем самым я не удаляю целую строку, просто меняю значение, так же легче БД. А когда рестарт делать буду, тогда все предметы с владельцем NULL очищу.
Кажется, вы уже хорошо подумали. Приоритетные изменения (большой эксп, ценный дроп) синхронизировать с БД сразу (об этом ниже). Менее приоритетное (расходники, соски, стрелы) - интервалами. Еще менее приоритетное (как вы заметили, тот же эквип) - синхронизировать при выходе или с бОльшими интервалами. Не забывать, что делиты дорогие, и использовать флаги или подобие.Не знал куда лучше написать, вот пишу тут, сейчас обдумываю как связать игрока и БД наиболее оптимизированным способом, к примеру игрок обновил макрос, или создал эго, стоит ли обновлять это сразу в БД или может сделать метод и запускать его при выходе персонажа с игры и тем методом обновлять все, что связанно с персонажем, но если сервер потухнет, тогда вся инфа собранная сервером будет обнулена до момента эго запуска, или может частично обновлять сразу важную инфу, а скажем если чел экипировал оружие, то такую можно не обновлять. Ну в общем все в таком ключе, если есть минутка, можем вместе подумать )))
Ну скажем, если я передаю предмет другому персонажу или выкидываю его, делаю 1 запрос в бд на замену владельца и готово, а если без этого, то мне нужно будет сначала удалить строчку с бд, а затем создать новую уже с другим владельцем.интересно откуда такая информация, если нет констрейнта, то удаление происходит практически так же как и UPDATE (иногда кстати даже быстрее), плюс выборки при использовании такого метода - логично будут идти медленнее (индексы то всё равно распухшие), если правильно указывать типы данных, и верно отправлять запросы, то никаких проблем с этим не будет.
как пример - стараться не хранить много полей с типом varchar (например, видел в некоторых сборках положение инвентаря указывалось с помощью varchar, а не enum).
База линейки - тупой набор циферок и имен персонажа, базовые методы реализованные уже во многих сборках более чем подходят (save при выходе + таймер, полная загрузка всего из базы данных в момент старта), забивать себе голову до появления явных проблем - так себе затея. Даже размер в 100мб (здесь я имею ввиду информацию о персонажах) - не всем покорится, говорить о бОльших размерах и не приходится.
Ну думаю, для предметов, а именно для манипуляций, продал, купил, выкинул, поднял делать сразу обнову в бд, предметы рассходников либо после выхода игрока с игры либо если игрок потерял соединение с сервером, то можно обновлять после повторного входа, а если он не заходит, то обновлять при рестарте, так же по макросам, по надетой, снятой броне, по экпе можно сделать, что-бы сохраняло скажем каждые 10-15% по отношению к уровню, скажем нужно 100 експ с 5 до 6 лвл, у тебя 5, нужно 100 експ, набил 10 експ пошло обновление, еще 10, получается 20 уже, еще обновил и т.д. так же по другим параметрам персонажа.Кажется, вы уже хорошо подумали. Приоритетные изменения (большой эксп, ценный дроп) синхронизировать с БД сразу (об этом ниже). Менее приоритетное (расходники, соски, стрелы) - интервалами. Еще менее приоритетное (как вы заметили, тот же эквип) - синхронизировать при выходе или с бОльшими интервалами. Не забывать, что делиты дорогие, и использовать флаги или подобие.
По поводу "синхронизировать сразу". Конечно же лучше всего батчить. Например, в конце текущего фрейма ранлупа. Хотя серверов L2 с тикрейтом и ранлупом в публичном доступе я еще не встречал (что странно, это сильно упрощает игровую логику и добавляет больше контроля).
Ну вот у меня к примеру для тех же стакуемых предметов давно уже сделано "ленивое" обновление, т.е. не апдейтит в бз каждое изменение количества к примеру, а вместо этого запускается таск, который сделает апдейт только через определенное время, за которое вполне количество этого предмета могло еще не раз поменяться и в итоге уже в бд уйдет итоговое значение на этот момент.Ну думаю, для предметов, а именно для манипуляций, продал, купил, выкинул, поднял делать сразу обнову в бд, предметы рассходников либо после выхода игрока с игры либо если игрок потерял соединение с сервером, то можно обновлять после повторного входа, а если он не заходит, то обновлять при рестарте, так же по макросам, по надетой, снятой броне, по экпе можно сделать, что-бы сохраняло скажем каждые 10-15% по отношению к уровню, скажем нужно 100 експ с 5 до 6 лвл, у тебя 5, нужно 100 експ, набил 10 експ пошло обновление, еще 10, получается 20 уже, еще обновил и т.д. так же по другим параметрам персонажа.
А как у тебя выполненно передача предмета другому чару? Удаляеш строку в бд и создаеш новую?Ну вот у меня к примеру для тех же стакуемых предметов давно уже сделано "ленивое" обновление, т.е. не апдейтит в бз каждое изменение количества к примеру, а вместо этого запускается таск, который сделает апдейт только через определенное время, за которое вполне количество этого предмета могло еще не раз поменяться и в итоге уже в бд уйдет итоговое значение на этот момент.
Подобное поведение очень значительно снижает количество запросов к бд, за счет уменьшения тех же апдейтов количества соул/спиритшотов например и т.п.
Лучшая оптимизация - это качественное железо, конфигурация базы. Всё другое, типо записывать все данные в каждую 10 секунду по вторникам не стоит внимание.сейчас обдумываю как связать игрока и БД наиболее оптимизированным способом
Я согласен тоже. Но хочу привести пример с L2J и около 300 ботов, все лучники. Так вот при таком тестировании там получилось то что предметы, поднимаемые игроками/ботами, негативно влияют на стабильность сервера. Запросы на сохранение данных просто постоянно тормозят потоки в Ява. Это просто к слову что одним железом не справишся, если сам сервер коряво написан.Лучшая оптимизация - это качественное железо, конфигурация базы. Всё другое, типо записывать все данные в каждую 10 секунду по вторникам не стоит внимание.
В твоем случае, я бы парился такими вопросами, если кол-во чтения/записи доходит до 4-5 тыс. в секунду.
Если предмет уже записан в БД, то нужно изменить objectId игрока в данных предметa (не имя, так как имя персонажа может изменяться). Нету смысла все-перезаписывать все заново, ведь изменился только один параметер (из многих) . Если посмотреть на то что может изменятся в предмете, там не так уж и много параметров, так вот из затачиваешь свои запросы к БД что-бы изменить толко иx.А как у тебя выполненно передача предмета другому чару? Удаляеш строку в бд и создаеш новую?
Да я тоже сделал только Id_owner перезаписывает.Если предмет уже записан в БД, то нужно изменить objectId игрока в данных предметa (не имя, так как имя персонажа может изменяться). Нету смысла все-перезаписывать все заново, ведь изменился только один параметер (из многих) . Если посмотреть на то что может изменятся в предмете, там не так уж и много параметров, так вот из затачиваешь свои запросы к БД что-бы изменить толко иx.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?