SQL *

В статье речь пойдёт о протоколировании изменений в 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, просто тратят деньги на ветер. Но постараюсь вас разуверить, где-где, а в больших компаниях умеют считать деньги. И их решения отнюдь не ошибочны.

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

Вы когда-нибудь анализировали вакансии?

Задавались вопросом, в каких технологиях наиболее сильна потребность рынка труда на текущий момент? Месяц назад? Год назад?

Как часто открываются новые вакансии Java-разработчиков в определенном районе Вашего города и как активно они закрываются?

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


(Источник картинки)

Юля: Так, кто вчера менял мою процедуру?
Лёша: не я
Максим: не я
— Ребят, может Git заведём ?
Серёжа: давно пора!
прошло 2 недели…

Юля: ребяяят?
— Юль, а ты не коммитила?
Юля: damn нет(…

Вот так всё и началось. Ну а что, каждый символ и каждую строчку коммитить?

А может всё это будет происходить само?) На этом моменте в голову начинают приходить
DDL-триггеры, Temporal table и картина складывается. Решено, будем хранить версии внутри
SQL Server'a !)

Описание уязвимостей — это одно, а вот попробовать найти уязвимость и поработать с ней — совсем другое дело. Именно для этих целей создаются и развиваются специальные приложения, в которых намеренно оставлены уязвимости. Если набрать в поисковой системе запрос «Purposely vulnerable app», вы найдете ни один десяток ссылок.

В этом цикле мы начнем разбирать уязвимости из OWASP Top 10, и в качестве полигона я буду использовать такое намеренно уязвимое приложение. В моем случае это будет OWASP Mutillidae II. Это не то, чтобы самый лучший вариант, но в нем уязвимости структурированы именно так, как нужно для образовательных целей.

Некоторое время назад передо мной была поставлена задача написать процедуру, которая выполняет прореживание котировок рынка Форекс (точнее, данных таймфреймов).

Формулировка задачи: данные поступают на вход с интервалом в 1 секунду в таком формате:

• Название инструмента (код пары USDEUR и пр.),
• Дата и время в формате unix time,
• Open value (цена первой сделки в интервале),
• High value (максимальная цена),
• Low value (минимальная цена),
• Close value (цена последней сделки),
• Volume (громкость, или объём сделки).

Необходимо обеспечить пересчёт и синхронизацию данных в таблицах: 5 сек, 15 сек, 1 мин, 5 мин, 15 мин, и т.д.

Описанный формат хранения данных имеет название OHLC, или OHLCV (Open, High, Low, Close, Volume). Он применяется часто, по нему сразу можно построить график «Японские свечи».


Под катом я описал все варианты, какие смог придумать, как можно прореживать (укрупнять) полученные данные, для анализа, например, зимнего скачка цены биткоина, а по полученным данным вы сразу построите график «Японские свечи» (в MS Excel такой график тоже есть). На картинке выше этот график построен для таймфрейма «1 месяц», для инструмента «bitstampUSD». Белое тело свечи означает рост цены в интервале, чёрное — снижение цены, верхний и нижние фитили означают максимальную и минимальную цены, которые достигались в интервале. Фон — объём сделок. Хорошо видно, что в декабре 2017 цена вплотную приблизилась к отметке 20К.

Решение будет приведено для двух движков БД, для Oracle и MS SQL, что, в некотором роде, даст возможность сравнить их на этой конкретной задаче (обобщать сравнение на другие задачи мы не будем).

Привет! Этот пост о том, что нового в DataGrip 2018.2. C этой версии поддержка баз данных есть в CLion и AppCode. В WebStorm её можно включить, если вы параллельно используете DataGrip.



— Лог всех запросов
— Новый форматер кода
— Запуск хранимых процедур
— Миграция исходников
— План запроса в виде диаграммы
— Редактирование SQL
— Редактор данных
— Улучшения в пользовательском интерфейсе

Здравствуйте!

Я работаю PL/SQL разработчиком. Есть задача собирать некоторые данные для метрик, чтобы отслеживать загрузку систем. Есть некоторая функция, которая вызывается с параметром, состоящим из списка ID.

1,2,3,4…1001,1002,1003…

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

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

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

Я не пытаюсь убедить вас использовать свой подход. Скорее я хочу подробнее объяснить, что именно имелось в виду в первоначальном выступлении в Twitter.

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

Всем привет. В качестве введения, хочется рассказать, как я дошел до жизни такой.

До того как встретиться с Big Data и Spark, в частности, мне довелось много и часто оптимизировать SQL запросы, сначала для MSSQL, потом для Oracle, и вот теперь я столкнулся со SparkSQL.

И если для СУБД уже существует множество хороших книг, описывающих методологию и «ручки», которые можно покрутить для получения оптимального плана запроса, то для Spark такого рода книг я не встречал. На глаза попадались больше статьи и наборы практик, причем больше относящиеся к работе через RDD/Dataset API, а не чистому SQL. Для меня одной из эталонных книг на тему оптимизации SQL является книга Дж. Льюис «Oracle. Основы стоимостной оптимизации». Что-то подобное по глубине проработки я и искал. Почему предметом исследования стал именно SparkSQL, а не API, лежащий в основе? Тут интерес был вызван особенностями проекта, над которым я работаю.