ruvirta Posted October 26, 2017 Share Posted October 26, 2017 (edited) В общем хочу по на эту тему пообщатся с бывалыми. Есть уже рабочее приложение и временная(тестовая) база из которой в конечном итоге должно быть все перекинуто в нормальную базу, над которой я до сих пор думаю и ошибок быть не должно. Я собираюсь хранить все 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 October 26, 2017 by ruvirta @ Quote Link to comment Short link Share on other sites More sharing options...
sirmax Posted October 26, 2017 Share Posted October 26, 2017 PostgreSQL. Ну и правильная структура данных. У нас данные за 2 года занимают 700 гб. Можно уменьшить, используя колоночные таблицы, но они для OLTP не очень подходят, больше для аналитики. 100 млн у тебя не будет, нужны только активные пользователи, их на порядок меньше. И да, в PG мы комбинируем SQL и NoSQL. Оперативные данные в jsonb, архивные в реляционных таблицах. @ Quote Link to comment Short link Share on other sites More sharing options...
ruvirta Posted October 26, 2017 Author Share Posted October 26, 2017 (edited) 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 October 26, 2017 by ruvirta @ Quote Link to comment Short link Share on other sites More sharing options...
seriych Posted October 26, 2017 Share Posted October 26, 2017 7 часов назад, sirmax сказал: PostgreSQL. Ну и правильная структура данных. Активную базу тоже с mongo на PG перевели? @ Quote Link to comment Short link Share on other sites More sharing options...
13 Posted October 26, 2017 Share Posted October 26, 2017 @seriych в процессе. Почти закончили. @ Quote Link to comment Short link Share on other sites More sharing options...
kharlashkin Posted October 28, 2017 Share Posted October 28, 2017 В 26.10.2017 в 19:36, Mr 13 сказал: @seriych в процессе. Почти закончили. Опытом поделитесь в разрезе статьи на хабре может быть? @ Quote Link to comment Short link Share on other sites More sharing options...
ruvirta Posted November 22, 2017 Author Share Posted November 22, 2017 (edited) Привет опять. В общем выбор почти сделан в пользу либо HBase либо PG с его nosql возможностями. Сейчас буду подробно разбираться с каждым по отдельности. HBase потому, что java и я в ней шарю и мне все прозрачно, но она больше для BigData т.е. для миллиардов данных для которых нужно космическое железо и не одно, чего у меня нет и никогда не будет. PG потому, что советуют все для этой задачи, позиционируя как стабильность, скорость, возможности, поддержка, развитие. У меня помимо апи данных есть еще куча всего, что должно безопасно хранится и с этим я конечно же решу вопрос сам, а вот насчет апи данных и примерной структуры для них допустим в PG, если не затруднит конечно, то можно по подробнее? Я думаю так: каждый из запросов хранить в разных таблицах со штампом последней активности. далее раз в день например стартуем скрипт по зачистке от неактивных и переносим их в архив с той же структурой. если есть запрос на игрока, которого нет в активе, шелестим архив и восстанавливаем. Ну это все сейчас из башки взято, а вообще надо думать. Помогите чем сможете пожалуйста)) Кстати, ваша причина перехода с монги на пг обоснована тем, что по последним тестам пг оказалась быстрее? Edited November 22, 2017 by ruvirta @ Quote Link to comment Short link Share on other sites More sharing options...
sirmax Posted November 22, 2017 Share Posted November 22, 2017 (edited) По структуре ничего не смогу посоветовать, это зависит от каждой конкретной задачи, и чтобы сделать правильную структуру, необходимо глубоко погружаться в эту задачу. Причина перехода на pg - нам потребовалась аналитика, которую в монге сделать нельзя. А раз все равно уже есть pg, то нет смысла дальше держать еще и монгу. По производительности те задачи, которая выполняла монга, pg выполняет примерно так же. UPD: Еще можно в плюсы pg записать SQL. Для меня SQL намного привычней и удобней, чем запросы в монге на JSON. К тому же в pg можно выносить часть логики из бэка, что иногда позволяет оптимизировать слишком тяжелые запросы (хотя это уже за рамками NoSQL). Edited November 22, 2017 by sirmax @ Quote Link to comment Short link Share on other sites More sharing options...
ruvirta Posted July 2, 2018 Author Share Posted July 2, 2018 (edited) @sirmax Спасибо за советы. PG реально покрыло все нужды. Будь добр здесь еще вопросик по wn8 @sirmax Кстати мои небольшие тесты показывают, что jsonb немного тяжелее при записи и чтении против bytea(json to gzip). Даже при том, что я напрягаю проц при компрессии и декомпрессии, ну и соответственно вся логика в бэке. Я не думаю, что будет какая-то разница в производительности, если трогать json в запросе или же дернуть и трогать в бэке. И база по размерам на порядок меньше с bytea (gzip). Странно, ведь jsonb по сути тоже сжимается. Для тестов брал 500к игроков: - чистый текст json = 50gb - jsonb = 10gb - bytea(gzip) = 7.7gb Edited July 2, 2018 by ruvirta @ Quote Link to comment Short link Share on other sites More sharing options...
Recommended Posts
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.