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

Доброго времени суток.

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

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

Нужный тип данных хранить в нужной таблице, или всю информацию сервера хранить в одной таблице сразу?

• Пример №1:

Код:

Таблица auth:
    Столбцы:
        player | last_ip | last_quit_time | password | session
Таблица clans:
    Столбцы:
        player | rank | clan_name | kills | deaths

• Пример №2:

Код:

Таблица 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 аккаунтов, выборка не будет долгой.

 

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

Содержание таблиц было приведено в пример.
Если же опираться на то, что хочу я, то, если делать одну глобальную таблицу, то в ней будет более 40 столбцов.
Если реализовывать вариант из второго примера, то у меня получится больше 15 таблиц и в каждой от 2 до 10 столбцов.

 

Если есть возможность использовать SQLite, то используй эту СУБД, побыстрее MySQL будет, так как хранилище локальное.На счёт таблиц, то тут стоит использовать реляционный тип базы данных.Так, например, некоторые свойства можно раскидать по таблицам, а связать их всех с помощью идентификатора.В роли идентификатора может выступать имя игрока, например.Да, один столбец всё же дублируется, и конкретно в этом примере реляционный подход особой силы не имеет, но как по мне, лучше сделать 2 таблицы и грамотно к ним обращаться в нужный момент.

 

Второй тоже может быть локальным. И настроек там не просто так много...

 

В качестве глобального хранилища стоит использовать SQLite?
Ибо, если у меня там будет 150к записей, сколько будет весить файл с бд?

 

Ну, тут неоднозначно.SQLite быстрее в плане того, что ему не нужно делать запросы на сторонний ресурс, у неё всё под рукой+простота+переносимость.Но SQLite стоит использовать в небольших проектах, если планируется работа с большим объемом данных, то, возможно, лучшим решением будет MySQL+можно сделать и локальное хранилище, если сервер позволяет.Я не думаю, что будут существенные различия в размерах между этими двумя СУБД.Так что если места на том же сервере не хватает, с помощью MySQL перекидывай на другой.[DOUBLEPOST=1485101394,1485095859][/DOUBLEPOST]Можно вообще, создать простую утилиту, запихать в базу этих 150к записей и проверить, какая покажет себя лучше.

 

Как раз занят этим =)

 

SQLite в разы медленней чем MySQL. На большой скорости абдейда он отвалится просто.[DOUBLEPOST=1485169405,1485169317][/DOUBLEPOST]Я рекомендую юзать MariaDB, там скорость записи выше чем у MySQL.
А если тебе нужна огромная скорость, то юзай redis. Этот уж точно не отвалится.

 

Кое-кто уже советовал мне redis.
Читал про него. Не устраивает то, что он хранит всю информацию в локальном кеше. Поэтому как глобальная база данных, redis, боюсь, не подойдёт.

 

А ты планируешь светить базой во внешку? Зачем?

 

Нет, зачем? Как мне коннектиться с разных серверов к одной базе данных, ммм? Да и потом, локальная память не безгранична, чтобы использовать redis для хранения всей информации.

 

Криво читал, к нему можно конектится извне. redis как раз таки направлен на глобальную базу с большой нагрузкой.

 

Не юзал бд ни разу, но думаю там уже должна быть учтена работа с большим количеством записей, с очень большим.
Например можно сделать пародию на бд, выбирающую из нескольких триллионов аккаунтов - нужный - за несколько миллисекунд, с помощью файлов и каталогов. (папка Players, в ней - максимум сотня папок, названия которых - первая буква ников, внутри каждой из них так же, и так далее)
В итоге получится, что для получения информации о игроке, у которого ник состоит из 10 знаков будет десять выборок из сотни папок, вместо одной выборки из триллиона файлов.
И уж если так можно решить эту проблему, то на аппаратном уровне баз данных тем более должно быть все нормально со скоростью.

 

Так локальный кеш же быстро забьётся, разве нет?

 

Это тебе не мемчача, redis сохраняет данные, хотя и временное хранение данных тоже там есть.

 

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

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

 

Спасибо за такой развёрнутый ответ с примером. Значит остановлюсь пока на этом.

Тему закрывать не стану, вдруг для кого будет актуально.