Управляемый сервис YDB: настройка, применение, мониторинг

Поделиться
HTML-код
  • Опубликовано: 11 янв 2025

Комментарии • 10

  • @TheRedbeardster
    @TheRedbeardster 2 года назад

    Хороший доклад, спасибо! Весло, с помощью которого добрался, отложил в сторону.

  • @AlexeyBaranoshnikov
    @AlexeyBaranoshnikov 2 года назад

    В примерах ydb-nodejs-sdk используется метод await driver.destroy(). Подскажите, в чем его суть? Он имеет смысл в случае serverless функции, которая и так прекращает свою жизнь после выполнения? Проблема в том, что для того, чтобы вызвать destroy нужно знать, когда обращение в БД уже выполняться не будет, а это не всегда тривиально. Нарушается принцип единственной ответственности. Некоторое место в программе должно знать о том, что происходило до нее и что будет после, а это плохо для читаемости кода.

    • @maxzinal8897
      @maxzinal8897 2 года назад +1

      Добрый день!
      Проконсультировался с коллегами, которые разрабатывали драйвер для nodejs, теперь могу ответить :)
      Если завершение всего процесса совпадает по времени с driver.destroy(), то явный вызов последнего избыточен. В настоящий момент он освобождает только ресурсы внутри самого процесса. Но здесь вопрос в том, как завершается процесс, по какому событию или сигналу. Если все функции в js-скрипте завершат своё выполнение, а периодические callback-функции будут продолжать выполняться, тот процесс сам по себе (без внешнего сигнала) не завершится. Driver.destroy() запускает остановку callback-функций, связанных с работой драйвера YDB.
      Для часто выполняемой serverless-функции более эффективно держать ссылку на драйвер в глобальной переменной, поскольку контейнер вызванной функции сразу не завершается, а какое-то время ждёт повторного вызова (что позволяет не тратить время на инициализацию). Если serverless-функция вызывается относительно редко, то можно создавать и уничтожать объект драйвера на каждом вызове, в противном случае стоит его закэшировать. Большого смысла вызывать в serverless функции destroy нет.

    • @AlexeyBaranoshnikov
      @AlexeyBaranoshnikov 2 года назад

      @@maxzinal8897 Спасибо. Все очень понятно написано. Не лишним будет предупредить тех, кто решит хранить драйвер в глобальной переменной. Если Вы заполняете его строго до выполнения основного кода с проверкой существования - это одно. Но если решите формировать его перед непосредственным использованием в асинхронном коде вроде Promise.all(...), то легко получить множественные инициализации драйверов, так как все процессы пойдут одновременно и начнут инициировать свои экземпляры драйвера.

  • @DarkbishopGaming
    @DarkbishopGaming 2 года назад

    Есть информация почему в python sdk 'ydb' - классы для модуля не отображаются ?

    • @maxzinal8897
      @maxzinal8897 2 года назад

      Добрый день! Не совсем понял, что именно не отображается и в какой момент?
      Установить YDB Python SDK со всеми зависимостями можно командой pip3 install -U 'ydb[yc]'.
      После этого SDK становится доступно для использования, и в том числе отображается в подсказках типовых Python IDE (например VSCode).

    • @DarkbishopGaming
      @DarkbishopGaming 2 года назад

      @@maxzinal8897 не там просто только через класс main можно к библиотеке обращаться.

    • @maxzinal8897
      @maxzinal8897 2 года назад

      @@DarkbishopGaming Посмотрите примеры для YDB Python SDK на Гитхаб (сюда ссылку вставить не позволяет).
      Если вдруг что-то не будет получаться, приходите в официальный чат - ссылки есть в шапке сайта YDB.

    • @DarkbishopGaming
      @DarkbishopGaming 2 года назад

      @@maxzinal8897 Так уже) И там реально import работает только через класс с названием main.
      Я даже себе проект библиотеки клонировал, сделал пару тестов, и не видит.
      Возможно проблема в Pycharm. Хотя до этого десятки модулей работали без привязки в main.

    • @DarkbishopGaming
      @DarkbishopGaming 2 года назад

      @@maxzinal8897 Посмотрю чат, спасибо.