Цитата: LightElf от 19.02.2018 16:30:47Вы рассматриваете ситуацию в моменте, а надо смотреть в перспективе. Сначала вход туда, где мало конкуренции и клиентов. Там - отладка, демонстрация возможностей и тыды. Потом новый раунд инвестиций и вход в конкурентные области "в силах тяжких". Т.е. избалованному широкополосным интернетом пользователю надо предлагать сразу рабочее решение, а не участие в отладке за свои деньги. А недоверчивым богатеньким буратинам надо не только рисовать красивые графики в пауэрпоинте, но и показывать действующую модель.Скрытый текст
Цитата: Lentz от 19.02.2018 16:43:45В местах массового скопления народа оно будет работать плохо (мягко говоря), проигрывая наземным конкурентам вчистую.
Цитата: Lentz от 19.02.2018 16:43:45Иными словами, сначала нужно влить много бабла, что бы получить рабочий продукт. Бабло отобьётся на большой клиентской базе потом. Вопрос, по-прежнему, тот же. На какой клиентской базе оно должно отбиться потом? В местах массового скопления народа оно будет работать плохо (мягко говоря), проигрывая наземным конкурентам вчистую. В остальных местах клиентской базы нет по определению.
Цитата: Поверонов от 19.02.2018 22:22:57Вы пропустили в оригинале было " Смысл NoSQL в отказе от понятия и реализации централизованной транзакции ACID ради ускорения обработки масштабируемости вычислительных ресурсов, когда точностью и непротиворечивостью данных пренебрегают" Дысите глубже.
Цитата3) Обработка транзакций
Транзакция обладает четырьмя свойствами.
Атомарность. Транзакция должна быть выполнена полностью, или не выполнена вообще. Это свойство позволяет, например, единой атомарной операцией осуществить денежный перевод между двумя счетами, уменьшив баланс на одном и увеличив на другом.
Согласованность. Изменения, вносимые транзакцией в базу данных, не должны повредить ее.
Изолированность. Независимо от числа пользователей, одновременно работающих с базой данных, у каждого из них должна быть иллюзия, что никаких параллельных операций над базой данных не выполняется.
Долговечность. Даже если утрачен диск, на котором хранилась база данных, должна быть возможность восстановить ее до состояния после выполнения последней согласованной транзакции.
Сочетание свойств атомарности, согласованности, изолированности и долговечности обычно обозначают сокращением ACID (atomicity, consistency, isolation, durability). Berkeley DB, как и большинство систем баз данных, обеспечивает ACID за счет набора базовых служб.
DB предлагает транзакционную подсистему, которая позволяет полную ACID-защиту процесса записи в базу данных.
Цитата: adolfus от 20.02.2018 01:52:28Смысл не-SQL БД в том, чтобы выбросить лишний уровень – парсер SQL и универсальный планировщик SQL запросов, которые поедают до 90% процессорного ресурса и столько же памяти, и взвалить эти функции на программиста, который хоть и будет писать приложение кратно дольше, но оно будет работать на порядок быстрее.
Цитата: adolfus от 20.02.2018 01:52:28В каком таком оригинале? В педиквикии, что-ли?
Просто берем документацию на типичную nonsql СУБД BerkleyDB /usr/share/doc/libdb-devel-doc/programmer_reference/BDB_Prog_Reference.pdf и внимательно читаем с самого начала, что пишут те, кто в базах данных всех собак поел, какими свойствами обладает большинство систем баз данных. Вот перевод на скорую руку:
ACID – это основные и неотъемлемые свойства любой нормальной БД, иначе она просто не будет выполнять свои две основные функции – доступ к даным и управдение ими.
Смысл не-SQL БД в том, чтобы выбросить лишний уровень – парсер SQL и универсальный планировщик SQL запросов, которые поедают до 90% процессорного ресурса и столько же памяти, и взвалить эти функции на программиста, который хоть и будет писать приложение кратно дольше, но оно будет работать на порядок быстрее.
Цитата: LightElf от 19.02.2018 16:54:03При полностью сформированной группировке должно получиться весьма нормально и в городах тоже.
Цитата: LightElf от 19.02.2018 16:54:03А уж во всякой "одноэтажной америке" и прочих домиках из бамбука - так вообще отлично.
Цитата: LightElf от 19.02.2018 16:54:03А дальше ...
Цитата: grizzly от 21.02.2018 00:13:33Даже в 60-е с тогдашней космической лихорадкой никогда больше 150 запусков в год не случалось.
За 2017 год всеми странами было проведено 90 запусков.
Даже количество запусков возрастет обратно до 150, первые запущенные спутники умрут раньше, чем будут выведены последние.
ЦитатаНадеяться на то, что одной ракетой можно вытолкать в одну орбитальную плоскость десяток спутников тоже не надо, спутники немаленькие, Илошка утверждает, что размеры 4x1.8x1.2 метров, плюс солнечные батареи даже в сложенном положении тоже место занимают, а объем отсека полезной нагрузки фиксированный.
ЦитатаЯ живу в таком домике. У меня D-link DIR-868L со всеми своими смартбимами с первого этажа даже до всех уголков в бейсменте не достает, а это не более 15 метров. Надо репитеры ставить.
ЦитатаПро прием со спутника на высоте 1150 километров без тарелки на крыше и думать нечего.
ЦитатаПередатчик для того, чтобы докричаться до спутника - еще одна отдельная история.
ЦитатаМаршрутизация траффика между спутниками, постоянно движущимися относительно друг друга в разных орбитальных плоскостях - целое отдельное собрание сочинений, особенно если как Илошка трендит, связь между спутниками будет в оптическом диапазоне.
ЦитатаА еще Илошка подал заявку на дополнительные семь с половиной тысяч спутников на орбитах высотой до 350 км, что вообще за гранью абсурда.
ЦитатаА если о курсе илошкиных акций, тогда крику будет всё больше и больше, пока лохи деньги нести не перестанут, впрочем лох не мамонт, он не вымрет.
Цитата: LightElf от 21.02.2018 12:55:18Количество пусков определяется количеством заказов на пусковые услуги,
Цитата: LightElf от 21.02.2018 12:55:18Т.е. ни у кого никогда и не было задачи сделать туеву хучу спутников и выпнуть их на орбиту. Соответственно никто и не оптимизировал РН под такую эксплуатацию.
Цитата: LightElf от 21.02.2018 12:55:18Судя по мурзилке на сайте SpaceX высота отсека 13м при диаметре 5м (есть сужение под обтекателем). На первый взгляд 10 штук вполне влезут, и по массе тоже с учетом возврата ступени.
Цитата: LightElf от 21.02.2018 12:55:18Может просто соседи засрали частоты. У меня в квартире и на 10 метров работает так себе, но диапазон засран невероятно, видно порядка 40 разных сетей.
Цитата: LightElf от 21.02.2018 12:55:18Ну тарелка в принципе не планируется - там обещается ФАР, что позволяет сделать слежение за спутником программным путем.
Цитата: LightElf от 21.02.2018 12:55:18Подробностей на эту тему я не видел, но предполагаю что оптика только для связи между спутниками в одной орбитальной плоскости, по сути простое оптической кольцо. Маршрутизация между кольцами скорее всего через наземные станции.
Цитата: LightElf от 21.02.2018 12:55:18Столбит частоты в V-диапазоне. Вполне логично, если конечно действительно собирается обсуждаемую систему создавать.
Цитата: Поверонов от 20.02.2018 10:14:41BerkleyDB неудачный пример. Эта встраиваемая ( embedded ) СУБД просто была недоделанной реляционной ( без SQL API а с API более низкого уровня ) Купив ее Oracle приделал к ней SQL
"Oracle added support for SQL in 11g R2 release based on the popular SQLite API by including a version of SQLite in Berkeley DB"
Встраиваемые СУБД часто не имеют сетевого доступа и SQL-оптимизатора так как предназначены для использования внутри единственного приложения с уже оптимизированной под него организацией данных.
Цитата: adolfus от 22.02.2018 01:25:49BerkleyDB – наверное самая лучшая nosql (пока оракл ее не убил еще). Вот список вещей, которые сложно найти вместе у других:
1) поддержка вторичных ключей.
2) транзакции вдоль (по записям одной "таблицы") и поперек (по группе "таблиц")
3) курсоры
Токийский шкаф, например, вторичные ключи не умеет,а без них ничего серьезного нельзя написать.
Что касается термина "встраиваемая", то он означает тот факт, что BDB можно использовать в таком режиме, но не означает, что это ее единственный или основной режим использования. Ничто не мешает ее использовать в модели "клиент-сервер".
BDB поддерживает исчерпывающий набор атомарных операций над базой данных, вторичные ключи, блокировки и транзакции. Собственно, это тот самый набор атомарных операций, который присутствует во всех без исключения СУБД. Вопрос лишь в том, что и как раализовано поверх этого множества, и доступен ли этот набор на прикладном уровне. В т.н. реляционных БД он недоступен, в nosql – это основной интерфейс. Поверх него никто не мешает разработать протокол обмена между сервером и клиентами, написать свой сериализатор запросов и вперед.
У оракла есть своя NoSQL (ЕМНИП), котроую они двигают на место BDB, так вот там в документации все подробно расписано, когда следует использовать SQL, а когда "add-get-put-del". SQL нгезаменим только в ожном случае, когда схема данных меняется клиентами в процессе текущего штатного функционирования системы. Т.е. когда от пользователей идет непрерывный поток запросов alter table. Во всех остальных случаях имеет смысл обратить внимание на nosql СУБД. В 95% случаев система будет кратно шустрее и меньше жрать ресурсов. Разного рода склады и прочая логистика отлично живут себе на nonsql.
Цитата: mark.76 от 22.02.2018 02:55:53Так в том то и смысл субд, что в ней работают все сотрудники, онлайн. У нас около сотни линейных процессов и более 4 миллионов событий за год .
Цитата: adolfus от 22.02.2018 01:25:49BerkleyDB – наверное самая лучшая nosql (пока оракл ее не убил еще). Вот список вещей, которые сложно найти вместе у других:
1) поддержка вторичных ключей.
2) транзакции вдоль (по записям одной "таблицы") и поперек (по группе "таблиц")
3) курсоры
Токийский шкаф, например, вторичные ключи не умеет,а без них ничего серьезного нельзя написать.
Что касается термина "встраиваемая", то он означает тот факт, что BDB можно использовать в таком режиме, но не означает, что это ее единственный или основной режим использования. Ничто не мешает ее использовать в модели "клиент-сервер".
BDB поддерживает исчерпывающий набор атомарных операций над базой данных, вторичные ключи, блокировки и транзакции. Собственно, это тот самый набор атомарных операций, который присутствует во всех без исключения СУБД. Вопрос лишь в том, что и как раализовано поверх этого множества, и доступен ли этот набор на прикладном уровне. В т.н. реляционных БД он недоступен, в nosql – это основной интерфейс. Поверх него никто не мешает разработать протокол обмена между сервером и клиентами, написать свой сериализатор запросов и вперед.
У оракла есть своя NoSQL (ЕМНИП), котроую они двигают на место BDB, так вот там в документации все подробно расписано, когда следует использовать SQL, а когда "add-get-put-del". SQL нгезаменим только в ожном случае, когда схема данных меняется клиентами в процессе текущего штатного функционирования системы. Т.е. когда от пользователей идет непрерывный поток запросов alter table. Во всех остальных случаях имеет смысл обратить внимание на nosql СУБД. В 95% случаев система будет кратно шустрее и меньше жрать ресурсов. Разного рода склады и прочая логистика отлично живут себе на nonsql.
Цитата: grizzly от 22.02.2018 00:57:50Раз Вы хотите одной ракетой вытолкнуть несколько спутников на одну и ту же орбиту, но чтобы они находились на определенном расстоянии друг от друга, а в илошкином случае это порядка 950 км, придется оснащать спутники еще и маневровым блоком. Орбита не шоссе, это только в "Гравитации" всё легко с одного пинка летит в нужную сторону, а по жизни для перехода по одной и той же орбите на сотни километров надо совершить ряд маневров, для людей, незнакомых с астродинамикой, совсем неочевидных.
Эти маневровые блоки съедят места и полезной нагрузки. К тому же вплотную их не установишь. Так что вряд ли больше 4-5 спутников влезет.
И пятому придется добираться до своего места почти 4 тысячи км.
Всё это относится к этапу начального развертывания. По мере выхода спутников из строя, а они будут это делать в непредсказуемом порядке, надо будет возобновлять группировку и вот тут выводить придется по одному.
ЦитатаВ радиусе 50 м от меня пять соседей, так что засрать они ничего особо не могут.
ЦитатаОбещания обещать Илошка мастер, печаль в том, что чем больше текущая диаграмма направленности отклонена от перпендикуляра к плоскости антенны, тем хуже чувствительность. Кстати, слежение за низкоорбитальными спутниками - это то еще удовольствие. Рядовому потенциальному потребителю масконета такое оборудование совершенно точно не по карману, тем более где-нибудь в глуши.
ЦитатаПодробностей никто не видел, иначе возникнет слишком много вопросов. Получается, каждый спутник должен тащить две системы связи, одну оптическую и вторую обычную радио и их как-то сопрягать надо. Тут я профан, не буду заниматься спекуляциями.
ЦитатаДля оптической связи надо весьма точно направлять луч на приемник, что влечет за собой кучу последствий, в частности требования к точности системы управления ориентацией самого спутника. Если лазер(ы) жестко смонтированы в корпусе спутника, значит надо поддерживать ориентацию самого спутника, чтобы на расстоянии почти тысячи км попадать лучом (даже с учетом его расходимости) в цель размером десяток метров, координаты которой надо знать как минимум с такой же точностью. При этом любые шевеления солнечных батарей в сторону Солнца, да даже просто колебания батарей в силу их ненулевой упругости эту самую ориентацию будут сбивать и системе придется это всё отрабатывать. А чем? Какие исполнительные органы есть у илошкиных спутников? Электромаховичные двигатели, гиродины, двигатели ориентации? Это все весит, жрет энергию, имеет свои ограничения, а движки расходуют невосполнимое рабочее тело. И все эти удовольствия в 390 кг массы? Короче, там технических вопросов на книгу хватит и это только у меня с моим всего-то 5-летним опытом работы в этой области, настоящие спецы зададут вопросов кратно больше, а ответов Илошка не даст, не дурак же он в самом деле.
ЦитатаА спутники из 7-тысячной заявки на орбите высотой 340 км будут иметь срок жизни года полтора, всю группировку придется обновлять раз в полтора года, этопиздецабсурд, надо запускать около сотни в день на фазе поддержания группировки, в начальный период надо будет раза в 3 больше как минимум.
ЦитатаТак что столбить для перепродажи Илошка точно собирается, принимать предварительные заказы как на Рowerwall и теслу модель 3, с предоплатой, скорее всего попробует, а создавать? Не верю, ну разве что если он рептилоид и за Луной у него прячется космический флот вымпелов в 500, тогда потянет.
Цитата: adolfus от 22.02.2018 01:25:49Во всех остальных случаях имеет смысл обратить внимание на nosql СУБД. В 95% случаев система будет кратно шустрее и меньше жрать ресурсов. Разного рода склады и прочая логистика отлично живут себе на nonsql.
Цитата: mark.76 от 22.02.2018 02:55:53Так в том то и смысл субд, что в ней работают все сотрудники, онлайн. У нас около сотни линейных процессов и более 4 миллионов событий за год .
Цитата: Andrew Carleet от 23.02.2018 02:31:39Загадкой назвать это сложно, скорее тест. Тут либо знаешь, либо нет.
Итак, для чего применяется это устройство в компьютерах SUN Microsystems?
Подсказка: Для него даже есть специальное место в корпусе.
Цитата: Andrew Carleet от 23.02.2018 02:31:39Загадкой назвать это сложно, скорее тест. Тут либо знаешь, либо нет.
Итак, для чего применяется это устройство в компьютерах SUN Microsystems?
Подсказка: Для него даже есть специальное место в корпусе.
Цитата: Podli от 22.02.2018 17:28:54adolfus, вы просто не понимаете, что кроется под термином nosql. Это не "No SQL", а "Not Only SQL".
Цитата: adolfus от 02.03.2018 03:34:19У Вас ретроактивное понимание термина. Nosql появился задолго до твиттера, гугля и прочей бигдаты и никакого отношения не имеет к хештегу #NoSQL, именно который есть этот Ваш "Not only SQL". Но #NoSQL -- это не NoSQL.
Процитирую из одной умной книги: "Целью реляционной модели было скрыть детали реализации под более ясным интерфейсом" (конец цитаты).
NoSQL – это то, что лежит под этим самым "ясным интерфейсом" и дает программисту реально неограниченные возможности, поскольку не заставляет его думать в терминах реляционной модели.
Цитата: Oleg K. от 02.03.2018 11:37:05Во-первых, NoSQL не дает неограниченных возможностей.