Помогите Оптимальный способ хранения данных

[MSArtyone]

Добрый вечер, сейчас работаю над мини-игрой. Нужно каким-то образом хранить данные игроков.

Вариантов несколько:
1. Хранить данные всех игроков в одном файле .yml
2. Для каждого игрока создавать отдельный файл .yml
3. JSON
4. SQLite

Какой лучше выбрать? Пожалуйста, прокомментируйте свой выбор.

 

[hyndorik]

Не согласен. Для юзеров самое лучшее это по файлу на игрока. Ибо записей может быть очень много.
Так мы сможем одинаково быстро работать хоть с миллиардом записей юзеров.

А когда понадобится что то чуть большее чем лукап юзера по нейму/уиду мы тут и обосремся

 

[alexandrage]

А когда понадобится что то чуть большее чем лукап юзера по нейму/уиду мы тут и обосремся

На офлайн моде то? Ага 9000 раз обосрались. Когда там uuid гвоздями прибит к имени игрока.

 

[hyndorik]

На офлайн моде то? Ага 9000 раз обосрались. Когда там uuid гвоздями прибит к имени игрока.

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

 

[alexandrage]

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

Да хоть 900 полей, все это так же будет хранится по файлу на изера с таким же успехом.
В майнкрафте это все спокойно уживается уже оверлет.

 

[LuckyZeeRo]

Не согласен. Для юзеров самое лучшее это по файлу на игрока. Ибо записей может быть очень много.
Так мы сможем одинаково быстро работать хоть с миллиардом записей юзеров.

А так с H2 не можем что ли?
На сколько ты увеличишь производительность, работая с отдельными файлами вместо базы данных? К тому же если не хранить в памяти всех игроков, нужно будет каждый запрос открывать файл, парсить, закрывать. И как сказал уже hyndorik, про какие нибудь фильтры, быстрый поиск по разным атрибутам вообще не будет слов.
Файлы подойдут, в простейших вариантах. Но какой смысл?

 

[alexandrage]

А так с H2 не можем что ли?
На сколько ты увеличишь производительность, работая с отдельными файлами вместо базы данных? К тому же если не хранить в памяти всех игроков, нужно будет каждый запрос открывать файл, парсить, закрывать. И как сказал уже hyndorik, про какие нибудь фильтры, быстрый поиск по разным атрибутам вообще не будет слов.
Файлы подойдут, в простейших вариантах. Но какой смысл?

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

 

[LuckyZeeRo]

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

Ну дак мы и говорим об H2 а не SQLite. С чего ты взял, что я не знаю как работать с бд?
Помещать в память онлайн игроков это понятное дело, я говорю обо всех, если нужно обращаться к ним, делать выборки, топы и т.д.

 

[alexandrage]

Помещать в память онлайн игроков

По сути это и хочет ТС.

 

[hyndorik]

По сути это и хочет ТС.

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

 

[alexandrage]

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

Если офлайн юзеры не важны, выводить топ среди играющих. Пруфит. Достаточно для какой то миниигры. Или же H2 как локал базу. MySQL для локальной базы не подходит, ни к чему нам оверхед ради одного сервера.

 

[hyndorik]

Если офлайн юзеры не важны, выводить топ среди играющих. Пруфит. Достаточно для какой то миниигры. Или же H2 как локал базу. MySQL для локальной базы не подходит, ни к чему нам оверхед ради одного сервера.

Ну собственно поэтому и надо юзать базу данных, а не файлики, так как параметры выборки могут меняться. Ну и использование локал бд тоже очень сомнительно, так как в будущем очень вероятно то, что данные с этой локал бд придется использовать где-то еще. Да и потом какой там оверхед от мускула то?) Если сервер и мускул стоят на одной машине, то там время запроса максимум увеличиться на ~40 наносекунд, а в будущем когда мускл база вырастет, то быстрота работы скомпенсирует время доставки

 

[alexandrage]

Ну собственно поэтому и надо юзать базу данных, а не файлики, так как параметры выборки могут меняться. Ну и использование локал бд тоже очень сомнительно, так как в будущем очень вероятно то, что данные с этой локал бд придется использовать где-то еще. Да и потом какой там оверхед от мускула то?) Если сервер и мускул стоят на одной машине, то там время запроса максимум увеличиться на ~40 наносекунд, а в будущем когда мускл база вырастет, то быстрота работы скомпенсирует время доставки

1) Смотря какая юаза и под какие нужды. Если припрет 1 запрос и получишь дамп sql для мускула.
2) Про скорость сам дойдешь, когда будешь работать с большим онлайном. Или просто статейки почитай.

 

[Reality_SC]

Как часто бывает, для того, чтобы получить правильный ответ, нужно правильно поставить вопрос.

ТС завёл обсуждение только о хранении, и тут пригодны все обсуждаемые варианты: .yml/.json на игрока, sqlite/h2, или отдельный mysql.

Никакой из способов не отменяет возможных оптимизаций в рантайме.

Как только у ТС появятся новые требования (возможные варианты поиска данных, etc.) или уточнения об их отсутствии, можно будет делать дальнейший выбор.

Подвёл итог.

 

[hyndorik]

1) Смотря какая юаза и под какие нужды. Если припрет 1 запрос и получишь дамп sql для мускула.
2) Про скорость сам дойдешь, когда будешь работать с большим онлайном. Или просто статейки почитай.

Зачем статейки читать) Есть спека архитектур этих двух бд, есть бенчи. Как раз таки при маленьком онлайне и маленьких данных H2 будет выигрывать, при увелечение данных выиграет мускл

 

[alexandrage]

Зачем статейки читать) Есть спека архитектур этих двух бд, есть бенчи. Как раз таки при маленьком онлайне и маленьких данных H2 будет выигрывать, при увелечение данных выиграет мускл

Выиграет какая нибудь cassandra.

 

[hyndorik]

Выиграет какая нибудь cassandra.

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