SQL *

При разработке и использовании распределенных систем перед нами возникает задача контроля целостности и идентичности данных между системами — задача реконсиляции.

Требования, которые выставляет заказчик — минимальное время данной операции, поскольку чем раньше расхождение будет найдено, тем легче будет устранить его последствия. Задача заметно усложняется тем, что системы находятся в постоянном движении (~ 100 000 транзакций в час) и добиться 0% расхождений не получится.

Всем привет! Решил написать эту статью по одной простой причине — не нашел подробной инструкции по настройке удаленного связанного сервера между серверами teradata и ms sql server.

В Сбербанке данные хранятся на разных серверах: oracle, teradata, mssql. Часто (бывает, по несколько раз день) мне и моим коллегам приходится выполнять действия, которые назвать «эффективными» очень трудно: пишешь запрос, экспортируешь данные в файл, импортируешь его на сервер mssql, работаешь. Временные затраты на один запрос — более 3 часов (около 90 млн строк).


«Эффективная» работа

Привет, Хабр! Представляю вашему вниманию перевод статьи «Architecture of a high performance GraphQL to SQL engine».

Это перевод статьи про то, как устроен изнутри и какие оптимизации и архитектурные решения несет в себе Hasura — высокопроизводительный легковесный GraphQL сервер, выступающий прослойкой между вашим веб-приложением и базой данных PostgreSQL.

Он позволяет генерировать GraphQL схему на основе существующей базы данных или создать новую. Поддерживает GraphQL Subscriptions из коробки на основе Postgres-триггеров, динамический контроль прав доступа, автоматическую генерацию join’ов, решает проблему N+1 запросов (batching) и многое другое.

Статья о том, как решали задачу оптимизации процесса удаления файлов из шардированной системы. Речь пойдет о проекте для совместного доступа и работы с файлами. Система была стартапом лет 8 назад, потом он успешно выстрелил и был несколько раз продан. В проекте 4 разработчика, которые с проектом с самого начала, что очень ценно. Документацию, традиционно, либо не успели написать, либо она не очень актуальна.

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

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

В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.

Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".

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

Свершилось! Можно открывать шампанское и закатывать вечеринку — спустя более, чем 7 лет с момента выпуска предыдущего релиза, для скачивания наконец доступна свежайшая Oracle Database 18c XE. Пока только для Linux x64, но версии для других платформ, также как и Docker и Vagrant образы обещают появиться совсем скоро.

• Официальный анонс
• Ссылка на скачивание
• Инструкция по установке и развертыванию
• Информация о лицензировании

Для тех, кто не в курсе, Oracle Database XE или Express Edition — это бесплатная редакция одной из самых мощных реляционных СУБД. Традиционно этот тип редакции обладал минимальным доступным функционалом, определенными ограничениями на используемые ресурсы, и малым размером дистрибутива. Тем не менее, даже эта версия СУБД всегда пользовалась большой популярностью среди тех, кто только познаёт возможности этой СУБД, небольших компаний, которых на данный момент устраивают все ограничения и они хотят оценить технологию и среди простых энтузиастов как мы с вами.

Новая же, 18-ая версия XE открывает просто небывалый простор для использования данной СУБД, так как в этот раз компания Oracle сменила тактику, и вместо предоставления минимального функционала, включила в эту редакцию практически все самые популярные опции самой дорогой и функциональной редакции Enterprise Edition. Но по-прежнему с ограничениями по используемым ресурсам.

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

Можно конечно взять сторонние утилиты, например какой-нибудь опенсорсный ILSpy, сохранить сборку на диск и потом декомпилировать.


Но хочется просто подключиться к БД и посмотреть все сборки и что там внутри.

И к тому же, есть очень много качественных Opensource компонент на все случаи программистской жизни, да и писать на C# удобно и легко :)

Итак.

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

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

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

В целом же решение является законченным и комплексным. Может быть внедрено «как есть» и прекрасно справляться со своей задачей.

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

Наш формат:

1. Выбираем книгу.
2. Определяем часть, которую необходимо прочитать за неделю. Выбираем небольшой объем.
3. В пятницу обсуждаем прочитанное.
4. Читаем в нерабочее время, обсуждаем в рабочее.
5. После окончания книги совместно выбираем следующую.

Что дает:

1. Мотивация на чтение и дочитывание.
2. Развитие скиллов (в том числе на будущее).
3. Выравнивание майндсета и терминологии в команде.
4. Рост доверия.
5. Лишний повод пообщаться.

Одна из недавних книг, которую мы читали — Designing Data-Intensive Applications. Да-да, та самая книга с кабанчиком. И эта книга настолько всем понравилась, что я решил сделать здесь обзор, чтобы большее количество людей ее прочитали.


Карта в исходном качестве

Цель моего поста — рассказать о C++ API распределенной базы данных Apache Ignite, который называется Ignite C++, а также о его особенностях.

О самом Apache Ignite на хабре писали уже не раз, так что наверняка некоторые из вас уже примерно представляют, что это такое и зачем нужно.

Кратко об Apache Ignite для тех, кто пока с ним не знаком

Не буду вдаваться в подробности о том, как появился Apache Ignite и чем отличается от классических баз данных. Все эти вопросы уже поднимались тут, тут или тут.

Итак, Apache Ignite — это по сути быстрая распределённая база данных, оптимизированная для работы с оперативной памятью. Сам Ignite вырос из дата грида (In-memory Data Grid) и до недавнего времени позиционировался как очень быстрый, находящийся полностью в оперативной памяти распределённый кэш на основе распределенной хэш-таблицы. Вот почему, кроме хранения данных, в нем есть множество удобных фич для их быстрой распределенной обработки: Map-Reduce, атомарные операции с данными, полноценные ACID транзакции, SQL запросы по данным, так называемые Continues Queries, дающие возможность следить за изменением определённых данных и другие.

Однако недавно в платформе появилась поддержка постоянного хранилища данных на диске. После чего Apache Ignite получил все преимущества полноценной объектно ориентированной базы данных, сохранив при этом удобство, богатство инструментария, гибкость и быстроту дата грида.

В прошлой статье я предположил, что читатель знает, как устроен язык запросов SQL в подробностях, а также механизм работы протокола HTTP. Но это, как правило, не так. И я сразу вспомнил историю, описанную в одной из моих любимых книг «Недоверчивые умы» Роба Бразертона. В ней описан следующий эксперимент. Психолог Ребекка Лоусон спросила у группы испытуемых, катались ли они в своей жизни хоть раз на велосипеде? Большинство ответило утвердительно. Далее она спросила, знают ли они, как устроен велосипед? Утвердительных ответов было уже поменьше, но всё равно подавляющее большинство. А затем она предложила следующее изображение и попросила дополнить его так, чтобы на этом велосипеде можно было ездить.


А дальше произошло самое интересное – более половины людей не смогли этого сделать. Эта обманчиво простая задача показывает, что большинство людей просто не представляет как устроен велосипед. Но самое интересное, что они не понимают, что они этого не знают, а начинают понимать это только в момент, когда им предстоит продемонстрировать эти знания.

C HTTP и SQL происходит примерно то же самое. SQL-запросы писали 90% ИТ-специалистов, хотя бы на лабораторных в своих учебных заведениях, с HTTP люди работают каждый день как пользователи, а те же ИТ-специалисты время от времени настраивают веб-серверы, которые собственно с HTTP и работают. Но когда приходится ответить на конкретный вопрос, регулярно наступает ступор.

В некотором царстве, в некотором государстве... понадобилось мне добавить триггер в модель на pgModeler. Что сделать достаточно легко. А вот добавить триггерную функцию… Тоже легко, но пришлось немного поразбираться с параметрами, предлагаемыми для заполнения/выбора в интерфейсе.

pgModeler — это весьма неплохой инструмент для проектирования баз данных, который умеет генерировать sql-скрипты для PostgreSQL. Подробно об этом инструменте и его возможностях можно почитать на официальном сайте.

Все началось с очередного скрина в группу whatsap со следующим содержанием (оригинал не на русском языке, но это не важно):

Сумма возрастов Саши, Пети и Вити 67 лет. Когда Витя был в возрасте Саши оставалось еще 3 года до рождения Пети. Какова сумма возрастов Саши и Пети?

Ясно, что задача для школьников, но после долгих часов решения задач на SQL-EX (кстати, спасибо им больше за качественные и интересные задачи) первое что приходит в голову, это:

SELECT DISTINCT r2 + r3
           FROM (SELECT rownum r1 FROM tab) r1
 CROSS JOIN (SELECT rownum r2 FROM tab) r2
 CROSS JOIN (SELECT rownum r3 FROM tab) r3
 WHERE r1 + r2 + r3 = 67 AND r1 - r2 = r3 + 3

Где tab это любая табличка с количеством строк около 100. Решение: 32, на что в группе коллега отреагировал: «А по отдельности им по сколько?». Убираем DISTINCT и меняем "+" на ","… получается 31 пара вариантов… не совсем точный ответ. Почему то захотелось ответить точно, и имея хоть какие-то доказательства на руках.

Итак. Берем всех имеющихся клиентов в подручной базе с именами из задачи и их дни рождения:

Однажды в студёную зимнюю... день понадобился мне бесплатный инструмент для проектирования баз данных. Такой, который бы ещё и скрипты умел генерировать. Очень нравится Visual Paradigm, но стоит он, конечно, как самолёт. Поэтому, вооружившись гуглом и советами знакомых разработчиков, отправился я на поиски.

В итоге набрёл на весьма неплохой инструмент pgModeler. Единственное, не очень понравилось, что sql-скрипты он умеет генерировать только для PostgreSQL. Но т.к. на тот момент (да и сейчас, а то и потом) использовалась эта база данных, то этого инструмента было вполне достаточно.

Приветствую всех любителей SQL!

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

Представленные ответы подходят для PostgreSQL (большинство задач подойдут и для других СУБД, но результаты и решения могут быть иными. Даже интересно, где возникнут отличия)

Постарайтесь ответить самостоятельно, перед открытием спойлера.

Поехали!

Вступление

Сама библиотека довольно таки зрелая, — первый релиз на гитхабе датируется аж 2004-ым годом. Я был удивлён когда Хабр в поисковике не выдал мне ни одной ссылки на статьи, в которых бы упоминалось об этой замечательной библиотеке.

Произносится как: сОцы, с ударением на первый слог.

SOCI поддерживает ORM, через специализацию soci::type_conversion.

Поддержка баз данных (БД) (бэкенды):

• DB2
• Firebird
• MySQL
• ODBC
• Oracle
• PostgreSQL
• SQLite

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

Это будет немного напыщенная речь, но меня действительно раздражает софт, в котором люди пытаются изобрести очередной собственный язык запросов. У нас уже есть триллион различных ORM, еще триллион баз данных с собственным языком запросов каждая, и еще триллион SaaS-продуктов, для доступа к которым нужно освоить какой-нибудь очередной DSL, которые они придумали.

Верните мне мой SQL обратно. Это язык понятный каждому, существует аж с 70-х и за это время успел стать стандартом. Он прост в чтении и может использоваться кем угодно, от бизнеса до инженеров.

Однако вместо этого мне приходится изучать целый ворох разных "garbage query language", потому что люди по-прежнему пытаются изобрести колесо заново.

PostgreSQL 10 был выпущен еще в начале октября 2017го, почти год назад.

Одна из наиболее интересных новых “фич” — это безусловно декларативное партиционирование. Но что, если вы не спешите апгрейдится до 10ки? Вот Amazon, к примеру, не торопится, и ввел поддержку PostgreSQL 10 только в последних числах февраля 2018-го.

Тогда на помощь приходит старое-доброе партиционирование через наследование. Я — software architect финансового отдела в компании занимающейся такси, так что все примеры будут так или иначе связаны с поездками (проблемы связанные с деньгами оставим на другой раз).

Поскольку мы начали переписывать нашу финансовую систему в 2015ом, когда я только присоединился к компании, ни о каком декларативном партиционировании речи не шло. Так что и по сей день успешно используется методика описанная ниже.

Изначальной причиной написания статьи стало то, что большинство примеров partitioning’а в PostgreSQL с которыми я сталкивался были очень базовыми. Вот таблица, вот одна колонка, на которую мы смотрим, и быть может даже заранее знаем, какие значения в ней лежат. Казалось бы, все просто. Но реальная жизнь вносит свои коррективы.

Читая многочисленные статьи на хабре об успешной миграции с Oracle на PostgreSQL у неискушенного читателя может создаться впечатление что PostgreSQL ничем не хуже, а даже лучше Oracle. И выбор очевиден. А Сотни тысяч компаний, которые в итоге платят миллиарды долларов компании Oracle, просто тратят деньги на ветер. Но постараюсь вас разуверить, где-где, а в больших компаниях умеют считать деньги. И их решения отнюдь не ошибочны.

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