отказоустойчивость, добавляет дополнительные затраты и требует больше усилий для поддержания.
Это, отчасти, так. Но, бонусы описаны выше. Они тоже есть. Например, решает проблему с отсутствием внешнего IP на домашнем маршрутизаторе. Или отсутствием защиты от DDoS.
Вообще, конечно, в облаке держать все проще, конечно. Но, это дороже, если данных много, и, есть люди, вроде меня, которые данные принципиально в облаках не хранят)
Не стоит смотреть на практическую сторону вопроса! Адепты оптимизации оптимизируют ради оптимизации, и, ни для чего больше!
На практике, с точки зрения экономической целесообразности про этот микросервис можно забыть до тех пор, пока нагрузка на него не вырастет раз в 10-100.
Тут возможен гибридный подход. Сам nextcloud на домашнем сервере, а в облаке копеечная виртуальная машина с внешним IP и защитой от DDoS, которая через постоянный тоннель редиректит трафик на домашний сервер.
Но, вообще, выставлять подобный сервис наружу немного опасно. Я предпочитаю все-же его прятать за VPN, запущенный на той же виртуалке.
Вы задали вопрос не мне, но, наиболее вероятным видится сценарий, при котором станет невозможно установить обновления даже оффлайн, или активировать систему на новом сервере.
То есть, процесс "умирания" облака растянется во времени. Но, на горизонте 2-3 года без поддержки, обновлений и новых серверов оно неизбежно умрет.
То, что он пока есть, это, конечно, хорошо. Но, санкции то накладывают, по сути, не на вас, а на МС. Им запрещают с вами работать. Пока что, только напрямую, а они просто исполняют. В определенный момент, такие схемы поставки могут тоже запретить, и канал снова исчезнет.
МС, видимо, заинтересован в том, чтобы не потерять рынок совсем, потому они с вами продолжают работать, но, не похоже, что при принятии очередных ограничений, их кто-то спрашивает.
В общем, такая схема не надежна. И, исключительно как личное мнение, я бы, выбирая облако, расположенное в РФ физически или юридически, предпочел бы работающее на OpenStack (kvm) вместо Hyper-V или VMWare.
Да, это оно. Тоже удивился, когда прочитал, что их заменили давно. Где-то в первом десятке 2000-ых сдавал на них тестирование по дифурам. Преподаватель тогда тоже говорил, что машины на троичной логике работают.
Мне кажется, что представителям МС стоило бы тщательнее редактировать подобные сообщения, хотя, это, возможно, просто "трудности перевода", или авторство тех, кто "связывался с представителями". Все потому, что после прочтения этого жизнеутверждающего заявления остается один незакрытый вопрос:
А когда, собственно, будут блокировать продукты физических лиц?
Вы сравнили один из самых дешевых "энтерпрайз" SSD с одним из самых дорогих "консьюмерских", причем в супер-компактном форм-факторе NVM-E. Это не совсем честное сравнение.
И то, разница получилась почти в два раза.
У этого "энтерпрайзного", к сожалению, IOPS на запись в 10 раз меньше. Благодаря чему он использует более щадящие режимы записи в NAND, за счет чего достигается больший ресурс записи. NAND используется в накопителях практически одинаковый.
Для write-only кэша не лучший вариант, мягко скажем.
видим «база данных» — ставим dc ssd (а лучше всегда когда видим сервер).
Про базы данных, в общем, согласен, но, есть варианты. Например, взять пару энтерпрайзных NVM-E SSD сравнительно небольшого объема, и использовать их как write-only кэш с отложенной синхронизацией на основной массив. Если размер постоянно изменяемого пространства (записи) ограничен по сравнению с общим размером базы, то проблем с использованием консьюмерских SSD для редко изменяемых данных не будет. Отложенная синхронизация сильно уменьшает износ консьюмерских SSD.
Тут все, конечно, зависит от конкретного применения, и, под него надо рассчитывать размеры кэша, холодного хранилища и задержку синхронизации записи. Решение, однозначно, не универсальное. Но, при определенных условиях, рабочее.
Что касается пункта "всегда, когда видим сервер". То, тут я категорически не согласен. Использования в сервере бывают разные. И, в масштабе, переплачивать за энтерпрайз в случае массива для хранения, например, бэкапов или других WORM-данных будет явным перебором)
Емкий кэш нужен пользователям однозначно. Просто потому, что, как доказано на практике, есть куча приложений которые могут от этого получить огромный прирост производительности. Но, конечно есть и те приложения, которые не могут. Но, иметь возможность лучше, чем не иметь.
А, вот, производителю процессоров, как раз, не выгодно добавлять этот кэш в процессор, т.к. он увеличивает стоимость производства. Увеличивается площадь кристалла и уменьшается процент выхода годных кристаллов, что является особенно заметной проблемой для монолитного дизайна.
Кстати, в монолитном дизайне увеличение кэша тоже неизбежно приведет уменьшению частоты. Это не какая-то особенная фишка чиплетного/3D дизайна. Просто из-за увеличения тепловыделения за счет увеличения количества транзисторов.
Имея все сказанное выше, идея AMD сделать увеличенный кэш доступной опцией, причем, даже в десктопных процессорах, является оптимальной. У пользователей есть выбор, и, это очень хорошо!
В общем, я как пользователь на практике 64х-ядерного эппика в десктопном mid-tower корпусе с воздушным охлаждением, скажу, что ядра роляют. В том числе для сборки Ядра и Хромиума) А про то, что тепло ДОЛЖНО отводиться по всей площади процессора написано в прямо в "Installation Guide".
Если я правильно понял видео, то там проблема была с охлаждением. Из-за того, что контактная площадка теплоотвода водянки не покрывала всю площадь процессора, большая часть чиплетов с ядрами, скорее всего, просто, постоянно перегревалась. Для TR это является большой проблемой даже при 300W ограничении. Все потому, что один единственный плохо охлаждаемый чиплет может выделять до 150 ватт тепла и греть другие чиплеты, оставляя остальным чиплетам только половину теплопакета. При одинаковой частоте. Или снижая их частоту из-за нагрева.
В конце видео вроде сказано, что после обновления водянки эта проблема исчезла.
Вы правы, автор галочку позволяющую использовать протон для не поддерживаемых игр, возможно, не нашел, но, скорее всего, там про то, что в Стиме есть далеко не все игры.
В режиме точки доступа оно волне себе вроде работает) Проверено. Более "интересные штуки" я как-то не смотрел.
Беспроводной кластер, который можно разбросать по комнате и добавлять ноды на лету, это, конечно, удобно. Спору нет. Но, если уж собирать в корпус, то наверно можно все-таки и паяльником поработать). Не сложнее печати частей корпуса на 3D принтере.
Смысл пайки как раз в эстетике. "Чтоб просто работало" можно и без пайки собрать. Размеры красного адаптера точно соответствуют формату Zero если отпаять USB порт. Так что, кластер растет только по высоте. А в вырез для GPIO пинов удобно размещается антенна.
Хаб, кстати, может питаться от Orange Pi и, запитывать его напрямую через micro usb не обязательно. Но, конечно, желательно если больше двух агентов. Иначе не потянет по питанию. Но, он тут только для примера. Есть аналоги))
Это, отчасти, так. Но, бонусы описаны выше. Они тоже есть. Например, решает проблему с отсутствием внешнего IP на домашнем маршрутизаторе. Или отсутствием защиты от DDoS.
Вообще, конечно, в облаке держать все проще, конечно. Но, это дороже, если данных много, и, есть люди, вроде меня, которые данные принципиально в облаках не хранят)
Не стоит смотреть на практическую сторону вопроса! Адепты оптимизации оптимизируют ради оптимизации, и, ни для чего больше!
На практике, с точки зрения экономической целесообразности про этот микросервис можно забыть до тех пор, пока нагрузка на него не вырастет раз в 10-100.
Тут вам DNF в помощь. SAT для выражений в DNF решается за линейное время. Плюс, DNF упрощает реализацию оптимизатора.
Шаг 1. Оптимизировать выражения.
Например, у вас куча условий по акциям, и, где-то в конце списка условий стоит наличие какого-то товара в корзине.
Если начать проверку условий с проверки этого товара, то остальные условия можно не проверять.
Это экономит время на бесполезной работе.
Шаг 2. Масштабирование / слияние выражений:
Предположим, у вас большая часть акций связана с наличием определенного товара.
Создаем таблицу товар->акции.
Пробиваем все товары из корзины по таблице в первую очередь.
Отправляем на дальнейшую обработку только акции из правой части таблицы.
Таким образом, мы за одну операцию проверили сразу все условия на "наличие товара" во всех акциях.
Шаг 3. Пишем свой оптимизатор
Автоматизация процесса на шаге 2.
Пишем свой собственный автоматический оптимизатор выражений / на основе статистики запросов.
Шаг 4. Компиляция в машинный код.
Например, средствами LLVM.
....
Имеем свой собственный оптимизирующий JIT компилятор DSL.
Тут возможен гибридный подход. Сам nextcloud на домашнем сервере, а в облаке копеечная виртуальная машина с внешним IP и защитой от DDoS, которая через постоянный тоннель редиректит трафик на домашний сервер.
Но, вообще, выставлять подобный сервис наружу немного опасно. Я предпочитаю все-же его прятать за VPN, запущенный на той же виртуалке.
Вы задали вопрос не мне, но, наиболее вероятным видится сценарий, при котором станет невозможно установить обновления даже оффлайн, или активировать систему на новом сервере.
То есть, процесс "умирания" облака растянется во времени. Но, на горизонте 2-3 года без поддержки, обновлений и новых серверов оно неизбежно умрет.
То, что он пока есть, это, конечно, хорошо. Но, санкции то накладывают, по сути, не на вас, а на МС. Им запрещают с вами работать. Пока что, только напрямую, а они просто исполняют. В определенный момент, такие схемы поставки могут тоже запретить, и канал снова исчезнет.
МС, видимо, заинтересован в том, чтобы не потерять рынок совсем, потому они с вами продолжают работать, но, не похоже, что при принятии очередных ограничений, их кто-то спрашивает.
В общем, такая схема не надежна. И, исключительно как личное мнение, я бы, выбирая облако, расположенное в РФ физически или юридически, предпочел бы работающее на OpenStack (kvm) вместо Hyper-V или VMWare.
Да, это оно. Тоже удивился, когда прочитал, что их заменили давно. Где-то в первом десятке 2000-ых сдавал на них тестирование по дифурам. Преподаватель тогда тоже говорил, что машины на троичной логике работают.
Если не ошибаюсь, у RUVDS хостинг на Hyper-V? В чем смысл тогда, если лицензию могут в любой момент отозвать?
Мне кажется, что представителям МС стоило бы тщательнее редактировать подобные сообщения, хотя, это, возможно, просто "трудности перевода", или авторство тех, кто "связывался с представителями". Все потому, что после прочтения этого жизнеутверждающего заявления остается один незакрытый вопрос:
Вы сравнили один из самых дешевых "энтерпрайз" SSD с одним из самых дорогих "консьюмерских", причем в супер-компактном форм-факторе NVM-E. Это не совсем честное сравнение.
И то, разница получилась почти в два раза.
У этого "энтерпрайзного", к сожалению, IOPS на запись в 10 раз меньше. Благодаря чему он использует более щадящие режимы записи в NAND, за счет чего достигается больший ресурс записи. NAND используется в накопителях практически одинаковый.
Для write-only кэша не лучший вариант, мягко скажем.
Про базы данных, в общем, согласен, но, есть варианты. Например, взять пару энтерпрайзных NVM-E SSD сравнительно небольшого объема, и использовать их как write-only кэш с отложенной синхронизацией на основной массив. Если размер постоянно изменяемого пространства (записи) ограничен по сравнению с общим размером базы, то проблем с использованием консьюмерских SSD для редко изменяемых данных не будет. Отложенная синхронизация сильно уменьшает износ консьюмерских SSD.
Тут все, конечно, зависит от конкретного применения, и, под него надо рассчитывать размеры кэша, холодного хранилища и задержку синхронизации записи. Решение, однозначно, не универсальное. Но, при определенных условиях, рабочее.
Что касается пункта "всегда, когда видим сервер". То, тут я категорически не согласен. Использования в сервере бывают разные. И, в масштабе, переплачивать за энтерпрайз в случае массива для хранения, например, бэкапов или других WORM-данных будет явным перебором)
Тогда, наверно, это все же "большой брат"/"старший брат"?
Не нужно изобретать. Этот собирательный образ давно существует. Зовется "дядя Сэм".
Емкий кэш нужен пользователям однозначно. Просто потому, что, как доказано на практике, есть куча приложений которые могут от этого получить огромный прирост производительности. Но, конечно есть и те приложения, которые не могут. Но, иметь возможность лучше, чем не иметь.
А, вот, производителю процессоров, как раз, не выгодно добавлять этот кэш в процессор, т.к. он увеличивает стоимость производства. Увеличивается площадь кристалла и уменьшается процент выхода годных кристаллов, что является особенно заметной проблемой для монолитного дизайна.
Кстати, в монолитном дизайне увеличение кэша тоже неизбежно приведет уменьшению частоты. Это не какая-то особенная фишка чиплетного/3D дизайна. Просто из-за увеличения тепловыделения за счет увеличения количества транзисторов.
Имея все сказанное выше, идея AMD сделать увеличенный кэш доступной опцией, причем, даже в десктопных процессорах, является оптимальной. У пользователей есть выбор, и, это очень хорошо!
В общем, я как пользователь на практике 64х-ядерного эппика в десктопном mid-tower корпусе с воздушным охлаждением, скажу, что ядра роляют. В том числе для сборки Ядра и Хромиума) А про то, что тепло ДОЛЖНО отводиться по всей площади процессора написано в прямо в "Installation Guide".
Если я правильно понял видео, то там проблема была с охлаждением. Из-за того, что контактная площадка теплоотвода водянки не покрывала всю площадь процессора, большая часть чиплетов с ядрами, скорее всего, просто, постоянно перегревалась. Для TR это является большой проблемой даже при 300W ограничении. Все потому, что один единственный плохо охлаждаемый чиплет может выделять до 150 ватт тепла и греть другие чиплеты, оставляя остальным чиплетам только половину теплопакета. При одинаковой частоте. Или снижая их частоту из-за нагрева.
В конце видео вроде сказано, что после обновления водянки эта проблема исчезла.
Вы правы, автор галочку позволяющую использовать протон для не поддерживаемых игр, возможно, не нашел, но, скорее всего, там про то, что в Стиме есть далеко не все игры.
В режиме точки доступа оно волне себе вроде работает) Проверено. Более "интересные штуки" я как-то не смотрел.
Беспроводной кластер, который можно разбросать по комнате и добавлять ноды на лету, это, конечно, удобно. Спору нет. Но, если уж собирать в корпус, то наверно можно все-таки и паяльником поработать). Не сложнее печати частей корпуса на 3D принтере.
Смысл пайки как раз в эстетике. "Чтоб просто работало" можно и без пайки собрать. Размеры красного адаптера точно соответствуют формату Zero если отпаять USB порт. Так что, кластер растет только по высоте. А в вырез для GPIO пинов удобно размещается антенна.
Хаб, кстати, может питаться от Orange Pi и, запитывать его напрямую через micro usb не обязательно. Но, конечно, желательно если больше двух агентов. Иначе не потянет по питанию. Но, он тут только для примера. Есть аналоги))