Вам никто не мешает сохранить ссылку на конец и начало. В таком случае вы всегда сможете вставить в эти места за O(1). Да, в вставка в произвольное место будет все еще O(n). Собственно об этом и сказано в таблице.
Стоит отметить, что сложность push — O(1), а для unshift — O(n). Так что использовать push и перевернуть один раз на очень больших инпутах, про которые идет речь в этой задаче, будет выгоднее.
Если после прочтения статьи у вас остался вопрос, как же использую goose работать с serverless базой, так как все примеры подключения в статье приведены для локальной базы данных, то вот решение. Из строки подключения, которую вы можете скопировать из Web UI, вам нужно выкинуть фрагмент ?database=. Например:
goose ydb "grpcs://ydb.serverless.yandexcloud.net:2135/ru-central1/b1g***/etn***?token=$IAM_TOKEN&go_query_mode=scripting&go_fake_tx=scripting&go_query_bind=declare,numeric" up
Формально, шифрованный вариант называется JWE. Подробнее в RFC https://datatracker.ietf.org/doc/html/rfc7516 Некоторые могут назвать его шифрованным JWT, потому что для конечного разработчика работа с ним схожа с JWT и многие библиотеки реализуют оба варианта.
Не на каждый. Есть возможность задать параметр concurrency — количество одновременно обрабатываемых контейнером запросов. От 1 до 16. Также serverless контейнеры будут горизонтально масштабироваться, если одновременно поступает много вызовов.
Во-вторых, вы правы, архивация кода и всех зависимостей не самое удобное решение, особенно, учитывая что зависимости нужно паковать для целевой платформы, которая далеко не всегда будет совпадать с платформой, на которой происходит сборка. Поэтому уже давно существует более простое решение: указать на директорию с кодом при помощи ключа --source-path и убедиться, что там есть файл с описанием зависимостей (для NodeJS это package.json). Все остальное за вас сделает yc CLI — соберет zip-архив с кодом, а потом на сервере будет выполнена загрузка указанных зависимостей.
В-третьих, пример, указанный в статье, недавно был актуализирован и переписан с использованием новой версии SDK для NodeJS. Новая версия SDK v2 не является drop-in replacement'ом и еще находится в разработке, но именно на неё я бы рекомендовал ориентироваться в текущий момент. В основном потому что там поддержаны все сервисы Облака, а так же используются свежие версии сторонних зависимостей.
Ну еще одно замечание: долгое время NodeJS SDK был не самым качественным и активно поддерживаемым, поэтому появилась альтернативная реализация, подхода описанного в статье, переписанная на Go.
На сколько я знаю, ffmpeg умеет сам получать доступ к файлам по HTTP(S). Нам нужно лишь сформировать ссылку. Если речь идет про бакет без публичного доступа, то можно воспользоваться предподписанной ссылкой. Например, так из сомандной строки.
Говоря про второй пункт в «Проблемах и ограничениях», хотел бы узнать, не смотрели ли вы в сторону нового сервиса Yandex Data Streams. В нем есть возможность задать функцию, которая будет использоваться для трансформации данных. Также его можно использовать как источник в другом новом сервисе Yandex Data Transfer, а приёмником указать кластер ClickHouse. Возможно в этом случае запись в базу будет идти оптимальнее.
Вот про это хотелось рассказать в следующем посте. Сейчас в превью есть CDN https://cloud.yandex.ru/services/cdn, цены на трафик оттуда ниже чем непосредственно из Yandex Object Storage.
Степень «кусачасти» цен оценивать не берусь. Если сравнивать с публично доступными ценами конкурентов, которые я смог найти, то выглядит весьма привлекательно.
Вы правы, но сравнение их может потянуть на отдельный пост. Моя же цель была рассказать, что обычный MP4 одним файлом — не лучшая идея. Одним из аргументов в пользу HLS может служить нативная поддержка этого формата браузерами: https://caniuse.com/?search=hls. В остальном это довольно схожие по функциональности и подходу форматы, имеющие примерно одинаковую поддержку сторонними плеерами.
Все так. В вашем посте описывается решение для стримминга. А тут скорее описан подход для статики, начиная с основ технологии. Хотелось показать, что в HLS нет никакой магии, а сделать это проще на элементарном примере с ffmpeg.
Вам никто не мешает сохранить ссылку на конец и начало. В таком случае вы всегда сможете вставить в эти места за O(1). Да, в вставка в произвольное место будет все еще O(n). Собственно об этом и сказано в таблице.
Вынужден сослаться на википедию. https://en.wikipedia.org/wiki/Array_(data_structure)#Comparison_with_other_data_structures
Для списков вставка в начало и конец O(1).
Стоит отметить, что сложность
push— O(1), а дляunshift— O(n). Так что использоватьpushи перевернуть один раз на очень больших инпутах, про которые идет речь в этой задаче, будет выгоднее.Вроде даже с предыдущими моделями работало https://yandex.cloud/ru/docs/foundation-models/concepts/yandexgpt/function-call
Нет, это персонаж из Scavengers Reign.
Если после прочтения статьи у вас остался вопрос, как же использую goose работать с serverless базой, так как все примеры подключения в статье приведены для локальной базы данных, то вот решение.
Из строки подключения, которую вы можете скопировать из Web UI, вам нужно выкинуть фрагмент
?database=. Например:Формально, шифрованный вариант называется JWE. Подробнее в RFC https://datatracker.ietf.org/doc/html/rfc7516 Некоторые могут назвать его шифрованным JWT, потому что для конечного разработчика работа с ним схожа с JWT и многие библиотеки реализуют оба варианта.
Можно начать с того, что в большом количестве камер Nikon стоят сенсоры Sony. https://www.digitalcameraworld.com/news/these-32-nikon-cameras-are-sonys-in-disguise
К тому же Sony лидер по технологиям сенсоров. Они выпустили первую full-frame камеру с глобальным затвором. https://electronics.sony.com/imaging/interchangeable-lens-cameras/all-interchangeable-lens-cameras/p/ilce9m3b
Загрузка готовых dll не «дыра в системе». Она вроде описана даже в документации в разделе Ручная поставка зависимостей.
Не на каждый. Есть возможность задать параметр concurrency — количество одновременно обрабатываемых контейнером запросов. От 1 до 16. Также serverless контейнеры будут горизонтально масштабироваться, если одновременно поступает много вызовов.
А клиенту в смете вы тоже 1 день выставите? А кушать на что будете оставшийся месяц? Нет в вас предпринимательской жилки.)
Есть видео, где эта тема раскрыта гораздо подробнее и нагляднее. https://www.youtube.com/watch?v=094y1Z2wpJg
Давайте по порядку. Во-первых, оригинальная статья была написана для блога на Medium. https://nikolaymatrosov.medium.com/yandex-cloud-cron-snapshot-bdee54c87541
Во-вторых, вы правы, архивация кода и всех зависимостей не самое удобное решение, особенно, учитывая что зависимости нужно паковать для целевой платформы, которая далеко не всегда будет совпадать с платформой, на которой происходит сборка. Поэтому уже давно существует более простое решение: указать на директорию с кодом при помощи ключа
--source-pathи убедиться, что там есть файл с описанием зависимостей (для NodeJS этоpackage.json). Все остальное за вас сделаетycCLI — соберет zip-архив с кодом, а потом на сервере будет выполнена загрузка указанных зависимостей.В-третьих, пример, указанный в статье, недавно был актуализирован и переписан с использованием новой версии SDK для NodeJS. Новая версия SDK v2 не является drop-in replacement'ом и еще находится в разработке, но именно на неё я бы рекомендовал ориентироваться в текущий момент. В основном потому что там поддержаны все сервисы Облака, а так же используются свежие версии сторонних зависимостей.
Ну еще одно замечание: долгое время NodeJS SDK был не самым качественным и активно поддерживаемым, поэтому появилась альтернативная реализация, подхода описанного в статье, переписанная на Go.
На сколько я знаю, ffmpeg умеет сам получать доступ к файлам по HTTP(S). Нам нужно лишь сформировать ссылку. Если речь идет про бакет без публичного доступа, то можно воспользоваться предподписанной ссылкой. Например, так из сомандной строки.
ffmpeg -i "$(aws s3 presign s3://MY_BUCKET/MY_FILE --expires 5)"Ну или формировать ее при помощи SDK на вашем любимом языке программирования.
Говоря про второй пункт в «Проблемах и ограничениях», хотел бы узнать, не смотрели ли вы в сторону нового сервиса Yandex Data Streams. В нем есть возможность задать функцию, которая будет использоваться для трансформации данных. Также его можно использовать как источник в другом новом сервисе Yandex Data Transfer, а приёмником указать кластер ClickHouse. Возможно в этом случае запись в базу будет идти оптимальнее.
Вот про это хотелось рассказать в следующем посте. Сейчас в превью есть CDN https://cloud.yandex.ru/services/cdn, цены на трафик оттуда ниже чем непосредственно из Yandex Object Storage.
Степень «кусачасти» цен оценивать не берусь. Если сравнивать с публично доступными ценами конкурентов, которые я смог найти, то выглядит весьма привлекательно.
Вы правы, но сравнение их может потянуть на отдельный пост. Моя же цель была рассказать, что обычный MP4 одним файлом — не лучшая идея.
Одним из аргументов в пользу HLS может служить нативная поддержка этого формата браузерами: https://caniuse.com/?search=hls. В остальном это довольно схожие по функциональности и подходу форматы, имеющие примерно одинаковую поддержку сторонними плеерами.
Если вы про https://aws.amazon.com/elastictranscoder/, то да, к сожалению, в Яндекс Облаке пока нет аналогичного managed решения.
Все так. В вашем посте описывается решение для стримминга. А тут скорее описан подход для статики, начиная с основ технологии. Хотелось показать, что в HLS нет никакой магии, а сделать это проще на элементарном примере с ffmpeg.
Спасибо за полезные уточнения, позволяющие сделать из простого примера в статье решение, более подходящее для продакшена.