1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.
  2. Вы находитесь в сообществе Rubukkit. Мы - администраторы серверов Minecraft, разрабатываем собственные плагины и переводим на различные языки плагины наших коллег из других стран.
    Скрыть объявление
Скрыть объявление
В преддверии глобального обновления, мы проводим исследования, которые помогут нам сделать опыт пользования форумом ещё удобнее. Помогите нам, примите участие!

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

Тема в разделе "Разработка плагинов для новичков", создана пользователем MSArtyone, 14 апр 2019.

  1. hyndorik

    hyndorik Активный участник Пользователь

    Баллы:
    98
    Имя в Minecraft:
    hyndo
    А когда понадобится что то чуть большее чем лукап юзера по нейму/уиду мы тут и обосремся
     
  2. alexandrage

    alexandrage Старожил Пользователь

    Баллы:
    173
    На офлайн моде то? Ага 9000 раз обосрались. Когда там uuid гвоздями прибит к имени игрока.
     
    Последнее редактирование: 16 апр 2019
  3. hyndorik

    hyndorik Активный участник Пользователь

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

    alexandrage Старожил Пользователь

    Баллы:
    173
    Да хоть 900 полей, все это так же будет хранится по файлу на изера с таким же успехом.
    В майнкрафте это все спокойно уживается уже оверлет.
     
    Последнее редактирование: 16 апр 2019
  5. LuckyZeeRo

    LuckyZeeRo Активный участник Пользователь

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

    alexandrage Старожил Пользователь

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

    LuckyZeeRo Активный участник Пользователь

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

    alexandrage Старожил Пользователь

    Баллы:
    173
    По сути это и хочет ТС.
     
  9. hyndorik

    hyndorik Активный участник Пользователь

    Баллы:
    98
    Имя в Minecraft:
    hyndo
    Ты проигнорировал слова об выборке и топах. С твоей системой хранения составить топ убийств какой нибудь, это же жестб по перфоменсу
     
  10. alexandrage

    alexandrage Старожил Пользователь

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

    hyndorik Активный участник Пользователь

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

    alexandrage Старожил Пользователь

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

    Reality_SC Старожил Пользователь

    Баллы:
    123
    Имя в Minecraft:
    Reality_SC
    Как часто бывает, для того, чтобы получить правильный ответ, нужно правильно поставить вопрос.

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

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

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

    Подвёл итог.
     
  14. hyndorik

    hyndorik Активный участник Пользователь

    Баллы:
    98
    Имя в Minecraft:
    hyndo
    Зачем статейки читать) Есть спека архитектур этих двух бд, есть бенчи. Как раз таки при маленьком онлайне и маленьких данных H2 будет выигрывать, при увелечение данных выиграет мускл
     
  15. alexandrage

    alexandrage Старожил Пользователь

    Баллы:
    173
    Выиграет какая нибудь cassandra.
     
  16. hyndorik

    hyndorik Активный участник Пользователь

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

Поделиться этой страницей