PRO ИНВЕСТИЦИИ

​📖 Введение в реляционные базы данных. Владимир Кириллов В книге рассматриваются основные понятия баз данных и систем управления ими (СУБД), моделей данных, положенных в основу баз данных и методов проектирования реляционных баз данных. Обсуждаются реляционные операции и основы теории нормализации отношений и приводятся примеры проектирования баз данных. Большое место уделено подробному описанию языка SQL – международного стандарта языка реляционных баз данных. Рассматриваются основные понятия, необходимые для изучения SQL и применения его на практике. Подробно рассмотрено манипулирование данными в интерактивном режиме, затронуты вопросы обеспечения безопасности хранимых данных, средств оптимизации запросов и создания прикладных программ. Идеально подойдëт для студентов и начинающих программистов. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Обработка исключений Spring WebFlux (часть 1) В Spring WebFlux приложении есть несколько способов обработки исключений. Рассмотрим возможные варианты. 1. Advice controller Сохранили контроллеры от Spring MVC — сохранили и возможность использовать Advice Controller. Чтобы обрабатывать исключения, можно аннотировать класс @AdviceController, а над методами разместить аннотации с типом (или несколькими типами) обрабатываемых исключений (используем @RestAdviceController как замену сочетания двух аннотаций @AdviceController и @ResponseBody). Методы должны возвращать Mono или Flux: код. Запустим приложение и перейдём на основную страницу http://localhost:8080/. После того, как пользователь авторизуется, если он обладает ролью ROLE_ADMIN — ему отобразится список всех пользователей (станут доступны REST-эндпоинты GET /api/users — получение списка всех пользователей и GET /api/users/{userId} получение информации по id пользователя). На странице Log in пройдём аутентификацию (имя пользователя: admin, пароль: password). Чтобы проверить обработку исключения при получении несуществующего пользователя, выполним GET-запрос с несуществующим userId: {"message":"User not found for id=100"} Проверим обработку исключения при попытке зарегистрировать уже существующего пользователя: перейдём на страницу Sign up и попытаемся добавить пользователя с именем admin, заведомо зная, что он уже есть в базе. Advice controller обработает исключение и на фронтэнд вернётся класс ErrorDto с сообщением об ошибке, преобразованный в JSON объект далее отобразится в HTML блоке c id=errorFragment. Помимо Advice Controller, исключения обрабатываются методом Mono handle(ServerWebExchange exchange, Throwable throwable) класса – DefaultErrorWebExceptionHandler. Поставим breakpoint внутри этого метода и вызовем исключение, которое мы не обрабатываем в Advice Controller: передадим строку в качестве userId: Whitelabel Error Page This application has no configured error view, so you are seeing this as a fallback. Wed Jul 06 12:33:18 MSK 2022 [92f5b0c9-12] There was an unexpected error (type=Bad Request, status=400). 📋 #Совет #Код ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Конфигурация доступа к эндпоинтам Spring WebFlux Для того, чтобы разграничить доступ по ролям для пользователей необходимо сконфигурировать SecurityWebFilterChain. Мы будем использовать форму логина от Spring, не будем использовать HTTP Basic аутентификацию (отключим её) и укажем с какими ролями и к каким эндпоинтам есть доступ: @EnableWebFluxSecurity public class WebSecurityConfig { @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } @Bean public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity httpSecurity) { return httpSecurity .formLogin().and() .httpBasic().disable() .authorizeExchange() .pathMatchers("/", "/login", "/signup").permitAll() .pathMatchers(HttpMethod.POST, "/api/users").permitAll() .pathMatchers(HttpMethod.GET, "/api/users/**").hasRole("ADMIN") .anyExchange().authenticated() .and() .build(); } } 📋 #Совет #Код ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Репозитории Spring WebFlux Чтобы создать реактивный репозиторий, нужно создать интерфейс, который расширяет ReactiveCrudRepository DomainType, PrimaryKeyType. Методы репозитория для выборки данных можно аннотировать @Query так же, как и для JPA репозиториев, чтобы извлекать данные SQL запросом, разница лишь в том, что реактивный репозиторий возвращает Mono или Flux: код. 📋 #Совет #Код ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Основы реляционных баз данных. Райордан Ребекка Книга посвящена вопросам проектирования и внедрения современных компьютерных систем, работающих с базами данных. Автор приводит и теоретические сведения, и информацию по разработке и внедрению таких систем. Содержится подробный анализ ситуаций, часто встречающихся на практике. Особое внимание уделено созданию проектной документации, проектированию пользовательского интерфейса и проблемам безопасности. В качестве примеров рассматриваются СУБД Microsoft. Издание адресовано менеджерам проектов, системным аналитикам и разработчикам баз данных, а также всем, кто интересуется вопросами, связанными с современными системами управления реляционными базами данных. Книга состоит из 18 глав, словаря терминов и предметного указателя. Прилагается компакт-диск с дополнительными материалами, шаблонами документов и форм, а также базами данных, которые анализируются в книге в качестве примеров. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Сервисы Spring WebFlux В методах сервисов, обращаясь к методам репозиториев: работаем с цепочкой Mono или Flux и по тем или иным условиям при необходимости выбрасываем исключения. Обратите внимание на метод switchIfEmpty издателя: выражение внутри него выполняется даже в том случае, если издатель будет не пустой (когда не нужно в результат возвращать значение из конструкции switchIfEmpty). Мы должны сохранять пользователя в базу только в том случае, если его ещё там нет. Если бы внутри конструкции switchIfEmpty мы не обернули вызов userRepository.save(user) в Mono.defer(…), то пользователь бы сохранялся всегда вне зависимости от того: есть он базе или нет. Лямбда-выражение внутри Mono.defer(…) выполняется только тогда, когда выражение идёт в возвращаемый результат. Для работы Spring Security необходимо предоставить бин, реализующий интерфейс ReactiveUserDetailsService, для чего необходимо переопределить метод Mono findByUsername(String username): код. 📋 #Совет #Код ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Контроллеры Spring WebFlux Обработку HTTP-запросов можно осуществлять с помощью контроллеров — классов, аннотированных @Controller, где аннотации над методами определяют тип и URL запроса (используем @RestController как замену сочетания двух аннотаций @Controller и @ResponseBody): код. Это те контроллеры, которые мы привыкли использовать в Spring MVC приложениях, для WebFlux на выходе они должны выдавать издателей реактивного потока: Flux или Mono. Контроллеры обращаются к сервисам, сервисы — к репозиториям. Flux и Mono испускают данные и только тогда эти данные обрабатываются подписчиками. Flux — это издатель, который эмитирует от 0 до N элементов. Mono — это издатель, который эмитирует либо ничего, либо один элемент. 📋 #Совет #Код ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Регистрация и авторизация в веб-приложении с помощью Spring WebFlux (часть 5) Пароли для пользователей должны храниться в закодированном виде. Для экономии времени используем онлайн BCrypt кодировщик паролей (для реального проекта лучше воспользоваться методом encode классa BCryptPasswordEncoder). Создадим пользователей admin (пароль password) и user (пароль userpassword) c ролями ROLE_ADMIN и ROLE_USER соответственно (файлы миграций V04insert_admin.sql и V05insert_user.sql): INSERT INTO users(username, password, role_id) VALUES ('admin', '$2a$12$ISkGJEEPR7I24altoMQNFu42sSpzoIE59Y2tmacCdBjTe47FQL85W', 2); INSERT INTO users(username, password, role_id) VALUES ('user', '$2a$12$3zd6n5NLCXg3fmGKGnZ9g.SRUFzEfpl01FktM1l.Xe4w9m3SJFPIS', 1); Теперь перейдём к коду приложения. Осуществляем переход на 1-ый коммит 1 Handle error with Advice Controller. 📋 #Совет #Код ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Регистрация и авторизация в веб-приложении с помощью Spring WebFlux (часть 4) Далее нажимаем «GENERATE» внизу страницы и браузер скачивает проект. Распаковываем проект и вручную добавим только зависимость ModelMapper, которым будем пользоваться для преобразования доменных сущностей в DTO (файл build.gradle блок dependencies): implementation 'org.modelmapper:modelmapper:3.1.0' Добавим миграции для базы данных в папке resources/db/migration: создадим и заполним таблицы users (здесь будут храниться пользователи) и roles (роли пользователей). В наименовании ролей пользователей Spring Security ожидает увидеть префикс ROLE_, поэтому для пользователя и администратора роли будут ROLE_USER и ROLE_ADMIN (файл миграций V03__populate_roles_table.sql): INSERT INTO roles(id, role_name) VALUES (1, 'ROLE_USER'), (2, 'ROLE_ADMIN') 📋 #Совет #Код ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Регистрация и авторизация в веб-приложении с помощью Spring WebFlux (часть 3) Создадим Spring WebFlux приложение с помощью Gradle. Мы будем использовать Spring Initializr, чтобы сэкономить время и не создавать структуру проекта вручную: Выбираем тип проекта, язык Java, версию Spring Boot, даём имя нашему приложению, тип выходного файла и версию Java с долгосрочной поддержкой (LTS версия на момент написания — 17). Добавляем зависимости в проект: 1. Spring Reactive Web (spring-boot-starter-webflux) — зависимость для построения Spring приложения на реактивном стеке. 2. Lombok — для избавления от рутинного кода, придания читабельности. 3. Spring Security — разграничение доступа к эндпоинтам. 4. PostgreSQL Driver — драйвер R2DBC и JDBC, который нужен для работы Flyway (пока что не умеет работать через R2DBC). 5. Thymeleaf — шаблонизатор страниц. 6. Spring Data R2DBC — стартер для R2DBC, который даёт возможность работать с ReactiveCrudRepository. 7. Flyway — инструмент для миграций баз данных (при помощи миграций создадим таблицы и заполним их данными). 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

❓С чего начать осваивать NoSQL БД? Администраторов и разработчиков 4 октября в 20:00 (мск) OTUS приглашает на открытый урок «OrientDB: запрашиваем данные из графов». 🔥На занятии вы рассмотрите базовые возможности OrientDB и способы манипуляции данными в графовых базах данных на примере OrientDB. Также разберете два варианта запросов данных: sql-like и cypher-like.  Один из них, Cypher — язык запросов neo4j другой известной графовой базы данных, будет изучаться на онлайн-курсе «NoSQL» от OTUS. 👉Хотите попасть на бесплатный вебинар и учиться потом на курсе по спец. цене? Сделайте первый шаг — пройдите вступительный тест 

​📖 Язык SQL. Базовый курс. Е. П. Моргунов Это учебно-практическое пособие представляет собой первую, базовую, часть учебного курса по языку SQL, предлагаемого российской компанией Postgres Professional. Учебный материал излагается в расчете на использование системы управления базами данных PostgreSQL. Пособие может использоваться как под руководством преподавателя, так и для самостоятельного изучения языка SQL. Пособие будет полезно широкому кругу студентов и специалистов, желающих ознакомиться с основами языка SQL в среде системы управления базами данных PostgreSQL. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Регистрация и авторизация в веб-приложении с помощью Spring WebFlux (часть 2) 1. Для корректного отображения символов кириллицы изменяем кодовую страницу: chcp 1251. 2. Заходим в psql под суперпользователем postgres, который был создан при установке БД (в данном случае «postgres»): psql -U postgres 3. Командой du выводим список пользователей, который есть сейчас. 4. Создаём базу данных chat_db: create database chat_db. 5. Создаём пользователя chat_user: create user chat_user with encrypted password ‘user_password’. 6. Делегируем пользователю chat_user привилегии для работы с базой данных chat_db: grant all privileges on database chat_db to chat_user. 7. Выведем список баз данных, чтобы удостовериться, что пользователь был добавлен к базе. Через созданного пользователя будем подключаться к базе данных через R2DBC драйвер в приложении. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Регистрация и авторизация в веб-приложении с помощью Spring WebFlux (часть 1) Для начала, нам нужно создать базу данных для хранения информации о пользователях. Поскольку мы создаём реактивное приложение, то и подключение к базе данных тоже должно быть реактивное и его обеспечит R2DBC. Не все базы данных на сегодняшний день поддерживают R2DBC, что ограничивает наш выбор, поэтому выберем PostgreSQL. Устанавливаем базу данных, не забываем прописать путь к psql в переменную PATH (если не пропишется при установке), чтобы в консоли можно было воспользоваться psql и создать базу данных и её пользователя. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Операции с агрегациями (часть 2) С сортировкой необходимо быть особенно аккуратным. Чтобы отсортировать все записи без группировки по ключу, Reduce соберёт все записи на один сервер и будет производить сортировку нераспределённо. Поэтому нужно избегать операций, которые выполняются с неравномерной группировкой (когда группирующих ключей меньше, чем доступных серверов). Теперь вы узнали, на что нужно обращать внимание при написании запросов к большим данным. Ключ к написанию эффективного запроса — наблюдение за потребляемыми ресурсами БД в зависимости от изменения вашего запроса. Меняйте порядок join, группировок, подзапросы и ищете лучшее сочетание производительности и нагрузки. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Операции с агрегациями (часть 1) Теперь рассмотрим операции с агрегациями. Допустим, мы хотим посчитать количество клиентов по полу. SQL-запрос такой: SELECT COUNT(*) FROM CLIENTS GROUP BY CLIENTS.GENDER Стадия Map без сюрпризов, снова параллельное чтение тремя серверами. А вот Reduce всё меняет. Поскольку у нас есть группировка по полу, в ответе мы хотим увидеть два числа — количество мужчин и количество женщин. Значит, на стадии Reduce мы можем задействовать максимум два сервера. Один сервер должен считать всех мужчин, другой — всех женщин. Для этого на стадии Shuffle необходимо передать записи всех мужчин на один сервер, а записи женщин — на другой сервер. Тогда на этапе Reduce результирующим серверам останется только посчитать все записи, полученные на этапе Shuffle. Мы видим, что Reduce распределяет вычисления в зависимости от группирующих функций. Такая логика применяется для всех агрегатных функций, distinct, join (где группировка идет в зависимости от условия join) и для сортировок. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Как писать эффективные SQL-запросы (часть 2) Этот запрос можно достаточно легко изменить: INSERT INTO CLIENTS_NEW SELECT * FROM CLIENTS Теперь вместо вывода результата на экран результат будет записан в другую таблицу. Поскольку другая таблица также хранится распределённо, запись могут производить одновременно 3 сервера. Таким образом, не потребуется собирать все данные в одном месте, все вычисления будут хорошо распределяться. Стадия Map будет хорошо параллелиться, однако теперь стадия Reduce (запись результата) будет выполняться распределённо на тех же серверах, где данные и были прочитаны. Мы можем пропустить стадию Shuffle (не передавать данные между серверами перед записью результата), что тоже ускоряет вычисления. Аналогичная логика применима к операциям с фильтрами, такими как «SELECT * FROM CLIENTS WHERE CLIENTS.GENDER = 1» и так далее. Такие фильтры также будут выполняться распределённо на стадии Map. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Как писать эффективные SQL-запросы (часть 1) Вернемся к запросу: SELECT * FROM CLIENTS Здесь мы получаем равномерное чтение таблицы на трёх серверах. Если результат надо вывести на экран, он должен быть собран на один сервер, с которого мы выполняем запрос. Получается, что наш последний шаг вывода на экран сводит распределённые вычисления на нет — вся финальная нагрузка придётся на наш сервер, где мы получаем результат. Стадия Map будет распределённой. Далее последует стадия Shuffle, которая перекинет все данные на один финальный сервер, который должен будет вместить весь результат и вывести его на экран. Если данные настолько большие, что не помещаются на один сервер, даже такой простейший запрос никогда не выполнится. Результирующий сервер всегда будет возвращать ошибку Out of memory. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Основы парадигмы MapReduce (часть 2) Каждая из этих операций по-разному распределяется и параллелится, поэтому важно понимать, что они собой представляют. 1. Стадия Map обычно представляет собой обычное чтение с жёсткого диска. Кроме чтения здесь могут применяться однострочные трансформации и фильтры, т.е. операции без join, group by, order by, distinct и без агрегирующих функций. Операции на этой стадии всегда хорошо параллелятся и не создают нагрузку на БД, т.к. каждый сервер читает только ту часть данных, которая имеется у него на жёстком диске. Данные зачастую сохранены равномерно на каждом сервере. Все серверы участвуют в этой стадии и делят нагрузку равномерно. 2. На стадии Shuffle никаких вычислений не происходит, зато все данные перемещаются между серверами таким образом, чтобы из них можно было получить финальный результат на стадии Reduce. Этот шаг станет понятен только после погружения в стадию Reduce, поэтому перейдём к ней. 3. Стадия Reduce самая проблемная, т.к. она может провоцировать большие проблемы с производительностью БД. Здесь происходят все группирующие операции, а также операции, которые записывают результат. Некоторые операции не могут выполняться одновременно на нескольких серверах, поэтому для их выполнения требуется собрать весь объем данных на одном сервере. Если данные не помещаются на один сервер, запрос всегда будет выдавать ошибку. 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL

​📖 Основы парадигмы MapReduce (часть 1) Всегда нужно помнить, что в больших данных почти любая БД хранит данные на нескольких серверах. Представим, что у нас есть 3 сервера и таблица клиентов. Вся таблица равномерно распределена на 3 части, каждый сервер хранит 1/3 данных. Чтобы вернуть результат запроса, нужно прочитать каждую часть с каждого сервера и собрать всё на одном сервере, где мы просматриваем результат. Простейший SQL-запрос: SELECT * FROM CLIENTS Такой простой запрос разбивается на три обязательные части MapReduce: 1. Map 2. Shuffle 3. Reduce 📋 #Совет ▬▬▬▬▬▬▬▬ // How To SQL