Курс по базам данных для начинающих

Серия уроков по серверам баз данных. Как установить базу данных, как настроить доступ, как сделать бэкап, как создать кластер базы данных, как настроить репликацию таблиц, базы данных. Ответы на эти вопросы вы получите в данном видеокурсе.

Подробнее: 👉 тут

#видео #бд

Буфферный кеш в PostgreSQL

Очередная серия статей от ребят из postgres. На этот раз о механизме журналирования, он же write-ahead log, он же WAL. Статьи не из лёгких и требуют серьезного погружения.

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

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

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

Размер кеша – это, что рекомендуют менять сразу после развёртывания базы. По умолчанию он равен 128 Мб. Нет конкретного значения, которое стоит выбрать для кеша, всё зависит от задачи и лучше выяснять на практике. Автор рекомендует взять для начала 1/4 оперативной памяти. Также стоит учитывать, что postgres использует обычные вызовы операционной системы, поэтому происходит двойное кеширование – кеш СУБД и кеш ОС.

Горячий вопрос: прогрев кеша. В postgres для этого есть расширение pg_prewarm. С помощью него можно сразу прочитать в кеш данные определённых таблиц. Также можно сохранять состояние кеша и восстанавливать после перезагрузки сервера.

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

#skills #database

Нестареющая классика, шпаргалка по SSH

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

Начинается с базы, коротко и по делу. Не нужно авторизовываться по паролю, настраивайте вход по ключу. Ключ генерируется одной командой и может быть закрыт паролем. Разумеется, ключ состоит из двух частей: открытой и закрытой. На сервер ключ можно скопировать ручками или специальной командой. У сервера есть свой ключ, который помещается в known_hosts. Для копирования данных через ssh-сессию есть команда scp. Это база. Теоретические основы были в отдельном посте.

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

– можно выполнить команду на удалённом сервере, оставаясь в локальной командной строке. Интересное применение, например, вывести содержимое какого-то файла и с помощью конвейера скормить его локально запущенной программе

– если хотим вызвать удалённую команду, а её вывод поместить в локальный файл, то для этого можно пробросить stdin/out

– чтобы каждый раз не вспоминать ip-адрес, куда подключаешься, или, наоборот, не вспоминать длиннющее имя сервера, то для этого можно в конфиг файле ssh прописать алиасы

– если локальная машина имеет графический x-сервер, а удаленная нет, то можно сделать так, чтобы приложения с сервера рисовались у вас на рабочем столе

– публичные wi-fi совсем небезопасны, а VPN порой просто режут, поэтому есть выход – работа ssh в режиме socks-proxy

– заканчивается статья такими схемами, от которых волосы начинают шевелиться: проброс портов, вложенные туннели, реверс-сокс-прокси и проброс авторизации

Интересный факт, которым меня мучали в институте, и он упоминается в статье: ip-адреса 127.0.0.1 и 127.1 идентичны и нет никакой ошибки. Вот такие пироги.

#skills

#interview

Вопросы для собеседования:

- Примеры последних интересных и скучных задач;
- Какие последние задачи запустили в продуктив;
- Как "выглядит" продуктив: какие инструменты/технологии используются, как это выглядит на практике;
- Есть ли мониторинг качества моделей и их переобучение?
- Есть ли code review или иные способы контроля качества проекта?
- Есть ли A/B тесты, как они реализованы, как используются результаты;
- Есть ли feedback от заказчиков по результатам проектов? Если есть, то в каком виде и как используется?
- Как приходят и ставятся/распределяются задачи?
- Какие обычные сроки у проектов? Есть ли adh-hoc и их доля? Есть ли исследовательские проекты?
- Какая текучка в отделе? Какая структура отдела?
- Какой стиль управления руководства/непосредственного начальника - жесткий контроль, свобода действия или что-то среднее.
- Были ли идеи от заказчиков, которые вы отказались делать? Что это было и почему?
- Какие конкретные задачи (1-2) буду выполнять, если выйду к вам?
- гибкий график? Возможность ходить на встречи/конференции? Переработки?
- Есть ли годовые цели и kpi? В каком виде?
- Планы по развитию отдела и людей?
- как ведется работа над проектами - в одиночку или команды по какому-то принципу?
- где хранятся данные, какое у них качество?
- как ведется разработка - инструменты, версионирование и так далее

#ml #petproject

(1) В этой статье можно отлично разобраться в большинстве оптимизаторов и их параметрах.

Статья с хорошими примерами проектирования сетей с помощью строительных блоков pytorch.

Топ обёрток для pytorch. Нереально классные штуки.

#systemdesign

Блог Alex Xu - https://blog.bytebytego.com/p/algorithms-you-should-know-before
Много интересного по систем дизайну