SQL *

На прошлом внутреннем митапе Pyrus мы говорили о современных распределенных хранилищах, а Максим Нальский, CEO и основатель Pyrus, поделился первым впечатлением от FoundationDB. В этой статье рассказываем о технических нюансах, с которыми сталкиваешься при выборе технологии для масштабирования хранения структурированных данных.

Когда сервис недоступен пользователям какое-то время, это дико неприятно, но всё же не смертельно. А вот потерять данные клиента — абсолютно недопустимо. Поэтому любую технологию для хранения данных мы скрупулезно оцениваем по двум-трем десяткам параметров.

Привет друзья. Ни для кого не секрет, что работая на крупных проектах со сложной логикой, Active Record становится не помощником, а обузой. Представьте, что вам необходимо сделать очень сложный запрос для PostgreSQL нативным образом (на чистом SQL), где должно присутствовать некоторое количество переменных. Но в Rails есть одна неприятная мелочь, функционал выполнения нативных запросов не позволяет использовать именованные биндинги. Но решение есть :) Опробовано и успешно внедрено на проекте с Rails API 5.2 + Ruby 2.6.0 + Postgres 11.

И снова привет!

Коллеги, в последний день января мы запускаем курс «MS SQL Server разработчик», в связи с чем у нас прошёл тематический открытый урок. На нём мы поговорили о том, как MS SQL Server выполняет запрос SELECT, обсудили, в каком порядке и что анализируется, а также немного погрузились в чтение плана запроса.

Преподаватель — Кристина Кучерова, архитектор модели данных в Сбербанке России.

Запуск новой версии в боевую эксплуатацию — всегда нервное мероприятие. Особенно если процесс включает в себя множество ручных операций. Человеческий фактор — страшная штука. “Хорошо бы этот процесс автоматизировать” — эта идея стара как весь ИТ-мир. И термин для этого есть — Continuous Deployment. Да вот беда, нет единственно верного способа настроить этот continuous deployment. Очень сильно сей процесс завязан на технологический стек проекта и на его окружение.

В этой статье я хочу поделиться практическим опытом настройки автоматического обновления системы без прерывания ее работы для конкретного технологического окружения, а именно: веб приложение на ASP.NET MVC + Azure SQL + Entity Framework в режиме Code First, развернуто приложение в Azure в виде App Service, а сборка и развертывание выполняются через Azure DevOps (бывший Visual Studio Team Services).

Введение

Liquibase представляет из себя систему управления версиями базы данных, в основном это касается структуры и в меньшей степени содержимого базы. При этом описание базы с одной стороны достаточно абстрактно и позволяет использовать на нижнем уровне различные СУБД, и с другой стороны всегда можно перейти на SQL-диалект конкретной СУБД, что достаточно гибко. Liquibase является устоявшимся проектом с открытым исходным кодом и активно используется за пределами своей родной Java среды и не требует глубоких знаний Java для работы. В качестве описания структуры базы и изменений базы исторически использовался XML формат, однако сейчас параллельно поддерживается YAML и JSON.

В данной статье мы немного обобщим опыт предыдущих поколений и сосредоточимся на работе с Liquibase с использованием Maven. В качестве тестовой операционной системы будем использовать Ubuntu.

Чуть больше года при моём участии состоялся следующий "диалог":

.Net App: Эй, Entity Framework, будь любезен дай мне много данных!
Entity Framework: Прости, не понял тебя. Что ты имеешь ввиду?
.Net App: Да просто мне прилетела коллекция из 100k транзакций. И теперь надо по-быстрому проверить корректность цен на бумаги, которые там указаны.
Entity Framework: Ааа, ну давай попробуем…
.Net App: Вот код:

var query = from p in context.Prices
            join t in transactions on 
              new { p.Ticker, p.TradedOn, p.PriceSourceId } equals
              new { t.Ticker, t.TradedOn, t.PriceSourceId }
            select p;
query.ToList();

Entity Framework:

Классика! Думаю многим знакома эта ситуация: когда очень хочется “красиво” и быстро сделать поиск в базе, используя JOIN локальной коллекции и DbSet. Обычно этот опыт разочаровывает.

В данной статье (которая является вольным переводом другой моей статьи) я проведу ряд экспериментов и попробую разные способы, чтобы обойти это ограничение. Будет код (несложный), размышления и что-то вроде хэппи-энда.

TL;DR: GitHub://PastorGL/AQLSelectEx.

Однажды, ещё не в студёную, но уже зимнюю пору, а конкретно пару месяцев назад, для проекта, над которым я работаю (нечто Geospatial на основе Big Data), потребовалось быстрое NoSQL / Key-Value хранилище.

Терабайты исходников мы вполне успешно прожёвываем при помощи Apache Spark, но схлопнутый до смешного объёма (всего лишь миллионы записей) конечный результат расчётов надо где-то хранить. И очень желательно хранить таким образом, чтобы его можно было по ассоциированным с каждой строкой результата (это одна цифра) метаданным (а вот их довольно много) быстро найти и отдать наружу.

Несколько лет назад на форуме SQL.ru решили провести сравнение реализаций трассировщиков лучей на разных языках программирования. К сожалению, моя заявка не может участвовать т.к. она не выводит надпись «PIXAR», поэтому публикую ее здесь.

Для чистоты эксперимента я использовал SQLite без расширений. Оказалось, что там нет даже функции SQRT.

WITH RECURSIVE numbers AS (SELECT 0 AS n UNION ALL SELECT n+1 FROM numbers WHERE n<89),
pixels AS (SELECT rows.n as row, cols.n as col FROM numbers as rows CROSS JOIN
numbers as cols WHERE rows.n > 4 AND rows.n < 38 AND cols.n > 9 AND cols.n < 89),
rawRays AS (SELECT row, col, -0.9049 + col * 0.0065 + row * 0.0057 as x,
-0.1487 + row * -0.0171 as y, 0.6713 + col * 0.0045 + row * -0.0081 as z FROM pixels),
norms AS (SELECT row, col, x, y, z, (1 + x * x + y * y + z * z) / 2 as n FROM rawRays),
rays AS (SELECT row, col, x / n AS x, y / n AS y, z / n AS z FROM norms),
iters AS (SELECT row, col, 0 as it, 0 as v FROM rays UNION ALL
SELECT rays.row, rays.col, it + 1 AS it, v + MAX(ABS(0.7+v*x) - 0.3,
ABS(0.7+v*y) - 0.3, ABS(-1.1+v*z) - 0.3, -((0.7+v*x) * (0.7+v*x) +
(0.7+v*y) * (0.7+v*y) + (-1.1+v*z) * (-1.1+v*z)) * 1.78 + 0.28) AS v
FROM iters JOIN rays ON rays.row = iters.row AND rays.col = iters.col WHERE it < 15),
lastIters AS (SELECT it0.row, it0.col, it0.v AS v0, it1.v AS v1, it2.v AS v2
FROM iters as it0 JOIN iters AS it1 ON it0.col = it1.col AND it0.row = it1.row
JOIN iters AS it2 ON it0.col = it2.col AND it0.row = it2.row
WHERE it0.it = 15 AND it1.it = 14 AND it2.it = 13),
res AS (SELECT col, (v0 - v1) / (v1 - v2) as v FROM lastIters)
SELECT group_concat(
substr('$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/|()1{}[]?-_+~<>i!lI;:,"^. ',
round(1 + max(0, min(66, v * 67))), 1) || CASE WHEN col=88 THEN X'0A' ELSE '' END, '')
FROM res;

Здесь можно покрутить кубик

Под катом построчный разбор запроса. Как обычно, достаточно знания основ SQL и школьной математики.

О чем будет статья, и так понятно из названия.

Кроме того, автор объяснит, зачем с его точки зрения это нужно, а также расскажет, что SUBJ не просто модная технология, но и «дело вдвойне нужное — как приятное, так и полезное».

Введение

Всем привет! Это моя первая статья и пишу я ее от лица младшего инженера-разработчика на языке C#. Так что здесь не будет каких-то подробных сведений о SQL, лишь практические сведения и размышления по решению довольно не очевидной задачи, с которой мне пришлось столкнуться, для таких же новичков, как и я сам.

Сначала я опишу формулировку своей задачи в качестве примера, в котором возникает реальная необходимость переноса большой таблицы.

Итак, представим, что у вас есть web-сервис и SQL (MS-SQL) база данных с таблицей html-писем, которые ваш сервис рассылает пользователям. Письма хранятся за некоторое количество лет и удалить их нельзя, так как они нужны для сбора статистики и аналитики. Однако, с каждым годом количество писем растет, база разрастается, а места на SQL-сервере все меньше (в нашем случае еще одним фактором было восстановление базы на тестовую площадку, т.к. его время пропорционально росло) и с этим нужно что-то делать. Благо, в нашем случае есть свободный сервер с кучей свободного места (в реальности его может не быть и конечно это временное решение, но это выходит за рамки статьи). Так возникла задача по переносу большой таблицы (и говоря «большой», я имею в виду реально большую таблицу, все что я видел, пока искал похожие решения, было в районе 60-100Гб, в нашем случае таблица весила более 300 Гб).

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

В «Ростелекоме», как и в любой крупной компании, имеется корпоративное хранилище данных (ЦХД). Наше ЦХД постоянно разрастается и расширяется, мы строим на нем полезные витрины, отчеты и кубы данных. В какой-то момент мы столкнулись с тем, что некачественные данные мешают нам при построении витрин, получаемые агрегаты не сходятся с агрегатами систем источников и вызывают непонимание бизнеса. Например, данные с Null значениями в внешних ключах (foreign key) не соединяются с данными других таблиц.
Краткая схема ЦХД:



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

Автор статьи – Виктор Варламов(varlamovVp18), OCP.
Оригинал статьи опубликован 07.07.2017.
Отдельное спасибо автору перевода — brutaltag.

В нашей системе подготовки отчетности обычно выполняются сотни длительных запросов, которые вызываются различными событиями. Параметрами запросов служат список клиентов и временной интервал (дневной, недельный, месячный). Из-за неравномерных данных в таблицах один запрос может выдать как одну строку, так и миллион строк, в зависимости от параметров отчета (у разных клиентов — различное количество строк в таблицах фактов). Каждый отчет выполнен в виде пакета с основной функцией, которая принимает входные параметры, проводит дополнительные преобразования, затем открывает статический курсор со связанными переменными и в конце возвращает этот открытый курсор. Параметр БД CURSOR_SHARING выставлен в FORCE.
В такой ситуации приходится сталкиваться с плохой производительностью, как в случае повторного использования плана запроса оптимизатором, так и при полном разборе запроса с параметрами в виде литералов. Связанные переменные могут вызвать неоптимальный план запроса.

4 декабря вышла финальная версия EF Core 2.2. Она выпущена параллельно с ASP.NET Core 2.2 и .NET Core 2.2 и является самым свежим релизом нашей опенсорсной и кроссплатформенной технологии для управления отображениями между объектами языка и базой данных.

EF Core 2.2 RTM содержит больше сотни исправлений и несколько новых фич, о которых мы и поговорим в этой статье.

Ссылки ведут на соответствующие статьи на Хабре. Это последняя, третья статья серии. В следующий раз мы поговорим о новом релизе — и это будет уже в новом году.

И снова добрый вечер!

Запускаем второй поток нашего нового курса «Реляционные СУБД», который мы чуть дотюнили по итогам первого прогона: дополнительные занятия по кластерам MySQL и Postgres, оказался востребованным docker и ещё разные «доработки напильником». Так что ждите открытые уроки (в которые вынесли часть старых тем) и интересные материалы. Сегодня мы покопаемся в техниках Oracle.

Поехали.

Bitmap-индексы Oracle сильно отличаются от стандартных индексов B-дерева. В bitmap-структурах создается двухмерный массив со столбцом для каждой строки в индексируемой таблице. Каждый столбец представляет отдельное значение в bitmap-индексе. Этот двухмерный массив показывает каждое значение индекса, умноженное на количество строк в этой таблице.

Oracle распаковывает bitmap (со скоростью извлечения строки) в буфер данных ОЗУ для быстрого сканирования на предмет совпадения значений. Эти совпадающие значения передаются Oracle в виде списка Row-ID, и значения Row-ID могут напрямую обращаться к необходимой информации.

Хотим поделиться историей, которая произошла на одном из наших проектов под Новый год. Суть проекта в том, что он автоматизирует работу врачей в медицинских учреждениях. Во время визита пациента доктор записывает информацию на диктофон, затем аудиозапись транскрибируется. После процесса транскрибирования – т.е. превращения аудиозаписи в текст – формируется медицинский документ по соответствующим стандартам и высылается обратно в клинику, откуда пришла аудиозапись, где ее получает отправивший врач, проверяет и утверждает. После прохождения обязательных проверок документ отсылается конечным пациентам.

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

• Поддержка Cassandra
• Создание SQL-файлов из объектов схемы
• Новые инспекции
• Много новых штук в автодополнении
• Работа с источником данных через одно подключение
• Новый поиск
• Высококонтрастная цветовая схема

Спасибо тем, кто пробует EAP-версии и сообщает в наш трекер о проблемах: это помогает не дотащить их до релиза :) Активные пользователи уже получили бесплатные подписки на год.

Типичный проект системной интеграции для нас выглядит так: у заказчика вагон систем для учета клиентов, задача — собрать клиентские карточки в единую базу. И не только собрать, а еще очистить от дублей и мусора. Чтобы на выходе получились чистые, структурированные, полные карточки клиентов.

Для начинающих поясню, что миграция идет по такой схеме: источники → преобразование данных (отвечает ETL или шина) → приемник.

На одном проекте мы потеряли три месяца просто потому, что сторонняя команда интеграторов не изучала данные в системах-источниках. Самое обидное, что этого можно было избежать.

Как запустить SQL profiler trace, когда проблему надо ловить с 3:00 до 3:30 утра? Делать это можно с помощью трейса на стороне сервера, но это крайне неудобно. Именно не сложно, а неудобно, и всегда лень. Наконец я решился автоматизировать это раз и навсегда. Вот так:

Хабр, это доклад инженера-программиста Алексея Старкова на конференции Moscow Python Conf++ 2018 в Москве. Видео в конце поста.

Всем привет! Меня зовут Алексей Старков — это я, в свои лучшие годы, работаю на заводе.
Теперь я работаю в Qrator Labs. В основном, всю свою жизнь, я занимался C и C++ — люблю Александреску, «Банду Четырех», принципы SOLID — вот это всё. Что и делает меня архитектурным космонавтом. Последние пару лет пишу на Python, потому что мне это нравится.

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

Я тоже имею тенденции к архитектурной космонавтике, но в этом докладе я расскажу немного о том, как это меня укусило и не позволило построить систему с необходимой производительностью. Главное — как я это поборол.

Краткое содержание моего доклада: было / стало.

Однажды, в далекой-далекой галактике, была фирма, давно выросшая из стартапа, но которая по прежнему оставалась довольно компактной и эффективной. Фирма хостила (на своем железе) сотни Windows-серверов, и это надо было как то мониторить. Еще до того, как я в нее пришел, в качестве решения была выбрана система NetIQ.

Настраивать NetIQ поручили мне, и тот, кто это делал до меня, не сказал о ней ни единого слова. Печатного. Вскоре я понял, почему. Стив Джобс наверное вертится в могиле, глядя на подобный интерфейс:


В одной строчке логика «птички» положительная (Raise event). В другой отрицательная (Do not raise event). Как работает «Only raise events when» с разным набором галочек я вообще понял только экспериментально (и уже забыл).