SQL *

Приветствую, уважаемые хаброжители!

Так как занимаюсь переводом кода с MS SQL в Postgre SQL с начала 2019 года, то решил продолжить сравнение этих двух СУБД.

В прошлой публикации мы рассматривали отличия в быстродействии MS SQL и PostgreSQL для 1C.

Сегодня давайте сравним основные конструкции синтаксиса MS SQL и PostgreSQL для правильного чтения кода, а также для того, чтобы быстро изменить код из MS SQL для PostgreSQL или наоборот.

Начнем рассмотрение с сопоставления типов.

Недавно мне пришлось объяснять это нашим братьям меньшим на работе, и я решил написать текст, который может пригодиться. В конце вы найдете ссылку на полезный скрипт для MSSQL, а также Postgres и MySQL.

В идеальном мире, если в таблице миллион записей, а разных значений например всего 100K, то на каждое значение приходится по 10 записей. Но что делать, если в список ваших значений затесалось особое значение, например, NULL, пробел или 'n/a'? Для SQL optimizier это головная боль. Для вас тоже.

Картинка иллюстрирует людей со значением 'n/a' в поле SSN

Введение

Часто перед дата-инженерами ставится задача по миграции данных из какого-либо источника или системы в целевое хранилище. Для этого существует множество различных инструментов. Если говорить про платформу Big Data, то чаще всего у разработчиков на слуху Apache NiFi или ETL-задачи, написанные на Spark, ввиду универсальности этих инструментов. Но давайте предположим, что нам необходимо провести миграцию данных из РСУБД в Hadoop. Для подобного рода задач существует очень недооцененный пакетный ETL-инструмент – Apache Sqoop. Его особенность в следующем:

• Облегчает работу разработчиков, предоставляя интерфейс командной строки. Для работы с этим инструментом достаточно заполнить основную информацию: источник, место назначения и детали аутентификации базы данных;
• Автоматизирует большую часть процесса;
• Использует инфраструктуру MapReduce для импорта и экспорта данных, что обеспечивает параллельный механизм и отказоустойчивость;
• Для работы с этим инструментом требуется иметь базовые знания компьютерной технологии и терминологии, опыт работы с СУБД, с интерфейсами командной строки (например bash), а также знать, что такое Hadoop и обладать знаниями по его эксплуатации;
• Относительно простая установка и настройка инструмента на кластере.

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

Искать в большом количестве фактов «уники» — всегда сложно и долго, если их достаточно много. Если интервалы фиксированы (календарные месяц/квартал/год), можно материализовывать такие агрегаты заранее. А если интервал — произвольный, как тогда эффективно найти ответ?

Реализация алгоритма k-средних на диалекте SQL без питонов и дополнительных библиотек.

В нашей компании (GFN.ru) мы очень сильно опираемся на данные. По каждой игровой сессии мы анализируем десятки параметров. Постройка и содержание системы метрик и алертов - очень затратная вещь и со временем ее поддержка становится трудоемкой и появляется риск забивания. С помощью ML мы решили эту проблему.

Я разрабатываю библиотеку для работы с Entity Attribute Value (репозиторий), сокращенно EAV (структура базы данных для хранения произвольных данных). В конце прошлой статьи я спросил у вас о чём мне ещё надо написать, вы попросили показать пример использования и сделать замеры быстродействия. Про замеры быстродействия статья была, эта будет о примере использования.

Назначение библиотеки

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

Для этих двух целей применяется EAV, но он существенно замедляется при увеличении объёма данных, и главная цель библиотеки это сделать скорость работы с данными независимой от объёма данных.

Это достигается за счёт использования материализованных представлений и таблиц, и главная задача которую решает библиотека, это синхронизации данных между таблицами EAV и конкретными таблицами, выделенными под каждую категорию (Entity - сущность). Конечно сущность может быть выделена в материализованное представление, библиотека оставляет выбор за пользователем.

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

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

Всем привет.

Я разрабатываю библиотеку для работы с Entity Attribute Value (репозиторий), сокращенно EAV (модель базы данных для хранения произвольных данных). В конце прошлой статьи я спросил у вас о чём мне ещё надо написать, вы попросили показать пример использования и сделать замеры быстродействия.

Что для нас важно при работе с данными ? Скорость записи (добавления или обновления) и скорость чтения (конкретно - фильтрации по моделям одной сущности). При чём скорость поиска в приоритете, потому что записываем мы один раз в цать дней, а читаем каждую минуту/секунду и даже не один раз, а может быть и не одну сотню раз.

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

В Новогодние каникулы я сделал замеры производительности и хочу с вами поделиться результатами

Что будем измерять ?

Чтение:

Время вычитывания всех позиций категории

Время формирования параметров фильтрации

Время фильтрации

Запись:

Время добавления новой характеристики (атрибута)

Время добавления новой товарной позиции (модели)

Время обновления товарной позиции

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

Ну а начиналось все очень мирно: мы хотели немного подтянуть сайт под обновленные требования Google.

Рецепт параллельных вычислений Fork/Join или Map/Reduce:
- разбить задачу на куски;
- посчитать куски по-отдельности;
- склеить вместе.

Неотрицательная сумма (a, b) -> max(0, a + b) неассоциативна и результат зависит от порядка склейки. Она сломает Fork/Join и результат будет некорректен. Магией моноида починить на Java, SQL и Haskell за 5 минут, но

Хотите легкого чтива под новый год? Вот крошечные истории про случаи из моей работы или случаи, свидетелем которых я стал.

Всем привет! На связи Антон Чимин. Не так давно я стал ИТ рекрутером и сегодня решил написать небольшую статью о том, что на самом деле происходит внутри кадровых агентств и стоит ли с ними работать. Называть свое кадровое агентство я не буду, чтобы это не было рекламой :) Просто пройдемся по фактам, что здесь и как.

Сегодня будет необычный пост, в котором я буду разрушать или подтверждать мифы о кадровых агентствах (КА), как это когда-то делали Адам Сэвидж и Джэми Хайнеман в одном известном шоу :) Погнали!

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

Ранее мы рассмотрели способы расчёта нарастающего (накопительного) итога в SQL. Самый распространённый вопрос - как посчитать тоже самое, но на данных с разрывами? После написания исходной статьи мне его задавали неоднократно – так что есть смысл написать об этом отдельно.

В начале месяца я прочитал доклад про индексы в базах данных для Saint P Ruby Community и буквально через несколько дней жизнь не замедлила подкинуть мне показательный пример работы индексов, планировщика баз данных и важности обновления СУБД.

Итак, дано: большая таблица projects с кучей (ненужных) индексов, в том числе обычный BTree-индекс по числовой колонке forks_count. У неё есть связь по has_one с таблицей project_dependencies с функциональным GIN-индексом по полю packages в колонке data, в котором поле находится JSON-объект с названиями NPM-пакетов в ключах и их версиями в значениях (куда ж сейчас без джаваскрипта?):

Задача: вытащить примеры проектов, имеющих в зависимостях определённый пакет, показать пользователю наиболее популярные. Показателем популярности и ценности как раз будет количество форков — как правило это какие-то уже раскрученные публичные стартер-проекты.

Недавно поменял работу, на новом месте столкнулся с нечитабельной структурой базы данных MSSQL, в которой таблицы и поля не имеют понятных названий (префикс + число). Например: таблицы называются Data1078, Data2022, а колонки называются f210, f1521. Подобные структуры часто встречаются в коробочных продуктах.

Так как в базе данных реализована логика в виде хранимых процедур, а объектов уже тысячи, переделывать или предлагать новую структуру достаточно сложно. В базе данных в отдельных таблицах уже есть описание всех таблиц и колонок, программисты для получения описания каждый раз вызывают вспомогательные хранимые процедуры, одна процедура для получения описания таблицы show_tab и одна процедура для получения описания поля show_fld.

Всем привет! Меня зовут Николай Когель, я главный инженер по разработке Управления технологий MIS Департамента ИТ-блока «Финансы» в Сбере.

Сейчас в Сбере существует несколько крупных систем, в которых происходит построение управленческой отчётности и расчёт финансового результата. Как правило, это предполагает обработку огромных массивов исторических данных нетривиальной структуры из различных систем, загружаемых в аналитическое хранилище данных. По этой причине хранилище данных строится на основе MPP-систем, а с недавнего времени в Сбере наряду с Teradata появилась альтернатива в виде GreenPlum.

Прочитав статью и восприняв понимание продукта Oracle BI Publisher критически, а именно, на момент существовавшей тогда версии 11.1.1.7.150120, хочется заметить, что все, указанное в цитируемой статье можно было сделать на BI Publisher и доверить любому непрограммирующему пользователю. Плюс к этому, продукт имел trial и stand-alone версию. Поддерживался API на Java, уже был доделан вызов продукта как web-сервиса.

Чуть более интересный вопрос, который был получен от читателей моего блога: как в 12-й версии работать с переменными типа REF CURSOR для массовой миграции с самодельной отчетной системы на продукт Oracle BI EE 12с.

Рассмотрим код, который вернет REF CURSOR в зависимости от параметра.

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

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

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