Я знаю для чего нужна ССО. Но я не вижу в публикации указания на это. Судя по вики при периоде обращения в 90 минут и наклонении в 96.6°, высота орбиты должна быть 274 км, что несколько отличается от указанного в публикации.
И цена эта была не для НАСА, а для коммерческих компаний
А мы об этом и говорим, так как стоимость запусков для NASA не включают в себя те миллиарды долларов, которые уже были ей затрачены на оплату разработок той же SpaceX.
Её нет смысла учитывать, так как она все равно необходима для одной из основной целей орбитальной станции - проведения экспериментов, требующих наличия уникальных условий космического полёта. Тестирование оборудования - это лишь дополнение к основным целям.
Вы не привели источник, а по моим данным, стоимость доставки килограмма груза на МКС у NASA сейчас от $3000, тогда как стоимость вывода килограмма на НОО (до 180 км, что более, чем в два раза ниже орбиты МКС) - от $45500. Разница на порядок. Скорее всего, Вы сравнили массу полезной нагрузки в грузовом корабле с полной стартовой массой при выводе спутника.
И это даже без учета того, что для тестирования оборудования на орбитальной станции нужно доставить только само оборудование, а для спутника необходима на порядки большая масса для систем питания, ориентации, связи и т.п.
Ваше утверждение верно, если содержать орбитальную станцию только для тестирования оборудованию. Но у неё сотни иных задач, которые спутники решить не могут.
А с чего Вы решили, что тестироваться на станции будет не оборудование, которое планируется использовать на спутниках, а фото-мыльницы? У меня противоположная информация.
А чисто тестировать оборудование - зачем там, опять же, обзор полюсов?
На мой взгляд, потому, что, во-первых, доставить тестируемое оборудование на орбиту очередным грузовиком заметно дешевле, чем отдельным автоматическим спутником. Во-вторых, возможности тестирования непосредственно человеком намного выше, чем удаленно в автоматическом режиме. В-третьих, сильно различаются требования к оборудованию, для примера, контроля ледовой обстановки у полюсов и экваториальной зоны. Это даже не считая различий в силе и направлении магнитных полей у экватора и вблизи полюсов, что тоже нужно учитывать.
Могу предположить, что для того, чтобы облет всей поверхности планеты производился быстрее. Иными словами, чтобы для сканирования всей поверхности Земли требовалось меньше оборотов станции вокруг неё.
Уже давно используем schema registry с protobuf в confluent. Никаких ограничений по сравнению с avro не обнаружили.
А исходя из того, что даже если gRPC ещё не используется, то есть заметная вероятность его использования в будущем, выбор protobuf выглядит более оправданным.
Остальные критерии не столь существенны. Avro чуть компактней, protobuf чуть меньше загружает CPU.
безаппеляционно заявлять про 50-80% экономии трафика на gRPC по сравнению с REST - это большое лукавство
Бритва Хэнлона. Это, скорее, ошибка, чем лукавство, так как не указано было, что речь идет исключительно о несжатых данных. В случае компрессии выигрыш 10-60%, в зависимости от количества бинарных данных и размеров пакета. Что, впрочем, тоже не мало.
gRPC по сравнению с REST
Protobuf по сравнению с JSON. Нужно отделять мух от котлет. gRPC не обязан использовать именно protobuf. Все же потоковый gRPC (HTTP/2) дает заметные преимущества перед REST в некоторых сценариях использования. Например, сервис прогнозируемых курсов валют на активном двунаправленном потоковом gRCP в локальной сети вполне может давать ответ на запрос за 1 мс. На REST такого достигнуть мало реально.
Не хватает данных по себестоимости (а она, по косвенным признакам, немаленькая), КПД (который более-менее приемлемым тут может быть только на очень низких оборотах) и стоимости владения (частоте технического обслуживания, например, по замене сальников).
выигрыш в 2+ раза - это скорее небольшой по размеру пакет
А я писал: "на небольших пакетах более чем в два раза". Вы это повторно не увидели?
Не спец в python
Но на proto то можно было посмотреть, раз именно его обсуждаем? Бинарный protobuf экономит место для чисел, но уж никак не для строк. А в репозитории по ссылке его старательно грузят преимущественно строками, на которых по определению заметной разницы между бинарным и текстовым форматом быть не может.
А если посмотреть, например, сюда, то получаем уже числа близкие к приведенной мной статистике по топикам Кафки. Если еще учесть, что текстовой информации у меня очень мало, а преимущественно - числа с фиксированной десятичной точкой и перечисления (то есть целые числа с точки зрения protobuf), то выигрыш более чем в два раза на небольших пакетах оказывается вполне ожидаем.
В контексте web-разработки
В контексте применимости RPC, пакеты могут любыми. С точки зрения скорости прохождения сообщений (реакции системы), они наоборот должны быть маленькими.
Даже в web-разработке для меня странно гонять десятки килобайт в одном запросе. Это же на один-два порядка хуже время реакции на одно сообщение в сотню байт. Для примера, в Kafka по умолчанию max.in.flight.requests.per.connection = 5. То есть сжимаемый пакет содержит не более пяти сообщений.
Это только если речь о внутренней разработке. Если gRPC используется в B2B сценарии, то монорепа уже решением быть не может. Тут удобней, когда сервис может сам предоставить схему proto по запросу.
О pg_trgm забыли упомянуть. А это ведь очень мощный механизм, причем поддерживающий индексацию.
С хайдоад не согласен. Через dblink можно так распараллелить запрос, как родному планировщику и не снилось.
Да и сама возможность асинхронного выполнения запросов многого стоит.
Я знаю для чего нужна ССО. Но я не вижу в публикации указания на это. Судя по вики при периоде обращения в 90 минут и наклонении в 96.6°, высота орбиты должна быть 274 км, что несколько отличается от указанного в публикации.
А мы об этом и говорим, так как стоимость запусков для NASA не включают в себя те миллиарды долларов, которые уже были ей затрачены на оплату разработок той же SpaceX.
Платило 6 лет назад.
Её нет смысла учитывать, так как она все равно необходима для одной из основной целей орбитальной станции - проведения экспериментов, требующих наличия уникальных условий космического полёта. Тестирование оборудования - это лишь дополнение к основным целям.
Вы не привели источник, а по моим данным, стоимость доставки килограмма груза на МКС у NASA сейчас от $3000, тогда как стоимость вывода килограмма на НОО (до 180 км, что более, чем в два раза ниже орбиты МКС) - от $45500. Разница на порядок. Скорее всего, Вы сравнили массу полезной нагрузки в грузовом корабле с полной стартовой массой при выводе спутника.
И это даже без учета того, что для тестирования оборудования на орбитальной станции нужно доставить только само оборудование, а для спутника необходима на порядки большая масса для систем питания, ориентации, связи и т.п.
Ваше утверждение верно, если содержать орбитальную станцию только для тестирования оборудованию. Но у неё сотни иных задач, которые спутники решить не могут.
И вы так и не ответили на мой вопрос. Некрасиво.
deleted. пропустил предыдущий комментарий
Если только для тестирования оборудования, то да. Но там кроме этого тысячи иных задач, которые автоматическими спутниками не решить.
А, для примера, на МКС бывает иначе?
Остался. По крайней мере Multiple Tab Rows после обновления у меня не отвалились.
А с чего Вы решили, что тестироваться на станции будет не оборудование, которое планируется использовать на спутниках, а фото-мыльницы? У меня противоположная информация.
На мой взгляд, потому, что, во-первых, доставить тестируемое оборудование на орбиту очередным грузовиком заметно дешевле, чем отдельным автоматическим спутником. Во-вторых, возможности тестирования непосредственно человеком намного выше, чем удаленно в автоматическом режиме. В-третьих, сильно различаются требования к оборудованию, для примера, контроля ледовой обстановки у полюсов и экваториальной зоны. Это даже не считая различий в силе и направлении магнитных полей у экватора и вблизи полюсов, что тоже нужно учитывать.
Могу предположить, что для того, чтобы облет всей поверхности планеты производился быстрее. Иными словами, чтобы для сканирования всей поверхности Земли требовалось меньше оборотов станции вокруг неё.
Уже давно используем schema registry с protobuf в confluent. Никаких ограничений по сравнению с avro не обнаружили.
А исходя из того, что даже если gRPC ещё не используется, то есть заметная вероятность его использования в будущем, выбор protobuf выглядит более оправданным.
Остальные критерии не столь существенны. Avro чуть компактней, protobuf чуть меньше загружает CPU.
Бритва Хэнлона. Это, скорее, ошибка, чем лукавство, так как не указано было, что речь идет исключительно о несжатых данных. В случае компрессии выигрыш 10-60%, в зависимости от количества бинарных данных и размеров пакета. Что, впрочем, тоже не мало.
Protobuf по сравнению с JSON. Нужно отделять мух от котлет. gRPC не обязан использовать именно protobuf. Все же потоковый gRPC (HTTP/2) дает заметные преимущества перед REST в некоторых сценариях использования. Например, сервис прогнозируемых курсов валют на активном двунаправленном потоковом gRCP в локальной сети вполне может давать ответ на запрос за 1 мс. На REST такого достигнуть мало реально.
Не хватает данных по себестоимости (а она, по косвенным признакам, немаленькая), КПД (который более-менее приемлемым тут может быть только на очень низких оборотах) и стоимости владения (частоте технического обслуживания, например, по замене сальников).
А я писал: "на небольших пакетах более чем в два раза". Вы это повторно не увидели?
Но на proto то можно было посмотреть, раз именно его обсуждаем? Бинарный protobuf экономит место для чисел, но уж никак не для строк. А в репозитории по ссылке его старательно грузят преимущественно строками, на которых по определению заметной разницы между бинарным и текстовым форматом быть не может.
А если посмотреть, например, сюда, то получаем уже числа близкие к приведенной мной статистике по топикам Кафки. Если еще учесть, что текстовой информации у меня очень мало, а преимущественно - числа с фиксированной десятичной точкой и перечисления (то есть целые числа с точки зрения protobuf), то выигрыш более чем в два раза на небольших пакетах оказывается вполне ожидаем.
В контексте применимости RPC, пакеты могут любыми. С точки зрения скорости прохождения сообщений (реакции системы), они наоборот должны быть маленькими.
Даже в web-разработке для меня странно гонять десятки килобайт в одном запросе. Это же на один-два порядка хуже время реакции на одно сообщение в сотню байт. Для примера, в Kafka по умолчанию max.in.flight.requests.per.connection = 5. То есть сжимаемый пакет содержит не более пяти сообщений.
Вы точно прочитали, то что я написал? Или ограничились только первым предложением?
Это только если речь о внутренней разработке. Если gRPC используется в B2B сценарии, то монорепа уже решением быть не может. Тут удобней, когда сервис может сам предоставить схему proto по запросу.