Рубрика «бд» - 2

image

Я присоединился к команде Facebook в 2011 году в качестве инженера бизнес-аналитика. К моменту, когда я покинул команду в 2013 году я уже был дата-инженером.

Меня не продвигали или назначали на эту новую позицию. Фактически, Facebook пришла к выводу, что выполняемая нами работа является классической бизнес-аналитикой. Роль, которую в итоге мы для себя создали, была полностью новой дисциплиной, а я и моя команда находились на острие этой трансформации. Мы разрабатывали новые подходы, способы решения задач и инструменты. При этом, чаще всего, мы игнорировали традиционные методы. Мы были пионерами. Мы были дата-инженерами!

Дата-инжиниринг?

Наука о данных как самостоятельная дисциплина переживает период отроческого самоутверждения и определения себя. В тоже время дата-инжиниринг можно было назвать ее «младшим братом», который тоже проходил через нечто подобное. Дата-инжиниринг принимал от своего «старшего родственника» сигналы, искал свое место и собственную идентичность. Как и ученые, занимающиеся обработкой данных, дата-инженеры тоже пишут код. Он является высокоаналитическим, с большой долей визуализации.

Но в отличие от ученых, работающих с данными и вдохновленными более зрелым прародителем сферы — программированием — дата-инженеры создают собственные инструменты, инфраструктуру, фреймворки и сервисы. На самом деле, мы намного ближе к программированию, чем к науке о данных.
Читать полностью »

Эволюционный дизайн баз данных - 1

За последнее десятилетие мы разработали и усовершенствовали несколько методов, которые позволяют дизайну баз данных эволюционировать параллельно с разработкой приложения.

Это очень ценное свойство гибких методологий. Методы опираются на применение непрерывной интеграции и автоматизированного рефакторинга к разработке баз данных, а также на тесное взаимодействие между разработчиками приложений и администраторами БД. Эти методы работают как в препродакшн и в уже стартовавших системах, в свежих проектах без легаси, так и в унаследованных системах.

В последнее десятилетие мы наблюдаем рост гибких методологий. По сравнению со своими предшественниками, они изменяют требования к дизайну баз данных. Одно из важнейших среди требований – идея эволюционной архитектуры. В гибком проекте вы предполагаете, что не можете заранее поправить требования системы. В результате, иметь детализированную, четкую стадию дизайна в начале проекта становится непрактично. Архитектура системы должна эволюционировать одновременно с итерациями софта. Гибкие методы, в частности, экстремальное программирование (XP), имеют набор методик, которые делают эту эволюционную архитектуру практичной.Читать полностью »

На счёт БД на первый взгляд может показаться, что функциональность из коробки весьма скудная. Отчасти это правда, но компенсируется тем, арсенал очень хорошо продуман, решает поставленные задачи и ориентирован на производительность.
А если вам нужны более функциональные инструменты — их всегда можно до установить по вкусу, это гораздо проще чем выпилить сложного медлительного монстра.

Данная статья покажет основные интерфейсы, а трейты csCRUD и csCRUD_helpers останутся на другой раз.

Читать полностью »

В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

Процесс проектирования БД с использование метода НФ является итерационным и заключается в последовательном переводе отношения из 1НФ в НФ более высокого порядка по определенным правилам. Каждая следующая НФ ограничивается определенным типом функциональных зависимостей и устранением соответствующих аномалий при выполнении операций над отношениями БД, а также сохранении свойств предшествующих НФ.
Читать полностью »

Рефакторинг серверной страховой компании: когда физического места меньше, чем данных - 1

Страховые — третьи после банков и сотовых операторов потребители «тяжелого» IT-железа. На момент начала работ ситуация была такая: в офисе одной компании стояла их центральная серверная (напоминающая небольшой машзал дата-центра), и в ней, в целом, всё прекрасно работало.

Проблема была в том, что место под стойки (и в самих стойках) в серверной кончилось ещё 2 года назад. В других двух ЦОДах место было, а вот здесь — нет.

Вторая проблема в том, что основная база продакшна лежала на 149 томах, физически — как швейцарский сыр в серверах. Обусловлено это было тем, что когда требовалось её увеличить, находили первую свободную дырку в физических дисках и пихали туда. Между томами базы могли находиться базы других проектов, ПО, разные временные файлы и так далее. В общем, нужно было наводить порядок. Читать полностью »

Оптимизация производительности – это такая область, в которой каждый хотел бы стать великим мастером. Если говорить о специалистах в области работы с базами данных, то мы все приходим новичками и в начале карьеры затрачиваем массу времени, изучая основы, стараясь постичь искусство настройки серверов баз данных и приложений для улучшения производительности. Однако, и по мере проникновения в тему глубже, оптимизация производительности не становится легче.

По мере развития технологий, внедрению современных «гибких» подходов, «непрерывной интеграции» в области баз данных необходимость в более быстром отклике на запросы конечных пользователей только усиливается. В нынешних условиях распространения мобильных устройств практически всегда требуется внести изменения в системы обработки данных, чтобы ускорить обмен данными с «нативными» или WEB-приложений пользователей.

Мы наблюдаем постоянное появление и ввод новых технологий. Это здорово! А в это же время имеющиеся «старые» технологии требуют массу внимания и времени для поддержки. «Океан» данных, «море» баз данных, больше распределенных систем. Остается меньше времени на настройку и оптимизацию. Сокращение окон для модификации, поддержки и внесения изменений осложняет задачу увеличить непрерывность работы систем на имеющемся оборудовании.

В области настройки оптимизации баз данных, часто встречаются ситуации, когда трудно выбрать «правильное» решение. В таких случаях приходится полагаться на различные инструменты, которые помогают оценить ситуацию и найти пути ее улучшения. Освоив такие инструменты, часто становится проще найти лучшее решение, если в дальнейшем возникает подобная ситуация.
В подтверждение этой мысли приведу перевод любопытной статьи из блога bulldba.com/db-optimizer


В новых релизах DB Optimizer компании Embarcadero, начиная с версии 3.0, имеется отличная новая возможность: наложить на диаграмму VST explain plan запроса!

[Примечание переводчика:
Диаграмма визуальной оптимизации Visual SQL Tuning (VST) превращает текстовый SQL-код в графическую SQL-диаграмму, показывает индексы и ограничения в таблицах и представлениях с использованием статистических сведений, а также операции соединения, используемые в инструкции SQL, такие как прямые и подразумеваемые декартовы произведения и отношения «многие ко многим». ]

Возьмем для примера следующий запрос:

SELECT COUNT (*) 
FROM   a,  b,  c
WHERE
       b.val2 = 100 AND
       a.val1 = b.id AND
       b.val1 = c.id; 

По колонкам b.id и c.id созданы индексы. В окне DB Optimizer этот запрос выглядит так:

Использование слоя плана выполнения SQL запроса на VST диаграммах

Красные линии связей такого вида в соответствии с определениями говорят, что отношения могут быть типа «многие ко многим».
Вопрос: «какой план выполнения этого запроса является оптимальным?».

Один из возможных оптимальных планов выполнения этого «дерева запроса» может быть таким:

  1. Начать с наиболее селективного фильтра
  2. Выполнить JOIN с подчиненными таблицами, если возможно
  3. Если нет – то выполнить JOIN с таблицей верхнего уровня

Читать полностью »

Написание статьи стало последствием работы в довольно интересном проекте, результатом которого должен быть интернет-магазин, с возможностью привязки номенклатуры к каталогу деталей «TecDoc».
Продукт «TecDoc» — это своего рода база данных, включающая в себя не только связи производителей запчастей с конкретными номерами деталей каталога, но и содержит изображения товаров, а так же рекомендуемую цену и самое главное — возможность поиска аналогов.

Читать полностью »

В начале этого года я начал заниматься разработкой системы workflow для одной компании, причем по условиям нужно было работать с фреймворком Turbogears — питоновской системой для создания клиент-серверных приложений, работающих через браузер. Чтобы было интереснее разбираться с новой для себя штукой, я одновременно начал писать для себя систему по классификации музыкальных альбомов. Дело в том, что существующие подобные базы, которые есть в интернете, меня не устраивали: Last.fm не позволяет оценивать альбомы, навигация везде неудобная, и главное — нет привязки к своей коллекции. Оффлайновые программы вроде iTunes меня тоже не устраивают, опять же из-за другой изначальной нацеленности: они заточены больше под прослушивание, чем классификацию и сортировку по нужным критериям, кроме того, в функционал необходимо было добавить и альбомы, которые находятся не на компьютере, а в виде физических дисков.

Зачем я всё это здесь пишу. Интересно посмотреть, насколько это дело сейчас актуально, кому-нибудь нужно. А может быть какие-то компании заинтересованы в подобных разработках — тогда буду рад предложениям о сотрудничестве (dimouse _at_ old-games.ru).

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

Читать полностью »

Картинка для привлечения внимания демонстрирующая пример предстоящей «вложенности» камеры с парашютом в ранец.
БД. Справочники. Глобалы. Вложенные структуры. Живые примеры
Часть 1
Часть 2
Часть 3

В прошлый раз мы остановились на том, что у нас есть метод create(), который на основании глобала правил ^RuleDictionary создаёт элементы справочника. Нами был разобран пример создания элементов простейшего, одноуровневого справочника. Сегодня, рассмотрим каким образом, с помощью наших глобалов и методов, можно создавать вложенные структуры.

В коде программы, были использованы «прозрачные» переменные t и map, которые явно не передаются в методы, но доступны внутри них. Мне подсказали, что это не самый лучший способ демонстрации работы, особенно учитывая то, что для большинства, синтаксис Caché Object Script — нов. Поэтому, перед тем как приступить к вложенным структурам, внесём некоторые изменения в программу.


Читать полностью »

Начало см. часть 1, часть 2.

Вторичные индексы

В реляционных базах данных вторичные индексы задаются как правило при определении таблиц, или после с помощью ALTER TABLE. Если индекс определён, то он автоматически создаётся, а потом поддерживается и пересчитывается базой данных при изменении данных.

В MUMPS индексы обслуживаются явно программистом, например, в функции обновления таблицы.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js