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

Всем привет! Я хотел бы поделиться своим опытом по расширению высоконагруженного кластера ClickHouse, немного о том как работает репликация и шардирование.

5-19 сентября пройдёт конференция Graph+AI Summit 2021 для людей, не равнодушных к графовой аналитике и машинному обучению. Мероприятие будет проходить в смешанном формате онлайн и оффлайн, участие бесплатное, старт в 18:00 по МСК.

Организатором выступила компания TigerGraph, создатель одноименной Графовой БД и аналитической платформы, а в программе будут доклады от спикеров из различных компаний: Gartner, Dell Technologies, Mastercard, Intuit Corporatio, Optum, Mercury NZ и др.

Между 5 и 19 октября будут воршопы, примеры реализаций по индустриям (ФинТех, БиоТех, Медиа, Реклама и Ритейл), тренинги и сертификации.

Почему это интересно? Будущий Графовый язык запросов GQL - первый за 40 лет язык запросов к БД, который ISO комитет решил стандартизироваать после SQL. И как говорит Марк Бейер, вице-президент-аналитик Gartner “To Graph or Not to Graph? That is NOT the Question – You Will Graph.”

Для тех, кто сразу хочет присоединиться к одному из 10000 участников, ссылка на регистрацию. Под катом - пример использования для борьбы с мошенническими звонками на примере China Mobile.

Этим летом вышел новый релиз платформы данных InterSystems IRIS Data Platform 2021.1.

Основные «темы» в этом релизе связаны с расширением доступности платформы для разработчиков на различных технологиях и новыми возможностями по анализу данных.

Расширяется выбор доступных языков разработки, как серверных, так и клиентских, а также новые компоненты для аналитики больших объемов данных. Но, обо всём по порядку.

Этим летом абитуриентам было жарко, МГУ по проходному баллу почти превратился в ПТУ, а кто-то успешно поступил в вооруженные силы РФ, сам того не желая. Отсутствие автоматизации в 2021 году, способной обработать распределение абитуриентов по учебным заведениям, а так же необходимость написать продолжение предыдущей статьи, описывающей основы теории о Распределенной Авторизации (РА) побудило решить эту детскую задачу автоматизации. Посмотрим, сколько же рпс нам в этом раз отсыпет антилопа.

Всем привет!

В своей первой статье, посвященной группам доступности, я уже писал о системе электронного документооборота ДОМ.РФ «СДУ Приоритет» и о том, как Always On Availability Groups помогли нам значительно сократить требуемое технологическое окно за счёт оптимальной процедуры отката со стороны БД. В этой части речь пойдет о том, как мы провели дедубликацию файлов в СЭД на уровне БД и сократили объем БД на 8Тб без потери информации, и как нам помогли в этом группы доступности.

Всем привет, меня зовут Александр, я работаю в команде СЭД компании ДОМ.РФ.

В этой статье я расскажу, как Always On Availability Groups помогает значительно сократить требуемое технологическое окно за счёт оптимальной процедуры отката со стороны БД, также как подружить СЭД с группами доступности. Во второй части статьи речь пойдет о том, как мы провели дедубликацию файлов в СЭД на уровне БД и сократили объем БД на 8Тб без потери информации, и как нам помогли в этом группы доступности.

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

В первой части я покажу что можно сделать, если на самом деле nvarchar(max) не был нужен, а хватило бы "нормальной" длины, с которой столбец можно проиндексировать. А во второй - что делать, если строка на самом деле такая длинная, что проиндексировать столбец с ней не представляется возможным.

Как найти самые "горячие" запросы на вашем PostgreSQL-сервере? Поискать их в логе и проанализировать план или воспользоваться расширением pg_stat_statements.

А если в лог попадает миллион запросов за сутки?.. Тогда любое значение лимита pg_stat_statements.max окажется недостаточно велико, чтобы собрать правдивую статистику. Так давайте собирать эту статистику прямо с планов!

Но для некоторых сервисов СБИС нам в "Тензоре" производительность запросов к базе настолько важна, что auto_explain.log_min_duration приходится выставлять в единицы миллисекунд - и вот они, миллионы планов... Как не потеряться в них?

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

Реализуемая в приложении задача высосана из вакуума и практической пользы не имеет. Само приложение состоит из трёх npm-пакетов: основного и двух зависимых. Каждый пакет декларирует свою собственную структуру данных в JSON-формате. Основное приложение создаёт в двух различных базах данных две различные структуры, комбинируя свою собственную декларацию и декларацию из соответствующего пакета (own + pack1 & own + pack2). Совмещение различных фрагментов в общую структуру является типовой задачей модульных приложений с единой БД. Эту задачу я и рассматриваю ниже.

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

Сначала краткая предыстория. Я пытался сделать так, чтобы логи медленных запросов в MySQL писались в /dev/stderr и их можно было бы читать с помощью простого docker-compose logs -f mysql без необходимости входить в контейнер с docker-compose exec mysql ash.

Привет, меня зовут Денис, в Arenadata я занимаюсь Greenplum — распределённой СУБД с открытым исходным кодом, разработанной на основе PostgreSQL и заточенной под аналитический профиль нагрузки. Моя работа (помимо разработки) заключается в разборе инцидентов, когда в кластерах клиентов происходит что-то непонятное для нашей технической поддержки. Такие истории обычно заканчиваются детальным внутренним разбором произошедшего, рекомендациями для клиентов и внесением правок в код Greenplum (как в наш fork, так и в upstream). Я расскажу вам про один из инцидентов, которым я занимался в последнее время. Хотя этот случай не привел к технически сложным доработкам, он является показательным примером того, как мы исследуем проблемы с Greenplum. Заодно я расскажу о подробностях внутреннего устройства Greenplum и PostgreSQL, которые не описаны в документации.

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

Сегодня на примере вполне реальной задачи рассмотрим такие возможности оператора INSERT ... ON CONFLICT.

Лет 6 назад я задавался вопросом "Как правильно организовать распределенное проектирование БД?" Тогда ответа на свой вопрос я так и не получил, но за прошедшее с тех пор время я встретился с вариантом, наиболее близко подобравшимся к моему видению "прекрасного" — это декларативная схема описания данных в Magento 2.

Мне нравится философия таких программных систем, как Magento, Odoo, WordPress, Drupal — базовый функционал, расширяемый за счёт сторонних плагинов. Она значительно отличается от философии FAANG. Философия FAANG направлена на построение уникальных высокопроизводительных решений, а философия WordPress — на адаптируемость к требованиям бизнеса. Каждый из этих подходов имеет свои плюсы и минусы, но мне ближе второй и рассматривать вопрос, вынесенный в заголовок публикации, я буду именно в рамках WordPress-подхода (WP-подхода).

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

Этим летом я по уши увяз в serverless-тематике и даже решил переписать один из своих pet-проектов целиком на serverless. Движок для сайта, поддерживающий бессерверные вычисления и вендор для кэширующей прослойки были найдены быстро - NextJS (с деплоем на Vercel) и Upstash с оплатой за каждую отдельную операцию и байт в хранилище. Камнем преткновения стал выбор провайдера для DBaaS. Мне бы хотелось реализовать всё таким образом, чтобы у проекта было две разных базы данных - для разработки и для production, и мне совсем не хотелось запускать базу данных для разработки на локальной машине. Поверхностное ознакомление с DBaaS провайдерами показало, что за дополнительную базу данных пришлось бы платить вдвое больше несмотря на то, что она использовалась бы дай Бог пару раз в неделю. И я ушёл в просмотр докладов и презентаций на YouTube и это именно тот момент когда я открыл для себя PlanetScale. Хочу поделиться своим открытием с вами.

Иван Чувашов, DBA Okko и Southbridge, поделился жизненными кейсами с PostgreSQL, которые помогут решить ваши проблемы.

Разберем случаи из PostgreSQL: запросы в статусе idle in transaction, выключенные контрольные суммы данных, переполнение int4, убивающие базу временные файлы и загрузку CPU.

Всем привет! Меня зовут Евгений, я занимаюсь разработкой и проектированием в Ozon. Больше всего работаю с MS SQL и C#, но попадаются и другие СУБД и языки программирования.

Ozon как продукт быстро растёт: во втором квартале этого года мы доставляли больше миллиона посылок в день. Для обработки такого объёма заказов мы используем разные языки и платформы: .NET (C#), Go, MS SQL Server и PostgreSQL.

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

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

Но сначала позвольте погрузить вас немного в предметную область — объясню, на примере чего будет демонстрироваться проблема дублирования данных, и освещу некоторые методы её решения.

Иногда при анализе производительности запроса на предмет "куда ушло все время" возникает стойкое ощущение deja vu, что вот ровно этот же кусок плана ты уже где-то раньше видел...

Пролистываешь выше - и таки-да, вот он рядом - но почему он там оказался, и как выйти из Матрицы самому и помочь коллегам?