Помогите Лучший способ хранения данных

  • Автор темы Автор темы Kurumi
  • Дата начала Дата начала

Kurumi

Активный участник
Пользователь
Баллы
76
Имя в Minecraft
Kurumi
Всем привет.
Вопрос только о файловом хранении.
Допустим, мне надо хранить одну строку для каждого игрока.
Код:
Kurumi: true
Как лучше сделаьь: на каждого игрока создавать по файлу с одной строкой или сделать один файл, где хранить одну строчку.
Попрошу объяснить свой совет. Спасибо!
 
Чем отличается от второго способа? Почему именно этот лучше
Что бы изменить информацию одного игрока тебе нужно сохранить файл (предварительно, возможно, прочитав его) со всеми игроками которые когда либо были на сервере.

Используя один файл под игрока ты читаешь и сохраняешь лишь то, что тебе в текущий момент нужно и сложность доступа не меняется в зависимости от количества игроков.
 
Чем отличается от второго способа? Почему именно этот лучше
Поймешь, когда начнешь работать с лямами записей. Начнем с того, что файл нужно весь считать и потом записать обратно. Ну и все это будет загружаться в память сервера.
 
Поймешь, когда начнешь работать с лямами записей. Начнем с того, что файл нужно весь считать и потом записать обратно. Ну и все это будет загружаться в память сервера.
а потом он захочет написать какие нибудь топы на основе информации в миллионе файлов. на этот экшон я бы посмотрел 😁
 
Поймешь, когда начнешь работать с лямами записей. Начнем с того, что файл нужно весь считать и потом записать обратно. Ну и все это будет загружаться в память сервера.
А если это всё делать в асинхроне ?
 
А если это всё делать в асинхроне ?
Это едва ли поможет. Можно подумать что под "асинхроном" подразумевается суперкомпьютер. Будут использоваться те же ресурсы, только не забивая при этом основной поток. Лучшее решение в твоём случае - использовать бд: redis или h2, если хранить нужно локально, или mysql если серверов несколько. И, как уже заметили выше, в бд можно хранить только тех, у кого параметр включён.
 
Это едва ли поможет. Можно подумать что под "асинхроном" подразумевается суперкомпьютер. Будут использоваться те же ресурсы, только не забивая при этом основной поток. Лучшее решение в твоём случае - использовать бд: redis или h2, если хранить нужно локально, или mysql если серверов несколько. И, как уже заметили выше, в бд можно хранить только тех, у кого параметр включён.
Значение boolean в моём примере было абстрактеым.
На деле мне нужно хранить значение типа string.
Игроков будет достаточно много, поэтому и появился вопрос производительности
 
Еще такой вопрос...
Разве при включении сервер не записывает себе в память содержимое файла?
Если это так, то почему нельзя при запуске плагина подгружать инфу , шаманить с ней в коде, а при выключении сохранять обратно?
 
Еще такой вопрос...
Разве при включении сервер не записывает себе в память содержимое файла?
Если это так, то почему нельзя при запуске плагина подгружать инфу , шаманить с ней в коде, а при выключении сохранять обратно?
Это не практично. Как часто у тебя будут играть все лям игроков из списка? Никогда)
Да и читать и писать километровый файл каждый раз, когда там накопится дохрена записей. Ты когда нибудь заглядывал в папку плееров? Там лежит огромный общий файл с игроками?
 
Еще такой вопрос...
Разве при включении сервер не записывает себе в память содержимое файла?
Если это так, то почему нельзя при запуске плагина подгружать инфу , шаманить с ней в коде, а при выключении сохранять обратно?
Все верно. И то, что ты написал вполне возможно сделать, но, может возникнуть ситуация, когда, например, сервер просто упадёт. И, скорее всего [я не проверял такое 😁], информация не успеет сохранится.
Другое дело, если информация будет периодически (или вообще постоянно) записываться в бд.
 
Все верно. И то, что ты написал вполне возможно сделать, но, может возникнуть ситуация, когда, например, сервер просто упадёт. И, скорее всего [я не проверял такое 😁], информация не успеет сохранится.
Другое дело, если информация будет периодически (или вообще постоянно) записываться в бд.
Это тоже не имеет смысла, писать подобные записи в sql базах. Если только их не надо где то еще получать помимо одного сервера..
 
Это тоже не имеет смысла, писать подобные записи в sql базах. Если только их не надо где то еще получать помимо одного сервера..
Речь не обязательно о sql. Можно использовать redis, например. Или h2. В обоих случаях они будут эффективнее, чем использование файла(ов).
 
Речь не обязательно о sql. Можно использовать redis, например. Или h2. В обоих случаях они будут эффективнее, чем использование файла(ов).
Нет) redis будет хавать для базы озу системы + файл. H2 тот же файл по сути и тоже крутится в озу сервера. Все это имеет избыточный функционал без надобности.
 
Нет) redis будет хавать для базы озу системы + файл. H2 тот же файл по сути и тоже крутится в озу сервера. Все это имеет избыточный функционал без надобности.
Скорость записи / чтения то совсем разная. При условии что он будет считывать и записывать сразу в файл при изменении данных, а не сохранять данные только при выключении плагина.
 
а потом он захочет написать какие нибудь топы на основе информации в миллионе файлов. на этот экшон я бы посмотрел 😁
а далеко ходить не надо. Essentials и топ по балансу
 
Скорость записи / чтения то совсем разная. При условии что он будет считывать и записывать сразу в файл при изменении данных, а не сохранять данные только при выключении плагина.
Ага ага. Что то файлики с игроками быстро работают, подозрительно.
 
Хорошо, я вас понял. Спасибо!)

У меня есть ещё один вопрос, не касающийся этой темы. Чтобы не плодить ещё одну тему, спрошу тут...
Я хочу добавить на сервер немного реалистики. Для этого я хочу, чтобы игрок мог пользоваться ТОЛЬКО слотами быстрого доступа (первые 9 слотов, которые предназначены для руки). То есть, хотелось бы как-то ограничить действия игроков с остальным своим инвентарём. Как это можно реализовать? Спасибо)
 
Назад
Верх