Комментарии 23

Можно и кафку, но, в зависимости от модели: через event hub — ну нет там стольких сообщений (хотя вариант рабочий и я думал на этот счёт), через HDInsights — слишком дорого.

Если поднять виртуальную машину на ПК для вашего сервиса, то какие будут требования к характеристикам ПК?

Боюсь продакшн версию всего этого хозяйства не поднять, так как почти везде используются сервисы Azure: Azure Storage, Azure Functions, даже CosmosDB не поставляется on-premise. Разве что WebJob можно сделать на виртуалке, т.к. это просто dotnet приложение. Для себя\тестирования можно установить эмуляторы всего этого (в статье приводил ссылки на них) и тогда будет работать локально. Но, все же, это эмуляторы и они имеют некоторые ограничения.
даже докер контейнеров нету под все эти сервисы? почему это еще существует :D
Попробуйте использовать эти дампы. Файл galaxy.json.gz должен содержать всё вам нужно (осторожно, распаковывается в 100+ ГБ)
spansh.co.uk/dumps
Всё хорошо и интересно, но цены Ажура жутко напрягают…
Сам с ним работаю — в «enterprise» среде всё с ним прекрасно, работаю и радуюсь. Но для «home» проекта — цены в 50-200 EUR/мес (плюс различные неожиданные «промахи», как в случае с AppInsignts у автора)… это жуть.
Да, есть линия бесплатных планов для многих Ажурных сервисов, но на многое их не хватит, даже что бы поиграться с «home» проектом.
согласен полностью. для пет-проектов довольно кусаче, но т.к. тоже в интерпрайзе работаю с ажурой — решил попробовать на ней. но и в этом есть свой существенный плюс — при SaaS подходе с программиста спадает вся ответственность за администрирование, поддержку, стабильность, настройку и безопасность инфраструктуры. остается только программировать. кому-то это может показаться плевым делом (поднимать и настраивать VPS-ски и потом их админить), но я не фанат такого дела, так что решил занести в ажуру и не париться.
  1. Так как транзакции не используются (а cosmosdb их поддерживает), то между проверкой message.CheckIfItemExists и записью в базу в ней запросто может успеть появиться новый элемент, который будет перезаписан (потому что Upsert=Insert or replace, потому что merge документов CosmosDB не поддерживает). Т.е. потенциально basic может перезаписать detailed. Ну, по крайней мере до тех пор, пока кто-то ещё раз не пришлёт detailed.
  2. CheckIfItemExists как экстеншн на message? ну такоэ себе выворачивание функционала...
  3. По поводу экономии: каждый CheckIfItemExists — это запрос (1RU). Каждый Upsert — это 2(+) RU. Налицо минимум тройной перерасход. Возможно, имеет смысл копать в сторону batch-процессинга с промежуточным буфером. Накапливать за час/день, bulk'ом читать из cosmosdb, сверять статусы и отправлять в базу только новые/изменённые. Из того же EventHub можно просто читать пачками по offset'ам, насколько я помню — так что можно тригериться по таймеру и брать с прошлого оффсета, никакое промежуточное хранилище не нужно.
1. тут правы. пока статья была на модерации, я уже успел прикрутить туда Optimistic Concurrency Control. В репе версия уже с ним, в статье обновлять не стал
2. +\- согласен. можно вынести, чтоб не засорять message
3. тут тоже соглашусь, опять же, пока шла модерация, я выяснил что Read операции стоят сильно дешевле и на этом можно неплохо сэкономить. Начал думать (и делать) в эту сторону, но столкнулся с другой проблемой: как проверить валидность сообщения? ведь входной канал у EDDN не поддерживает авторизации и заслать туда сообщение можно с любой биллибердой сколько угодно раз. Так что кто-то, теоретически, может сильно засорить данные. В EDSM для этого предусмотрен механизм валидации — одно и то же сообщение должно придти минимум от 3-х разных пилотов и, так как там есть аворизация, они могут себе это позволить. Ну а у меня пока upsert с надеждой что сообщение будет перезаписано другим пилотом. Пока разбираюсь что делать.
В EventHub и bulk тоже уже смотрю, как на средство нормально сэкономить, но, опять же, это усложнит валидацию сообщений (если я ее все же придумаю). Если валидации не будет, то можно спокойно делать булки

Ну а вообще стоит посчитать такой вариант: виртуалка типа B* на убунте с монгой(постгрёй? :)) в качестве процессинга/кэша, которая периодически скидывает в CosmosDB обновления. Виртуалка будет стоить копейки: B1S (1cpu,1gb) в регионе Switzerland North в 1year reserved обходится в $4.25/month. Там на графике 2М вызовов Azure Functions за трое суток это в среднем 8rps. Даже такой калькулятор справится с запасом :)
CosmosDB оставить чисто как reliable storage и для удобных запросов/аналитики/графиков. Там на
Да, это не будет уже стильно-модным-молодёжным saas, но значительно дешевле кмк :)

я понимаю, что виртуалка будет сильно дешевле, но очень не хочу с ней связываться не из-за модности, а из-за того что не хочу отвечать за монги, постгресы и т.п. бэкапы, реплики, кластеры и вот это все — это излишний гемор. А так да, первая версия проекта работала на VPS-ке с постгресом (т.е. я даже приводил модель в реляционный вид, это был мрак) и стоило это все ~10 баксов в месяц

Можно было не приводить в реляционный вид, а хранить в json-поле в постгре. Причём можно извернуться и даже смёржить json при обновлениях, если нужно.
Можно без реплик/бэкапов, если собрать докер-образ — и обновлять проще и запускать можно где угодно, хоть на той же виртуалке в azure. Ведь если CosmosDB использовать как хранилище, то бэкапы читалки не нужны :)

  1. Раз уж использовалась реляционная субд — хотелось использовать все ее преимущества.
  2. Каким образом докер отменяет необходимость бэкапов и повышает стабильность? Что если этот колхоз упадёт? Кубернетес мутить?
    Про читалки совсем не понял
Особенно радует строчка с % исследованных систем. Это за 6 лет существования игры. Но сейчас не об этом.


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

Для тех кто дотерпел до конца и все еще заинтересован где искать землеподобные планеты в элите, вот вам ответ


Получается это графическое представление настроек генератора случайных звездных систем))

Да, EDSM (и все остальные) накапливает только данные, которые отправляет специальный софт. Кто его не использует — те конечно не пополняют эту базу. Но других источников нет, не было и, скорее всего не будет, т.к. FD не собираются отдавать данные о галактике (на этом завязано много мистификаций в игре, та же Raxxla). Так что это максимальный объём информации, доступный игрокам. Иногда FD делятся частью своей статистики и, согласно их показаниям, пилоты открыли 0.02% галактики. Это не сильно отличается от показателя EDSM (0.015%)


И нет, никаких случайных генераторов там нет. Статистические результаты могут не совпасть с реальностью из-за неполных данных (представим что остальная часть галактики состоит из белых карликов и там вовсе нет землеподобных планет). Ну так и график показывает — у каких систем пилоты чаще встречали эти планеты. Т.е. речь не об открытии новых в контексте галактики, они могут быть новыми для конкретного пилота (который ещё не посещал эту систему)

Ну я не думаю, что авторы элиты уже сгенерили все сколько там миллиардов звезд и игроки просто посещают их и уж тем более это не реальная галактика, а просто с похожими характеристиками и некоторыми звездами из реальной. Я думаю скорее всего игроки «находят» и, и при первом посещении звездной системы игра генерит эту звездную систему с планетами и прочим своим генератором солнц. Даже не звезду, а просто seed какой то, а от него все остальные аттрибуты звездной системы. Иначе никаких серверов не хватит на хранение всех орткрытых звезд. А вот просто некое число запросто. Может и того даже нет, а есть исходный сид для всей галактики и от него считаются алгоритмами все звезды. Типа «big bang» + детерминизм всей нашей жизни в действии ))) Просто игроки этих алгоритмов не знают, вот и приходится хранить все данные о звездах и планетах в базе, котя все можно наверное сжать в точку «вернувшись на 13 миллиардов лет назад».

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

Вы все верно предположили. действительно есть некий seed (матрица) и некие законы (гармоники) генерации звездных систем. но они не случайны (именно потому что есть зерно и алгоритмы). Случайно сгенерить галактику довольно проблемно — у звездного тела в элите с полтора десятка параметров, представьте что будет если просто случайно генерировать их значения? К тому же галактика (и реальная и элитовская) — не однородная. некоторые регионы, например центр, более горячие, некоторые (окраины) более холодные (речь идет о типах звезд свойственных тому или иному региону галактики). Такая закономерность и в реальной галактике и в виртуальной элитовской. Нельзя просто случайно раскидать звезды — такая галактика не сможет существовать. И этот алгоритм у FD иногда дает очень забавные результаты. Например (на хабре вроде даже была новость про это пару лет назад) когда в реале открыли планету Trappist-1 — точно такую (ну или очень похожую) и на том же самом месте в галактике нашил и в элите =) И это не разработчики ее туда поместили, это сгенерил алгоритм. В общем назвать это все случайной генерацией никак нельзя. Она, если можно так выразиться, пре-сгенерированная.
P.S. А и да, чуть не забыл. Все системы видны на карте, если вы не играли в элиту поясню: у вас есть карта галактики, которая содержит все 400ккк систем. Вы перемещаетесь строго от системы в систему, т.е. это не так что вы летите неизвестно куда и хоп, новая система. Нет, вы явно выбираете на карте куда лететь. Карта как бы "распаковывается" или "генерируется" при зуме на определенном участке, который FD называют "бокселем". Это фактически куб. Галактика у них состоит из кубов. Так вот, когда вы приближаете карту к определенному бокселю — игра распаковывает из сида и гармоник стабильный набор систем в этом бокселе. Как-то так. Более подробней они рассказывали в своем интервью на ютубе, но что-то на скорую руку не смог его найти.

F, K, G, A типы и, почему-то, нейтронки составляют топ 5 типов звезд у которых пилоты находили землеподобные планеты.

Предположу, что имеет место проблема в том, что Вы сделали статистику без поправки на распределение звезд по типам. И это, поскольку KGB FOAM — самые распространенные (и еще чаще изучаемые, так как исследователи чаще в них задерживаются чтобы запрвавиться) дает Вам искажение статистики появления землеподобных планет в их пользу. Нейтронные звезды тоже значительно более популярны, чем должны при их небольшой доле в общем распределении, потому что их используют для FSD boost.

Честно говоря — не помню и запросов с тех времён не сохранилось (только картинка и сохранилась). Но ваше рассуждение выглядит логично, так что надо будет построить это распределение ещё раз, на новых данных и с учетом распределения типов звёзд.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.