В прошлом году Tarantool исполнилось 15 лет. Он прошел долгий путь от обычного кэша до платформы управления данными с десятками разных внутренних продуктов и расширений. Такое обилие инструментов создает множество возможностей — и в этой статье мы расскажем о десяти, о которых многие забывают или попросту не знают.
Однажды нам нужно было уменьшить мастер кластера PostgreSQL по CPU и памяти. План был надёжный: дождаться низкой нагрузки на кластер, сменить мастер на одну из асинхронных реплик, переконфигурировать виртуальную машину с бывшим мастером и сделать switchover обратно. Казалось бы, что могло пойти не так?
Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".
В первой части лекции мы узнали, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. В этой - разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош.
Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.
Это вторая часть статьи, в которой обсуждаются вспомогательные функции, использующиеся функциями предназначенными для непосредственного формирования PlantUML-скриптов. Основные процедур и функции обсуждались в первой части статьи. Здесь же присутствует контрольный пример с таблицами, которые использовались для демонстрации функций.
Эта публикация - перевод статьи Scott Sutherland - Hijacking SQL Server Credentials using Agent Jobs for Domain Privilege Escalation. В публикации описано, как объекты учетных данных SQL Server могут быть использованы злоумышленниками для выполнения кода от имени пользователя SQL Server, локального пользователя Windows или доменного пользователя. Также, в публикации будет информация о том, как настроить логирование для обнаружения соответствующего поведения.
Статья продолжает знакомить с функциями для документирования баз данных PostgreSQL. Но на этот раз речь пойдет о специальных функциях, подготавливающих описания диаграмм классов на языке PlantUML.
В качестве основного средства документирования выбрана система управления проектами TRAC с подключенным плагином plantuml.
В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.
Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.
В начале двухтысячных я работал программистом и системным администратором в компании, в которой к настоящему моменту уже 14 лет тружусь простым директором. Интересный это опыт — смотреть спустя много лет на инфраструктуру, которую собирал своими руками, и которую теперь перестраивают другие люди под твоим руководством.
«Что там с базами, не пора ли добавлять ресурсов?» — казалось бы, звучит как дежурная реплика менеджера, и классический ответ на неё: «всё ок, до конца недели должно хватить!».
На деле этот безобидный на первый взгляд вопрос может быть сигналом о целом ворохе проблем. Важно разобраться, почему его задают (можно ведь посмотреть алерты и мониторинг), о чём именно речь (у нас точно всё ок с архитектурой?), как часто вопрос возникает (сколько денег мы тратим на содержание баз?).
Однажды на вопрос «что там с базами?» мы в команде решили ответить несколько иначе. Вместо «до конца недели должно хватить» — сказали: «давайте мигрируем базы в единый кластер, а тяжёлые файлы перенесём в S3».
О том, что из этого вышло, читайте под катом.
Масштабирование ИТ-инфраструктуры и переход к высоконагруженным многокомпонентным сервисам дает бизнесу не только преимущества, но и сложности. Одна из основных — необходимость обеспечения для сервисов возможности отказоустойчиво и надежно обмениваться тысячами сообщений без риска их потери или повреждения. И в этих задачах часто не обойтись без реализации очередей сообщений.
Рассказываем об основных сложностях развития высоконагруженных ИТ-систем и способах их преодоления с помощью очередей сообщений на примере Tarantool Queue Enterprise.
Материал подготовлен по мотивам вебинара «Как создавать высокопроизводительные очереди сообщений с различной архитектурой». Вы можете посмотреть его здесь.
Кластеризация необходима для большинства СУБД уровня Enterprise. Есть много способов создать или развернуть кластер: от бесплатных до дорогих, от простых до сложных. У разных вендоров свои приоритеты: одни делают настройку кластера в пару кликов (как в MS SQL), другие фокусируются на надежности и функциональности (Oracle).
В мире СУБД на базе PostgreSQL на сторону которых всё активнее переходит российский IT, тоже есть свои кластерные инструменты и решения: как бесплатные и открытые Patroni, Stolon, pacemaker/corosync, так и проприетарные. Лидер по популярности среди открытых решений – Patroni. Сегодня я расскажу, почему настраивать кластеризацию на нем руками весело только первые пару раз. Поговорим об особенностях поддержки Patroni в Proxima DB, снижении порога входа для новичков и повторяемости конфигураций.
Завершение цикла
Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)
Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат / Хабр (habr.com)
Задача
Оценить производительность СУБД при постоянной нагрузке, в условиях нестабильной инфраструктуры .
Проблема
На производительность СУБД влияет множество случайных факторов. Производительность инфраструктуры не постоянна и меняется в очень широком диапазоне.
Гипотеза
В идеальных условиях, при постоянной нагрузке, значения производительности СУБД должно иметь нормальное распределение.
Начало Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)
Следующая серия экспериментов выполняется с использованием периода сглаживания = 1 час.
Предпосылка к исследованию
Исследование гипотезы СУБД по природе своей является стохастической, а не детерминированной системой.
С целью проверки утверждения и в связи с началом работ по подготовке методики статистического анализа СУБД в условиях облачной среды, была начата серия экспериментов для определения влияния внешних/случайных факторов инфраструктуры на производительность СУБД .
Отчасти это действенный совет, отчасти — вопрос к читателям.
Совет: при создании нового приложения, требующего постоянного хранения данных, как это и бывает в случае большинства веб-приложений, по умолчанию следует выбирать Postgres.
Распределённая блокировка — очень удобный инструмент в кластере, который помогает обеспечивать эксклюзивный доступ к некоторому общему ресурсу. Цель такой блокировки — обеспечить доступ к ресурсу лишь одному сервису или запросу в данный момент времени. Так предотвращается гонка за данными и их неконсистентность. Распределённая (или кластерная) блокировка называется так потому, что она обеспечивается несколькими узлами, и выход из строя одного из них не повлияет на приложение. В этой статье я расскажу, как реализовать этот инструмент с помощью Tarantool 3.
Привет, Хабр! Мы продолжаем серию статей о проведённой миграции аналитического хранилища данных с платформы Teradata на GreenPlum. В предыдущей статье мы рассказали о нашем опыте и результатах автоматизированного переписывания SQL-скриптов из диалекта Teradata в диалект GreenPlum с помощью реализованного сервиса миграции кода. В этой статье мы расскажем вам о полученном нами опыте и результатах переноса архива данных объёмом более 400 Тб из Teradata в GreenPlum, а также о трудностях и решениях, связанных с этим процессом.
Редис – это кеш? А, может быть, это основная база данных? Так мы и живём в Мойре – опенсорс-системе реалтайм-алёртинга, родом из компании Контур. Расскажу вам про плюсы и минусы такого подхода, про жизнь в Редисе при 3 миллионах RPS, про миграции данных и оптимизацию базы.
В апреле этого года мы, команда производительности из Postgres Professional, совместно с коллегами из Selectel решили протестировать несколько дистрибутивов PostgreSQL и узнать, как они себя поведут на разных архитектурах. С результатами можно ознакомиться в этой статье, но, как сразу было верно отмечено читателями, там был один важный косяк – мы не сравнили производительность ванильного PostgreSQL с применением всем известных настроек по улучшению производительности и Postgres Pro Enterprise из коробки as is. Терпеть такое не было решительно никакой возможности, поэтому сегодня будет продолжение истории и ответ на важный для многих вопрос: «А есть ли у нашего форка хоть какое-то преимущество перед бесплатной ваниллой?» Или мы просто накатили общеизвестный конфиг и занимаемся импортозаместительным переклеиванием наклеек?
Привет, Хабр! Меня зовут Семен Попов, я отвечаю за разработку хранилища клиентских данных в Сбере. Расскажу, как мы в эксплуатации перешли с одной базы данных на другую — а именно, с Oracle на Platform V Pangolin, разработку СберТеха на основе PostgreSQL, доработанного в области безопасности, надёжности и производительности.
