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

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

Привет, Хабр!

Сегодня поговорим о том, как правильно настраивать автовакуумирование в PostgreSQL — одном из механизмов, который позволяет базе данных оставаться "в форме" и поддерживать производительность на должном уровне. Если неправильно подойти к настройке, можно столкнуться с деградацией скорости обработки запросов и внезапным ростом объема данных.

Задачи эксперимента

1) Оценить степень влияния регулярного выполнения vacuum/analyze на производительность СУБД.

2) Оценить степень влияния распухания таблицы на производительность СУБД.

От редакции: Майкл Стоунбрейкер - один из самых известных в IT мире ученых и отец-основатель Postgres. В соавторстве с Энрю Павло, недавно опубликовал большой обзор всех актуальных технологий систем управления базами данных. В этом материале — подробно обо всем, что произошло в мире баз данных за последнее время, а также прогнозы. Мы посчитали что нельзя лишать нашу аудиторию возможности ознакомиться с этим обзором, поэтому подготовили данный перевод.

В одной из предыдущих статей я описывал проблемы, которые возникают при работе с временными таблицами. Тогда я вкратце описывал, почему нам приходится их так часто использовать. В частности, одной из причин была неправильная работа планировщика запросов в PostgreSQL. Многие из проблем планировщика запросов (и не только PostgreSQL) были также описаны в статье Почему не SQL. В этой статье я покажу достаточно простой и часто используемый случай, когда планировщик ошибается, что может приводить к значительному росту потребления ресурсов. 

Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками. 

Рассмотрим простую доменную логику, в которой есть документы и их строки. Для каждой строки вводится сумма. Строки лежат в отдельной таблице и ссылаются на документ :

О том, как сделать прозрачную синхронизацию заметок Obsidian между устройствами (Desktop, Android, iOS) через GitHub:

1. Без сторонних приложений (вроде iCloud, SyncThing, Termux и пр)
2. Бесплатно
3. Бонусом — резервная копия: как самих заметок, так и истории изменений.

В результате получается полноценная замена Notion: структурированные заметки с автоматической синхронизацией между устройствами.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В первой части лекции мы узнали, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. В этой - разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.

Пару дней назад у меня, как и у многих пользователей, появилось предупреждение об уходе Notion из России. Я начал срочно искать альтернативу сервису, которым я пользовался более 5 лет.

В Notion я хранил личные задачи и заметки. Notion был базой знаний моей жизни. Он повидал бюджет на свадьбу и бюджет на переезд. Он даже повидал план ремонта! Это приложение было всегда открыто на моём компьютере.

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

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

В качестве основного средства документирования выбрана система управления проектами TRAC с подключенным плагином plantuml.

Спойлер: через iCloud

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

Соответсвенно, встал резонный вопрос — а как синхронизировать заметки между телефоном и компьютером, так еще и на разных операционных системах (iOS, MacOS и Windows в моем случае).

В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.

Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.

Кластеризация необходима для большинства СУБД уровня Enterprise. Есть много способов создать или развернуть кластер: от бесплатных до дорогих, от простых до сложных. У разных вендоров свои приоритеты: одни делают настройку кластера в пару кликов (как в MS SQL), другие фокусируются на надежности и функциональности (Oracle).

В мире СУБД на базе PostgreSQL на сторону которых всё активнее переходит российский IT, тоже есть свои кластерные инструменты и решения: как бесплатные и открытые Patroni, Stolon, pacemaker/corosync, так и проприетарные. Лидер по популярности среди открытых решений – Patroni. Сегодня я расскажу, почему настраивать кластеризацию на нем руками весело только первые пару раз. Поговорим об особенностях поддержки Patroni в Proxima DB, снижении порога входа для новичков и повторяемости конфигураций. 

Notion объявили, что уходят из России и 9 сентября блокируют аккаунты пользователей.

Пока не понятно до конца, касается ли это в том числе пользователей, которые используют бесплатный функционал.

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

Я сам долгое время пользовался Ноушеном. Первое знакомство было умопомрачительно, захватывающе. Чего только стоят мои конспекты с футбольными тактиками, где я ковертировал видео с матчей и тренировок в гифки, а потом добавлял к конспектам.

Год назад перевёл все свои заметки в Обсидиан. Причина простая: Обсидиан может гораздо больше вещей, чем Notion.

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

В продолжение серии статей об устройстве системы управления базами данных PostgreSQL (раз, два) смотрим, как ускорить выполнение запросов к базе данных с помощью индексов.

Привет, Хабр! Меня зовут Артур Титаев, я аналитик департамента проектирования и разработки IBS. Недавно наша команда занималась масштабным импортозамещением компонентов системы поддержки принятия решений для крупного российского заказчика. После переезда с Oracle и MySQL на PostgreSQL мы определили, что время выполнения SQL-запросов для показателей хозяйственно-экономической деятельности клиента в PostgreSQL заметно больше, чем время выполнения тех же запросов для тех же показателей в Oracle. Для «тяжелых» показателей разница во времени выполнения запроса могла достигать 20–30 минут. И это несмотря на то, что база данных Oracle не была проиндексированной!

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

Прочитал и посмотрел почти все статьи и видео по Obsidian, которые вышли недавно (в среднем не более 1-2 ух месяцев назад). Дал каждому источнику субъективную оценку и написал короткий комментарий.

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

Или, точнее, задача, поскольку в этом году мы попробовали другой формат: задача была всего одна, но большая. Требовалось написать SQL-запрос, играющий в крестики-нолики «пять в ряд».

Приложение Obsidian представляет из себя огромную базу ваших заметок. Одним из её плюсов является поддержка Markdown (.md).

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