Раз уж половина статьи — это код, можно немножко побрюзжу?
Легко же облагородить код: return сразу вместо ифа, обрамляющего весь код внутри main (я про if( -1 != (current_level=getLevel()) ) ), getopt + switch для проверки опций. Выглядеть будет намного понятней, более логично, и кривые опции нельзя будет запихнуть.
А как реализована загрузка процессора? В старых BIOS'ах он прыгал на определённый адрес, где начинался код инициализации оперативки и распаковки собственно образа BIOS'а в память. Тут примерно так же, или в процессор добавились какие-то новые инструкции/микрокоды/etc, и он как-то понимает, что вставлен в материнскую плату с UEFI?
Откуда данные?
Например, тут 74 запуска и только 8 неудач, из них 2 связаны с 1-2 ступенями (6 сентября 2007, 2 июля 2013), 2 из-за неправильной подготовки программы полёта (5 декабря 2010, 18 августа 2011), остальные связаны с проблемами разгонного блока Бриз-М.
Нередко бывает так, что на практике разницу между деревом и хэш-таблицей, когда они в памяти, будет видно только после добавления десятков, а то и сотен миллионов ключей. Если вкладывать хэш-таблицу в хэш-таблицу, то от load factor уйти не получится. Если дерево — то придётся балансировать: много бакетов — мелкие деревья — быстрый доступ, мало бакетов — большие деревья — дольше доступ. Будет быстрее или медленнее — зависит от многих параметров. Асимптотически хэш-таблица в хэш-таблице будет работать за константу, дерево в таблице — за логарифм уже.
Из преимуществ хэш-таблицы можно назвать независимость бакетов друг от друга, если конечно перебалансировку не делаете. То есть при добавлении любого ключа меняется только один бакет. Можно ставить по одному локу на бакет. При использовании деревьев почти всегда используют самобалансирующиеся деревья, при добавлении ключа может измениться до log N узлов дерева. То есть работа с деревом — только под локом на всё дерево.
По теме, ну хорошо, внутри там дерево, а не хеш-таблица. Чем это лучше и для каких use-case?:) По идее должно быть лучше на бооооооольшом количестве ключей, когда сравнивать хеши уже дорого, а по дереву пробежаться быстрей.
Ну откуда вы могли придумать такое? На получение одного ключа асимптотика дерева О(log N), а у хэш-таблицы О(1). Другое дело, что в случае с деревом появляется возможность работать с поддеревьями, в статье как раз пример про множественные get/set.
Основная проблема хэш-таблиц — это соответствие количества бакетов количеству ключей. При хорошем алгоритме хеширования хорошее отношение размера памяти к количеству коллизий достигается при load factor < 0.7. Если динамически изменять размер, то производительность на запись резко падает и становится не сильно лучше, чем у деревьев. При этом абсолютные цифры не важны, главное — load factor, то есть отношение количества ключей к количеству бакетов.
При стоимости в 22 371 рублей при покупке на амазоне (по текущему курсу, не учитывая потери про конвертации валюты) разница не такая уж и большая. 2600 рублей или 2-3 недели ожидания, тут каждый сам пусть выбирает.
Потенциальным владельцам квадрокоптера стоит ещё найти место, где покупать запчасти, в этом плане квадрокоптеры не сильно далеко от вертолётов ушли. Про вертолёты шутят: «зато он всегда новый» :)
Да вообще фигня вопрос. Делаете штук 6 вот таких двигателей:
Каждый всего то по 100 тонн тяги выдаёт, а давление в камере сгорания 170 атмосфер. Приделываете баки на несколько десятков тонн топлива и окислителя к каждому. Да, штук 20-30 ещё придётся для огневых испытаний сделать, с первого раза редко получается построить двигатель.
Чуток уменьшаете в размерах получившуюся конструкцию и делаете двигатели второй ступени. Там уже всего то по 50 тонн тяги надо, правда скорость полёта повыше. Аналогично делаете третью ступень. Ну разгонный блок ладно уж, для простоты старый можно взять.
Чтобы вся эта фиговина взлетела таки вверх и не падала, когда ветерок дует, придётся сконструировать систему управления, а для неё ещё систему навигации. К сожалению, воспользоваться сигналами GPS вряд ли получится, придётся делать старомодную инерциалку. Проблем то всего ничего: ускорение до 5g при штатном полёте, вибрации, особенно при старте и переходе на сверхзвук, да вращение планеты придётся учитывать. Лететь 10 минут всего, авось ошибок не накопится много. На микросхемах, которые MEMS, вряд ли получится собрать, надо будет всё таки использовать лазерные или волоконно-оптические гироскопы.
Ну и останутся всякие мелочи типа разделения ступеней, работы насосов в условиях отсутствия гравитации, стартовый комплекс ещё собрать… Чтобы не морочиться с системой поджига топлива и криогенными технологиями берите гептил. Правда это древняя технология, самая модная сейчас SABRE.
В общем, пяток фрилансеров нанимайте, прикупите фрезерный и токарный станки на aliexpress, набор для вакуумирования композитных материалов (карбон же будете использовать?) и вперёд!
Кстати, SpaceX построили старомодную ракету на основе технологий, отработанных и проверенных NASA, всего за пол миллиарда долларов. Копейки же.
Живу в Москве, меньше года назад проехал с восточного побережья США до западного на машине. Они другие, от Москвы по менталитету отличаются сильно. Возможно, не так сильно, как азиаты, но чувствуешь там себя явно не как дома, в отличие от Европы. При этом мне показалось, что к нам ближе южане из Техаса, чем жители Нью-Йорка или Сан-Франциско, но всё равно они от нас далеки.
Италопромом, видимо, не владели? Это же целая песня, подвоха стоит ожидать с любой стороны :) Например, пакет шурупов внутри двери, за обшивкой. Зазоры между кузовными панелями или деталями салона, причём все зазоры разные. Крышечка бачка омывайки, в которую вливать можно либо через воронку, либо после двух месяцев тренировок и в безветренную погоду. Или, в случае феррари (хотя могу ошибаться и это была ламборгини, но точно что-то итальянское и среднемоторное), воду, стекающую по кромке «капота» прямо в свечные колодцы.
Но, зато, удобный салон, приятные на ощупь материалы, красивый звук двигателя (серьёзно, есть специальный инженер, который занимается именно этим), красивый внешний вид. Итальянцы вообще умеют хорошо жить.
Судя по таблице из этой статьи большинство неудач запусков Протон-М связано именно с разгонными блоками. Мне, как дилетанту в ракетостроении, кажется, что проблема сегодняшнего запуска вряд ли связана с разгонным блоком, т.к. работали ещё только двигатели первой ступени. Лично мне по видео показалось, что один из двигателей первой ступени не заработал, из него не было такого же факела пламени, как из остальных.
Кстати, вы не в курсе, почему спутники ГЛОНАСС хотели выводить именно ДМ-03, а не Бриз-М?
Кстати, что интересно — израильтяне вообще авторитетов слабо признают, и для них нормально перебивать начальников на встречах и т.д. Бразильцы тоже очень близки к нам ментально, 3 недели работал в команде с ними в американском офисе, от американцев сильно отличаются. С итальянцами не работал, но несколько раз в Италии был. Они вообще наши браться по разуму, только совсем раздолбаи :) Так что запад западу рознь.
1. Нарушается, по каким либо причинам, связность между машинами, в результате обе становятся активными мастерами, репликация, естественно, останавливается. Что делать? Как защищаться от split bain?
2. Что делать с лагом репликации?
3. CARP по своим внутренним убеждениям решил направить нагрузку на слейв. В том числе записи. Как они попадут на мастер? А что с чтениями, при наличии лагов?
4. Что делать в случае master-slave-master, когда машины по-очереди ребутятся/падают, особенно с учётом пункта 2?
3 сервера, а, в общем случае, нечётное число > 1, используют не просто так. Арбитраж состояния кластера — это уже математика, просто так сделать действительно надёжную схему на скриптах крайне сложно. А без арбитража в конце концов кластер развалится на куски, каждый из которых продолжит жить своей жизнью, в итоге получится много неконсистентных данных. Если никаких автопереключалок нету, то у вас будет как минимум 1 консистентная копия на мастере. Если они есть, или несколько раз не глядя переключали руками — то даже на мастере уже никто ничего не сможет гарантировать.
Galera — это случай, когда арбитраж встроили в готовый продукт, просто берите и пользуйтесь. Хотите делать на скриптах — возьмите зукипер какой нибудь. Как минимум получите единое состояние всех нод, при правильном использовании.
Вы как-то неправильно к снаряду подходите. Если делать, как вы пишете — то обязательно в какой-то момент получите два мастера. Наверняка в какой-то момент потеряете данные из-за переключений master-slave-master. Да, в конце концов, всё может разломаться из-за небольшого затупа в сети. У двух машин нету единого состояния, по которому можно узнать, кто мастер. А что будет, если CARP решит направить нагрузку на слейв?
Переключение мастер-слейв — операция нетривиальная, явно не для скрипта в 20 строчек. В этой части лучше применять технологии, которые умные люди уже написали и даже потестировали в разных случаях, например Galera (на самом деле оно даже круче, потому что multimaster).
А вот когда у вас уже есть MySQL, который умеет переключаться — можно и CARP добавить. И читать, кстати, с разных нод можно будет.
Легко же облагородить код: return сразу вместо ифа, обрамляющего весь код внутри main (я про if( -1 != (current_level=getLevel()) ) ), getopt + switch для проверки опций. Выглядеть будет намного понятней, более логично, и кривые опции нельзя будет запихнуть.
Например, тут 74 запуска и только 8 неудач, из них 2 связаны с 1-2 ступенями (6 сентября 2007, 2 июля 2013), 2 из-за неправильной подготовки программы полёта (5 декабря 2010, 18 августа 2011), остальные связаны с проблемами разгонного блока Бриз-М.
Из преимуществ хэш-таблицы можно назвать независимость бакетов друг от друга, если конечно перебалансировку не делаете. То есть при добавлении любого ключа меняется только один бакет. Можно ставить по одному локу на бакет. При использовании деревьев почти всегда используют самобалансирующиеся деревья, при добавлении ключа может измениться до log N узлов дерева. То есть работа с деревом — только под локом на всё дерево.
Ну откуда вы могли придумать такое? На получение одного ключа асимптотика дерева О(log N), а у хэш-таблицы О(1). Другое дело, что в случае с деревом появляется возможность работать с поддеревьями, в статье как раз пример про множественные get/set.
Основная проблема хэш-таблиц — это соответствие количества бакетов количеству ключей. При хорошем алгоритме хеширования хорошее отношение размера памяти к количеству коллизий достигается при load factor < 0.7. Если динамически изменять размер, то производительность на запись резко падает и становится не сильно лучше, чем у деревьев. При этом абсолютные цифры не важны, главное — load factor, то есть отношение количества ключей к количеству бакетов.
www.xmodels.ru/catalog/303/5741/ — тоже 25.
megakopter.ru/modeli/DJI-Hobby/arf-rtf-kit/DJI-Phantom-RTF/ — и тут 25.
При стоимости в 22 371 рублей при покупке на амазоне (по текущему курсу, не учитывая потери про конвертации валюты) разница не такая уж и большая. 2600 рублей или 2-3 недели ожидания, тут каждый сам пусть выбирает.
Потенциальным владельцам квадрокоптера стоит ещё найти место, где покупать запчасти, в этом плане квадрокоптеры не сильно далеко от вертолётов ушли. Про вертолёты шутят: «зато он всегда новый» :)
Каждый всего то по 100 тонн тяги выдаёт, а давление в камере сгорания 170 атмосфер. Приделываете баки на несколько десятков тонн топлива и окислителя к каждому. Да, штук 20-30 ещё придётся для огневых испытаний сделать, с первого раза редко получается построить двигатель.
Чуток уменьшаете в размерах получившуюся конструкцию и делаете двигатели второй ступени. Там уже всего то по 50 тонн тяги надо, правда скорость полёта повыше. Аналогично делаете третью ступень. Ну разгонный блок ладно уж, для простоты старый можно взять.
Чтобы вся эта фиговина взлетела таки вверх и не падала, когда ветерок дует, придётся сконструировать систему управления, а для неё ещё систему навигации. К сожалению, воспользоваться сигналами GPS вряд ли получится, придётся делать старомодную инерциалку. Проблем то всего ничего: ускорение до 5g при штатном полёте, вибрации, особенно при старте и переходе на сверхзвук, да вращение планеты придётся учитывать. Лететь 10 минут всего, авось ошибок не накопится много. На микросхемах, которые MEMS, вряд ли получится собрать, надо будет всё таки использовать лазерные или волоконно-оптические гироскопы.
Ну и останутся всякие мелочи типа разделения ступеней, работы насосов в условиях отсутствия гравитации, стартовый комплекс ещё собрать… Чтобы не морочиться с системой поджига топлива и криогенными технологиями берите гептил. Правда это древняя технология, самая модная сейчас SABRE.
В общем, пяток фрилансеров нанимайте, прикупите фрезерный и токарный станки на aliexpress, набор для вакуумирования композитных материалов (карбон же будете использовать?) и вперёд!
Кстати, SpaceX построили старомодную ракету на основе технологий, отработанных и проверенных NASA, всего за пол миллиарда долларов. Копейки же.
Но, зато, удобный салон, приятные на ощупь материалы, красивый звук двигателя (серьёзно, есть специальный инженер, который занимается именно этим), красивый внешний вид. Итальянцы вообще умеют хорошо жить.
Кстати, вы не в курсе, почему спутники ГЛОНАСС хотели выводить именно ДМ-03, а не Бриз-М?
2. Синхронная репликация типа Galera как раз решает эту проблему.
3. Да, но можно стараться делать более надёжные конструкции. А как записи со слейва на мастер приедут?
2. Что делать с лагом репликации?
3. CARP по своим внутренним убеждениям решил направить нагрузку на слейв. В том числе записи. Как они попадут на мастер? А что с чтениями, при наличии лагов?
4. Что делать в случае master-slave-master, когда машины по-очереди ребутятся/падают, особенно с учётом пункта 2?
3 сервера, а, в общем случае, нечётное число > 1, используют не просто так. Арбитраж состояния кластера — это уже математика, просто так сделать действительно надёжную схему на скриптах крайне сложно. А без арбитража в конце концов кластер развалится на куски, каждый из которых продолжит жить своей жизнью, в итоге получится много неконсистентных данных. Если никаких автопереключалок нету, то у вас будет как минимум 1 консистентная копия на мастере. Если они есть, или несколько раз не глядя переключали руками — то даже на мастере уже никто ничего не сможет гарантировать.
Galera — это случай, когда арбитраж встроили в готовый продукт, просто берите и пользуйтесь. Хотите делать на скриптах — возьмите зукипер какой нибудь. Как минимум получите единое состояние всех нод, при правильном использовании.
Переключение мастер-слейв — операция нетривиальная, явно не для скрипта в 20 строчек. В этой части лучше применять технологии, которые умные люди уже написали и даже потестировали в разных случаях, например Galera (на самом деле оно даже круче, потому что multimaster).
А вот когда у вас уже есть MySQL, который умеет переключаться — можно и CARP добавить. И читать, кстати, с разных нод можно будет.