Comments 23
Если поднять виртуальную машину на ПК для вашего сервиса, то какие будут требования к характеристикам ПК?
spansh.co.uk/dumps
Сам с ним работаю — в «enterprise» среде всё с ним прекрасно, работаю и радуюсь. Но для «home» проекта — цены в 50-200 EUR/мес (плюс различные неожиданные «промахи», как в случае с AppInsignts у автора)… это жуть.
Да, есть линия бесплатных планов для многих Ажурных сервисов, но на многое их не хватит, даже что бы поиграться с «home» проектом.
- Так как транзакции не используются (а cosmosdb их поддерживает), то между проверкой
message.CheckIfItemExistsи записью в базу в ней запросто может успеть появиться новый элемент, который будет перезаписан (потому что Upsert=Insert or replace, потому что merge документов CosmosDB не поддерживает). Т.е. потенциально basic может перезаписать detailed. Ну, по крайней мере до тех пор, пока кто-то ещё раз не пришлёт detailed. - CheckIfItemExists как экстеншн на message? ну такоэ себе выворачивание функционала...
- По поводу экономии: каждый CheckIfItemExists — это запрос (1RU). Каждый Upsert — это 2(+) RU. Налицо минимум тройной перерасход. Возможно, имеет смысл копать в сторону batch-процессинга с промежуточным буфером. Накапливать за час/день, bulk'ом читать из cosmosdb, сверять статусы и отправлять в базу только новые/изменённые. Из того же EventHub можно просто читать пачками по offset'ам, насколько я помню — так что можно тригериться по таймеру и брать с прошлого оффсета, никакое промежуточное хранилище не нужно.
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, но значительно дешевле кмк :)
Можно было не приводить в реляционный вид, а хранить в json-поле в постгре. Причём можно извернуться и даже смёржить json при обновлениях, если нужно.
Можно без реплик/бэкапов, если собрать докер-образ — и обновлять проще и запускать можно где угодно, хоть на той же виртуалке в azure. Ведь если CosmosDB использовать как хранилище, то бэкапы читалки не нужны :)
Особенно радует строчка с % исследованных систем. Это за 6 лет существования игры. Но сейчас не об этом.
Но я так понимаю, что через сервис идут данные только тех игроков, кто запустил агента на своем компьютере. То-есть иследованно может быть и больше. Тем более сервис запущен не с самого начала.
Для тех кто дотерпел до конца и все еще заинтересован где искать землеподобные планеты в элите, вот вам ответ
Получается это графическое представление настроек генератора случайных звездных систем))
Да, EDSM (и все остальные) накапливает только данные, которые отправляет специальный софт. Кто его не использует — те конечно не пополняют эту базу. Но других источников нет, не было и, скорее всего не будет, т.к. FD не собираются отдавать данные о галактике (на этом завязано много мистификаций в игре, та же Raxxla). Так что это максимальный объём информации, доступный игрокам. Иногда FD делятся частью своей статистики и, согласно их показаниям, пилоты открыли 0.02% галактики. Это не сильно отличается от показателя EDSM (0.015%)
И нет, никаких случайных генераторов там нет. Статистические результаты могут не совпасть с реальностью из-за неполных данных (представим что остальная часть галактики состоит из белых карликов и там вовсе нет землеподобных планет). Ну так и график показывает — у каких систем пилоты чаще встречали эти планеты. Т.е. речь не об открытии новых в контексте галактики, они могут быть новыми для конкретного пилота (который ещё не посещал эту систему)
Может и ошибаюсь, но мне представляется это более логичным, чем 400 миллиардов записей в базе данных.
Вы все верно предположили. действительно есть некий seed (матрица) и некие законы (гармоники) генерации звездных систем. но они не случайны (именно потому что есть зерно и алгоритмы). Случайно сгенерить галактику довольно проблемно — у звездного тела в элите с полтора десятка параметров, представьте что будет если просто случайно генерировать их значения? К тому же галактика (и реальная и элитовская) — не однородная. некоторые регионы, например центр, более горячие, некоторые (окраины) более холодные (речь идет о типах звезд свойственных тому или иному региону галактики). Такая закономерность и в реальной галактике и в виртуальной элитовской. Нельзя просто случайно раскидать звезды — такая галактика не сможет существовать. И этот алгоритм у FD иногда дает очень забавные результаты. Например (на хабре вроде даже была новость про это пару лет назад) когда в реале открыли планету Trappist-1 — точно такую (ну или очень похожую) и на том же самом месте в галактике нашил и в элите =) И это не разработчики ее туда поместили, это сгенерил алгоритм. В общем назвать это все случайной генерацией никак нельзя. Она, если можно так выразиться, пре-сгенерированная.
P.S. А и да, чуть не забыл. Все системы видны на карте, если вы не играли в элиту поясню: у вас есть карта галактики, которая содержит все 400ккк систем. Вы перемещаетесь строго от системы в систему, т.е. это не так что вы летите неизвестно куда и хоп, новая система. Нет, вы явно выбираете на карте куда лететь. Карта как бы "распаковывается" или "генерируется" при зуме на определенном участке, который FD называют "бокселем". Это фактически куб. Галактика у них состоит из кубов. Так вот, когда вы приближаете карту к определенному бокселю — игра распаковывает из сида и гармоник стабильный набор систем в этом бокселе. Как-то так. Более подробней они рассказывали в своем интервью на ютубе, но что-то на скорую руку не смог его найти.
F, K, G, A типы и, почему-то, нейтронки составляют топ 5 типов звезд у которых пилоты находили землеподобные планеты.
Предположу, что имеет место проблема в том, что Вы сделали статистику без поправки на распределение звезд по типам. И это, поскольку KGB FOAM — самые распространенные (и еще чаще изучаемые, так как исследователи чаще в них задерживаются чтобы запрвавиться) дает Вам искажение статистики появления землеподобных планет в их пользу. Нейтронные звезды тоже значительно более популярны, чем должны при их небольшой доле в общем распределении, потому что их используют для FSD boost.
Elite: Dangerous и CosmosDB