Волшебный дым: микроконтроллеры против линейных регуляторов

Волшебный дым (также «электронная фея» или «полупроводниковый джинн») — магический едкий дым, на котором работают все микросхемы в мире до тех пор пока не происходит чрезмерная электрическая нагрузка с перегревом, и волшебный дым гневно удаляется из микросхемы навсегда, после чего та перестаёт работать.

У меня неравной борьбы не выдержали Digispark, ESP-01 и Arduino pro mini 3.3V

Нетерпеливым можно посоветовать использовать step-down на MP1584EN, остальным — добро пожаловать по кат.

Итак, сначала был электровелосипед на digispark.

И естественно, не обошлось без "полупроводникового джинна" — китайский линейный регулятор 78M05 буквально сгорел в дыму и пламени, плюнув вверх расплавленным пластиком:

Странно, что по даташит-у элемента входное напряжение заявлено до 35 Вольт, а уже при 28 — такие спецэффекты!

Это тем более непонятно, что при потреблении микроконтроллером ~10мА вообще ни один параметр регулятора не должен был выйти за рамки по тепловому режиму.

Ввиду того, что дело было в деревне, и step-down взять было негде(ага, а Digispark под рукой был ;-), поставил костыль из 330Ом последовательно по цепи питания.

Списал все на надежность китайской техники.

Потом "электронная фея" посетила меня на управлении 12-вольтовым двигателем с помощью ESP-01:

Ну тут сам виноват — поставить ams1117 рассеивать такую мощность (около 1.5W)

Попробовал регулятор на LM317 в корпусе TO220 — и тот без радиатора грелся черезмерно.

Итог — поставлен простейший регулятор на MP1584EN :

Преимущество перед другими step-down — сама схема регулятора потребляет всего 0.3мА (хотя по доке может и 0.1 )

И надо сказать, такое питание положительно сказалось на стабильности ESP-шки.

Но самую вишенку я приберег для последней части.

Сейчас стали широко использоваться LDO-регуляторы (с низким падением напряжения — около 0.1В и низким потреблением — ~0.1мА)

Для сравнения на AMS1117 падает ~0.5В и кушает она 5 миллиампер.

Все прекрасно в LDO-шках, за исключением одного — входное напряжение до 6 вольт и токи до 300мА

Нет, "синюю пилюлю" (STM32) питать от USB — cамое оно, но зачем их паять на платы Arduino Pro Mini 3.3V, если сам чип нормально работает до 5.5В???

Разве что для работы с устройствами с 3.3В TTL

Тем более, что стандартная мини-плата комплектуется нормальным преобразователем на MIC5205 (KB33,LB33, KBAA) со входным напряжением до 20Вольт.

И какая-же была моя реакция когда из преобразователя ардуинки, включенной на 12В пошел дым?

Англоязычный энтузиаст was surprised, как-же, я поднял напряжение до 15 вольт — но искр так и не получил!

В общем, если Вы планируете пользовать микроконтроллер с 12В питанием (на самом деле, гелевые батареи от бесперебойников дают до 14.8В), то лучше взять step-down преобразователь.

Если вдруг черт дернул использовать Arduino Pro mini 3.3В без такового, обращайте внимание на маркировку бортовых преобразователей.

KB33, LB33, KBAA, L0RA, L0RB, LG33 скорей всего будут работать — они рассчитаны на 15-19Вольт

Но лучше прежде чем паять схему, стоит сделать преобразователю "Тест на дым" — 4B2X и 52RL его не прошли.

Пятивольтовые ардуинки обычно содержат "трехногие" клоны AMS1117 и таких проблем не имеют.

На версиях PRO Mini 5V обычно идут пятиногие KB50 с низким потреблением и падением напряжения, при входном до 20В.

Но потребление самого чипа на пяти вольтах удручает!

В общем, удачных Вам самоделок, и пореже видеть полупроводникового джинна!

С уважением, Андрей.

ссылка на оригинал статьи https://habr.com/ru/post/489196/

Устройство Helm и его подводные камни


Typhon freight hauler concept, Anton Swanepoel

Меня зовут Дмитрий Сугробов, я разработчик в «Леруа Мерлен». В статье расскажу, зачем нужен Helm, как он упрощает работу с Kubernetes, что поменялось в третьей версии и как с его помощью обновлять приложения в продакшене без простоя.

Это конспект по мотивам выступления на конференции @Kubernetes Conference by Mail.ru Cloud Solutions — если не хотите читать, смотрите видео.

Почему мы используем Kubernetes в продакшене

«Леруа Мерлен» — лидер на рынке DIY-ритейла в России и Европе. В нашей компании больше ста разработчиков, 33 000 внутренних сотрудников и огромное количество людей, посещающих гипермаркеты и сайт. Для того чтобы сделать всех их счастливыми, мы решили придерживаться стандартных подходов в индустрии. Разрабатывать новые приложения, используя микросервисную архитектуру; для изоляции окружений и правильной доставки использовать контейнеры; а для оркестрации использовать Kubernetes. Цена использования оркестраторов стремительно дешевеет: на рынке растёт количество инженеров, владеющих технологией, появляются провайдеры, предлагающие Kubernetes как сервис.

Всё, что делает Kubernetes, конечно, можно сделать другими способами, например, обмазав скриптами какой-нибудь Дженкинс и docker-compose, но зачем усложнять жизнь, если есть готовое и надежное решение? Поэтому мы пришли к Kubernetes и уже год его используем в продакшене. Сейчас у нас двадцать четыре кластера Kubernetes, самому старому из них больше года, в нем порядка двухсот подов.

Проклятие большого количества YAML-файлов в Kubernetes

Для запуска микросервиса в Kubernetes создадим по меньшей мере пять YAML-файлов: для Deployment, Service, Ingress, ConfigMap, Secrets — и отправим в кластер. Для следующего приложения напишем тот же пакет ямликов, с третьим — еще один и так далее. Помножим количество документов на количество окружений, уже получим сотни файлов, и это ещё не учитывая динамические окружения.

Adam Reese, core maintainer Helm, ввел понятие «Цикл разработки в Kubernetes», которое выглядит так:

  1. Copy YAML — копировать YAML-файл.
  2. Paste YAML — вставить его.
  3. Fix Indents — починить отступы.
  4. Repeat — повторить заново.

Вариант рабочий, но приходится много раз копировать YAML-файлы. Чтобы этот цикл изменить, и придумали Helm.

Что такое Helm

Во-первых, Helm — пакетный менеджер, помогающий находить и устанавливать нужные программы. Для установки, например, MongoDB не нужно заходить на официальный сайт и скачивать бинарники, достаточно выполнить команду helm install stable/mongodb.

Во-вторых, Helm — шаблонизатор, помогает параметризировать файлы. Вернемся к ситуации с YAML-файлами в Kubernetes. Проще написать тот же файл YAML, добавить в него некоторые placeholder-ы, в которые Helm подставит значения. То есть вместо большого набора ямликов будет набор темплейтов (шаблонов), в которые в нужный момент подставятся нужные значения.

В-третьих, Helm — мастер по развертыванию. С его помощью можно устанавливать, откатывать и обновлять приложения. Давайте разберёмся, как это делать.

Как пользоваться Helm для деплоя собственных приложений

Установим Helm клиент на компьютер, следуя официальной инструкции. Затем создадим набор YAML-файлов. Вместо указания конкретных значений оставим плейсхолдеры, которые в будущем Helm заполнит информацией. Набор таких файлов называется Helm чарт. В консольный клиент Helm его можно отправить тремя способами:

  • указать папочку с шаблонами;
  • упаковать в .tar архив и указать на него;
  • положить шаблон в удалённый репозиторий и добавить ссылку на репозиторий в Helm клиент.

Ещё нужен файл со значениями — values.yaml. Данные оттуда будут подставляться в шаблон. Создадим и его.

Во второй версии Helm есть дополнительное серверное приложение — Tiller. Оно висит снаружи Kubernetes и ждёт запросы от Helm-клиента, а при вызове подставляет нужные значения в шаблон и отправляет в Kubernetes.

Helm 3 устроен проще: вместо обработки шаблонов на сервере, информация теперь обрабатывается целиком на стороне Helm-клиента и отправляется напрямую в Kubernetes API. Это упрощение повышает безопасность кластера и облегчает схему выката.

Как всё это работает

Запускаем команду helm install. Укажем название релиза приложения, дадим путь до values.yaml. В конце укажем репозиторий, в котором лежит чарт и название чарта. В примере это «lmru» и «bestchart» соответственно.

helm install --name bestapp --values values.yaml lmru/bestchart 

Выполнение команды возможно только единожды, при повторном выполнении вместо install нужно использовать upgrade. Для простоты вместо двух команд можно выполнять команду upgrade с дополнительным ключом --install. При первом исполнении Helm отправит команду на установку релиза, а в дальнейшем будет его обновлять.

helm upgrade --install bestapp --values values.yaml lmru/bestchart 

Подводные камни деплоя новых версий приложения с Helm

В этом месте рассказа я играю с залом в «Кто хочет стать миллионером», и мы выясняем, как заставить Helm обновить версию приложения. Смотреть видео.

Когда я изучал работу Helm, меня удивило странное странное поведение при попытке обновления версий запущенных приложений. Код приложения обновил, в докер-реджистри загрузил новый образ, отправил команду на деплой – и ничего не произошло. Ниже несколько не совсем удачных способов обновления приложений. Изучая каждый из них более подробно, начинаешь понимать внутреннее устройство инструмента и причины такого не очевидного поведения.

Способ 1. Не менять информацию с момента последнего запуска

Как гласит официальный сайт Helm, «Kubernetes чарты бывают большими и сложными, поэтому Helm старается лишний раз ничего не трогать». Поэтому, если обновить latest-версию образа приложения в docker registry и выполнить команду helm upgrade, то ничего не произойдёт. Helm будет думать, что ничего не поменялось и посылать в Kubernetes команду на обновление приложения не нужно.

Здесь и дальше тег latest показан исключительно в качестве примера. При указании этого тега Kubernetes будет каждый раз скачивать образ из docker registry, вне зависимости от параметра imagePullPolicy. Использование latest в продакшене нежелательно и вызывает побочные эффекты.

Способ 2. Обновлять LABEL в image

Как написано в той же документации, «Helm будет обновлять приложение, только если оно поменялось с момента последнего релиза». Логичным вариантом для этого покажется обновление метки LABEL в самом докер-образе. Однако Helm не заглядывает в образы приложений и не имеет понятия о каких-либо изменениях в них. Соответственно, при обновлении меток в образе Helm о них не узнает, и команда обновления приложения в Kubernetes не поступит.

Способ 3. Использовать ключ --force

Обратимся к мануалам и поищем нужный ключик. Больше всего по смыслу подходит ключ --force. Несмотря на говорящее название, поведение отличается от ожидаемого. Вместо форсированного обновления приложения, его реальное предназначение — восстановление находящегося в статусе FAILED релиза. Если не использовать этот ключ, то нужно последовательно выполнять команды helm delete && helm install --replace. Вместо этого предлагается использовать ключ --force, который автоматизирует последовательное выполнение этих команд. Больше информации в этом пулл-реквесте. Для того чтобы сказать Helm всё-таки обновить версию приложения, к сожалению, этот ключ не подойдёт.

Способ 4. Изменять labels напрямую в Kubernetes

Обновление label напрямую в кластере с помощью команды kubectl edit — плохая идея. Это действие приведёт к неконсистентности информации между работающим приложением и тем, что изначально отправилось на деплой. Поведение Helm при деплое в этом случае отличается от его версии: Helm 2 ничего делать не будет, а Helm 3 задеплоит новую версию приложения. Для понимания причины нужно понять, как работает Helm.

Как устроен Helm

Для определения, изменилось ли приложение с момента последнего релиза, Helm может воспользоваться:

  • запущенным приложением в Kubernetes;
  • новым values.yaml и актуальным чартом;
  • внутренней информацией Helm о релизах.
Для самых любознательных: где Helm хранит внутреннюю информацию о релизах?

Выполнив команду helm history, мы получим всю информацию о версиях, установленных с помощью Helm.

Ещё есть подробная информация об отправленных шаблонах и значениях. Мы можем её запросить:

Во второй версии Helm эта информация лежит в том же неймспейсе, где запущен Tiller (по умолчанию — kube-system), в ConfigMap, помеченном меткой «OWNER=TILLER»:

В момент появления третьей версии Helm информация переехала в секреты, причём в тот же неймспейс, где запущено приложение. Благодаря этому стало возможно запускать одновременно несколько приложений в разных неймспейсах с одинаковым названием релиза. Во второй версии это была сильная головная боль, когда неймспейсы изолированы, но могут друг на друга влиять.

Второй Helm, когда пытается понять, нужно ли обновление, использует только два источника информации: то, что ему предоставили сейчас, и внутреннюю информацию о релизах, которая лежит в ConfigMap.

Третий Helm использует стратегию three-way merge: в дополнение к той информации учитывает ещё и приложение, которое работает прямо сейчас в Kubernetes.

По этой причине старая версия Helm не будет ничего делать, так как не учитывает информацию приложения в кластере, а вот Helm 3 получит изменения и отправит новое приложение на деплой.

Способ 5. Использовать ключ —recreate-pods

С помощью ключа --recreate-pods можно достичь того, что изначально планировалось получить с помощью ключа --force. Контейнеры перезапустятся и, согласно политике imagePullPolicy: Always для тега latest (об этом в сноске выше), Kubernetes скачает и запустит новую версию образа. Делать будет это не самым лучшим образом: не учитывая StrategyType деплоймента, резко выключит все старые инстансы приложения и пойдёт запускать новые. Во время перезапуска система не будет работать, пользователи будут страдать.

В самом Kubernetes похожая проблема тоже существовала продолжительное время. И вот, спустя 4 года после открытия Issue, проблему исправили, и начиная с 1.15 версии Kubernetes появляется возможность rolling-restart подов.

Helm же просто выключает все приложения и запускает рядом новые контейнеры. В продакшене так делать нельзя, чтобы не вызвать простой приложения. Такое нужно только для нужд разработки, можно выполнять только в stage-окружениях.

Как обновить версию приложения с помощью Helm?

Будем менять значения, отправляемые в Helm. Как правило, это значения, подставляемые на место тега образа. В случае latest, часто используемого для непродуктивных окружений, в роли изменяемой информации выступает аннотация, которая для самого Kubernetes бесполезна, а для Helm будет выступать сигналом к необходимости обновления приложения. Варианты заполнения значения аннотации:

  1. Рандомное значение с помощью стандартной функции — {{ randAlphaNum 6 }}.
    Есть нюанс: после каждого деплоя с использованием чарта с такой переменной значение аннотации будет уникальным, и Helm будет полагать, что есть изменения. Получается, всегда будем перезапускать приложение, даже если не поменяли его версию. Это не критично, так как простоя не будет, но всё же неприятно.
  2. Вставлять текущую дату и время{{ .Release.Date }}.
    Вариант похож на рандомное значение с постоянно уникальной переменной.
  3. Более правильный способ — использовать контрольные суммы. Это SHA образа либо SHA последнего коммита в гите — {{ .Values.sha }}.
    Их надо будет подсчитывать и отправлять в Helm клиент на вызывающей стороне, например в Дженкинсе. Если приложение поменялось, то и контрольная сумма поменяется. Следовательно, Helm будет обновлять приложение только тогда, когда нужно.

Подытожим наши попытки

  • Helm делает изменения наименее инвазивным способом, поэтому любое изменение на уровне образа приложения в Docker Registry не приведёт к обновлению: после выполнения команды ничего не произойдёт.
  • Ключ --force используется для восстановления проблемных релизов и не связан с принудительным обновлением.
  • Ключ --recreate-pods принудительно обновит приложения, но сделает это вандальным способом: резко выключит все контейнеры. От этого пострадают пользователи, на проде так делать не стоит.
  • Напрямую вносить изменения в кластер Kubernetes с помощью команды kubectl edit не надо: нарушим консистентность, а поведение будет отличаться в зависимости от версии Helm.
  • С выходом новой версии Helm появилось много нюансов. Issues в репозитории Helm описаны понятным языком, они помогут разобраться в деталях.
  • Добавление изменяемой аннотации в чарт сделает его более гибким. Это позволит выкатывать приложение правильно, без простоя.

Мысль из разряда «мир во всём мире», работающая во всех сферах жизни: читайте инструкцию перед применением, а не после. Только владея полной информацией, получится строить надёжные системы и делать пользователей счастливыми.

Другие ссылки по теме:

  1. Знакомство с Helm 3
  2. Официальный сайт Helm
  3. Репозиторий Helm на GitHub
  4. 25 полезных инструментов Kubernetes: развертывание и управление

Этот доклад впервые прозвучал на @Kubernetes Conference by Mail.ru Cloud Solutions. Смотрите видео других выступлений и подписывайтесь на анонсы мероприятий в Telegram Вокруг Kubernetes в Mail.ru Group.

ссылка на оригинал статьи https://habr.com/ru/company/mailru/blog/488192/

Пришло ли время забыть о React и перейти на Svelte?

Каждый год выходит исследование State of JavaScript, которое обобщает результаты опроса, изучающего текущее состояние экосистемы JavaScript. Это исследование затрагивает фронтенд-фреймворки, серверную и мобильную разработку, тестирование, популярные ресурсы для разработчиков и многое другое.

В нём всё, конечно, крутится вокруг JavaScript. Поэтому если вы используете для веб-разработки JS — я очень рекомендую взглянуть на State of JavaScript в том случае, если вы ещё этого не сделали.

Для меня одним из самых интересных результатов State of JavaScript стало неожиданное внимание тех, кто участвовал в опросе, к фронтенд-фреймворку Svelte.

В общем рейтинге ведущих фронтенд-инструментов (основанном на показателях осведомлённости о фреймворке, интереса к нему и удовлетворённости им) Svelte появился на второй позиции. Он идёт там сразу после React, опережая такие хорошо известные инструменты, как Vue.js, Preact, Angular и Ember.
Меня это слегка шокировало, так как Svelte — это сравнительно новый инструмент — как в плане возраста, так и в плане парадигмы разработки программного обеспечения.


Рейтинг фронтенд-фреймворков по результатам исследования State of JavaScript

Знаю, что многие из вас могут тут возмутиться и сказать, что React и Svelte — это, всё же, не фреймворки, а библиотеки. Я это знаю, но отчёт по исследованию писал не я, поэтому давайте на этом вопрос о терминологии закроем.

Я разобрался с примером шаблонного проекта Svelte и создал небольшое Hello World-приложение.

Слева — простейший React-проект. Справа — аналогичный проект, основанный на Svelte

Хотя этот простой проект и несложно было довести до рабочего состояния, тому, кто раньше писал на React, понадобится какое-то время для того, чтобы освоить Svelte.

Стоит ли тратить время на освоение Svelte? Может быть, перед нами лишь очередная модная штучка, которая исчезнет так же быстро, как появилась? Предлагаю это выяснить.

Цель исследования

Мне хочется ответить на следующий вопрос: «Стоит ли мне прекратить тратить время на изучение React и начать разбираться со Svelte?».

Мы будем искать ответ на этот вопрос, исследуя фундаментальные различия между React и Svelte. Это позволит нам прийти к пониманию того, какими уникальными качествами обладает каждый из этих инструментов. В итоге же мы выясним то, в изучение какого из них стоит вкладывать время.

Начнём с обзора каждой из библиотек, затем поговорим об их плюсах и минусах, а потом сделаем выводы.

React

В последние пару лет буквально все говорят о React. Эта библиотека, созданная Facebook, очень быстро захватила мир веб-разработки. Сейчас это — инструмент веб-разработки, занимающий первое место в мире (правда, ответ на вопрос о том, «номер один» он или нет, зависит от того, кому задают этот вопрос).

Библиотека React, во многом благодаря сообществу, сложившемуся вокруг неё, растёт в наши дни быстрее, чем когда бы то ни было. И пока не видно никаких признаков замедления этого роста.

Вот три особенности React, которые делают эту библиотеку особенно привлекательной:

  1. Декларативная природа.
  2. Структура приложений, основанная на компонентах.
  3. Простота использования в плане интеграции в существующий стек технологий.

Декларативная природа React — это то, что позволяет создавать интерактивные пользовательские интерфейсы. Программисту достаточно просто спроектировать визуальные элементы приложения для каждого состояния, после чего React сделает всё остальное. Это упрощает чтение и понимание кода, облегчает отладку.

Как React «делает всё остальное»? Благодаря использованию технологии виртуальной DOM. Определение того, какие части DOM нужно обновить, проводится в недрах библиотеки, на промежуточном уровне, находящемся между кодом, написанным программистом, и реальной DOM. Именно благодаря этой технологии можно гарантировать высокие скорости рендеринга страниц.

Библиотека React спроектирована так, что то, какие именно технологии используются в стеке инструментов разработчика, значения не имеет. React-фронтенд можно «прикрутить» к чему угодно. Например — к бэкендам, основанным на Node.js, Ruby on Rails, Spring Boot, PHP и так далее. Эта библиотека совершенно нейтральна по отношению к тому, с чем именно ей придётся взаимодействовать.

Почему некоторые называют React «библиотекой», а некоторые — «фреймворком»? Для того чтобы создать некое приложение, вместе с React нужно пользоваться дополнительными библиотеками, применяемыми для управления состоянием приложения, для маршрутизации, для взаимодействия с различными API. Если создать шаблон React-проекта, воспользовавшись create-react-app — в нём не будет некоего набора инструментов, которого можно было бы ожидать от фреймворка.

Svelte

Svelte — это инструмент, который создан для того, чтобы изменить ситуацию, сложившуюся в сфере разработки фронтенда. Вот хорошее видео по Svelte 3, в котором Рич Харрис, создатель Svelte, очень интересно и эмоционально рассказывает об этой библиотеке. Если вы это видео ещё не смотрели — рекомендую на него взглянуть.

В этом выступлении хорошо представлена история реактивного программирования, освещены изъяны, присущие традиционной реализации реактивных механизмов, представлено решение соответствующих проблем.

Многое из того, что можно отнести к сильным сторонам React, положено в основу Svelte. Рич Харрис очень хорошо осведомлён о плюсах и минусах внутреннего устройства React.

React занимается поддержкой интерфейса в актуальном состоянии и выполняет другие действия прямо в браузере. Svelte же делает своё дело во время сборки проекта. В этом и заключается основная разница между React и Svelte. Вот что об этом сказано в документации по Svelte: «Svelte конвертирует ваше приложение в идеальный JavaScript-код во время сборки проекта, а не интерпретирует код приложения во время его работы».

Svelte не использует техник наподобие сравнения реальной и виртуальной DOM.

Компилятор Svelte берёт декларативный компонент и превращает его в эффективный императивный низкоуровневый код, который напрямую взаимодействует с DOM.

Так как Svelte использует компилятор, а не виртуальную DOM, это позволяет снизить нагрузку на браузер, повысить скорость работы страниц, облегчить JS-движку браузера сборку мусора. Браузеру не приходится решать некоторые задачи во время выполнения кода страницы, что улучшает производительность проектов.

Правда, как и React, Svelte использует компоненты, написанные в декларативном стиле. Основная часть различий между React и Svelte начинается после того, как запускают сборку Svelte-проекта.

Сильные и слабые стороны React и Svelte

Поговорим о сильных и слабых сторонах исследуемых библиотек.

▍Сильные стороны React

  • Серьёзная поддержка сообщества.
  • Множество библиотек для тестирования кода, написанных в расчёте на React.
  • Поддержка TypeScript.
  • Качественные инструменты разработчика.
  • Множество полезных компонентов, созданных силами сообщества.
  • Большое количество вакансий для React-разработчиков.

▍Сильные стороны Svelte

  • Отличная производительность, улучшающая впечатления пользователей от работы с сайтами, созданными на Svelte.
  • В основе библиотеки лежат веб-стандарты (HTML, CSS, JS).
    • JSX не используется.
  • Более компактный код.
    • Объём кода Svelte-приложения примерно на 40% меньше, чем объём кода аналогичного React-приложения.
  • Во время компиляции производится оптимизация сборок (что приводит к очень маленькому размеру итогового кода).
  • Библиотеку можно без проблем интегрировать в любой существующий проект.

▍Слабые стороны React

  • Виртуальная DOM — сравнительно медленная технология.
  • Дополнительная нагрузка на систему ухудшает производительность.
  • Библиотека постоянно меняется.
  • Документация не успевает обновляться из-за высокой скорости разработки новых возможностей React.
  • JSX-конструкции могут быть сложными для понимания.

▍Слабые стороны Svelte

  • Не очень большое (в сравнении с React) сообщество.
  • Нет встроенной поддержки TypeScript.
  • Ограниченное количество расширений для редакторов кода, средств подсветки синтаксиса, наборов компонентов, инструментов разработки.
  • Небольшое количество вакансий, требующих знания Svelte (пока это так, но ситуация может измениться).

Итоги

Вернёмся к нашему вопросу: «Стоит ли мне прекратить тратить время на изучение React и начать разбираться со Svelte?».

Честно говоря, я начинал работу над этой статьёй, ожидая, что приду к выводу о том, что Svelte — слишком молодая технология, и что пока не стоит особенно сильно вкладывать время в её изучение. Но после того, как я разобрался в происходящем, после того, как вник в основы, я оказался весьма заинтригован и впечатлён тем, что мне открылось, тем, какую динамику развития Svelte я ощутил.

Неоспоримо то, что Svelte-проекты отличаются очень хорошей производительностью.

Идеи, лежащие в основе Svelte, выглядят смелыми и прогрессивными. Растёт размер сообщества Svelte. Я уверен в том, что успешность фронтенд-инструментов (равно как и широта их распространения) сильно зависит от сообщества, и от того, как эти инструменты принимают разработчики.

В результате можно сказать, что если Svelte и всё, что связано с этой библиотекой, и дальше будет развиваться в том же темпе, можно будет ожидать повсеместного распространения этой технологии.

Конечно, Svelte только начинает свой путь, поэтому мы пока не знаем о тех проблемах, а их может быть немало, которые неизбежно проявятся в ходе внедрения Svelte в реальные проекты. Мы не знаем о том, как программисты будут обходить эти проблемы, о том, как разработчики библиотеки будут её улучшать.

Когда библиотека React только появилась, она выглядела современнейшим инструментом, у которого вообще нет никаких недостатков. Но, по мере развития и распространения React оказалось, что веб-разработчикам приходится справляться с различными непростыми ситуациями, им приходится искать обходные пути, компромиссы. Да и разработчикам самой библиотеки тоже приходится немало работать над её улучшением.

Уверен, то же самое ждёт и Svelte. Ведь мир веб-разработки чрезвычайно изменчив.

Если вы пока не готовы оставить React, я посоветовал бы вам, как минимум, внимательно наблюдать за Svelte. Эта библиотека может стать сильным конкурентом React гораздо быстрее, чем можно себе представить.

Уважаемые читатели! Что вы думаете о Svelte?

ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/488660/

Какие стартапы ищет Y Combinator в 2020 году

«Люди важнее, чем идеи.»
— Y Combinator

Многие из лучших идей, которые мы финансировали, были идеями, которые нас удивили, а не идеями, которых мы ждали.

Тем не менее, есть некоторые темы стартапов, которые нам очень интересны. Ниже приведен обновленный запрос на стартапы (Request for Startups, RFS), в котором излагаются некоторые из этих идей в общих чертах.

1. A.I.
2. Bio
3. Brick and Mortar 2.0
4. Carbon Removal Technologies
5. Cellular Agriculture and Clean Meat
6. Cleaner Commodities
7. Computer Security
8. Diversity
9. Education
10. Energy
11. Enterprise Software
12. Financial Services
13. Future of Work
14. Government 2.0 (NEW)
15. Healthcare
16. Improving Memory
17. Longevity and Anti-aging
18. One Million Jobs
19. Programming Tools
20. Robotics
21. Safeguards Against Fake Video
22. Supporting Creators
23. Transportation & Housing
24. Underserved Communities
25. Voice Apps
26. VR and AR

Пожалуйста, не думайте, что вам нужно работать над одной из этих идей, чтобы подать заявку в Y Combinator. Хотя многие из перечисленных ниже областей относятся к категории «передовых технологий», подавляющее большинство стартапов, которые мы финансируем, будут по-прежнему интернет компаниями и мобильными компаниями, которые мы финансировали в прошлом. Если это то, чем вы хотели заниматься до этого поста, продолжайте этим заниматься.

Кроме того, вы не должны создавать компанию только потому, что она находится в этом списке. RFS в основном существует, чтобы побудить вас подать заявку, если вы уже работаете над идеей в одной из этих областей.

Искусственный интеллект

Искусственный интеллект имеет большое влияние на общество. Настолько большое, что мы создали для него конкретную область внутри YC.

Похоже, это может быть одной из разделительных линий в истории технологий, где до и после выглядят совершенно иначе. Мы заинтересованы в том, чтобы люди проводили исследования в любой узкой области (открытие лекарств, помощь с программированием, юридические консультации, обнаружение мошенничества и т. д.).И особенно нас интересуют области, которые находятся на пересечении искусственного интеллекта и робототехники (производство продукции, беспилотные автомобили и т.д.)

Био

Пока рано спешить с выводами, но похоже, что мы, наконец, добиваемся реального прогресса, «взламывая» биологию.

Мы уверены, что это будет удивительная, мощная и спорная область в течение нескольких следующих десятилетий. Похожая ситуация была с микрокомпьютерами в 1970-х годах.

Инженерные принципы в настоящее время регулярно применяются в синтетической биологии, а биология затрагивает все аспекты жизни от здравоохранения до производства и даже продукты питания и сельское хозяйство.

Биология может развиваться во многих направлениях. Это может быть борьба с болезнями, замедление старения, слияние людей и компьютеров, загрузка воспоминаний, генетическое программирование и т. д.

Чтение ДНК стало невероятно быстрым и дешевым. Существуют много интересных приложений. Возможно, появятся еще более интересные приложения по мере того, как мы будем совершенствовать запись в ДНК.

Мы также заинтересованы в применении биотехнологий для предотвращения злоупотреблений этой технологией. Например, если плохие парни могут быстро создавать новые инфекционные заболевания, было бы неплохо, если бы хорошие ребята могли быстро создавать новые лекарства и вакцины.

Примечание. Чтобы узнать о программе YC Bio, посвященной здоровью и биотехнологиям, связанным со старением, пройдите по этой ссылке.

Brick and Mortar 2.0 (Кирпич и бетон 2.0)

Мы заинтересованы в стартапах, которые преподносят традиционную рекламу или торговое пространство интересными и эффективными способами.

Amazon выводит торговые центры и большие магазины из бизнеса. Вместо того, чтобы бороться в проигрышной битве с Amazon, бренды должны переосмыслить, как использовать торговые площадки таким образом, чтобы играть на их сильных сторонах. Например, Тесла, Уорби Паркер и Пелотон используют традиционные помещения в качестве демонстрационных залов, которые дополняют их онлайн-каналы продаж. Без необходимости хранения инвентаря торговое пространство можно использовать гораздо эффективнее.

Интересное использование обычного пространства не ограничивается розничными магазинами: подобные колоссальные изменения происходят с ресторанами, развлекательными заведениями, местными поставщиками услуг и офисными зданиями. Новые компании будут созданы специально для клиентов, которые обучены ожидать таких функций, как онлайн-заказ, глубокая интеграция с другими службами и немедленная доставка. Гибкость является ключевым фактором. Например, вполне вероятно, что предприятия будущего будут использовать «микро-лизинг», который длится дни или даже часы, а не многолетние арендные договоры.

Кроме того, эра больших магазинов, которые переносили внимание потребителей с главной улицы в пригородные торговые центры, окруженные автостоянками, скорее всего, изменится по мере того, как начнется эра самоуправления. Когда беспилотные автомобили будут в обиходе, наши отношения с физическим пространством будут развиваться способами, которые трудно предсказать. Мы хотим видеть стартапы, которые думают об этой перемене и создают новые способы использования физического пространства.

Снижение CO2

В Парижском соглашении поставлена глобальная цель ограничить повышение температуры Земли до 1,5 ° C в этом столетии. Просто перейти на возобновляемые источники энергии будет недостаточно для достижения этой цели. Нам также придется удалять углерод из атмосферы.

Технологии удаления углерода и секвестрации все еще находятся в зачаточном состоянии. Текущие решения можно разделить на две группы: естественные (например, лесовосстановление и биоуголь) и технологические (например, прямой захват воздуха). Две проблемы с прямым захватом воздуха — это затраты и масштаб. Несколько стран, в том числе США, недавно активизировались и создали финансовые стимулы для удаления углерода из атмосферы, но с нынешней технологией это все еще не рентабельно. Более подробную информацию можно получить в Центре по удалению углерода.

Другие подходы к геоинженерии для противодействия последствиям изменения климата также могут иметь потенциал.

Мясо

Недавние научные разработки изменили наше представление о производстве белка.

Впервые мы можем производить продукты, которые с научной точки зрения неотличимы от продуктов животного происхождения, таких как мясо и молочные продукты, используя только клетки и не нанося вреда животным.

Сегодня люди используют сельскохозяйственных животных в основном для производства мяса и молочных продуктов. Независимо от того, считаете ли вы, что это жестоко и расточительно, мы знаем, что это неэффективно. Все больше людей едят мясо каждый год, но большая часть доступных сельскохозяйственных угодий в нашем мире уже используется для производства мяса. Сельскохозяйственный сектор является вторым по величине источником выбросов парниковых газов в мире после энергетического сектора, а использование антибиотиков в сельском хозяйстве представляет собой реальную опасность для нашей собственной системы здравоохранения.

Выращивание реального мяса животных непосредственно из клеток — революционная наука. Мы хотели бы финансировать больше стартапов, продвигающих эту науку на рынок. Мы также хотим финансировать стартапы, специализирующиеся на фазе масштабирования клеточного сельского хозяйства. Мир будет в значительной степени в выигрыше от более устойчивого, более дешевого и более здорового производства мяса.

Более чистые пищевые продукты

При нынешних темпах обезлесения через 100 лет не будет тропических лесов.

Существует множество экологических причин, объясняющих почему это плохо, но также это станет проблемой для отраслей, полагающихся на эти все более скудные ресурсы.

Стартапы уже начали рассматривать потребность в более чистых потребительских продуктах, но промышленные товары, такие как пальмовое масло и соя, получают меньше внимания.

Например, пальмовое масло является наиболее используемым растительным маслом в мире — это около 50% товаров продуктового магазина. В 2016 году мировой рынок пальмового масла оценивался в 65 миллиардов долларов, и ожидается, что к 2021 году он достигнет 92 миллиардов долларов. Но производство пальмового масла, как правило, основывается на грубых, экологически разрушительных методах вырубки/сжигания, эксплуататорском труде и дает наибольшее количество выбросов, приближающих глобальное потепление, среди всех продуктов, кроме говядины.

Мы считаем, что эти рыночные/низкотехнологичные отрасли могут быть интересными. Примерами стартапов, которые мы хотели бы видеть, являются те, которые работают над синтетическими продуктами, более экологически чистыми альтернативами или улучшением цепочки поставок. Вопрос стоимости, вероятно, будет очень важен здесь, гораздо важнее чем для потребительских товаров. Было бы здорово, если бы были созданы новые рабочие места или если решение будет включать в себя лесовосстановление.

Компьютерная безопасность

Защита компьютеров это довольно сложное занятие, потому что требуемая работа ужасно асимметрична — атакующий должен найти только один недостаток, а защитник должен защитить от всех возможных уязвимостей.

К сожалению, обеспечивать безопасность компьютеров не просто сложно — это критически и невероятно важно. По мере того, как к интернету подключается более важная информация и системы, мы становимся более уязвимыми для кибератак, и нарушения становятся более серьезными.

Разнообразие (Diversity)

Разнообразие сотрудников — это очень хорошо для бизнеса и для всего мира.

Без разных точек зрения, продукты и услуги, которые мы создаем, упускают большие возможности для больших групп людей. Мы хотим финансировать некоммерческие организации и стартапы, которые работают над тем, чтобы сделать технологию более привлекательной и заманчивой для людей всех возрастов, рас, сексуальных ориентаций и культур.

Образование

Если мы сможем исправить образование, мы сможем в конечном итоге сделать все остальное в этом списке.

Интеллектуальная мощь человека не используется в полной мере на этой планете, потому что у большинства людей нет доступа к хорошему образованию. Сильные образовательные программы приводят к большей социальной мобильности, улучшению работы, улучшению качества жизни граждан, а также увеличению числа новых и лучших стартапов. Небольшое увеличение объема получаемых знаний в образовательных системах во всем мире оказало бы огромное влияние на производительность и экономический рост человека.

Мы заинтересованы в новых школьных моделях, которые могут развивать критическое мышление, творчество, гражданскую позицию и рабочие навыки в крупных масштабах. Мы ищем идеи, которые сочетают в себе технологии и взаимодействие между людьми, чтобы обеспечить индивидуализированный подход в обучении.

Мы также знаем, что 90% человеческого мозга развивается до 5 лет, и пробелы в достижении успехов открываются перед детским садом. Мы заинтересованы в предприятиях, которые значительно улучшат результаты для детей до пяти лет, уменьшив неравенство и повысив качество жизни детей и их семей в будущем. Масштабируемые решения в этих областях теперь должны стать выполнимыми благодаря достижениям когнитивистики и таким технологиям как интеллектуальные домашние устройства, умные и мобильные устройства.

Энергия

Существует значительная связь между стоимостью энергии и качеством жизни.

На протяжении всей истории, когда стоимость энергии сильно снижалась (например, в случае с паровым двигателем), качество жизни значительно улучшалось.

Дешевая энергия сделала бы значительный вклад в уменьшение бедности. Новые источники энергии могут также помочь окружающей среде и экономике, сократить количество войн, обеспечить стабильное будущее, сделать продукты питания и воду более доступными и многое другое.

Мы считаем, что экономика будет доминировать — новые источники должны быть дешевле старых, без субсидий, и иметь возможность расширяться до уровня глобального спроса. Ядерная энергия может “согласиться на сделку” (hit the bid) и тоже самое относится к возобновляемым источникам энергии. Но ценообразование — это вопрос первой важности.

В дополнение к выработке электроэнергии мы также заинтересованы в хранении и передаче энергии. Батареи, которые будут в 10 раз качественнее, позволят изобретать много новых отличных вещей, также как и способность легко перемещать энергию.

Программное обеспечение для крупных компаний

Программное обеспечение, используемое крупными компаниями, по-прежнему ужасно и по-прежнему очень прибыльно.

Определяющие категорию компании-производители программного обеспечения появляются для решения проблем каждой отрасли, бизнеса любого размера и каждой должностной функции. Вот три конкретных области, которые мы считаем особенно интересными:

Удешевление дорогих вещей: из-за стоимости традиционного корпоративного программного обеспечения многие категории решений ранее были дорогостоящими для небольших или даже средних предприятий.

Еще один миллиард работников: Традиционые офисные сотрудники были пользователями корпоративного программного обеспечения. Мобильные телефоны и планшеты превращают каждого сотрудника — начиная от продавца розничного магазина до члена сервисных бригад — в сотрудника по работе со знаниями.

Оцифровка каждой отрасли: каждая отрасль проходит через некоторую форму информационного разрушения; это приводит к тому, что предприятия модернизируют свои практики, используют новые данные, ускоряют ключевые процессы и предоставляют цифровое взаимодействие в ходе своей работы.

Финансовые слуги

Мировые финансовые системы все чаще не могут удовлетворить потребности потребителей и бизнеса.

В этом есть смысл, поскольку правила, предназначенные для защиты клиентов, не могут меняться достаточно быстро, чтобы идти в том темпе, в котором технология меняет потребности этих клиентов. Это несоответствие создает неэффективность практически на каждом уровне финансовой системы. Это влияет на то, как люди вкладывают свои сбережения, как компании получают доступ к капиталу для роста, как оцениваются и страхуются риски, и как финансовые компании ведут бизнес друг с другом.

Мы считаем, что программное обеспечение ускорит темпы изменения финансовых услуг и в конечном итоге изменит характер правил. Мы хотим финансировать компании с новыми идеями о том, как это сделать.

Работа будущего

Работа будет выглядеть совсем по-другому через 25 лет.

Мы уже видели огромный сдвиг в сторону автоматизации, роботов и искусственного интеллекта, и темпы их воздействия на работу не замедляются.

Существует неопределенность в отношении того, приведут ли эти новые технологии к большему или меньшему количеству рабочих мест в совокупности. Нам интересно ваше мнение о том, что произойдет, и что будет дальше.

В частности, мы хотим выяснить, какая новая работа будет создана для использования этих новых технологий. И что можно построить, чтобы помочь людям и компаниям адаптироваться к изменяющимся требованиям по отношению к навыкам, с которыми они сталкиваются.

Мы также хотим знать, как будет развиваться смысл работы. Люди ищут работу на полный рабочий день по многим причинам, включая деньги, здравоохранение и чувство цели. Нам бы хотелось увидеть решения, которые касаются каждого из этих факторов (или любых других) в ожидании изменения рынка труда.

Правительство 2.0

В 2018 году исследовательский центр Pew Research Center отчитался, что 57% американцев считают, что сегодняшние дети в Америке будут хуже жить финансово, чем их родители. С 2013 года это число достигло 65% — несмотря на то, что мы десять лет находимся в зоне экономического роста.

Мы считаем, что такое мышление является результатом возросшего семейного долга, стагнации заработной платы и отсутствия приверженности правительства обеспечению равного доступа к основным услугам, необходимым семьям для процветания. Эти услуги включают доступ к качественному образованию, доступному жилью, здравоохранению, продовольствию, физической безопасности, точным новостям и информации, сети социальной защиты и пригодной для жизни окружающей среде.

Здравоохранение

Здравоохранение в Соединенных Штатах сильно нарушено. Мы приближаемся к тому, чтобы тратить 20% нашего ВВП на здравоохранение; это никуда не годится.

Мы заинтересованы в том, чтобы сделать здравоохранение лучше за меньшие деньги, а не в компаниях, которые собираются использовать систему, чтоб на ней навариться.

Мы особенно заинтересованы в стартапах здравоохранения, работающих в следующих направлениях:

  • Диагностика: Диагностика направляет клинические решения и может оказать значительное влияние на здравоохранение. Теперь мы можем строить диагностику дешевле и быстрее, чем когда-либо прежде, и наиболее важные возможности заключаются в том, чтобы этим воспользоваться.
  • Медицинские приборы: затраты на прототипирование и производство ниже, чем когда-либо, и вычислительная мощность выше, чем когда-либо. Мы хотим видеть устройства, которые оказывают наилучшее клиническое воздействие и то как данные, которые они генерируют, могут сделать медицинские устройства более ценными, чем когда-либо прежде.
  • Фармацевтика: Развитие лекарств стало медленнее и дороже. Мы хотели бы финансировать компании, делающие это по-новому. Мы мыслим глобально: мы заинтересованы в вещах, которые не могут стать лекарствами по рецепту, но по-прежнему помогают людям.
  • Профилактическая медицина: это, вероятно, самый лучший способ улучшить здоровье. Датчики и данные интересны во многих областях, но особенно в области здравоохранения.

Улучшение памяти

Человеческая память слишком изменчива.

По сравнению с компьютерами у людей довольно странная система памяти. Мы можем вспомнить тонкие эмоции и чувства 10-летней давности, одновременно забывая, где находится наш телефон и что нужно взять в магазине. Возрастающая бомбардировка информацией и идеями, конечно же, не облегчает работу нашей памяти, как и возрастные заболевания, такие как деменция и болезнь Альцгеймера.

Слияние человека и компьютера уже происходит. Некоторые решения, такие как голосовые помощники и носители, могут помочь дополнить краткосрочную память. Более сложные подходы связаны с нейронными интерфейсами, но возникают новые проблемы UX. Мы хотим финансировать стартапы, которые изучают, как улучшить человеческую память с помощью технологий. В идеале мы можем решить проблему Митча Хедберга раз и навсегда.

Долголетие и омоложение

YC Bio — это новый способ для YC финансировать компании по науке о жизни на ранней стадии, которые все еще находятся в лабораторной фазе. Первой областью, на которой мы собираемся сосредоточиться, является здоровье и возрастные заболевания.

Мы считаем, что есть огромная возможность помочь людям жить здоровее дольше и что это может быть один из лучших способов решения нашего кризиса в сфере здравоохранения.

Это будет особый путь. Компании будут проходить через стандартную процедуру YC, но будет несколько отличий. Вместо обычной сделки для YC-компаний (которая составляет $120 000, за 7% долю), мы будем предлагать этим компаниям любую сумму от $500 000 до $1 000 000 за 10-20% долю, масштабируя линейно. Мы также предложим компаниям бесплатное лабораторное пространство, ряд особых сделок и доступ к широкому кругу экспертов.

Миллион рабочих мест

Мы хотим финансировать компании, которые могут создать миллион рабочих мест.

Есть много областей, где имеет смысл разделить труд между людьми и компьютерами — мы очень хорошо разбираемся в некоторых вещах, в которых компьютеры ужасны, и наоборот — и некоторые из них требуют огромного количества человеческих ресурсов.

Это хорошо для мира, и, вероятно, это в принципе хорошая бизнес-стратегия — поскольку существующие рабочие места уходят, компания, которая создает много новых рабочих мест, должна быть в состоянии получить много талантливых людей.

Инструменты разработки

Разработчики программного обеспечения затрагивают нашу повседневную жизнь все больше и больше.

Продукты, которые они используют для создания программного обеспечения, являются мощным рычагом: они оказывают существенное влияние на качество и тип создаваемого программного обеспечения.

Мы заинтересованы в том, чтобы помочь разработчикам быстрее создавать программное обеспечение. Это включает новые способы написания, понимания и совместной работы с кодом, а также следующего поколения инструментов и инфраструктуры для непрерывного и надежного предоставления программного обеспечения.

Мы считаем, что особенно важно создавать продукты, которые делают разработку программного обеспечения доступной для самой широкой части нашего общества. На самом деле нас особенно интересуют новые способы программирования. Вероятно, есть намного лучшие способы для людей программировать, и нахождение одного из них будет иметь огромный эффект.

Фреймворки лучше, языки немного умнее, но в основном мы делаем то же самое.

Можно мыслить подобным образом: что придет после языков программирования?

Робототехника

Роботы будут основным способом достичь результата в физическом мире.

Наше определение довольно широкое — например, мы считаем беспилотную машину за робота. Роботы — это то, как мы, вероятно, будем исследовать пространство и, возможно, даже человеческое тело.

Защита от поддельных видео

Поддельные видеоролики встречаются все чаще и чаще.

Технология создания поддельных видео, неотличимых от реальных, теперь существует, и вскоре она будет широко доступна любому, у кого есть смартфон.

Мы заинтересованы в финансировании технологий, которые предоставят общественности инструменты, необходимые для идентификации поддельных видео и аудио.

Поддержка творцов

Интернет облегчил распространение творческой работы миллионам людей, но никто не понял, как помочь творцам зарабатывать себе на жизнь.

В искусстве есть армия посредников, которая находится между «художником» и «зрителем».

Каждый посредник отъедает часть каждого доллара, заработанного творцом. Мы хотим видеть больше стартапов, которые строят прямой конвейер от исполнителя к поклоннику.

Мы считаем, что существуют способы создания более удобных для разработчиков платформ, и мы заинтересованы в том, чтобы проекты, облегчали для творцов привлечение финансирования, отслеживали использование их работ и предотвращали пиратство.

Транспорт и жилье

Около половины всей энергии используется на транспорт, и люди тратят огромное количество времени на невеселые ежедневные поездки на работу из пригорода и обратно.

Встречи лицом к лицу по-прежнему очень важны; людям все равно нужно передвигаться. И жилье продолжает дорожать, отчасти из-за проблем с транспортом. Мы заинтересованы в том, чтобы люди могли жить где-то в хорошем месте, работать вместе и легче добирались на работу из пригорода и обратно.

В частности, нам интересны легкогрузные поездки на короткие расстояния.

Недостаточно обеспеченные сообщества и социальные услуги

Десятки миллионов работающих бедных в Америке не видят пути к среднему классу.

Это люди вынуждены ориентироваться в мире с некачественными услугами, низким качеством жилья, переполненными школами и преступностью в своих районах. Они часто не имеют банковского счета и живут от зарплаты до зарплаты.

Правительство США тратит сотни миллиардов долларов в год на социальные услуги и программы социальной защиты для этих малообеспеченных сообществ.

Мы считаем, что крупные некоммерческие и коммерческие компании могут принести технологии и сильные подходы, основанные на показателях, на этот всеми игнорируемый крупный рынок.

Голосовые помощники

У десятков миллионов семей есть умные голосовые помощники.

Мы заинтересованы в том, чтобы выяснить, какие голосовые приложения окажут наибольшую ценность на этой новой платформе.

Голосовые приложения настолько отличаются от типичных веб-приложений, что мы считаем, что создание продуктов, которые привлекают и удерживают пользователей, потребует множества инноваций.

Компании с голосовыми приложениями, которые участвуют в YC, будут иметь прямой доступ к Amazon Alexa и Google Assistant.

VR и AR

Виртуальная реальность и дополненная реальность были давно невыполненным обещанием.

Но мы чувствуем, что волна наступает, и настало время начать работать над ней.

Примечания

То, насколько вы соответствуете этому списку, никогда не будет решающим фактором в том, кого мы финансируем. Как мы уже неоднократно говорили, люди важнее, чем идеи. Кроме того, вы не можете хорошо поработать над чем-то, если вы действительно не заинтересованы в этом. Поэтому не хватайтесь за идею, описанную в RFS, если есть какая-то другая идея, над которой вам лучше работать. Вы с гораздо большей вероятностью получите финансирование, чтобы работать над идеей, которая вам действительно нравится.

За перевод спасибо Диане Шеремьевой и Андрею Гончарову.

P.S.

ссылка на оригинал статьи https://habr.com/ru/post/489200/

varchar(max)-varchar(max) и в продакшн

Недавно поучаствовал в дискуссии на тему влияния на производительность указания длины в столбцах с типом nvarchar. Доводы были разумны у обеих сторон и поскольку у меня было свободное время, решил немного потестировать. Результатом стал этот пост.

Спойлер – не всё так однозначно.

Все тесты проводились на SQL Server 2014 Developer Edition, примерно такие же результаты были получены и на SQL Server 2016 (с небольшими отличиями). Описанное ниже должно быть актуально для SQL Server 2005-2016 (а в 2017/2019 требуется тестирование, поскольку там появились Adaptive Memory Grants, которые могут несколько исправить положение).

Нам понадобятся – хранимая процедура от Erik Darling sp_pressure_detector, которая позволяет получить множество информации о текущем состоянии системы и SQL Query Stress – очень крутая open-source утилита Adam Machanic/Erik Ejlskov Jensen для нагрузочного тестирования MS SQL Server.

О чём вообще речь

Вопрос, на который я стараюсь ответить – влияет ли на производительность выбор длины поля (n)varchar (далее везде просто varchar, хотя всё актуально и для nvarchar), или можно использовать varchar(max) и не париться, поскольку если длина строки < 8000 (4000 для nvarchar) символов, то varchar(max) и varchar(N) хранятся IN-ROW.

Готовим стенд

create table ##v10  (i int, d datetime, v varchar(10)); create table ##v100 (i int, d datetime, v varchar(100)); create table ##vmax (i int, d datetime, v varchar(max));

Создаём 3 таблицы из трёх полей, разница только в длине varchar: 10/100/max. И заполним их одинаковыми данными:

;with x as (select 1 x union all select 1) , xx as (select 1 x from x x1, x x2) , xxx as (select 1 x from xx x1, xx x2, xx x3) , xxxx as ( 	select row_number() over(order by (select null)) i 		, dateadd(second, row_number() over(order by (select null)), '20200101') d 		, cast (row_number() over(order by (select null)) as varchar(10))  v 		 	from xxx x1, xxx x2, xxx x3 ) --262144 строк insert into ##v10			--varchar(10) select i, d, v from xxxx;	  insert into ##v100			--varchar(100) select i, d, v from ##v10;  insert into ##vmax			--varchar(max) select i, d, v from ##v10; 

В итоге каждая таблица будет содержать 262144 строк. Столбец I (integer) содержит неповторяющиеся числа от 1 до 262145; d (datetime) уникальные даты и v (varchar) – cast (I as varchar(10)). Чтобы это было чуть больше похоже на реальную жизнь, создаём уникальный кластерный индекс по i:

create unique clustered index #cidx10 on ##v10(i); create unique clustered index #cidx100 on ##v100(i); create unique clustered index #cidxmax on ##vmax(i);

Поехали

Сначала посмотрим планы выполнения разных запросов.

Во-первых, проверим, что отбор по полю varchar не зависит от его длины (если там хранится < 8000 символов). Включаем действительный план выполнения и смотрим:

select * from ##v10 where v = '123'; select * from ##v100 where v = '123'; select * from ##vmax where v = '123';

Как ни странно, разница, хоть и небольшая, но есть. План запроса с varchar(max) сначала выбирает все строки, а потом их отфильтровывает, а varchar(10) и varchar(100) проверяют совпадения при сканировании кластерного индекса. Из-за этого, сканирование занимает практически в 3 раза больше времени – 0,068 секунд против 0.022 у varchar(10).

Теперь посмотрим, что будет, если просто выводить varchar-колонку, а отбирать данные по ключу кластерного индекса:

select * from ##v10  where i between 200000 and 201000; select * from ##v100 where i between 200000 and 201000; select * from ##vmax where i between 200000 and 201000; 

Тут всё понятно – для таких запросов никакой разницы нет.

Теперь интересная часть. Предыдущим запросом мы получили всего-то 1001 строку, а теперь хотим отсортировать их по неиндексированной колонке. Пробуем:

select * from ##v10  where i between 200000 and 201000 order by d; select * from ##v100 where i between 200000 and 201000 order by d; select * from ##vmax where i between 200000 and 201000 order by d;

Ой, а что там такое жёлтенькое?

Забавно, т.е. запрос запросил и получил 6,5 мегабайт оперативной памяти для сортировки, а использовал только 96 килобайт. А насколько будет хуже, если строк будет побольше. Ну, пусть будет не 1000, а 100000:

А вот тут уже посерьёзнее. Причём первый запрос, который работает с самым маленьким varchar(10) тоже чем-то недоволен:

Слева тут предупреждение последнего запроса: запрошено 500 мегабайт, а использовано всего 9,5 мегабайт. А справа – предупреждение сортировки: запрошено было 8840 килобайт, но их не хватило и ещё 360 страниц (по 8 кб) было записано и прочитано из tempdb.

И тут напрашивается вопрос: WTF?

Ответ – так работает оптимизатор запросов SQL Server. Чтобы что-то отсортировать, это что-то нужно сначала поместить в память. Как понять сколько памяти нужно? Вообще, нам известно сколько какой тип данных занимает места. А что же со строками переменной длины? А вот с ними интереснее. При выделении памяти для сортировок/hash join, SQL Server считает, что в среднем они заполнены наполовину. И выделяет под них память как (размер / 2) * ожидаемое количество строк. Но varchar(max) может хранить аж 2Гб – сколько же выделять? SQL Server считает, что там будет половина от varchar(8000) – т.е. примерно 4 кб на строку.

Что интересно – такое выделение памяти приводит к проблемам не только с varchar(max) – если размер ваших varchar’ов любовно подобран так, что большая часть из них заполнена наполовину и больше – это тоже ведёт к проблемам. Проблемам иного плана, но не менее серьёзным. На рисунке выше есть описание – SQL Server не смог корректно выделить память для сортировки маленького varchar’а и использовал tempdb для хранения промежуточных результатов. Если tempdb лежит на медленных дисках, или активно используется другими запросами – это может стать очень узким местом.

SQL Query Stress

Теперь посмотрим, что происходит при массовом выполнении запросов. Запустим SQL Query Stress, подключим его к нашему серверу, и скажем выполнить все эти запросы по 10 раз в 50 потоках.

Результаты выполнения первого запроса:

Интересно, но без индексов, при поиске varchar(max) показывает себя хуже всех, причём солидно так хуже по процессорному времени на итерацию и общему времени выполнения.

sp_pressure_detector не показывает тут ничего интересного, поэтому её вывод не привожу.
Результаты выполнения второго запроса:

Тут всё ожидаемо – одинаково хорошо.

Теперь интересная часть. Запрос с сортировкой полученной тысячи строк:

Тут всё оказалось точно также, как и с предыдущим запросом – строк не много, сортировка проблем не вызывает.

Теперь последний запрос, который сортирует неоправданно много строк (я добавил в него top 1000, чтобы не тянуть весь сортированный список):

И вот тут привожу вывод sp_pressure_detector:

Что он нам говорит? Все сессии запрашивают по 489 МБ (на сортировку), но только на 22 из них SQL Server’у хватило памяти, даже учитывая, что используют все эти 22 сессии всего по 9 МБ!
Всего доступно 11 Гб памяти, 22 сессиям было выделено по 489.625 и у SQL Server’a осталось всего-то 258 доступных мегабайт, а новые сессии тоже хотят получить по 489. Что делать? Ждать, пока освободится память – они и ждут, даже не начиная выполняться. Что будут делать пользователи, если в их сессиях выполняются такие запросы? Тоже ждать.

Кстати, обратите внимание на рисунок с varchar(10) – запросы с varchar(10) выполнялись дольше, чем запросы с varchar(100) – и это при том, что у меня tempdb на очень быстром диске. Чем хуже диск под tempdb – тем медленнее будет выполняться запрос.

Отдельное примечание для SQL Server 2012/2014

В SQL Server 2012/2014 есть ещё одна забавная шутка с sort spills. Даже если вы используете тип char/nchar – это не гарантирует отсутствие spill’ов в tempdb. MS признала проблему в оптимизаторе, когда он выделял слишком мало памяти для сортировки, даже если количество строк было оценено верно.

Маленькое демо:

create table ##c6  (i int, d datetime, v char(6)); insert into ##c6 (i, d, v) select i, d, v from ##v10 select * from ##c6 where i between 100000 and 200000 order by d;

Включаем документированный флаг трассировки (НЕ ДЕЛАЙТЕ ЭТОГО НА ПРОДЕ БЕЗ НЕОБХОДИМОСТИ):

DBCC TRACEON (7470, -1);

Восклицательный знак у сортировки пропал, spill’а больше нет.

Выводы

С осторожностью используйте сортировку в своих запросах, там где у вас есть колонки (n)varchar. Если сортировка всё же нужна, крайне желательно, чтобы по колонке сортировки был индекс.

Учтите, что чтобы получить сортировку совсем необязательно явно использовать order by – её появление возможно и при merge join’ах, например. Та же проблема с выделением памяти возможна и при hash join’ах, например, вот с varchar(max):

select top 100 *  from ##vmax v1 inner hash join ##v10 v2 on v1.i = v2.i

Выделено 2.5 ГИГАБАЙТА памяти, используется 25 мегабайт!

Главный для меня вывод: размер колонки (n)varchar – ВАЖЕН! Если размер слишком маленький – возможны spill’ы в tempdb, если слишком большой – возможны слишком большие запросы памяти. При наличии сортировок разумным будет объявлять длину varchar как средняя длина записи * 2, а в случае SQL Server 2012/2014 — даже больше.

Неожиданный для меня вывод: varchar(max), содержащий меньше 8000 символов, реально работает медленнее, при фильтрах по нему. Пока не знаю как это объяснить — буду копать ещё.

Бонусный вывод для меня: уже почти нажав «опубликовать» я подумал, что ведь и с varchar(max) можно испытать проблему «маленького varchar’a». И правда, при хранении в varchar(max) больше чем 4000 символов (2000 для nvarchar) — сортировки могут стать проблемой.

insert into ##vmax(i, d, v) select i, d, replicate('a', 4000) v from ##v10;  select * from ##vmax where i between 200000 and 201000 order by d; 

truncate table ##vmax;  insert into ##vmax(i, d, v) select i, d, replicate('a', 4100) v from ##v10;  select * from ##vmax where i between 200000 and 201000 order by d;

Почему в самом начале я написал, что не всё так однозначно? Потому что, например, на моём домашнем ноуте с полумёртвым диском, spill’ы в tempdb при сортировке «маленьких» varchar приводили к тому, что такие запросы выполнялись на ПОРЯДКИ медленнее, чем аналогичные запросы с varchar(max). Если у вас хорошее железо, возможно, они не станут такой проблемой, но забывать о них не стоит.

Что было бы ещё интересно — посмотреть есть ли какие-то проблемы из-за слишком больших/маленьких размеров varchar’ов в других СУБД. Если у вас есть возможность проверить — буду рад, если поделитесь.

Маленький бонус

Отловить такие проблемы с помощью кэша планов запросов, к сожалению, не получится. Вот примеры планов из кэша: никаких предупреждений в них, увы, нет.

ссылка на оригинал статьи https://habr.com/ru/post/489182/