Jump to content
Korean Random

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


Recommended Posts

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

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

 

Я собираюсь хранить все 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 не моя тема и я в ней не так давно. 

Edited by ruvirta
Link to comment
Short link
Share on other sites

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

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

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

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

Link to comment
Short link
Share on other sites

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 мин. Это может быть причиной быстрого роста базы.

Edited by ruvirta
Link to comment
Short link
Share on other sites

  • 4 weeks later...

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

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

Я думаю так:

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

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

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

Edited by ruvirta
Link to comment
Short link
Share on other sites

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

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

 

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

Edited by sirmax
Link to comment
Short link
Share on other sites

  • 7 months later...

@sirmax Спасибо за советы. PG реально покрыло все нужды. Будь добр здесь еще вопросик по wn8

@sirmax  Кстати мои небольшие тесты показывают, что jsonb немного тяжелее при записи и чтении против bytea(json to gzip). Даже при том, что я напрягаю проц при компрессии и декомпрессии, ну и соответственно вся логика в бэке. Я не думаю, что будет какая-то разница в производительности, если трогать json в запросе или же дернуть и трогать в бэке. И база по размерам на порядок меньше с bytea (gzip). Странно, ведь jsonb по сути тоже сжимается.
Для тестов брал 500к игроков:
- чистый текст json = 50gb

- jsonb = 10gb

- bytea(gzip) = 7.7gb

Edited by ruvirta
Link to comment
Short link
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...