В этой статье хочу посмотреть на ML опцию, встроенную в Oracle 12.
пятница, 27 марта 2020 г.
воскресенье, 8 марта 2020 г.
Нейронные сети и компьютерное зрение
Метки:
machine learning,
ml,
python,
torch
Это краткий пересказ курса Нейронные сети и компьютерное зрение.
В этой заметке больше внимания будет уделено практической части. Теорию можно почитать в предыдщей статье "Введение в нейронные сети".
Код практической части на гитхабе курса.
В этой заметке больше внимания будет уделено практической части. Теорию можно почитать в предыдщей статье "Введение в нейронные сети".
Код практической части на гитхабе курса.
среда, 26 февраля 2020 г.
Работа с Kafka через Spark Structure Streaming
Памятка по чтению данных из Kafka топика средствами Spark Structure Streaming
- Подключение к Kafka
- Описание схемы топика
- Системные столбцы
- Преобразование json в плоскую таблицу
- Запуск стрима
- Указание начального смещения
- Запуск batch процессинга
- Создание событий на стрим
- Поддержка состояния в стриме
- Обработка avro схемы
- Стримминг в inmemory DF
- Join статичных и Stream таблиц
- Обработка окна в 1 час с шагом в 1 минуту
- Обработка стрима мини батчами
- Запуск из консоли
- Использование стрима в HiveQL
суббота, 25 января 2020 г.
SQL заметки за 2019
Продолжение цикла заметок и статьи 2016 года.
Хочу зафиксировать моменты Oracle и SQL в общем, которые достаточно интересны, но малы для отдельной статьи.
Хочу зафиксировать моменты Oracle и SQL в общем, которые достаточно интересны, но малы для отдельной статьи.
-
Трансформация запросов
- Виды преобразований запросов
- Результрующий запрос после всех преобразований оптимизатора
- Ручная трансформаиця 1 запроса в другой
-
Статистика
- Устаревание статистики
- Инкрементальный сбор статистики в партицированных таблицах
- Селективность колонки с 12.2
- Хинт для задания статистики колонки
- статистика по использованию сегмента
- Ассоциация статистики к функции
- Колонки-кандидаты для гистограммы
- Просмотр данных гистограммы
- Join cardinality по гистограмме
- Определение селективности, если на обоих столбцах соединения есть гистограмма
-
PLSQL
- Автономная транзакция
- Иключение при поиске элемента по ключу
- plsql redefinition
- Консистентность функций
- Параллелизация pipeline функций
-
PLSQL коллекции
- Varrays - обычный массив
- Hash table - Associative array над связанным списком
- Nested tables
-
Анализ производительности запросов
- индекс - кандидат на удаление
- forall - в статистике (ash/awr)
- Выявление skew через oem monitor
- Пометка запроса для awr
- Чтение плана
- Монотонный рост значений в индексе
- Долгий вызов plsql в запросе
- Undo/redo при вставке
- Параллельное последовательное чтение индекса
- Result_cache
- Вставка игнорируя consraint, но с сохранением ошибок
- Пометка блока горячим
-
Оптимизация хранения
- Создание not null поля с default
- Index coalesce
- Вставка в новую таблицу
- Вставка в длинную таблицу
- Include Индекс
- Дополнительные параметры таблиц в Exadata
- Отрицательная эффективность Exadata
- Структура Lob
-
Партицирование
- Системное партицирование
- Reference partitions
- Глобальные индексы
- INDEXING OFF|On
- Тепловая карта партиций
-
Настройки бд
- Виды репликаций
- Exadata 12.2
- Особенности только в exadata
-
Разные SQL алгоритмы
- Пагинация на ключах
- start_of_group - нумерация групп по разрывам
- Забор таблицы частями без fullscan, индексов и партиций
- Поиск одного пропуска
- Вставка данных больше размера varchar
- partition join
- Округление через to int
- Удаление из обновляемого представления
- Выражение на месте join
- DBMS_HS_PASSTHROUGH - Полное выполнение запроса на удаленной бд
- Top уникальных строк в группе
четверг, 21 ноября 2019 г.
понедельник, 19 августа 2019 г.
Оптимизация хранения данных в bigdata
воскресенье, 30 июня 2019 г.
Машинное обучение через решающие деревья
Это краткий пересказ курса: Введение в Data Science и машинное обучение с дополнением 2 тем: градиентный бустинг и решающие деревья в Spark.
суббота, 18 мая 2019 г.
Oracle 18-19: новые возможности для разработчика
Список нововведений в Oracle DB, важных, по моему мнению, для разработчика.
воскресенье, 10 марта 2019 г.
понедельник, 18 февраля 2019 г.
RBTree - красно-черное дерево
Красно-чёрное дерево (Red-black tree, RB-Tree) — самобалансирующееся двоичное дерево поиска, гарантирующих логарифмический рост высоты от числа узлов.
Дополнительные требования к двоичному дереву:
1. Узел либо красный, либо чёрный
2. Корень — чёрный
3. Все листья (NIL) — чёрные (листья не содержат данных)
4. Оба потомка каждого красного узла — чёрные.
5. Всякий простой путь от данного узла до любого листового узла, являющегося его потомком, содержит одинаковое число чёрных узлов.
Эти ограничения реализуют главное свойство красно-чёрных деревьев: путь от корня до самого дальнего листа не более чем в два раза длиннее пути от корня до ближайшего листа.
Результатом является то, что дерево примерно сбалансировано.
Реализацию красно-черного дерева на java можно посмотреть тут: RBTree.java
Но в такой реализации оно сложно для понимания и программистам бд более близка реализация через B-дерево с фактором = 4.
В таком дереве каждый узел может содержать от 1 до 3 значений и от 2 до 4 указателей на потомков.
Если страница В-дерева содержит только одно значение, данный узел чёрный и имеет двух потомков.
Если страница содержит три значения, то центральный узел является чёрным, а каждый его сосед — красным.
Однако, если страница содержит два значения, любой узел может стать чёрным в красно-чёрном дереве (и тогда второй будет красным).
Пример реализации красно-черного дерева на основе B-дерева с размером блока = 3 можно посмотреть тут: BTree.scala
Для программистов БД нужно помнить 2 отличия B-дерева от B+дерева:
* при разделение элемент переносится наверх (не остается в листе)
* листы не связаны друг с другом ссылками
Красно-чёрные деревья являются одними из наиболее активно используемых на практике самобалансирующихся деревьев поиска.
В частности, контейнеры set и map в большинстве реализаций библиотеки STL языка C++, класс TreeMap языка Java, ассоциативный массив, когда реализация через списки дает слишком много коллизий
( подробное описание хэш массива тут: 3ий вариант реализации Oracle HashMap )
Популярность красно-чёрных деревьев связана с тем, что на них часто достигается подходящий баланс между степенью сбалансированности и сложностью поддержки сбалансированности при удалении.
Дополнительные требования к двоичному дереву:
1. Узел либо красный, либо чёрный
2. Корень — чёрный
3. Все листья (NIL) — чёрные (листья не содержат данных)
4. Оба потомка каждого красного узла — чёрные.
5. Всякий простой путь от данного узла до любого листового узла, являющегося его потомком, содержит одинаковое число чёрных узлов.
Эти ограничения реализуют главное свойство красно-чёрных деревьев: путь от корня до самого дальнего листа не более чем в два раза длиннее пути от корня до ближайшего листа. Результатом является то, что дерево примерно сбалансировано.
Реализацию красно-черного дерева на java можно посмотреть тут: RBTree.java
Но в такой реализации оно сложно для понимания и программистам бд более близка реализация через B-дерево с фактором = 4.
В таком дереве каждый узел может содержать от 1 до 3 значений и от 2 до 4 указателей на потомков. Если страница В-дерева содержит только одно значение, данный узел чёрный и имеет двух потомков.
Если страница содержит три значения, то центральный узел является чёрным, а каждый его сосед — красным.
Однако, если страница содержит два значения, любой узел может стать чёрным в красно-чёрном дереве (и тогда второй будет красным).
Пример реализации красно-черного дерева на основе B-дерева с размером блока = 3 можно посмотреть тут: BTree.scala
Для программистов БД нужно помнить 2 отличия B-дерева от B+дерева:
* при разделение элемент переносится наверх (не остается в листе)
* листы не связаны друг с другом ссылками
Красно-чёрные деревья являются одними из наиболее активно используемых на практике самобалансирующихся деревьев поиска.
В частности, контейнеры set и map в большинстве реализаций библиотеки STL языка C++, класс TreeMap языка Java, ассоциативный массив, когда реализация через списки дает слишком много коллизий
( подробное описание хэш массива тут: 3ий вариант реализации Oracle HashMap )
Популярность красно-чёрных деревьев связана с тем, что на них часто достигается подходящий баланс между степенью сбалансированности и сложностью поддержки сбалансированности при удалении.
Подписаться на:
Сообщения (Atom)