Администрирование баз данных

Использование Clickhouse в качестве замены ELK, Big Query и TimescaleDB

• Перевод
• Tutorial

Clickhouse — это колоночная система управления базами данных для онлайн обработки аналитических запросов (OLAP) с открытым исходным кодом, созданная Яндексом. Ее используют Яндекс, CloudFlare, VK.com, Badoo и другие сервисы по всему миру для хранения действительно больших объемов данных (вставка тысяч строк в секунду или петабайты данных, хранящихся на диске).
В обычной, «строковой» СУБД, примерами которых служат MySQL, Postgres, MS SQL Server, данные хранятся в таком порядке:
При этом значения, относящиеся к одной строке, физически хранятся рядом. В столбцовых СУБД значения из разных столбцов хранятся отдельно, а данные одного столбца – вместе:

Как я стал докладчиком Percona Live (и несколько интригующих деталей с американской границы)

Percona Live Open Source Database Conference — одно из главных мероприятий на календаре мира СУБД. Когда-то всё начиналось с разработки одного из форков MySQL, но потом сильно переросло прародителя. И хотя очень многие материалы (и посетители) всё ещё плотно связаны с тематикой MySQL, общий информационный фон стал значительно шире: это и MongoDB, и PostgreSQL, и другие менее популярные СУБД. В этом году «Перкона» стала значительным событием и на нашем календаре: впервые мы принимали участие в этой американской конференции. Как вы наверняка уже знаете, нас очень волнует состояние технологий мониторинга в современном мире. Со сдвигом инфраструктурных парадигм в сторону максимальной гибкости, микросервисов и кластерных решений должны меняться и сопутствующие инструменты и подходы в поддержке. О том, собственно, и был мой доклад. Но для начала хочу рассказать, как вообще попадают на штатовские конференции и какие сюрпризы могут ждать сразу после посадки самолёта.

KeyDB как [потенциальная] замена Redis

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

Руководство по выживанию с MongoDB

Все хорошие стартапы либо быстро умирают, либо дорастают до необходимости масштабироваться. Мы смоделируем такой стартап, который сначала про фичи, а потом про перфоманс. Перфоманс будем улучшать с MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать, и многие проблемы имеют решения «из коробки». Однако, когда нагрузка растет, вылезают грабли, о которых вас заранее никто не предупреждал… до сегодняшнего дня!
Моделирование проводит Сергей Загурский, который отвечает за инфраструктуру бэкенда вообще, и MongoDB в частности, в Joom. Также был замечен в серверной части разработки MMORPG Skyforge. Как сам себя описывает Сергей — «профессиональный набиватель шишек собственным лбом и граблями». Под микроскопом — проект, который использует стратегию накопления для управления техническими долгом. В этой текстовой версии доклада на HighLoad++ будем двигаться в хронологическом порядке от возникновения проблемы до решения с помощью MongoDB.

SQL ключи во всех подробностях

Перевод

В Интернете полно догматических заповедей о том, как нужно выбирать и использовать ключи в реляционных базах данных. Иногда споры даже переходят в холивары: использовать естественные или искусственные ключи? Автоинкрементные целые или UUID?
Прочитав шестьдесят четыре статьи, пролистав разделы пяти книг и задав кучу вопросов в IRC и StackOverflow, я (автор оригинальной статьи Joe «begriffs» Nelson), как мне кажется, собрал куски паззла воедино и теперь смогу примирить противников. Многие споры относительно ключей возникают, на самом деле, из-за неправильного понимания чужой точки зрения.

Давайте разделим проблему на части, а в конце соберём её снова. Для начала зададим вопрос – что же такое «ключ»?

Google запустила бета-версию Cloud Spanner — СУБД поколения NewSQL

Google открыла для всех бета-версию сервиса Cloud Spanner, глобально распределённой высокомасштабируемой мультиверсионной NewSQL БД с поддержкой распределённых транзакций.
Несколько лет Google использовала этот сервис исключительно для внутренних нужд. На нём работают ключевые системы Google, в том числе AdWords и Google Play. Spanner — эволюционное развитие NoSQL-предшественника Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений, то есть оно сочетает в себе преимущества реляционных и нереляционных СУБД. Это ACID-транзакции и SQL-синтаксис традиционных СУБД без ущерба для горизонтального масштабирования и высокой доступности, присущих NoSQL.
Исходя из опыта работы системы внутри компании, Google предлагает клиентам аптайм 99,9999% (шесть девяток, то есть максимум 31,5 секунды простоя в год), клиентские библиотеки с поддержкой Java, Go, Python, Node.js и др.

Презентация DriverPack Cloud

Камрады, надеюсь у вас нет больших планов на завтрашний вечер, потому что мы в DriverPack решили позвать сисадминов в ламповый паб и поделиться с вами радостью, связанной со скорым запуском нашей новой программы! Не спешите писать о том, как скучны, полны официоза, а главное бесполезны официальные мероприятия и презентации. Мы с командой также, как и вы не выносим корпоративного этикета и пафосно нудных презентаций по 10 часов. Поэтому и предлагаем встретиться именно в пабе — посидеть за кружечкой пива, отведать мясных бургеров, а за одно, во время дружеской беседы мы расскажем вам о новом продукте и послушаем ваши предложения по его развитию, а также ответим на все ваши вопросы. Я буду рад видеть вас на нашем мероприятии, которое пройдет уже завтра, 14 октября в одном из лучших московских пабов.

Панель дополнительных инструментов для разработчика на InterSystems IRIS

Панель дополнительных инструментов для мониторинга и исследования ошибок приложений и интеграицонных решений на платформе данных InterSystems IRIS, интеграционной платформе Ensemble и СУБД Caché, или история еще одного велосипеда.
В этой статье я хочу рассказать о приложении, которым, наряду со стандартными средствами администрирования, пользуюсь ежедневно при мониторинге приложений и интеграционных решений на платформе InterSystems IRIS и нахождении ошибок при их возникновении.
Решение включает просмотр и редактирование глобальных массивов, выполнение запросов (включая JDBC / ODBC), отправка результатов поиска по электронной почте в виде архивированных XLS-файлов. Просмотр объектов классов с возможностью редактирования. Несколько простых графиков по протоколам системы.
Это CSP-приложение, на основе jQuery-UI, chart.js, jsgrid.js
Если интересно, то прошу под кат и в репозиторий.

Half-HA cluster PostgreSQL на Windows 2012

Из песочницы

Благодарность

Спасибо тебе, Хабр, за то, что ты есть и за те прекрасные часы которые я проводил в тебе! Спасибо, отважные хаброписатели, за статьи высокого качества, тонкого юмора и широкого кругозора. Только благодаря вам и Марь Ивановне (которая меня в первом классе научила читать) я добился серьёзных успехов в ИТ, а теперь хочу поделиться историей, когда нестандартное мышление помогло решить идиоматическую задачку от заказчика.

Некоторое время назад я работал над проприетарным продуктом. Этот софт хранил свои данные во внешней СУБД. Первоначально работа осуществлялась с MS SQL, однако позже специально для пользователей «я только *nix-подобные системы ставлю» сделали совместимость с PostgreSQL. Тут взяли меня для решения задач класса «база данных упала — нужно восстановить по журналам транзакций».
В один прекрасный день команда поехала реализовывать очередной проект. Первоначально было оговорено, что на объекте уже есть два сервера Windows 2012, на которых будет развёрнут отказоустойчивый кластер MS SQL. Однако в последний момент у заказчика денег на инстансы не хватило, и мне было поручено ставить рostrge’совые БД, а так же как-то решить задачу отказоустойчивости. Спасибо сообществу разработчиков рostgres, которые скомпилировали установщик для Windows. Задачи:

Как мы делали ядро инвестиционного бизнеса «Альфа-Банка» на базе Tarantool

Кадр из фильма «Our Secret Universe: The Hidden Life of the Cell»
Инвестиционный бизнес — это одно из сложнейших направлений в банковском мире, потому что здесь есть не только кредиты, займы и депозиты, но и ценные бумаги, валюта, товары, деривативы и всякие сложности в виде структурных продуктов.
В последнее время мы наблюдаем рост финансовой грамотности населения. Всё больше людей вовлекается в торговлю на рынках ценных бумаг. Индивидуальные инвестиционные счета появились не так давно. Они позволяют вам торговать на рынках ценных бумаг и при этом либо получать налоговые вычеты, либо не платить налоги. И все клиенты, которые к нам приходят, хотят управлять своим портфелем и видеть отчётность в реальном времени. Причем чаще всего этот портфель мультипродуктовый, то есть люди являются клиентами различных направлений бизнеса.
Кроме того, растут и потребности регуляторов, как российских, так и зарубежных.
Чтобы соответствовать текущим потребностям и заложить фундамент для будущих модернизаций, мы разработали ядро инвест-бизнеса на основе Tarantool.

sudo rm -rf, или Хроника инцидента с базой данных GitLab.com от 2017/01/31

Перевод

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных и сам сервис ушел в офлайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими

Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы. It, как говорится, happens. Но надо отдать должное команде проекта: они нашли в себе силы отнестись ко всему с юмором, не потеряли голову и проявили удивительную открытость, написав обо всем в твиттере и выложив в общий доступ, по сути, внутренний документ, в котором команда в реальном времени вела описание разворачивающихся событий.

Во время его чтения буквально ощущаешь себя на месте бедного YP, который в 11 часов вечера после тяжелого трудового дня и безрезультатной борьбы с Постгресом, устало щурясь, вбивает в консоль боевого сервера роковое и жмет Enter. Через секунду он понимает, что натворил, отменяет удаление, но уже поздно — базы больше нет…

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

Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации

Tutorial

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.
Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.
Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.
Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.
В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

Как быстро удалить множество строк из большой базы в MySQL

Tutorial

Как известно, все системные администраторы делятся на две категории. Те, кто уже делают бэкапы и те, кто ещё нет.
Подобно им, администраторы БД также делятся на две категории, те, кто уже запускал процедуру удаления на большой БД с типом таблиц InnoDB, и те, кому это ещё предстоит.
Разумеется, в теории все знают, что из-за особенностей InnoDB, удаление может быть долгим, но это знание сродни тому, что «надо делать бэкапы». Многие осознают эти нехитрые истины, только наступив на грабли.
Для понимания, удаление 350М записей в таблице на 500М записей может занять более двух суток. Вторые грабли, на которые многие наступают, это попытка прибить запрос. Как мы все помним, InnoDB движок транзакционный, поэтому если вы попытаетесь прибить запрос, он попытается откатить изменения, а это может занять больше времени, чем выполнялся запрос.
Как сделать так, чтобы не было мучительно больно? Добро пожаловать под кат!

DBA: в погоне за пролетающими блокировками

В прошлой статье, где я рассказывал о мониторинге БД PostgreSQL, была такая фраза:Такая ситуация — одна из самых неприятных для DBA:

• на первый взгляд, база работает
• никакие ресурсы сервера не исчерпаны
• … но часть запросов при этом «подтормаживает»

Шансов поймать блокировки «в моменте» крайне мало, да и длиться они могут всего по несколько секунд, но ухудшая при этом плановое время выполнения запроса в десятки раз. А хочется-то не сидеть и ловить происходящее в онлайн-режиме, а в спокойной обстановке разобраться постфактум, кого из разработчиков покарать в чем именно была проблема — кто, с кем и из-за какого ресурса базы вступил в конфликт.
Но как? Ведь, в отличие от запроса с его планом, который позволяет детально понять, на что пошли ресурсы, и сколько времени это заняло, подобных наглядных следов блокировка не оставляет после себя…
Разве что короткую запись в логе: А давайте попробуем зацепиться именно за нее!

Настройка MongoDB ShardedCluster с X.509 аутентификацией

Из песочницы

Всем доброго времени суток! Недавно жизнь подкинула автору увлекательную работу по развертыванию MongoDB кластера с настройкой репликации и шардирования, а также аутентификации c использованием x.509 сертификатов. В данной статье я в первую очередь хотел бы изложить свои мысли и поделиться полученными опытом. Так как некоторые вещи оказались не тривиальными и сделать их с первого раза не удавалось, то думаю мои пошаговые инструкции могут пригодиться для освещения вопроса тем кто только знакомится с шардированием данных и работой с MongoDB в целом.
Также я буду очень рад увидеть рекомендации по добавлению/изменению конфигурации кластера и просто вопросы или критику по самой статье или по сути вопроса.

Перенос данных бэкапа новой версии MS SQL Server на более старую версию

Из песочницы

Предыстория

Как-то раз для воспроизведения бага мне потребовался бэкап production-базы.
К моему удивлению я столкнулся со следующими ограничениями:

1. Бэкап базы был сделан на версии SQL Server 2016 и не был совместим с моей SQL Server 2014.
2. На моем рабочем компьютере в качестве ОС использовалась Windows 7, поэтому я не мог обновить SQL Server до версии 2016
3. Поддерживаемый продукт был частью более крупной системы с сильно связанной легаси-архитектурой и также обращался к другим продуктам и базам, поэтому его развертывание на другой станции могло занять очень много времени.

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

Greenplum 6: обзор новых фич

Вот уже 16 лет как открытая массивно-параллельная СУБД Greenplum помогает самым разным предприятиям принимать решения на основе анализа данных.
За это время Greenplum проник в различные сферы бизнеса, в числе которых: ритейл, финтех, телеком, промышленность, e-commerce. Горизонтальное масштабирование до сотен узлов, отказоустойчивость, открытый исходный код, полная совместимость с PostgreSQL, транзакционность и ANSI SQL — трудно представить более удачное сочетание свойств для аналитической СУБД. Начиная от громадных кластеров в мировых компаниях-гигантах, как, например, Morgan Stanley (200 узлов, 25 Пб данных) или Tinkoff (>70 узлов), и заканчивая маленькими двух-нодовыми инсталляциями в уютных стартапах — всё больше компаний выбирают Greenplum. Особенно приятно наблюдать этот тренд в России — за последние два года количество крупных отечественных компаний, использующих Greenplum, выросло втрое.
Осенью 2019 года вышел очередной мажорный релиз СУБД. В этой статье я коротко расскажу об основных новых возможностях GP 6.

Путеводитель по резервному копированию баз данных

Резервным копированием называется сохранение копии данных где-то вне основного места их хранения.
Главное назначение резервного копирования – восстановление данных после их потери. В связи с этим нередко приходится слышать, что при наличии реплики базы данных с неё всегда можно восстановить данные, и резервное копирование не нужно. На самом деле резервное копирование позволяет решить как минимум три задачи, которые не могут быть решены при помощи реплики, да и реплику без резервной копии не инициализировать.
Во-первых, резервная копия позволяет восстановить данные после логической ошибки. Например, бухгалтер удалил группу проводок или администратор БД уничтожил табличное пространство. Обе операции абсолютно легитимны с точки зрения базы данных, и процесс репликации воспроизведёт их в базе-реплике.
Во-вторых, современные СУБД – весьма надёжные программные комплексы, однако изредка всё же происходит повреждение внутренних структур базы данных, после которого доступ к данным пропадает. Что особенно обидно, такое нарушение происходит обычно при высокой нагрузке или при установке какого-нибудь обновления. Но как высокая нагрузка, так и регулярные обновления говорят о том, что база данных – отнюдь не тестовая, и данные, хранящиеся в ней, ценны.
Наконец, третья задача, решение которой требует наличия резервной копии, – это клонирование базы, например, для целей тестирования.
Резервное копирование баз данных так или иначе базируется на одном из двух принципов:

• Выборка данных с последующим сохранением в произвольном формате;
• Снимок состояния файлов БД и сохранение журналов.

Давайте рассмотрим эти принципы и реализующие их инструменты подробнее.

Знакомство с СУБД CockroachDB и создание отказоустойчивого кластера с ней на Ubuntu 16.04

• Перевод
• Tutorial

Предисловие от переводчика: CockroachDB — достаточно молодая реляционная СУБД с открытым кодом (лицензия Apache 2.0), изначально созданная быть распределённой (с горизонтальным масштабированием «из коробки») и отказоустойчивой. Её авторы из компании Cockroach Labs, созданной в 2015 году, задаются целью «совместить богатство функциональности SQL с горизонтальной доступностью, привычной для NoSQL-решений». Данное руководство написано одним из сотрудников компании-разработчика и опубликовано на сайте облачного провайдера DigitalOcean для того, чтобы познакомить ИТ-специалистов с этой СУБД и продемонстрировать её использование.

Введение

CockroachDB — распределённая СУБД (SQL) с открытым кодом, обеспечивающая согласованность данных, масштабируемость и выживаемость.
Настройка CockroachDB проста: устанавливаете её на нескольких серверах (узлах) и объединяете их в единое целое для совместной работы (кластер). Все узлы кластера действуют «симметрично» и предлагают доступ к одинаковым данным. Если хранилище для данных необходимо увеличить, то при используемой архитектуре достаточно создать новые узлы и присоединить к кластеру.

Некоторые аспекты мониторинга MS SQL Server. Рекомендации по настройке флагов трассировки

Tutorial

Предисловие

Довольно часто пользователи, разработчики и администраторы СУБД MS SQL Server сталкиваются с проблемами производительности БД или СУБД в целом, поэтому весьма актуальным является мониторинг MS SQL Server.
Данная статья является дополнением к статье Использование Zabbix для слежения за базой данных MS SQL Server и в ней будут разобраны некоторые аспекты мониторинга MS SQL Server, в частности: как быстро определить, каких ресурсов не хватает, а также рекомендации по настройке флагов трассировки.
Для работы следующих приведенных скриптов, необходимо создать схему inf в нужной базе данных следующим образом:

Способы диагностики PostgreSQL — Владимир Бородин и Ильдус Курбангалиев

Одним из самых популярных докладов конференции PG Day в 2015 году стал рассказ Владимира Бородина и Ильдуса Курбангалиева о ситуациях, когда посгресовым базам становится плохо, надо их диагностировать и искать узкие места. Все примеры в докладе взяты из реальной практики Яндекса, сопровождаются иллюстрациями и подробным рассказом о поиске «боттлнека». Не смотря на то, что проблемы рассматривались в разрезе 9.4 и 9.5 версий базы данных, общая ценность и практическая применимость советов Владимира и Ильдуса остается неизменной. Рады предложить вам транскрипцию этого доклада.Вступление Ильи Космодемьянского: сейчас у нас будет рассказ о том, как жить, если очень хочется иметь Oracle, а его нет. На самом деле, это полезный доклад, потому что одна из проблем, которую мы сейчас имеем – это проблема средств диагностики. Средства диагностики местами не достают, местами, вместо привычных средств диагностики нужно использовать довольно сложные тулзы, которые вообще предназначены для разработчиков Linux, а не для DBA. У DBA зубы начинают болеть, когда они смотрят на эти скрипты. И вот ребята из Яндекса и PG Pro расскажут о методах диагностики Postgres, которые они применяют, как ими пользоваться и немного расскажут о том, как они собираются улучшить этот мир.

Сравнение компараторов для синхронизации схем и данных баз данных MS SQL Server

Tutorial

Описание общей потребности в синхронизации изменений

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

SSO на микросервисной архитектуре. Используем Keycloak. Часть №1

В любой крупной компании, и X5 Retail Group не исключение, по мере развития возрастает количество проектов, где требуется авторизация пользователей. С течением времени требуется бесшовный переход пользователей из одного приложения в другой и тогда возникает необходимость использования единого сервера Single-Sing-On (SSO). Но как быть, когда такие идентификационные провайдеры как AD или иные, не обладающие дополнительными атрибутами, уже используются в различных проектах. На помощь придет класс систем под названием «идентификационные брокеры». Наиболее функциональными являются его представители, такие как Keycloak, Gravitee Access management и пр. Чаще всего сценарии использования могут быть различны: машинное взаимодействие, участие пользователей и пр. Решение должно поддерживать гибкий и масштабируемый функционал, способный объединить все требования в одном, и такие решением в нашей компании сейчас является индикационный брокер – Keycloak.

PostgreSQL и настройки согласованности записи для каждого конкретного соединения

Перевод

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

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

Практика использования Spark SQL, или Как не наступить на грабли

Если вы работаете с SQL, то вам это будет нужно очень скоро. Apache Spark – это один из инструментов, входящих в экосистему Hadoop, который обрабатывает данные в оперативной памяти. Одним из его расширений является Spark SQL, позволяющий выполнять SQL-запросы над данными. Spark SQL удобно использовать для работы посредством SQL-запросов с большими объемами данных и в системах с высокой нагрузкой.
Ниже вы найдёте некоторые нехитрые приёмы по работе со Spark SQL:

• Как с помощью сбора статистики и использования хинтов оптимизировать план выполнения запроса.
• Как, оставаясь в рамках SQL, эффективно обрабатывать соединения по ключам с неравномерным распределением значений (skewed joins).
• Как организовать broadcast join таблицы, если её размер слишком велик.
• Как средствами Spark SQL понять, сколько приложение Spark реально использовало памяти и ядер кластера в развёртке по времени.

Китай принял свой «пакет Яровой»

В конце прошлого года китайское правительство представило новый закон о киберпезопасности, так называемую Многоуровневую схему кибебезопасности (Cybersecurity Muti-Level Protection Scheme, MLPS 2.0). Закон, вступивший в силу в декабре, фактически означает, что правительство имеет неограниченный доступ ко всем данным внутри страны, независимо от того, хранятся ли они на китайских серверах или передаются через китайские сети.
Это означает, что не будет никаких анонимных VPN (а многие популярные VPN принадлежат китайским компаниям). Никаких личных или зашифрованных сообщений. Никаких анонимных онлайн-аккаунтов и конфиденциальных данных. Любые данные будут доступны и открыты для китайского правительства, в том числе и данные иностранных компаний на китайских серверах или проходящие через Китай, поясняется в комментарии юридической фирмы Reed Smith. В каком-то смысле MLPS 2.0 и сопутствующие законы можно сравнить с российским «пакетом законов Яровой».

О чем молчит EXPLAIN, и как его разговорить

Из песочницы

Классический вопрос, с которым разработчик приходит к своему DBA или владелец бизнеса — к консультанту по PostgreSQL, почти всегда звучит одинаково: «Почему запросы выполняются на базе так долго?»
Традиционный набор причин:

• неэффективный алгоритм
  когда вы решили сделать JOIN нескольких CTE по паре десятков тысяч записей
• неактуальная статистика
  если фактическое распределение данных в таблице уже сильно отличается от собранной ANALYZE’ом в последний раз
• «затык» по ресурсам
  и уже не хватает выделенных вычислительных мощностей CPU, постоянно прокачиваются гигабайты памяти или диск не успевает за всеми «хотелками» БД
• блокировки от конкурирующих процессов

И если блокировки достаточно сложны в поимке и анализе, то для всего остального нам достаточно плана запроса, который можно получить с помощью оператора EXPLAIN (лучше, конечно, сразу EXPLAIN (ANALYZE, BUFFERS) …) или модуля auto_explain.
Но, как сказано в той же документации, Но можно обойтись и без него, если воспользоваться подходящим инструментом!

Материалы с казанского Go-митапа: разбор XML, gopls, drone.io и работа с миграциями

Привет! Мы вернулись из Казани, где проводили свой первый региональный митап для Go-разработчиков вместе с сообществом GolangKazan. Спасибо всем, кто пришёл послушать доклады и познакомиться — было здорово.

На митапе выступали спикеры из компаний «Дремучий лес», Авито, Ozon.ru и Marketplace Technologies. Они рассказывали про разбор и хранение большого XML-файла на маленькой VDS, language server gopls, CI/CD платформу drone.io и инструменты для миграции баз данных.

Под катом вас ждут видеозаписи всех докладов с таймкодами для удобной навигации, ссылки на репозитории спикеров на Гитхабе и фотоотчёт с митапа. А мы пойдём паковать рюкзаки ко второму казанскому митапу по фронтенду, который пройдёт уже 15 февраля.

Elastic сделала бесплатными проблемные security-функции, ранее выведенные в open source

На днях в блоге Elastic появилась запись, в которой сообщается о том, что основные security-функции Elasticsearch, выведенные в open source-пространство более года назад, теперь являются бесплатными для пользователей.
В официальной блогозаписи содержатся «правильные» слова о том, что open source должен быть бесплатным и что владельцы проекта строят свой бизнес на прочих дополнительных функциях, которые предлагаются ими для enterprise-решений. Теперь в базовые сборки версий 6.8.0 и 7.1.0 включены следующие security-функции, ранее доступные только по gold-подписке:

• TLS для шифрованной связи.
• Файл и native-реалм для создания и управления пользовательскими записями.
• Управление доступом пользователей к API и кластеру на базе ролей; допускается многопользовательский доступ к Kibana с использованием Kibana Spaces.

Однако перевод security-функций в бесплатную секцию — это не широкий жест, а попытка создать дистанцию между коммерческим продуктом и его главными болячками.
А они у него есть и серьезные.

Транзакции и механизмы их контроля

Из песочницы

Транзакцией называется последовательность операций над данными имеющая начало и конец

Транзакция это последовательное выполнение операций чтения и записи. Окончанием транзакции может быть либо сохранение изменений (фиксация, commit) либо отмена изменений (откат, rollback). Применительно к БД транзакция это нескольких запросов, которые трактуются как единый запрос.

Атомарность. Транзакция либо выполняется полностью либо не выполняется вовсе.
Согласованность. При завершении транзакции не должны быть нарушены ограничения накладываемые на данные (например constraints в БД). Согласованность подразумевает, что система будет переведена из одного корректного состояния в другое корректное.
Изолированность. Параллельно выполняемые транзакции не должны влиять друг на друга, например менять данные которые использует другая транзакция. Результат выполнения параллельных транзакций должен быть таким, как если бы транзакции выполнялись последовательно.
Устойчивость. После фиксации изменения не должны быть утеряны.

GUI на Grafana для mgstat — утилиты мониторинга системы на InterSystems Caché, Ensemble или HealthShare

Tutorial

Добрый день! Данная статья является продолжением статьи «Дружим Prometheus с Caché». Мы рассмотрим вариант визуализации результатов работы утилиты ^mgstat. Эта утилита предоставляет статистику производительности Caché, а именно, число вызовов глобалов и рутин, локальное и по ECP, длину очереди демона записи, число блоков, записанных на диск и считанных с диска, объем ECP-трафика и прочее. Запускаться ^mgstat может как отдельно (интерактивно или джобом), так и при работе другой утилиты оценки производительности ^pButtons.
Изложение материала хотелось бы разбить на две части: в первой графически показать непосредственно статистику, собираемую ^mgstat, а во второй — рассмотреть, как именно эта статистика собирается. Если коротко, то используются $zu-функции. Однако к большинству собираемых параметров есть и объектный интерфейс через классы пакета SYS.Stats. И далеко не все параметры, которые можно собрать, показываются в ^mgstat. В дальнейшем мы попробуем все их отобразить на Grafana-дашбоардах. В этот же раз покажем только то, что нам предоставляет сам ^mgstat. Кроме того, попробуем на вкус Docker-контейнеры.

Unit-тесты в СУБД — как мы делаем это в Спортмастере, часть первая

Привет, Хабр!
Меня зовут Максим Пономаренко и я — разработчик в Спортмастере. Имею 10-летний опыт работы в IT-сфере. Начинал карьеру в в области ручного тестирования, затем переключился на разработку баз данных. Последние 4 года, аккумулируя знания, полученные в тестировании и разработке, занимаюсь автоматизацией тестирования на уровне СУБД.
В команде Спортмастера я состою чуть более года и на одном из крупных проектов занимаюсь разработкой автоматизированного тестирования. В апреле мы с ребятами из Sportmaster Lab выступали на конференции в Краснодаре, мой доклад назывался «Unit-тесты в СУБД», и сейчас хочу поделиться им с вами. Текста будет много, поэтому я решил разбить доклад на два поста. В первом мы поговорим об автотестах и тестировании в общем, а во втором я подробнее остановлюсь на нашей системе unit-тестирования и результатах ее применения.
Вначале немного скучной теории. Что такое автоматическое тестирование? Это тестирование, которое проводится программными средствами, и в современном IT оно все чаще и чаще используется при разработке ПО. Связано это с тем, что компании растут, растут их информационные системы и соответственно растет и количество функционала, которое надо тестировать. Проводить ручное тестирование становится всё накладнее и накладнее.