|
|
|
mysql |
|
|
Reality Audit |
23.7.2017, 10:09
|
Neophyte
Сообщений: 12
Регистрация: 16.7.2017 Группа: Пользователи Наличность: 0
Пользователь №: 18.540
Возраст: 30
|
Цитата(Aimed @ 22.7.2017, 22:53) Гипотетическая задача была дана, - сделать топ500. Дальше можно самому додумать. Конечно нет. Открываешь/закрываешь новое подключение к бд вручную, как и везде обычно.
Предположим, делаем топ500 (пробежался по сайтам шардов, чтобы заценить что именно туда выносят) Почти все нужная инфа есть на чаре в дефолтных полях (киллы/карма) или в тегах (опыт или лвл, например) или по соседству (на аккаунте). Самый зверский способ - писать в базу каждый раз при изменении атрибута. Если онлайн небольшой, можно не запариваться и так и сделать. Если сервер упал или был откат - при старте можно перекалькулировать Компромисс - писать в какое-то время всё целиком и привязать это, например, к сейву. Засейвились, открыли коннекцию к базе, пробежались по чарам/аккаунтам, скинули в базу, закрыли коннект.
|
|
|
|
Aimed |
24.7.2017, 0:02
|
Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012 Группа: Пользователи Наличность: 8768
Пользователь №: 15.607
|
Цитата(Soteric @ 23.7.2017, 12:54) (IMG: style_emoticons/default/blink.gif) Даже двухнедельный junior разработчик понимает, что новый коннект это ненужные накладные расходы и старается их избежать. Оно и видно что джуниор и статья 2010 года. Во первых, на сегодняшний день апликации стараются делать мультипоточными и для работы с БД это делается как я описал выше - с очередями по producer/consumer принципу. Либо через всякие async/await/Task. Потому что работа прозводится в отдельном потоке, те пару мс или даже секунд для создания соединения роли не играют, гораздо важнее что бы не было утечек. (Внимание, потенциально опасная тема для холивара!) Во вторых, singleton шаблон, это устаревший шаблон который как можно быстрее желательно забыть и не вспоминать. Для современных, мультипоточных апликаций желательно создавать новые обьекты и клонировать все это дело на крайний случай, что-бы не было веселых ситуаций с race conditions или всяких проблем от того что понавставлено 100500 локов и в коде все это выглядит как настоящий ад, а каждое изменения такого кода приводит к потецинальному дед локу.\ В третьих, обычно если со Сферы что-то загоняют в БД, этой БД желательно находится на той-же самой машине и создание соединения там будет длиться 0 времени. Ежели БД на другом сервере где-то в сети, лучше просто работать через AEXECUTE/AQUERY. Цитата(Reality Audit @ 23.7.2017, 9:09) Предположим, делаем топ500 (пробежался по сайтам шардов, чтобы заценить что именно туда выносят) Почти все нужная инфа есть на чаре в дефолтных полях (киллы/карма) или в тегах (опыт или лвл, например) или по соседству (на аккаунте). Самый зверский способ - писать в базу каждый раз при изменении атрибута. Если онлайн небольшой, можно не запариваться и так и сделать. Если сервер упал или был откат - при старте можно перекалькулировать
Компромисс - писать в какое-то время всё целиком и привязать это, например, к сейву. Засейвились, открыли коннекцию к базе, пробежались по чарам/аккаунтам, скинули в базу, закрыли коннект.
Хм, да, забыл что может сервер упасть и случиться откат. Смешно вышло, потмоу что сам не так давно занимался системой сейвов для РанУО в реальном времени с сохранением изменений в базу на каждом тике в главном цикле )) На самом деле это не зверский способ, примерно так на сегодняшний день сохраняют данные современные ММОРПГ. Для УО, с её сейвами в файл с остановлением сервера правда лучше после сейва брать все это дело. А потому что речь идёт о Сфере, в которой нет возможности писать мультипоточный код, лучше все-таки сделать отдельную программу и парсить файл с сейвами, что-бы не мешать Сфере работать и не удлиннять сейвы и не создавать лаги для игроков. Соберая данные для БД из всех плееров по какому-то таймеру раз в х времени может записать неактуальные данные в базу если сервер откатится, а так-же может создать лаги, потому что все это будет происходить в главном треде Сферы.
|
|
|
|
Aimed |
24.7.2017, 0:45
|
Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012 Группа: Пользователи Наличность: 8768
Пользователь №: 15.607
|
Цитата(Llirik @ 23.7.2017, 14:15) У меня коннект открывается всего лишь 1 раз при старте сферы и я работаю с базой и нигде её не закрываю. Я думаю 1 коннект это нормально. И закроется он сам.
Да правильнее было бы всё закрывать руками, но, как же сборка мусора и т.д. т.е. программа сама может закрыть.
А не дрочить каждый раз DB.CONNECT DB.CLOSE, как дятел.
Мой ответ: "Без разницы!" с 1 постоянно открытым коннектом я думаю ничего страшного не случиться и к тому же он убьётся при закрытии сферы.
Твой ответ ничего не значит потому что ты не смотрел в исходники Сферы. Ты лишь предполагаешь. Я только что посмотрел на исходники из мастер ветки на гитхабе ( ХЗ что там в старых исходниках 56б ). Там вызов закрытия соединения только в деструкторе обьекста CDataBase ( который выполняется при закрытии сервера )и различные закрытия при попытках оперировать с БД, но при этом БД не отвечает. Сферовци сами реализовали обьект соединения с БД как синглтон. Так-же нельзя иметь одновременно соединения с двумя разными БД. При краше Сферы или переполнении стека ( бесконечный цикл ), у тебя будет утечка одного коннекта в самой БД уже. (Можно ещё как вариант глянуть в самой MySQL?(если речь о ней), есть ли там какой-то уборщик соединений которые не использовалишь дольше чем х времени и просто удалять их, освобождая тред. Наверняка должно что-то такое быть. На крайняк сделать свой скрипт и поставить на выполнение по расписанию) "А не дрочить каждый раз DB.CONNECT DB.CLOSE, как дятел" Зачем, если это можно мопестить в одну функцию и вызывать её постоянно, передавая ей в аргументы то что тебе нужно? В принципе у Сферы нормальная стабильность, если руки на месте. Держать коннект постоянно открытым можно, но я не могу назвать это нормальной практикой (IMG: style_emoticons/default/smile.gif)
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|