Перейти к содержимому
Korean Random
ruvirta

Выбор базы данных и ее примерная структура(Мобильный оленемер - BINT)

Рекомендуемые сообщения

(изменено)

В общем хочу по на эту тему пообщатся с бывалыми.

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

 

Я собираюсь хранить все api данные пользователя, поэтому меня интересует на чем все это держать.

Сейчас порядка 75к игроков с api данными в мускуле(mysql). Я ничего не сжимаю не кодирую - храню так как есть. Занимает все это чуть больше 5гб на ссд диске.

 

В самой игре WoT Blitz зарегистрировано около 100.000.000 юзеров и можно подозревать, что рано или поздно они окажутся у меня в базе и я должен с этим что-то делать.

 

Мои варианты: 

1. NoSQL + SQL.

Я хочу хранить на диске в NoSQL базе ссылки(номера) на таблицы в SQL базе в которых будут данные того или иного юзера, которая в свою очередь будет содержать много таблиц например api_data_1, api_data_2 итд. А NoSQL (key, value) будет хранить : key = nickname, value = table num.

Объясню свою(может быть не правильную) логику - игроков много и легче их дергать из файловой, однотипной базы. А далее по номеру таблицы дергаем его данные из небольшой(порядка 100к строк) SQL таблицы, чтобы это происходило как можно быстрее.

Я сую по запросу статы каждого игрока в отдельный поток, тем самым у меня 14 запросов(игроков у нас в бою 14) одновременно и приходят они тоже относительно одновременно. Чуть не забыл, работает это все на Java сервере.

 

2. Использовать исключительно NoSQL базу и по ключу(nickname) дергать абсолютно все данные. Ожидаемые(предпологаемые) минусы: большой размер базы; не возможность нормально управлять базой(в отличие от простейшей субд Mysql например); вероятность потери данных при таких объемах.

Тестил одну их таких баз - создал 100m записей примерно за 10мин, потом 14 потоков дернули данные примерно за 1 сек. Это по сути не много, но нужно быстрее. По тестам тотже PostgreSQL при 600m делает это за 0.0012сек. ( WHERE id = ... ).

Я уже начитался всевозможной литературы по NoSQL и это отличная штука, но подходят ли они конкретно для моей задачи?...

 

Хотелось бы чтобы и разработчики XVM немного открыли завесу их реализации.

 

База растет быстро и ждать особо времени нет.

 

Все плюсы и минусы SQL и NoSQL решении я уже изучил, но выбрать что-то одно сложно. А комбинировать как по мне это велосипед.

 

П.с. linux не моя тема и я в ней не так давно. 

Изменено пользователем ruvirta

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

PostgreSQL. Ну и правильная структура данных.

У нас данные за 2 года занимают 700 гб. Можно уменьшить, используя колоночные таблицы, но они для OLTP не очень подходят, больше для аналитики.

100 млн у тебя не будет, нужны только активные пользователи, их на порядок меньше.

И да, в PG мы комбинируем SQL и NoSQL.  Оперативные данные в jsonb, архивные в реляционных таблицах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(изменено)
26 минут назад, sirmax сказал:

PostgreSQL. Ну и правильная структура данных.

У нас данные за 2 года занимают 700 гб. Можно уменьшить, используя колоночные таблицы, но они для OLTP не очень подходят, больше для аналитики.

100 млн у тебя не будет, нужны только активные пользователи, их на порядок меньше.

 

Да, я изменил пост и добавил про PostgreSQL. 

Ну про 100m да, возможно загнул. Но лучше так сказать перебздеть, чем недобздеть, ибо жизнь то долгая, все может произойти.

Колоночные таблицы или их аналог (column family) как раз таки есть например в HBase (nosql) и по слухам это работает гораздо бытрее SQL.

 

Ну а как насчет хранить все api данные так как есть(json)? Тоесть мне они реально нужны именно ВСЕ.

Опять же забыл, что некоторые даные будут обновляться очень часто. Тоесть у нас есть некоторая разница и функционал BINT этого требует.

Если бы это было только обновление api данных в какой-то период времени, то я бы уже сделал свой выбор в пользу любой SQL.

 

Может важно: 75000 юзеров это за 1 месяц использования небольшим количеством юзеров BINT.

Тоесть бои у нас мах 7 мин. , а обычно это 4-5 мин. Это может быть причиной быстрого роста базы.

Изменено пользователем ruvirta

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, sirmax сказал:

PostgreSQL. Ну и правильная структура данных.

Активную базу тоже с mongo на PG перевели?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@seriych в процессе. Почти закончили.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 26.10.2017 в 19:36, Mr 13 сказал:

@seriych в процессе. Почти закончили.

Опытом поделитесь в разрезе статьи на хабре может быть?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(изменено)

Привет опять. В общем выбор почти сделан в пользу либо HBase либо PG с его nosql возможностями. Сейчас буду подробно разбираться с каждым по отдельности. HBase потому, что java и я в ней шарю и мне все прозрачно, но она больше для BigData т.е. для миллиардов данных для которых нужно космическое железо и не одно, чего у меня нет и никогда не будет. PG потому, что советуют все для этой задачи, позиционируя как стабильность, скорость, возможности, поддержка, развитие.

У меня помимо апи данных есть еще куча всего, что должно безопасно хранится и с этим я конечно же решу вопрос сам, а вот насчет апи данных и примерной структуры для них допустим в PG, если не затруднит конечно, то можно по подробнее?

Я думаю так:

каждый из запросов хранить в разных таблицах со штампом последней активности. далее раз в день например стартуем скрипт по зачистке от неактивных и переносим их в архив с той же структурой. если есть запрос на игрока, которого нет в активе, шелестим архив и восстанавливаем.

Ну это все сейчас из башки взято, а вообще надо думать. Помогите чем сможете пожалуйста))

Кстати, ваша причина перехода с монги на пг обоснована тем, что по последним тестам пг оказалась быстрее?

Изменено пользователем ruvirta

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(изменено)

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

Причина перехода на pg - нам потребовалась аналитика, которую в монге сделать нельзя. А раз все равно уже есть pg, то нет смысла дальше держать еще и монгу. По производительности те задачи, которая выполняла монга, pg выполняет примерно так же.

 

UPD: Еще можно в плюсы pg записать SQL. Для меня SQL намного привычней и удобней, чем запросы в монге на JSON. К тому же в pg можно выносить часть логики из бэка, что иногда позволяет оптимизировать слишком тяжелые запросы (хотя это уже за рамками NoSQL).

Изменено пользователем sirmax

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×