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

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

CoolBoy

Активный участник
Пользователь
Баллы
96
Имя в Minecraft
Xezard
Доброго времени суток.

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

Касательно mysql хранилищ:
1) Как эффективнее работать с данными сервера?

Нужный тип данных хранить в нужной таблице, или всю информацию сервера хранить в одной таблице сразу?
  • Пример №1:
YAML: 
Таблица auth:
    Столбцы:
        player | last_ip | last_quit_time | password | session
Таблица clans:
    Столбцы:
        player | rank | clan_name | kills | deaths
  • Пример №2:
YAML: 
Таблица data:
    Столбцы:
        player | last_ip | last_quit_time | password | session | rank | clan_name | kills | deaths

Какой из предложенных способов организации хранения данных будет наиболее эффективным?

Пример №1:
Меня немного смущает тот факт, что в разных таблицах будут храниться однаковые данные.
Например, столбец "player".
Плюс же такого способа организации хранения и обработки данных очевиден - быстрая скорость работы с базой данных.

Пример №2:
Минус этого примера очевиден - огромный размер таблицы, а как следствие, возможно, более долгие запросы.
Плюс - данные таблицы не дублируются больше нигде.

2) Существуют ли другие типы баз данных, более эффективные для хранения подобного рода информации?
Если да, то какие?

3) Быть может, кому-нибудь уже известно, как работают с данными крупные проекты вроде "Mineplex", "Hypixel" и другие?

P.S. Раньше работать с большим количеством данных не приходилось, отсюда и такие, возможно, глупые, вопросы. Да и, насколько я знаю, тема работы с "Big Data" всегда была актуальна. :)
 
Последнее редактирование:
На самом деле - как хочешь, так и делай, (ИМХО) оба варианта одинаковы.

Предположим, выбираем вариант №1 (две таблицы). Первую будет использовать предположительно система авторизации на сайте + авторизация на лаунчере. Вторую таблицу будет использовать плагин сбора игровой статистики + опять же сайт для её отображения. Если обе таблицы используются сайтом - то я бы лучше их объединил.

А насчет скорости можно просто прикинуть, сколько игроков планируется на проекте. Судя по таблице предположу, что будет всего 1 сервер. И даже если наберется 1000 аккаунтов, выборка не будет долгой.
 
TaoGunner сказал(а):
На самом деле - как хочешь, так и делай, (ИМХО) оба варианта одинаковы.

Предположим, выбираем вариант №1 (две таблицы). Первую будет использовать предположительно система авторизации на сайте + авторизация на лаунчере. Вторую таблицу будет использовать плагин сбора игровой статистики + опять же сайт для её отображения. Если обе таблицы используются сайтом - то я бы лучше их объединил.

А насчет скорости можно просто прикинуть, сколько игроков планируется на проекте. Судя по таблице предположу, что будет всего 1 сервер. И даже если наберется 1000 аккаунтов, выборка не будет долгой.
Нажмите, чтобы раскрыть...
А если у меня сборка на нескольких Bungee?
И одна таблица на все данные?
Я так думаю, лучше несколько таблиц.
Ибо, имея одну таблицу, в которой хранятся все данные, коннект к ней и обновление данных будет происходить чуть ли не ежесекундно.
А это не есть хорошо.
Плюс, волнуюсь, как бы небыло задержек в обновлении данных.

Содержание таблиц было приведено в пример.
Если же опираться на то, что хочу я, то, если делать одну глобальную таблицу, то в ней будет более 40 столбцов.
Если реализовывать вариант из второго примера, то у меня получится больше 15 таблиц и в каждой от 2 до 10 столбцов.
 
Если есть возможность использовать SQLite, то используй эту СУБД, побыстрее MySQL будет, так как хранилище локальное.На счёт таблиц, то тут стоит использовать реляционный тип базы данных.Так, например, некоторые свойства можно раскидать по таблицам, а связать их всех с помощью идентификатора.В роли идентификатора может выступать имя игрока, например.Да, один столбец всё же дублируется, и конкретно в этом примере реляционный подход особой силы не имеет, но как по мне, лучше сделать 2 таблицы и грамотно к ним обращаться в нужный момент.
 
AtomicInteger сказал(а):
Если есть возможность использовать SQLite, то используй эту СУБД, побыстрее MySQL будет, так как хранилище локальное.На счёт таблиц, то тут стоит использовать реляционный тип базы данных.Так, например, некоторые свойства можно раскидать по таблицам, а связать их всех с помощью идентификатора.В роли идентификатора может выступать имя игрока, например.Да, один столбец всё же дублируется, и конкретно в этом примере реляционный подход особой силы не имеет, но как по мне, лучше сделать 2 таблицы и грамотно к ним обращаться в нужный момент.
Нажмите, чтобы раскрыть...
В качестве глобального хранилища стоит использовать SQLite?
Ибо, если у меня там будет 150к записей, сколько будет весить файл с бд?
 
CoolBoy сказал(а):
В качестве глобального хранилища стоит использовать SQLite?
Ибо, если у меня там будет 150к записей, сколько будет весить файл с бд?
Нажмите, чтобы раскрыть...
Ну, тут неоднозначно.SQLite быстрее в плане того, что ему не нужно делать запросы на сторонний ресурс, у неё всё под рукой+простота+переносимость.Но SQLite стоит использовать в небольших проектах, если планируется работа с большим объемом данных, то, возможно, лучшим решением будет MySQL+можно сделать и локальное хранилище, если сервер позволяет.Я не думаю, что будут существенные различия в размерах между этими двумя СУБД.Так что если места на том же сервере не хватает, с помощью MySQL перекидывай на другой.
Можно вообще, создать простую утилиту, запихать в базу этих 150к записей и проверить, какая покажет себя лучше.
 
AtomicInteger сказал(а):
Ну, тут неоднозначно.SQLite быстрее в плане того, что ему не нужно делать запросы на сторонний ресурс, у неё всё под рукой+простота+переносимость.Но SQLite стоит использовать в небольших проектах, если планируется работа с большим объемом данных, то, возможно, лучшим решением будет MySQL+можно сделать и локальное хранилище, если сервер позволяет.Я не думаю, что будут существенные различия в размерах между этими двумя СУБД.Так что если места на том же сервере не хватает, с помощью MySQL перекидывай на другой.
Можно вообще, создать простую утилиту, запихать в базу этих 150к записей и проверить, какая покажет себя лучше.
Нажмите, чтобы раскрыть...
Как раз занят этим =)
 
AtomicInteger сказал(а):
Если есть возможность использовать SQLite, то используй эту СУБД, побыстрее MySQL будет, так как хранилище локальное.На счёт таблиц, то тут стоит использовать реляционный тип базы данных.Так, например, некоторые свойства можно раскидать по таблицам, а связать их всех с помощью идентификатора.В роли идентификатора может выступать имя игрока, например.Да, один столбец всё же дублируется, и конкретно в этом примере реляционный подход особой силы не имеет, но как по мне, лучше сделать 2 таблицы и грамотно к ним обращаться в нужный момент.
Нажмите, чтобы раскрыть...
SQLite в разы медленней чем MySQL. На большой скорости абдейда он отвалится просто.
Я рекомендую юзать MariaDB, там скорость записи выше чем у MySQL.
А если тебе нужна огромная скорость, то юзай redis. Этот уж точно не отвалится.
 
alexandrage сказал(а):
SQLite в разы медленней чем MySQL. На большой скорости абдейда он отвалится просто.
Я рекомендую юзать MariaDB, там скорость записи выше чем у MySQL.
А если тебе нужна огромная скорость, то юзай redis. Этот уж точно не отвалится.
Нажмите, чтобы раскрыть...
Кое-кто уже советовал мне redis.
Читал про него. Не устраивает то, что он хранит всю информацию в локальном кеше. Поэтому как глобальная база данных, redis, боюсь, не подойдёт.
 
CoolBoy сказал(а):
Не устраивает то, что он хранит всю информацию в локальном кеше. Поэтому как глобальная база данных, redis, боюсь, не подойдёт.
Нажмите, чтобы раскрыть...
А ты планируешь светить базой во внешку? Зачем?
 
TaoGunner сказал(а):
А ты планируешь светить базой во внешку? Зачем?
Нажмите, чтобы раскрыть...
Нет, зачем? Как мне коннектиться с разных серверов к одной базе данных, ммм? Да и потом, локальная память не безгранична, чтобы использовать redis для хранения всей информации.
 
CoolBoy сказал(а):
Кое-кто уже советовал мне redis.
Читал про него. Не устраивает то, что он хранит всю информацию в локальном кеше. Поэтому как глобальная база данных, redis, боюсь, не подойдёт.
Нажмите, чтобы раскрыть...
Криво читал, к нему можно конектится извне. redis как раз таки направлен на глобальную базу с большой нагрузкой.
 
Последнее редактирование:
Не юзал бд ни разу:rolleyes:, но думаю там уже должна быть учтена работа с большим количеством записей, с очень большим.
Например можно сделать пародию на бд, выбирающую из нескольких триллионов аккаунтов - нужный - за несколько миллисекунд, с помощью файлов и каталогов. (папка Players, в ней - максимум сотня папок, названия которых - первая буква ников, внутри каждой из них так же, и так далее)
В итоге получится, что для получения информации о игроке, у которого ник состоит из 10 знаков будет десять выборок из сотни папок, вместо одной выборки из триллиона файлов.
И уж если так можно решить эту проблему, то на аппаратном уровне баз данных тем более должно быть все нормально со скоростью.
 
При работе с MySQL важно запомнить одно правило. Чем проще запросы - тем лучше. Откуда эти запросы берут информацию - совершенно не важно. Так-же очень важна роль индексов в огромных таблицах, это ускоряет выборку в разы.

Сейчас работаю с базой, у которой 7к ппс и около 2к коннектов. Проблем нет совершенно и по ресурсам сервер бд жрет копейки. (использую MariaDB)
 
Jampire сказал(а):
При работе с MySQL важно запомнить одно правило. Чем проще запросы - тем лучше. Откуда эти запросы берут информацию - совершенно не важно. Так-же очень важна роль индексов в огромных таблицах, это ускоряет выборку в разы.

Сейчас работаю с базой, у которой 7к ппс и около 2к коннектов. Проблем нет совершенно и по ресурсам сервер бд жрет копейки. (использую MariaDB)
Нажмите, чтобы раскрыть...
Спасибо за такой развёрнутый ответ с примером. Значит остановлюсь пока на этом.

Тему закрывать не стану, вдруг для кого будет актуально.
 
Для ответа нужно войти/зарегистрироваться
Назад
Верх