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

"Размышления без практики приводят к заблуждению, практика без размышления приводит к затруднению."

Мы ведём войну с индивидуальностью у шардов в кластере MongoDB. Это продолжение статьи Шардинг от которого невозможно отказаться, а это значит, что наступила пора конкретики.

Как я и обещал, здесь мы рассмотрим подробнее:

• настройку процесса выравнивания размера шардов
• расчет поправок для коррекции границ
• мониторинг распределения данных в коллекциях

Liquibase — это инструмент управления изменениями в базе данных. С его помощью вы можете отслеживать изменения в базе данных, сделанные с помощью SQL (или XML) скриптов. Эти скрипты могут быть добавлены в системы контроля версий, такие как git.

В данной статье мы рассмотрим, как автоматизировать развертывание баз данных с помощью Liquibase. Автоматизация может быть выполнена с помощью

1. Пайплайн Jenkins 

2. Shell-скриптов

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

Существует два способа записи наборов изменений в Liquibase, т.е. XML и SQL. Я выбрал SQL, чтобы избежать записи соответствующих изменений XML для каждого выполняемого нами обновления SQL. Таким образом, тот же SQL-файл, который мы пишем для разработки, используется для развертывания Liquibase.

Иногда при выполнении длительных или плохо написанных запросов в PostgreSQL происходят разные неприятные вещи типа внезапного сбоя процесса или краша всего сервера.

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

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

Yelp — это крупнейшее в США приложение для заказа еды и услуг. Оно установлено более чем на 30 млн. уникальных устройств, в нём зарегистрировано более 5 млн. компаний. Для хранения и доступа к данным в Yelp используют Cassandra. Как и для каких задач применяется эта база данных, на конференции Cassandra Day Russia 2021 рассказал Александр Широков, Database Reliability Engineer в Yelp.

SAP HANA — реляционная in-memory база данных от компании SAP, в которой данные хранятся и обрабатываются исключительно в оперативной памяти. Диски используются только для логирования и хранения бэкапов, необходимых для восстановления системы. О плюсах такого решения можно найти много информации в интернете. Но сегодня мы хотим поговорить о минусах.

Наша компания постепенно расширяется, у нас работает всё больше инженеров. А когда их много, надо как-то распределять права и доступы. Почему это важно? У нас есть большое количество скриптов по мониторингу, обслуживанию и т.п., которые обслуживаются просто по крону. Но всегда присутствует необходимость писать новые скрипты, актуализировать уже работающие при изменениях конфигурации, а так же дебажить какие-то проблемы. Поэтому технической команде нужно выбрать инженера, который будет заниматься данным вопросом в конкретный момент времени.

Но иногда бывает так, что написать новый скрипт или чинить уже существующий отправляют человека, у которого нет права на доступ в эту область инфраструктуры. Например, потому что он новичок. И что делать в этой ситуации?

Этот день — яркий пример того, как несколько вещей, которые сами по себе не приводят к отказу, могут удачно совпасть. Итак, 23 апреля было совершенно обычным днём, с обычным трафиком и обычной загрузкой ресурсов. Как обычно, с запасом больше трети, чтобы при потере любого из ЦОДов пережить это без проблем. Никто не думал, что к серверному мониторингу нужно прикручивать ещё мониторинг того, что говорит президент на прямой линии, поэтому дальше случилось вот что:



Примерно в 13:30 у нас резко подскочила нагрузка на поиск по авиации и по железнодорожным билетам. Где-то в этот момент РЖД сообщила о перебоях на сайте и в приложении, а мы начали экстренно наливать дополнительные инстансы бекендов во всех ЦОДах.

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

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

С докладом пока так и не сложилось, зато появилась эта статья, в которой я постарался собрать наиболее показательные вещи, которые вызывают "напряги" при активном использовании PostgreSQL в реальном бизнесе.

А не пора ли нам шардить коллекции?
Не-е-е:

• у нас нет времени, мы пилим фичи!
• CPU занят всего на 80% на 64 ядерной виртуалке!
• данных всего 2Tb!
• наш ежедневный бекап идет как раз 24 часа!

В принципе, для большинства проектов вcё оправдано. Это может быть еще прототип или круг пользователей ограничен… Да и не факт, что проект вообще выстрелит.
Откладывать можно сколько угодно, но если проект не просто жив, а еще и растет, то до шардинга он доберется. Одна беда, обычно, бизнес логика не готова к таким "внезапным" вызовам.
А вы закладывали возможность шардинга при проектировании коллекций?

Эта статья для продвинутых разработчиков.
Для тех, кто планирует шардинг своего кластера.
Для тех, кто уже шардировал кластер ранее, но админы все еще плачут.
Для тех, кто руками перемещал jumbo-чанки.

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

Привет, Хабр! Меня зовут Станислав Маскайкин, я архитектор аналитических систем ВТБ. Сегодня я расскажу о том, почему мы перевели нашу систему подготовки отчётности с Oracle SuperCluster на российскую Arenadata DB. Как мы выбирали решение, почему не взяли чистый опенсорс, а также о некоторых результатах такой миграции — под катом.

Каждый раз сталкиваясь с различными классификациями баз данных и технологий, связанных с ними, я чувствовал недовольство структурой и подачей этого материала. В результате, я решил выложить свои заметки. Уверен, они могут быть полезны как для опытных специалистов с целью устранения пробелов в знаниях, в качестве отправной точки для изучения материала глубже, так и для подготовки к собеседованиям с обеих сторон.

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

Замечания и предложения приветствуются.

В СУБД растут объемы данных и нагрузки. А это значит, что нужно держать нос по ветру и узнавать больше об инструментах и методах взаимодействия с базами данных. Чтобы этого добиться, лучше всего сходить на профильную конференцию (было бы странно, если бы мы не дали вам этот совет, правда?), или хотя бы почитать о самых актуальных проблемах области. 

Какие тренды последних лет усиливаются в PostgreSQL прямо сейчас? Как не устроить highload на ровном месте? Где почитать про мифы и реальность СУБД в облаках? Об этом и многом другом мы поговорили с Николаем Самохваловым. 

Николай — член программного комитета конференции HighLoad++, куратор секции Базы данных, а также основатель Postgres.ai и #RuPostgres.

Если вы когда-нибудь сталкивались с распределёнными СУБД или системами обработки данных, то слышали о двух теоремах: CAP и PACELC, определяющих грани возможных конфигураций этих систем. Споры об их универсальности не утихают до сих пор, однако альтернативы, способные полностью заместить данные научные изыскания, ещё не сформулированы и вряд ли в ближайшее время появятся. Поэтому всем, кто работает с распределёнными системами, необходимо учитывать эти теории. Мы, команда разработки СУБД Jatoba, также столкнулись с противоречивостью теорем, детально разобрались и готовы помочь всем, кто только начинает работу с ними.

Введение

В 2000 году Эрик Брюер выдвинул гипотезу, суть которой можно описать так: в распределённой системе невозможно обеспечить одновременное выполнение всех трёх условий: корректности, доступности и устойчивости к разделению узлов CAP (Consistency-Availability-Partition tolerance). За 20 лет применения теорема действительно доказала свою состоятельность, однако показалась недостаточной. Так в 2010 году появилась PACELC как расширение CAP, которое гласит, что в случае разделения сети в распределённой компьютерной системе необходимо выбирать между доступностью и согласованностью, но даже если система работает нормально в отсутствии разделения, нужно выбирать между задержками и согласованностью.
Как это работает, рассмотрим далее.

Расшифровка доклада «Noisia — генератор аварийных и нештатных ситуаций в PostgreSQL» с конференции PGConf.Online 2021.

В докладе рассказывается про утилиту Noisia которая используется для намеренного создания аварийных ситуаций в СУБД PostgreSQL. Докладчик (то есть я) рассказывает о функциональности и назначении утилиты и о разных способах сломать Postgres.

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

Сам доклад и видео здесь.

Алексей Миловидов делает ClickHouse и, конечно, знает его вдоль и поперек. В том числе и о том, как его можно использовать дополнительно к его штатным и всем хорошо известным функциям.

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

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

База данных становится слишком большой или старой? Ее тяжело обслуживать? Что ж, надеюсь, я смогу немного помочь. Текст, который вы собираетесь прочитать, содержит реальный опыт масштабирования монолитной базы данных, лежащей в основе одного из сайтов Топ-250 (согласно alexa.com). На момент написания этой статьи chess.com занимал 215 место в мире по популярности. Ежедневно к нам заглядывали более 4 млн уникальных пользователей, а наши MySQL-базы обрабатывали в общей сложности более 7 млрд запросов. Год назад сайт ежедневно посещали 1 млн уникальных пользователей; в марте прошлого года их число увеличилось до 1,3 млн; сегодня более 4 млн человек заходят на chess.com ежедневно, а число сыгранных партий превышает 8 млн. Я, конечно, знаю, что это не сопоставимо с самыми крупными игроками на рынке, однако наш опыт все же может помочь в такой сложной задаче, как «исправление» монолитной базы данных и ее вывод на новый уровень производительности.

Полгода назад я устроился в финтех-стартап, имеющий примерно 15 тысяч клиентов. Моя задача заключалась в развитии биллинговой инфраструктуры. Когда я пришёл в компанию, меня немного беспокоила узость задач моей новой должности и нового отдела. Я думал: ну какая глубина может быть в биллинге? Разве у нас не закончатся задачи спустя 3-4 месяца? Клиент регистрируется, ежемесячно оплачивает подписку, вот и всё, правда ведь?

… правда?

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

Поиск всех этих пограничных случаев один за другим был не самым приятным процессом. Было бы здорово, если бы кто-то составил краткое руководство о том, что мне нужно знать. Поэтому вот и оно, моё руководство! Если вы размышляете о создании (или даже об использовании) системы биллинга, то читайте внимательно.

В этой статье описаны шаги по установке базы данных SAP HANA в домашних условиях. Основное отличие этого материала заключается в том, что мы не будем использовать традиционные виртуальные машины, такие как Oracle VirtualBox или VM Ware Workstation Player. В этом документе речь пойдет о новом подходе, разработанном компанией Microsoft, под названием Windows Subsystem for Linux.

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

Вот прямое определение от Microsoft:

The Windows Subsystem for Linux lets developers run a GNU/Linux environment — including most command-line tools, utilities, and applications — directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup.

Более детальную информацию о WSL можно получить на сайте Microsoft по ссылке ниже.

В 2019 году появилась стабильная версия WSL2, которая получила ряд существенных дополнений по сравнению с первой версией. Основное отличие от первой версии - улучшенная производительность файловой системы, а также появившаяся полная поддержка системных вызовов ядра Linux. Ниже представлено сравнение двух версий WSL.

Инструкция по диагностике проблем в работе баз данных в случае аварии.

Привет. У каждого на работе иногда случаются «чёрные» дни. Для меня такими днями являются аварии в работе сервисов, приводящие к недоступности систем для конечных пользователей. По счастью, такое происходит нечасто, но каждый такой случай заставляет меня долго рефлексировать над вопросами «что мы сделали не так».

После одной из аварий я поймал себя на мысли, что диагностика причины недоступности сервиса заняла слишком много времени. Инженеры, задействованные в разрешении инцидента, действовали не совсем скоординированно: проверяли одни и те же гипотезы и тратили время на изучение совсем уж «фантастических» вариантов. В квалификации ребят никакого сомнения у меня нет, поэтому в рамках рефлексии я списываю это на стрессовую ситуацию аварии.

Чтобы в следующий раз диагностика и устранение причин аварии происходили быстрее, мы совместно с DevOps-инженером Алексеем Поповым решили написать «план эвакуации при пожаре»: пошаговую инструкцию, которую можно было бы использовать для быстрого исследования инцидента.

Последняя проблема касалась работы базы данных и взаимодействия web-приложения с базой. Поэтому инструкция касается диагностики именно базы данных. Также хочу отметить, что эта схема — не истина в последней инстанции, а всего лишь наш опыт, перенесенный на «бумагу». Мы намеренно не стали включать слишком «экзотические» причины аварии, поскольку схема становится слишком громоздкой и нечитаемой.

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

Базы данных — это Святой Грааль для хакеров, поэтому их необходимо защищать с особой тщательностью. Это первая из серии статей, в которых мы дадим обзор best practice в обеспечении безопасности баз данных. Мы начнем с одной из самых популярных СУБД с открытым исходным кодом, PostgreSQL, и рассмотрим несколько уровней безопасности, о которых стоит задуматься: