Комментарии 38
Прекрасная история получилась, 100500 мелких проектов развиваются именно так: начинают с полного незнания того, что такое базы данных и Linux, и заканчивают вполне определенным успехом. Главное мотивация!
Ну нельзя сказать что мы не знаем что такое БД и Linux. :)
Просто этот проект изначально начинался, да и продолжается до сих пор как хобби, в основном чтобы отдохнуть от правил и ограничений, которые существуют на основной работе. Так что мы тут специально позволяем себе некоторые вольности, не от незнания, а больше ради экспериментов, которые при других условиях сложно себе позволить.
Просто этот проект изначально начинался, да и продолжается до сих пор как хобби, в основном чтобы отдохнуть от правил и ограничений, которые существуют на основной работе. Так что мы тут специально позволяем себе некоторые вольности, не от незнания, а больше ради экспериментов, которые при других условиях сложно себе позволить.
Очень интересная история об эволюции back-end'а мода.
А вы не пытались вести диалог с WG о том, чтоб сократить количство запросов и вернуть данные одним специальным запросом? Технически то это возможно, но вот какова политика партии?
А вы не пытались вести диалог с WG о том, чтоб сократить количство запросов и вернуть данные одним специальным запросом? Технически то это возможно, но вот какова политика партии?
Само по себе большое число запросов ни нам ни WG не мешает. Мы бы укладывались и в текущие лимиты, если бы их можно было использовать на 100%. Проблема в том, что запросы с детальной статистикой по танкам — тяжелые для серверов WG. Они уже неоднократно эти методы ускоряли (раньше было хуже). Как только скорость методов отдачи статистики станет такой, что проблема лишних запросов станет более приоритетной — будем говорить с ними и о такой оптимизации.
Кстати об ID пользователя, тоже в свое время заинтересовала эта проблема (году где-то в 2012). Решение нашлось, как тогда, так и сейчас работает ссылка вида worldoftanks.ru/community/accounts/named/UserName
А еще интересно: сейчас, в бескостыльные времена public api, есть ли какие-то другие причины, помимо активации пользователем вашего мода на сайте, на то, чтобы напрягать ваш сервер обслуживать миллионы пользователей?
Почему бы не отправлять запросы к API непосредственно с клиентского компьютера и там их обрабатывать? Будет и real-time статистика и не будет нагрузки на ваш сервер. Сервера WG возможно пострадают, но компания крупная, думаю сможет смасштабироваться.
Почему бы не отправлять запросы к API непосредственно с клиентского компьютера и там их обрабатывать? Будет и real-time статистика и не будет нагрузки на ваш сервер. Сервера WG возможно пострадают, но компания крупная, думаю сможет смасштабироваться.
К сожалению масштабы бедствия таковы, что прямые запросы от всех желающих и близко не могут быть обработаны серверами WG. И, кстати, этот вариант тоже потребует активации, только уже на сайте WG.
А что активировать на сайте WG? :) Вы предлагаете каждому юзеру свой токен у варгейминга получать?
Смотрите: возьмем, скажем, API Хабрахабра и его официальное приложение для Android. Разработчик получил токен для приложения, написал его и залил в play маркет. Тысячи пользователей его скачали и пользуются, на сайте ничего не активировали, кроме подтверждения прав приложения. Также и с VK API, и с любым нормальным API.
А проблемы нагрузки на WG, по-моему, они должны их решать, иначе зачем делать public api, которое банально не будет справляться с нагрузками? :)
Смотрите: возьмем, скажем, API Хабрахабра и его официальное приложение для Android. Разработчик получил токен для приложения, написал его и залил в play маркет. Тысячи пользователей его скачали и пользуются, на сайте ничего не активировали, кроме подтверждения прав приложения. Также и с VK API, и с любым нормальным API.
А проблемы нагрузки на WG, по-моему, они должны их решать, иначе зачем делать public api, которое банально не будет справляться с нагрузками? :)
У WG надо будет получать свой application_id, если следовать их соглашению об использовании API. Т.к. свой id светить нельзя, а для application_id=demo есть ограничения.
Пока не обсуждали с WG такой вариант. При случае узнаем что они об этом думают.
Пока не обсуждали с WG такой вариант. При случае узнаем что они об этом думают.
Да, под токеном app_id и имел ввиду, мысли путаются уже к полвторому ночи %)
Надеюсь, WG посмотрит как делают API большинство сервисов. В моем видении идеально оно сделано у VK.
А вам большое спасибо за нужный и полезный мод, хоть сейчас я в WoT и не играю, но большую часть моего игрового времени я провел с XVM. И успехов вам в дальнейшей разработке! :)
Надеюсь, WG посмотрит как делают API большинство сервисов. В моем видении идеально оно сделано у VK.
А вам большое спасибо за нужный и полезный мод, хоть сейчас я в WoT и не играю, но большую часть моего игрового времени я провел с XVM. И успехов вам в дальнейшей разработке! :)
Число попаданий в наш кэш — более 95%. Текущая архитектура WG API не потянет.
Классная статья, таких давно на хабре не видел, с подробностями не маркетинга а именно технических моментов. Однако мне кажется что хранение данных в монге в данном случае не оправдано, тут больше пошёл бы посгрес, и даже тот же самый мускуль с хорошо заданными индексами. По сути нужно несколько таблиц. Пользователи, танки, таблица связи пользователя с танком. В таблица с пользователями хранить пользовательскую стату, в таблице танки хранить статы танков. Мне кажется мускул тут будет шустрее монги. В танки не играю, поэтому что в статах не знаю, но в целом думаю схема будет достаточно общая. И попробуйте ещё Go Lang, по производительности он очень даже не плох, особенно если хорошо продумать его архитектуру, плюс нет таких проблем с зависимостями как у D. :)
Еще раз большое спасибо за статью.
Еще раз большое спасибо за статью.
Монга как раз идеально подходит. Вернее даже задача идеально подходит для монги. Выбор NoSQL полностью оправдан. У нас тут чистейший AdHoc.
Вы недооцениваете возможности PostgreSQL в рамках «nosql» решений. Я бы сказал в данный момент она лучшая для этого.
У меня на данных вида (timestamp long, id varchar(255), json blob-text, pkey вообще нет) PostgreSQL с несколько убавленой надежностью обгоняет монгу раз в 5. Если надежность не убавлять — тоже обгоняет. Если в выборке есть аггрегирование пострес справляется за секунды, а монгу мне вообще лень ждать становится. Объем данных — более 54,000,000 строк в таблице. Общий объем примерно 4 Гб, btree индекс. Машина: Core2Duo на 2.4, 6 Гб оперативной, обычный хард.
Так что мой вам совет: бросайте монгу и переходите на Пострес.
У меня на данных вида (timestamp long, id varchar(255), json blob-text, pkey вообще нет) PostgreSQL с несколько убавленой надежностью обгоняет монгу раз в 5. Если надежность не убавлять — тоже обгоняет. Если в выборке есть аггрегирование пострес справляется за секунды, а монгу мне вообще лень ждать становится. Объем данных — более 54,000,000 строк в таблице. Общий объем примерно 4 Гб, btree индекс. Машина: Core2Duo на 2.4, 6 Гб оперативной, обычный хард.
Так что мой вам совет: бросайте монгу и переходите на Пострес.
Давно не следил за PostgreSQL, хотя использую ее еще с конца 90х. В частности, на POS'ах она у нас уже более 10 лет работает. Действительно, в 9.3 появилась работа с JSON, стоит посмотреть.
В 9.4 Json сделали бинарным, я еще на него с 9.3 не перешел, но рост в производительности обещают от 10 до 150 раз.
Вот эти два документа должны вас окончательно убедить, я думаю:
wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
www.pgcon.org/2014/schedule/attachments/318_pgcon-2014-vodka.pdf
Вот эти два документа должны вас окончательно убедить, я думаю:
wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
www.pgcon.org/2014/schedule/attachments/318_pgcon-2014-vodka.pdf
PG 9.3 зарелизили только 2013-09-09, так что когда мы выбирали монгу, он еще не умел работать с JSON'ом.
В общем, попробуем, посмотрим что получится. Спасибо за информацию.
В общем, попробуем, посмотрим что получится. Спасибо за информацию.
Последний мой вам совет, за который меня сейчас закидают помидорами: если очень нужна скорость и есть отдельный сервер для резервного кластера, то вырубайте fsync и full_page_writes на уровне кластера и используйте unlogged таблицы. Постгрес ускоряется в 100500 раз ценой краша ВСЕХ данных в случае сбоя. Или держите два кластера: нормальный мастер для обычной работы и его полностью расторможенную копию на случай высокой нагрузки, и переключайте в случае чего. Ну и вагон памяти, настройка random_page_cost, effective_cache_size и вы забудете о mongo.
А клиент с патчем не может сам предоставлять необходимую информацию? Хотя такая фича не подходит — для этого необходимо чтобы все в рандоме были с патчем.
Либо кэширование на определённое время, не думаю что статистика игрока с 10к боев поменяется, скажем, за сутки.
Вообще при таком количестве запросов у любого API будут проблемы. Оптимизировать их можно бесконечно, всё равно будешь упираться в скорость сети.
Логичным решением было бы либо хоститься вместе, либо разделять базу игроков, но это, думаю, вам может светить только после какой-либо коммерциализации, насчёт этого не было мыслей?
Сам после выхода 9 версии ВОТ не играю, и хочу спросить — меня интересует — есть ли спад количества игроков и от чего он зависит? Скоро снова в школу, будет ли увеличение игроков? Ну и т.п. тенденция, плиз. Этого варгейминг никогда не скажет.
Либо кэширование на определённое время, не думаю что статистика игрока с 10к боев поменяется, скажем, за сутки.
Вообще при таком количестве запросов у любого API будут проблемы. Оптимизировать их можно бесконечно, всё равно будешь упираться в скорость сети.
Логичным решением было бы либо хоститься вместе, либо разделять базу игроков, но это, думаю, вам может светить только после какой-либо коммерциализации, насчёт этого не было мыслей?
Сам после выхода 9 версии ВОТ не играю, и хочу спросить — меня интересует — есть ли спад количества игроков и от чего он зависит? Скоро снова в школу, будет ли увеличение игроков? Ну и т.п. тенденция, плиз. Этого варгейминг никогда не скажет.
Когда были проблемы с обновлениями, мы думали об этом, но отказались из соображений безопасности. По определению клиент — это враг, и данные с него могут быть подделаны, что полностью скомпрометирует всю идею.
Кэширование на клиенте не нужно — в рандоме попаданий в кэш очень мало, да и узким местом является именно WG API, а не наш сервер. Есть несколько идей как это улучшить, мы как раз обсуждаем их с WG.
В целом, обновления статистики раз в неделю вполне достаточно, но есть психологический момент — себя, любимого, пользователи хотят обновлять чаще. Вплоть до того, что сидят часами, лишь бы увеличить рейтинг еще на единичку. Поэтому пользователей мода мы обновляем чаще.
Спада игроков в общем-то нет, в июле немного уменьшилось, сейчас немного увеличилось, в целом особо не изменилось, количество пользователей с активированной статистикой держится в районе 1.2 млн. В статье есть скрин мониторилки, на нем в принципе все видно (только на годовом графике есть сильный спад — надо смотреть после него, а то у нас криво считалось изначально).
Кэширование на клиенте не нужно — в рандоме попаданий в кэш очень мало, да и узким местом является именно WG API, а не наш сервер. Есть несколько идей как это улучшить, мы как раз обсуждаем их с WG.
В целом, обновления статистики раз в неделю вполне достаточно, но есть психологический момент — себя, любимого, пользователи хотят обновлять чаще. Вплоть до того, что сидят часами, лишь бы увеличить рейтинг еще на единичку. Поэтому пользователей мода мы обновляем чаще.
Спада игроков в общем-то нет, в июле немного уменьшилось, сейчас немного увеличилось, в целом особо не изменилось, количество пользователей с активированной статистикой держится в районе 1.2 млн. В статье есть скрин мониторилки, на нем в принципе все видно (только на годовом графике есть сильный спад — надо смотреть после него, а то у нас криво считалось изначально).
Скажите, а как вы отказались от Dokan? Можно подробней как обошли ограничение.
Впереди будет еще одна часть, которая расскажет о самом интересном — развитии клиентской части модификации.
Наверное, скажут в третьей части :)
В двух словах — перешли на игровой питон, в нем нет ограничений для работы с сетью. Хотя есть и свои приколы — в частности нет поддержки SSL, и нельзя подключать бинарные либы, так что пришлось для HTTPS использовать pure-python библиотеку tlslite.
Нет мыслей поиграться с С/С++?
Если вам нужны бэкендщики еще — я буду рад помочь. И да, насчет постгрес — правда попробуйте)
НЛО прилетело и опубликовало эту надпись здесь
Забавно, что начальный наколенный вариант на PHP, раздающий статику, можно было бы без проблем горизонтально отмасштабировать до 5-6к запросов в сек при том же уровне затрат.
(И да, в том случае в VPS возникали еще и проблемы с полным количеством inode-ов в системе).
(И да, в том случае в VPS возникали еще и проблемы с полным количеством inode-ов в системе).
Ну можно было ее на уровне веб-сервера отдавать, а при cache miss уже идти до пхп
Ты просто забыл, что мы уже начали упираться в IO и стали думать насчет memcached. С монгой мы просто пошли чуть дальше. Так что про 5-6к ты немного преувеличиваешь. :)
Мы уперлись в inode-ы, поэтому и думали, как это обойти на том VPS
По CPU, IO (с отключенными логами nginx, хехе) и памяти там запас был огромный + задача отлично могла бы работать на нескольких инстансах через LB.
Про преувеличение — на прошлом месте работы прекрасно летало 3-5к запросов в минуту к динамике. :-P
По CPU, IO (с отключенными логами nginx, хехе) и памяти там запас был огромный + задача отлично могла бы работать на нескольких инстансах через LB.
Про преувеличение — на прошлом месте работы прекрасно летало 3-5к запросов в минуту к динамике. :-P
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы делали XVM — популярный мод для World of Tanks. Часть вторая: развитие серверной части