MySQL, XML или встроенные функции аккаунта

[Mr_Bob]

Здравствуйте. Подскажите пожалуйста, что лучше всего из перечисленного выбрать для хранения игровых аккаунтов? И еще, возможно такое, что если в таблице большое количество строк (в моем случае больше 30 000) значительно увеличивается скорость выполнения запроса, потому как в SAMP было именно так.

[lil Toady]

Стандартная система лучше любой собственной.

[Evgeni_Degerev]

Стандартная система лучше любой собственной.

У меня в моде сделана полная имплементация всех функций данной системы и полная интеграция с ней.

За основу брал доработанный ini-враппер, кроме того включил ряд возможностей миграции ( в/с sqlite )

и добавил туда жалкое подобие структурированных запросов

Стандартную систему перестал использовать после 3х-кратной

полной потери данных. Воспроизвести проблему не удалось.

[lil Toady]

Стандартная система лучше любой собственной.

У меня в моде сделана полная имплементация всех функций данной системы и полная интеграция с ней.

За основу брал доработанный ini-враппер, кроме того включил ряд возможностей миграции ( в/с sqlite )

и добавил туда жалкое подобие структурированных запросов

Ты конечно молодец, но:

• ini по определению не может быть быстрее базы данных
  
• твою систему не могут использовать сторонние ресурсы
  
• вся система прав построена на стандартной системе аккаунтов
  
• http ресурсы так же работают только со стандартной системой

И проблемы с потерей данных были до того как мы перешли на sqlite

P.S: В новой админке есть удобный менеджер аккаунтов и прав, со всякими сторонними он работать не будет.

[MX_Master]

Насчет аккаунтов мой совет простой. Статичные данные хранить в статичных обычных файлах, динамичные и часто меняющиеся данные - в базе данных. И организация структуры самой БД тоже важна.

Второй хороший совет - не хранить в одной таблице, будь то мускул или sqlite, большое кол-во записей. Стандартная система как раз-таки на sqlit'e. И этот sqlite даже мне умудрился попортить нервы, когда в БД стало много данных. Так что все опыты показывают, sqlite лучше использовать на мелких объемах данных или по крайней мере юзать не одну БД для всего, а несколько. У мускула все понятно - все таблицы хранятся в отдельных файлах + файлы для хранения индексов и чего то еще, а у sqlite - все в одном файле лежит!!

Я кстати делал запрос в баг трекере на добавление функционала создания/правки своих sqlite баз, вместо использования общих internal/registry.db. И думаю, с правами доступа к файлам БДшек какого-то ресурса не будет проблем, если их правильно указать для нужных ресурсов. Но это так, отступление.

• Но есть небольшая хитрость для любой системы хранения аккаунтов, которая позволит убрать эту перегрузку серва при работе с большими БД или файловыми системами.
  Обычно, для получения/изменения данных аккаунта мы должны иметь какой-то один ИДент игрока, допустим, это будет его ник в нижнем регистре (логин). Смысл в том, чтобы разбить общую БД аккаунтов (файлы, хмл или бд) на части по какому-то принципу. В данном случае - по первому символу в нике игрока. Если быть точнее, будем использовать код первого символа в нике для разбиения общей БД на части. Если система файловая - то создаем подпапки с именами кодов символа, если это БД мускул, то создаем таблицы с именами всех возможных кодов. Пример - 33,34,35,36,... Далее в скриптах, перед тем как обратится к системе хранения, будем сначала узнавать код первого символа в нике (логине) в нижнем регистре и только потом обращаться к нужной папке/таблице с запросами или поиском. Обычно, код первого символа ника (логина) можно сохранить при входе в аккаунт, чтобы не транжирить этим делом ресурсы серва снова.
  Какой мы получаем позитивный эффект от такого разделения? Выигрыш в скорости и больше стабильности, а при использовании файлов - нет этого огромного кол-ва файлов акков в 1 папке, они разделены по нашим группам.

если кто-то знает еще более хитрые хитрости, пишите

[Evgeni_Degerev]

Возможно я был не так понят, попробую внести ясность:

- система может работать полностью независимо, интеграция

создана только для совместимости с ресурсом admin, ему подобными и системой привелегий MTA.

ini по определению не может быть быстрее базы данных

Разумеется, однако данные аккаунта полностью загружаются в память при первом обращении к нему, далее

идет простое обращение к таблице, аккаунт освобождается если игрок вышел с сервера.

Недостатком является то, что если к аккаунту было обращение в тот момент, когда в него не был залогинен игрок

он не будет выгружен, а только синхронизирован с диском по таймауту.

тесты эквивалентов getAccountData / setAccountData , вызываемых удаленным скриптом показывают

скорость в 2-3 раза быстрее ( чтение в 2, запись в 3 ... если не ошибаюсь )

http ресурсы так же работают только со стандартной системой

у меня расчет на то что http будет использоваться только администраторами, в противном случае

привелегия подключения через http будет доступна всем игрокам.

С момента создания моей системы было несколько коммитов улучшающих

встроенную систему аккаунтов, однако переходить не неё обратно не вижу смысла.

ИМХО можно улучшить сущствующую систему, создав аналог executeSQLQuery для internal.db, конечно, сделав

его разрешенным только для группы .

Т.к бы не помешали бы в ней запросы поиска/обновления групп данных, а также BEGIN,END,COMMIT и т.д.

Насчет аккаунтов мой совет .....

если кто-то знает еще более хитрые хитрости, пишите

Истину глаголишь...

Есть одна глупая идейка для встроенной БД - можно создавать таблицу вида

< TEXT ACCOUNTNAME, TEXT SERIAL, TEXT REGISTER_IP, BOOL AUTOLOGIN, BLOD ACCOUNT_DATA >

и хранить в ACCOUNT_DATA все данные игрока в виде JSON, чтобы не увеличивать количество записей в таблице.

Не помню точно как выглядит структура internal.db, да и нутром чую что не все так гладко как написал.. но а вдруг?

PS: Прошу строго не судить за слишком явный бред.

PSS: очень нехватает spoiler или offtop bb-кода.

Добавлено:

Опять же, то что я сказал выше. Твой метод не будет быстрее. Меньше записей совсем не значит что будет быстрее.

Я учусь на информатическом факультете и уж знаю что говорю.

Это не метод, а лишь один из вариантов решения проблемы sqlite, в том виде в каком понял.

Что идейка с уменьшнием числа записей глупая писал еще ранее, т.к сомневался

Кроме того эта идея является взаимоисключающей с предложением расширенного доступа к БД.

Edited March 26, 2011 by Guest

[lil Toady]

Обычно, для получения/изменения данных аккаунта мы должны иметь какой-то один ИДент игрока, допустим, это будет его ник в нижнем регистре (логин). Смысл в том, чтобы разбить общую БД аккаунтов (файлы, хмл или бд) на части по какому-то принципу. В данном случае - по первому символу в нике игрока. Если быть точнее, будем использовать код первого символа в нике для разбиения общей БД на части. Если система файловая - то создаем подпапки с именами кодов символа, если это БД мускул, то создаем таблицы с именами всех возможных кодов. Пример - 33,34,35,36,... Далее в скриптах, перед тем как обратится к системе хранения, будем сначала узнавать код первого символа в нике (логине) в нижнем регистре и только потом обращаться к нужной папке/таблице с запросами или поиском. Обычно, код первого символа ника (логина) можно сохранить при входе в аккаунт, чтобы не транжирить этим делом ресурсы серва снова.

Какой мы получаем позитивный эффект от такого разделения? Выигрыш в скорости и больше стабильности, а при использовании файлов - нет этого огромного кол-ва файлов акков в 1 папке, они разделены по нашим группам.

Почитай про b-tree и binary tree search, это метод поиска который используют реляционные базы данных, в том числе и sqlite, и ты поймешь что смысла в том что ты делаешь нет.

Есть одна глупая идейка для встроенной БД - можно создавать таблицу вида

< TEXT ACCOUNTNAME, TEXT SERIAL, TEXT REGISTER_IP, BOOL AUTOLOGIN, BLOD ACCOUNT_DATA >

и хранить в ACCOUNT_DATA все данные игрока в виде JSON, чтобы не увеличивать количество записей в таблице.

Опять же, то что я сказал выше. Твой метод не будет быстрее. Меньше записей совсем не значит что будет быстрее.

Я учусь на информатическом факультете и уж знаю что говорю.

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

[MX_Master]

Личный опыт уже не является фактом? А данные, которые написаны кем-то на бумажке в сети или учебнике это незыблемая аксиома? Для больших и часто меняющихся объемов sqlite не подходит. А база аккаунтов это как раз самый большой и динамичный список. Я неоднократно фиксировал падение производительности при записи/чтении из таких больших sqlite БД. С небольшими списками всё гладко.

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

Файловый сборник аккаунтов в 1 папке - это зло. Поэтому без группировки этой стопки не обойтись, если вы хотите вручную на удаленном серве править файлы акков. Ну и не обойтись без архивирования этой стопки, чтобы делать бэкапы.

Для не оптимизированных систем мой способ железно поможет сделать систему стабильнее как минимум. Хотя сейчас и нельзя создавать свои sqlite БДшки, но надеюсь позже это можно будет делать. Общая БД стандартной аккаунт системы не вызывает доверия, лично у меня.

Edited March 27, 2011 by Guest

[Evgeni_Degerev]

Файловый сборник аккаунтов в 1 папке - это зло. Поэтому без группировки этой стопки не обойтись, если вы хотите вручную на удаленном серве править файлы акков. Ну и не обойтись без архивирования этой стопки, чтобы делать бэкапы.

Для не оптимизированных систем мой способ железно поможет сделать систему стабильнее как минимум. Хотя сейчас и нельзя создавать свои sqlite БДшки, но надеюсь позже это можно будет делать. Общая БД стандартной аккаунт системы не вызывает доверия, лично у меня.

Очень бы хотелось увидеть tar/gz архивированние скриптовыми

функциями, а также работу с gz-иповаными файлам не лету

Тестировал систему акквов в ревизии 17xx (мб 1746?) встроенную систему аккаунтов с большими обьемами данных

тогда и обнаружил потерю производительности при работе с БД.

С того времени было применено не меньше 2х ревизий оптимизаций встроенной БД, точно не помню, но раньше

при запросе/установке данных через (get/set)AccountData поиск аккаунтов проходил в цикле проверяющем соотвествие каждого аккаунта, что позднее было заменено на sql-запрос.

И еще как минимум одна ревизия, изменяющая запросы чтения/записи.

[MX_Master]

"Бэкапирование" это уже индивидуальное дело, которое зависит от платформы ПК и, собственно, админа. МТАСА тут ни при чем и разговор не о том.