Помогите Метод хранения используемых данных

[zenbot]

Всем доброго времени суток. Я относительно недавно пишу плагины, до недавнего времени не было вопросов про "а хватит ли мне ОЗУ, и много ли будет его использоваться", ибо считал, что плагины не такие уж и большие, а зря. Переписал все плагины свои под БД, в ОЗУ храню, разве что пару HashSet'ов и пару массивов строк. Меня все устраивает, задержки нет. Не задавал бы такой вопрос, если бы не хотел написать плагин для паба. Знакомые с другого сервера жалуются на WClans (Автор Jampire) на то, что он жрет много ОЗУ. В мыслях уже есть сделать две версии плагина, с хранением данных в ОЗУ и сохранении их в БД и полное использование БД. Насколько это вообще целесообразно? Или не стоит париться и использовать ОЗУ? Не бросайте помидорами, кх. Всем спасибо хотя бы за то, что прочли. Всем добра, жду ответов :3

 

[Jampire]

в моем WClans была ошибка, из за которой он накапливал ResultSet в памяти. со временем это приводило к нехватке ОЗУ

проблема так и не была решена, ибо контакт с заказчиком был потерян. позже плагин был слит.

так-же от себя добавлю, что хранение копии датасета в памяти является лучшим решением как минимум по причине того, что из за любого изменения не нужно долбить базу. это хорошо когда запросов 50 - 100 в секунду. а когда плагином пользуется активно 2к+ человек одновременно это может вызывать проблем и очереди в базе в случае, если она настроена не правильно.

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

 

[alexandrage]

При 2к онли конечно же не хватит одной таблици. Тут придется распределять.

 

[zenbot]

в моем WClans была ошибка, из за которой он накапливал ResultSet в памяти. со временем это приводило к нехватке ОЗУ

проблема так и не была решена, ибо контакт с заказчиком был потерян. позже плагин был слит.

так-же от себя добавлю, что хранение копии датасета в памяти является лучшим решением как минимум по причине того, что из за любого изменения не нужно долбить базу. это хорошо когда запросов 50 - 100 в секунду. а когда плагином пользуется активно 2к+ человек одновременно это может вызывать проблем и очереди в базе в случае, если она настроена не правильно.

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

Такое дело, я взял класс MySQL с твоих сурсов bClans, и использую его во всех своих плагинах, где нужна база. К примеру, на моем сервере с 100 онли примерно, стоит плагина 2-4, которые активно юзают БД, лагов особых не вызывает, вроде как. Один из таких плагинов, кланы, основная идея взята от твоих кланов, но переписано много...
Ладненько, насколько я понял, лучше всего использовать ОЗУ
Спасибо за ответы :3

 

[alexandrage]

В кланах только одно будет грузить, это когда запрос на топ делать, вот его стоит в мапе хранить. Ну и инфу о клане игроков онлайн, чтоб не лезть в базу при клан чате и тп

 

[Jampire]

Такое дело, я взял класс MySQL с твоих сурсов bClans, и использую его во всех своих плагинах, где нужна база. К примеру, на моем сервере с 100 онли примерно, стоит плагина 2-4, которые активно юзают БД, лагов особых не вызывает, вроде как. Один из таких плагинов, кланы, основная идея взята от твоих кланов, но переписано много...
Ладненько, насколько я понял, лучше всего использовать ОЗУ
Спасибо за ответы :3

крайне не советую использовать мой старый MySQL класс как раз по причине жесткой утечки памяти. там банально нет ResultSet.close()

 

[zenbot]

крайне не советую использовать мой старый MySQL класс как раз по причине жесткой утечки памяти. там банально нет ResultSet.close()

О как. А нельзя ли у тебя попросить новый MySQL, на крайняк купить?

В кланах только одно будет грузить, это когда запрос на топ делать, вот его стоит в мапе хранить. Ну и инфу о клане игроков онлайн, чтоб не лезть в базу при клан чате и тп

У меня при любом использовании /c(clan) идет запрос к бд, как минимум запрашивается название клана, для его вывода, ну и проверка есть ли он вообще, а так же у меня ранги сделаны, а это еще запросы...

 

[alexandrage]

О как. А нельзя ли у тебя попросить новый MySQL, на крайняк купить?

У меня при любом использовании /c(clan) идет запрос к бд, как минимум запрашивается название клана, для его вывода, ну и проверка есть ли он вообще, а так же у меня ранги сделаны, а это еще запросы...

Ну ты делай запрос на клан и пиши его во временный хешмап. Какое то время он будет в кеше и запросов не будет.
Ну и обновляй маму при изменениях, удалениях кланов, пока мапа живет.
И не держи в озу лишнюю инфу. Ибо если ты сделаешь executeQuery("SELECT * FROM clan_list"); то сам понимаешь, писец будет если там овермиллион кланов.

 

[Jampire]

Ну ты делай запрос на клан и пиши его во временный хешмап. Какое то время он будет в кеше и запросов не будет.
Ну и обновляй маму при изменениях, удалениях кланов, пока мапа живет.
И не держи в озу лишнюю инфу. Ибо если ты сделаешь executeQuery("SELECT * FROM clan_list"); то сам понимаешь, писец будет если там овермиллион кланов.

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

 

[AtomicInteger]

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

Ну, если записей много, то SELECT тоже неплохую погоду сделает.А на счёт фильтрации, то её лучше делать на этапе выборки, то есть при SQL запросе, это и количество получаемых данных(нагрузку) уменьшит, и дальнейшей фильтрации не нужно.

 

[zenbot]

Насчет овермного кланов, в планах сделать автоудаление неиспользуемых кланов