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

ruvirta

Пользователь
  • Публикации

    15
  • Зарегистрирован

  • Посещение

Репутация

0 Нуп

О ruvirta

  • День рождения 27.01.1988

Основная информация

  • Пол
    Мужчина
  • Город
    Нижний Новгород
  • Интересы
    Противоположный пол

Контакты

  • Ник
    Platinum_Account
  • Сервер WoT
    RU / CIS
  • Skype
    ruvirta
  1. ruvirta

    WN8 (рейтинг): формула и обсуждение

    @sirmax я на тот сайте первый раз, как думаешь если запостить тему по блицовому wn8, там поддержут? кстати перестали листаться страницы именно в той теме, выводит цифру 78 на пустой странице, это только у меня так?
  2. ruvirta

    WN8 (рейтинг): формула и обсуждение

    @sirmax ну я примерно так и думал. У себя я брал за последний месяц. А к кому идти за формулой для нас, может подскажешь опытного игрока или все же лучше поискать среди wotb юзеров
  3. ruvirta

    WN8 (рейтинг): формула и обсуждение

    @sirmax полностью согласен, может в будущем с помощью опытных игроков мы и вычислим правильную формулу для нас, ну а пока ничто же не мешает использовать что уже есть. А вы цепляете всех игроков при вычислении wn8 или тех кто был активен в ближайший месяц например? тоесть со статой посвежее, ведь wg api тоже с интевалом обновляется.
  4. ruvirta

    WN8 (рейтинг): формула и обсуждение

    @sirmax Спасибо. Я сейчас читаю эту тему. Сам wn8 я уже реализовал, отбирал от 1к боев и от 50 на танке. Результат с 1кк игроков wot blitz выглядит так http://battleinterfaces.com/wn8/wn8exp.json А с учетом того, что у нас бои в два раза меньше по времени, мне наверно надо увеличить ваши 10к и 100 в два раза.
  5. ruvirta

    WN8 (рейтинг): формула и обсуждение

    @sirmax Спасибо, обязательно почитаю. Под параметрами отбора я имел ввиду как написано в wiki wn8 то, что участвовали только игроки с 1000+ боев и танки 50+ боев. А еть ли еще что-то?
  6. @sirmax Спасибо за советы. PG реально покрыло все нужды. Будь добр здесь еще вопросик по wn8 @sirmax Кстати мои небольшие тесты показывают, что jsonb немного тяжелее при записи и чтении против bytea(json to gzip). Даже при том, что я напрягаю проц при компрессии и декомпрессии, ну и соответственно вся логика в бэке. Я не думаю, что будет какая-то разница в производительности, если трогать json в запросе или же дернуть и трогать в бэке. И база по размерам на порядок меньше с bytea (gzip). Странно, ведь jsonb по сути тоже сжимается. Для тестов брал 500к игроков: - чистый текст json = 50gb - jsonb = 10gb - bytea(gzip) = 7.7gb
  7. ruvirta

    WN8 (рейтинг): формула и обсуждение

    Привет разрабам XVM от BINT-а (Wot Blitz). Объясните пожалуйста нубу по каким критериям именно вычислять медианы для ожидаемых значений wn8? Тоесть интересует начиная с того момента как идет выборка с БД танков игроков. Буду очень признателен за помощь!
  8. Привет опять. В общем выбор почти сделан в пользу либо HBase либо PG с его nosql возможностями. Сейчас буду подробно разбираться с каждым по отдельности. HBase потому, что java и я в ней шарю и мне все прозрачно, но она больше для BigData т.е. для миллиардов данных для которых нужно космическое железо и не одно, чего у меня нет и никогда не будет. PG потому, что советуют все для этой задачи, позиционируя как стабильность, скорость, возможности, поддержка, развитие. У меня помимо апи данных есть еще куча всего, что должно безопасно хранится и с этим я конечно же решу вопрос сам, а вот насчет апи данных и примерной структуры для них допустим в PG, если не затруднит конечно, то можно по подробнее? Я думаю так: каждый из запросов хранить в разных таблицах со штампом последней активности. далее раз в день например стартуем скрипт по зачистке от неактивных и переносим их в архив с той же структурой. если есть запрос на игрока, которого нет в активе, шелестим архив и восстанавливаем. Ну это все сейчас из башки взято, а вообще надо думать. Помогите чем сможете пожалуйста)) Кстати, ваша причина перехода с монги на пг обоснована тем, что по последним тестам пг оказалась быстрее?
  9. Да, я изменил пост и добавил про PostgreSQL. Ну про 100m да, возможно загнул. Но лучше так сказать перебздеть, чем недобздеть, ибо жизнь то долгая, все может произойти. Колоночные таблицы или их аналог (column family) как раз таки есть например в HBase (nosql) и по слухам это работает гораздо бытрее SQL. Ну а как насчет хранить все api данные так как есть(json)? Тоесть мне они реально нужны именно ВСЕ. Опять же забыл, что некоторые даные будут обновляться очень часто. Тоесть у нас есть некоторая разница и функционал BINT этого требует. Если бы это было только обновление api данных в какой-то период времени, то я бы уже сделал свой выбор в пользу любой SQL. Может важно: 75000 юзеров это за 1 месяц использования небольшим количеством юзеров BINT. Тоесть бои у нас мах 7 мин. , а обычно это 4-5 мин. Это может быть причиной быстрого роста базы.
  10. В общем хочу по на эту тему пообщатся с бывалыми. Есть уже рабочее приложение и временная(тестовая) база из которой в конечном итоге должно быть все перекинуто в нормальную базу, над которой я до сих пор думаю и ошибок быть не должно. Я собираюсь хранить все 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 не моя тема и я в ней не так давно.
  11. Во всех языках есть плюсы и минусы. В одном проекте может использоваться несколько языков одновременно. Начните с Hello World любого языка и по ходу событий в вашей голове (а это либо "ахтунг" либо "ниче так") поймете, что вам по душе и интелекту. Я сам Java любитель/копипастер, прочитал пару книг по яве и по андроиду, через месяц родил полноценное приложение. Ява в моем случае проще прилипапа к извилинам. После явы (хз почему, ибо должно быть наоборот) все остальные языки мне показались проще и сейчас я 50/50 во всех их шарю.
  12. ruvirta

    [Android] Аналог XVM для WoT Blitz

    Все, что возможно - это создать разметку, а вот заставить код работать с ней - проблематично.
  13. ruvirta

    [Android] Аналог XVM для WoT Blitz

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