Идея исправления и улучшения ID Factory

Теги:
 
+
-
edit
 

Balancer

администратор
★★★★★
Есть идея по сабжу.

- Отказываемся от хранения цифровых идентификаторов в БД вообще.

- Принадлежность вещей, петов и т.п. игрокам прописывается прямо не цифровым индексом, а именем игрока (напомню, имена у нас уникальные, скорость поиска по индексированной строке в mysql не ниже, чем поиск по индексированным числовым значениям).

- Идентификаторы кланов задаются также их именами

- Идентифиакторы раздаются с минимального значения при каждом старте сервера каждому новому создаваемому объекту и в БД не хранятся

Плюсы:
- не будет больше бардака с ID
- не потребуется сжатие БД
- проще будет работать визуально с БД (скажем, сразу видишь, какому игроку принадлежит предмет)

Минусы:
- Усложняется переименование игрока (апдейт всех таблиц) и кланов
- Требуется переписывание структуры нынешних БД

...

Жду отзывов от других разработчиков. Не хотелось бы ради одного этого эксперимента опять "отслаиваться" в L2J Balancer, а внесение столь серьёзной доработки в L2JRU или l2j.sf требует согласования с другими участниками :)
 
+
-
edit
 

zabbix

разработчик OpenWorlds
Ну у NCSofta вполне все с цифровыми идентификаторами работает :-) Хотя, я подозреваю, что к успеху этой схемы cached приложил свою руку...

а вообще не ясно, почему принадлежность айтема/клана/пета к игроку, определяемая числовым идентификатором не устраивает?

вообще, я так понимаю, не-l2j-сервер просто постоянно дефрагментирует свою базу - если предмет грохнули/исчез - количество предметов с этим id становится равным нулю, а уж выборку по одному полю сделать - не накладное занятие; в этом я не уверен, но по моему все именно так там.

Ну например, грокаем предмет с id = 1212

UPDATE items SET count = 0, owner_id=0 WHERE object_id = 1212;

Теперь создали какой-то предмет:

SELECT object_id FROM items WHERE owner_id = 0 AND count = 0;

вот тебе и слот для предмета свободный
Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.  
+
-
edit
 

Balancer

администратор
★★★★★
Я не знаю, как сделано на официале. Вполне м.б. что там два набора цифровых идентификаторов. Один - для идентификации в БД, другой - в игре. Это тот же вариант, что я предложил, дополненный цифровым индексом каждого объекта БД.

По скорости ничем не лучше варианта со строковыми именами, немного сложнее в обработке, проще - в переименовании (но оно на официале не практикуется, как я понимаю).

Твой вариант с выборкой первых незанятых индексов не проходит
1. Далеко не все объекты имеют счётчик их числа (петы, игроки, кланы). Хотя тут можно ввести доп. поле
2. Таблиц больше, чем одна. Придётся обходить их все. Полудюжина запросов на каждое изменение предметов. На загруженном сервере - очень накладно.
3. При интенсивной игре в таблицах будет гораздо больше пустых записей, чем занятых, что замедлит выборки. Вместе с третьим пунктом это может создать заметную нагрузку на сервер.

И, в любом случае, из-за пункта 1, потребуется модификация имеющихся БД. Так что лучше уже мой вариант вводить :D
 
+
-
edit
 

zabbix

разработчик OpenWorlds
К объектам типа "клан", "пет" и т.п. подход тот же - если овнера пета/лидера клана нету(равны 0), значит объект свободен; количество тут можно просто игнорировать.

и ведь при изменении предметов только items дергать надо?



Ну вобщем теперь ясно, почему офф сервер общается с базой через cached
Там данные вообще(на глаз) где-то раз в 20 минут в базу сливаются, а так он все
в себе держит, и сделать пару тысяч запросов к бд выходит не проблема — и серверу всеравно,
ибо он этой базы не видит и не знает что к чему, и кешу;
Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.  
+
-
edit
 

Balancer

администратор
★★★★★
Если работать только с items, то полезут дубли. Завёл новый item_object_id, а такой же, скажем, в кланах есть :)

А они должны быть уникальными на весь игровой мир.
 
+
-
edit
 

zabbix

разработчик OpenWorlds
это кривая архитектура 8-)
точнее, кривая архитектура
зачем все в одну кучу мешать?

клан это клан, пет это пет? айтем это айтем, общего между ними ничего нету абсолютно
для клана поле pledge_id, чтоб определять принадлежность игроков к клану, и owner_id,чтоб найти лидера
Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.  
+
-
edit
 

_BoBkA_

втянувшийся
по моему хорошая идея :) но пока не внедрят в L2jRU или к Балансеру и при етом необкатают и не скажут что воркает я в KOMBOPACK не буду сувати :)
Если что-то не так, то ищи проблему в себе... http://SkySoft.nm.ru http://la2bobka.nm.ru  

Serge
Serge2

новичок
IMO - Из плюсов вижу только визуализацию базюки (без которой вполне можно обойтись) А гемора реализовывать данную фичу будет много... Я-бы оставил IdFactory...
...I'm very responsible person, then something goes wrong I'm response.  
+
-
edit
 

zabbix

разработчик OpenWorlds
да, только idfactory вечно сюрпризы преподносит, прям как ВинМЕ - дернешь один мешочек с г..., а взрываются десять лежащих рядом
Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.  
+
-
edit
 

dampil

опытный
Тока если будете что-то делать, давайте обойдёмся без падения сервера на 1 - 2 месяца, а то у меня уже представление, что больше ломаете чем делаете. :)
DampiL SpellHowler 70+ (KillMag) Ally:Juctice [MAD's] Увлечение, хоби: KILL BALOVNI  
+
-
edit
 

Balancer

администратор
★★★★★
zabbix:
клан это клан, пет это пет? айтем это айтем, общего между ними ничего нету абсолютно
 


Скажи это разработчикам Lineage2. Клиент требует уникальных идентификаторов для каждого игрового объекта.
 
+
-
edit
 

Balancer

администратор
★★★★★
Serge:
Я-бы оставил IdFactory...
 


Это самое отвратительное, что есть в нынешнем сервере :D
 
+
-
edit
 

zabbix

разработчик OpenWorlds
sux
но тоже упростить можно, правда, пока не ясно как
Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.  

Serge
Serge2

новичок
zabbix:
да, только idfactory вечно сюрпризы преподносит
 
Ну как говорится - в семье не без урода ;-)
...I'm very responsible person, then something goes wrong I'm response.  
+
-
edit
 

zabbix

разработчик OpenWorlds
ок, а если сделать пул свободных идентификаторов?
например, тред с низким приоритетом каждые минуту-две-три-десять(нужное подчеркнуть) дергает базу в поисках свободных идентов и кидает их в фифо?
Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.  

awarm

разработчик l2j-сервера

Ну на офе все сделано просто - там за всем сам SQL следит, благо в нем все для этого есть, в отличии от MySQL.
А вообще меня эти ID убивали с самого начала. Для CSV файлов они еще нужны были, а тут... :( да и сама структура базы дикая :(
Теперь по сути:
1. Отказываться от цифровых идентификаторов считаю неразумным - очень сильно разрастется объем базы данных.
2. Вместо ручной генерации ID, нужно переходить на identity, с переодичской реорганизацией. Реорганизацию организовать с ручным запуском.
3. Для контроля целостности использовать связи. таким образом, пока на какой-то из объектов будет существовать ссылка, удалить этот объект будет нельзя. использовать это для конроля при удалении записей.
Могу дальше напридумывать много плюсов, хотя минусы тоже есть.
Но плюсов больше.
Я - ЗА.
 

awarm

разработчик l2j-сервера

Хотя если требуется вообще уникальный id для каждого объекта... ну тогда ой..
Разве что вводить какие-нибудь префиксы, суффиксы и т.п., что тоже гемор еще тот... :(
 

Serge
Serge2

новичок
awarm:
Хотя если требуется вообще уникальный id для каждого объекта... ну тогда ой..
 

Balancer:
- Идентифиакторы раздаются с минимального значения при каждом старте сервера каждому новому создаваемому объекту и в БД не хранятся
 
Да нет, не "ой" ж-)
...I'm very responsible person, then something goes wrong I'm response.  

awarm

разработчик l2j-сервера

Ну если внутриигровые генерить по порядку, а в базе использовать нормальные свои, тогда можно. ;)
 
+
-
edit
 

_BoBkA_

втянувшийся
awarm:
Ну на офе все сделано просто - там за всем сам SQL следит, благо в нем все для этого есть, в отличии от MySQL.
А вообще меня эти ID убивали с самого начала. Для CSV файлов они еще нужны были, а тут... :( да и сама структура базы дикая :(
Теперь по сути:
1. Отказываться от цифровых идентификаторов считаю неразумным - очень сильно разрастется объем базы данных.
2. Вместо ручной генерации ID, нужно переходить на identity, с переодичской реорганизацией. Реорганизацию организовать с ручным запуском.
3. Для контроля целостности использовать связи. таким образом, пока на какой-то из объектов будет существовать ссылка, удалить этот объект будет нельзя. использовать это для конроля при удалении записей.
Могу дальше напридумывать много плюсов, хотя минусы тоже есть.
Но плюсов больше.
Я - ЗА.
 


я за с самого начала :) но пока необкатают не поставлю :)
и ещё - оффтоп :

что то вроде геодаты планируется ?

и ещё - оффтоп :

Дайте мне готовую пхп страницу для отображения колличества игроков он-лине и топа
чтобы не на сервере стояло а на хосте но инфу брали бы с моей ДБ ? надеюсь это возможно :( посто в php не шарю хоть стреляйся :( помогите ради бога
Если что-то не так, то ищи проблему в себе... http://SkySoft.nm.ru http://la2bobka.nm.ru  

Serge
Serge2

новичок
awarm:
а в базе использовать нормальные свои
 
А свои это какие? держать bigint-овые поля с autoencrement-ом? сдается мне что это не вариант...
...I'm very responsible person, then something goes wrong I'm response.  
+
-
edit
 

zabbix

разработчик OpenWorlds
на офе идент объекта - int 4 ;-)
Речи тайна Йоды магистра раскрыта - на Форте программист просто старый оказывается он.  

awarm

разработчик l2j-сервера

Serge:
awarm:
а в базе использовать нормальные свои
 
А свои это какие? держать bigint-овые поля с autoencrement-ом? сдается мне что это не вариант...
 

Ты считаешь, что текстовые поля будут лучше???
у меня есть проекты из 30-40 таблиц по нескольку миллионов записей в каждой и постояной ротацией записей. раз в неделю делается реорганизация, и все ОК. Хотя в принципе можно делать и раз в пару месяцев. А то, что мы имеем сейчас это просто жуть какая-то :(
 

Serge
Serge2

новичок
awarm:
Ты считаешь, что текстовые поля будут лучше???
 
Не! Я не об этом! Речь шла о внутриигровых и датабазных идентификаторах (не о привязки чего-либо к чарактеру) с внутриигровыми понятно - простой каунтер на спавн, вопрос какой способ генерации IDшников выбрать для базы... авто-инкрементное поле либо фича а-ля той-же IdFactory. авто-инкремент для таких вещей как-раз предназначен, единственное что настораживает это как-раз процесс "реорганизаци" + "alter table xxx auto_increment=zz" этих ID-шников...
...I'm very responsible person, then something goes wrong I'm response.  
RU NetImperia #17.08.2005 00:04
+
-
edit
 

NetImperia

новичок
Balancer:
Есть идея по сабжу.
- Отказываемся от хранения цифровых идентификаторов в БД вообще.
 

Я еще не до конца разобрался в структуре сервака. Сейчас его изучаю. Поэтому прощу прощения если че.
Выресовывается вопрос.
Как используются идентификаторы пользователей. Это что что-бы получить пользователя, идет обращение к ID в базе. А затем по этому ID ищится ник и работа по никам производится?
Если так то это вообще берд полный. Как я понимаю в идеале нужно получать ID, login, ID клана, Имя клана и ник персонажа тогда когда игрок входит на сервер. И всегда его помнить пока он не выйдет.
Тогда не нужно будет думать что использовать для доступа. Можно использовать как ник так и ID. Если конечно его нужно тут использовать. А не читать из базы его каждый раз.

Как не крути, а по ID доступ в разы быстрее если по этому полю построен индекс. Так как тогда все это число помещается в индексе если конечно оно в разумных переделах.А если делать поиск по строкам. То тогда это медленее будет. Потому что тогда в индексе не будет отиндексировано все слово ,а только часть его. И поиск будет медлеенее.

Balancer:
- Принадлежность вещей, петов и т.п. игрокам прописывается прямо не цифровым индексом, а именем игрока
 

Если сервер помнит ID пользователя. То тогда об этом вообще думать не стоит.

Balancer:
(напомню, имена у нас уникальные, скорость поиска по индексированной строке в mysql не ниже, чем поиск по индексированным числовым значениям).
 

Заблуждаешся. Медленее. На маленьких базах этого не будет заметно. Но когда записей много тогда это очень заметно.

Balancer:
- Идентификаторы кланов задаются также их именами
 

Об этом выше писал.

Balancer:
- Идентифиакторы раздаются с минимального значения при каждом старте сервера каждому новому создаваемому объекту и в БД не хранятся
 

А как тогда обращаться к мобам или каким-то вещам в квестах?
Например какой-нить квест пойди найди то-то. И дотронься. Это так для примера.

Balancer:
Плюсы:
- не будет больше бардака с ID
 

Бардак с ID потому что надо делать ID Auto Increment. Тогда будет все ок.

Balancer:
- не потребуется сжатие БД
 

В этом я сомневаюсь. Все равно придется. Например после удаления пользователя.

Balancer:
- проще будет работать визуально с БД (скажем, сразу видишь, какому игроку принадлежит предмет)
 

Пользователи и админы вообще не должны лазать в базу что-бы произвести какие-то манипуляции. Все эти манипуляции должны делаться через интерфейсы в игре либо WEB интерфейсы.

Balancer:
Минусы:
- Усложняется переименование игрока (апдейт всех таблиц) и кланов
- Требуется переписывание структуры нынешних БД

...

Жду отзывов от других разработчиков. Не хотелось бы ради одного этого эксперимента опять "отслаиваться" в L2J Balancer, а внесение столь серьёзной доработки в L2JRU или l2j.sf требует согласования с другими участниками :)
 


Я не считаю что это действиельно необходимо. Как таковое нужно просто помнить ID и все. И этого делать не придется.
Тяжела жизнь программиста: радость находки своего бага всегда омрачает осознание собственной тупости...  

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru