Вопрос Про эффективное управление базой данных

[Gepron1x]

Привет! Может, знает кто-нибудь примеры эффективного использования бд в майнкрафт плагинах, откуда можно списать? под эффективностью я имею ввиду:

• Минимум бессмысленных обновлений
• Отсутствие постоянной нагрузки на бд
• Разделение кода: Хочется, чтобы обычные объекты не зависили напрямую от хранилища. Проще говоря, SOLID не нарушать

Пробовал три варианта:

1. Исполнять бд-код напрямую в методах обновления (Clan.setDisplayName, Clan.addMember) - проблемы сразу явные - объект зависит от базы, что явно нарушает SOLID. Да и не думаю, что базе понравится постоянные обновления при любом тыке.
2. Периодически сохранять все в базу. Уже не нарушает solid, но, черт подери, очень и очень много бессмысленных обновлений, а запросы жирные. Вообще, неплохой вариант.
3. Ивенты. В методах обновления, вместо исполнения бд-кода напрямую, я вызываю ивенты (ClanAddMemberEvent, ClanSetDisplayNameEvent). В отдельном слушателе обрабатываю их, и добавляю в очередь некие DatabaseUpdate. Периодически исполняю все обновления в очереди. Тоже классный вариант, но проблемы тоже присутствуют. Во-первых, SOLID нарушается, объекты не получится использовать без сервиса для вызова ивентов. Во-вторых нужно пипец как много ивентов, почти для каждого поля каждого класса, что довольно громоздко.
   
   Как это делается в больших плагинах? Меня долго мучает данный вопрос, много где спрашиваю, но ответы всегда максимально расплывчатые.

 

[NullPointer]

Как это делается в больших плагинах?

Берешь и смотришь их исходный код - Profit!

 

[BlackBaroness]

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

Глупости. Можно спокойно отправлять запрос, когда нужно, это дешево

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

Периодически исполняю все обновления в очереди.

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

 

[Gepron1x]

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

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

 

[BlackBaroness]

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

???
С каких пор постоянно дёргают подключение?

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

Для этого есть CachedThreadPool. Если есть риск, что потоков будет слишком много, можно просто ограничить его размер или перейти на ForkJoin

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

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

Кстати, "асинхронных поток" это как?

 

[Gepron1x]

???
С каких пор постоянно дёргают подключение?

Для этого есть CachedThreadPool. Если есть риск, что потоков будет слишком много, можно просто ограничить его размер или перейти на ForkJoin

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

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

Кстати, "асинхронных поток" это как?

Ну, окей. А подскажешь примеры высоконагруженных систем, работающих подобных образом?