В этой статье поговорим о Greenplum — СУБД, основанной на PostgreSQL. Разберём её общую архитектуру, способы хранения данных, а также перечислим проблемы, с которыми можно столкнуться в ходе эксплуатации.
Эта статья описывает реализацию 64–битных счётчиков транзакций (XID, ксидов) в СУБД Postgres Pro Enterprise, которая создана на основе свободной, опенсорсной объектно–реляционной СУБД Postgres. Она ориентирована на тех, кто имеет практический опыт в работе с СУБД Postgres Pro Enterprise, но будет интересна и тем, кто интересуется развитием СУБД Postgres, так как описывает сравнение этих двух систем. Статья также описывает устройство таблиц на диске и организацию формата хранения данных отношений.
Postrges старается быть максимально гибким в конфигурации, чтобы удовлетворить запросы как можно большего числа своих пользователей. Большинство параметров, например, таких, как: размер страницы BLCKSZ (по умолчанию 8 кБ), размер сегмента SEGSIZE (по умолчанию 1 Гб), могут быть изменены при сборке Postgres.
Хотелось бы сразу обозначить, что мы будем рассматривать 64–битный вариант сборки Postrges, в котором все параметры имеют значение по умолчанию. Также мы не будем углубляться в мультитранзакции. Для целей этой статьи будет достаточным предположения, что они в данном контексте аналогичны "обычным" транзакциям.
Мы выложили наш вариант реализации в сообщество, а также занимаемся активным продвижением его в сообществе разработчиков Postgres. Он не на 100% идентичен коду, используемому в Postgres Pro Enterprise (в частности, там ксиды всё ещё образуют кольцо), но общая идея такая же, как изложена в статье. На текущий момент патч ожидает ревью. Мы верим, что этот патч положительно скажется на удобстве использования и устойчивости Postgres, надеемся, что он будет принят сообществом в ближайшем будущем. Тем не менее по этому вопросу предстоит ещё много работы. Поэтому мы будем благодарны всем желающим и небезразличным за посильное участие в его развитии.
История создания регулярных выражений берет свое начало с 1942 года. В то время Уолтер Питтс — американский логик, работавший, в основном, в области когнитивной психологии, работал с известным физиологом Уорреном МакКаллоком. Основой их работы были труды связанные с теоретическим построением нейронных сетей. Немного позже, американский математик Стивен Клини изучал события в сетях МакКаллока-Питтса и предложил способ описания таких событий при помощи языка регулярных выражений.
Работа Клини вышла в середине 50-х годов двадцатого века. Научные труды были бы забыты, но американский программист Кен Томпсон в конце 60-х годов обнаружил, что регулярные выражения можно использовать для задания шаблонов поиска строк в длинных текстах. Смысл поиска заключается в том, что регулярное выражения преобразуется в конечный автомат, который производит поиск строк, которые должны соответствовать определенным шаблонам. Для построения конечного автомата Томпсон придумал специальный алгоритм, который сейчас носит название «построение Томпсона». Таким образом Кен Томпсон смог принести в мир стандарт для задания поисковых шаблонов.
Сами по себе, регулярные выражения есть ни что иное, как текстовый шаблон, который соответствует какому-то тексту. В трудах Джеффри Фридла пишется, что: «Регулярные выражения— это мощнейший инструмент, хорошо известный программистам. Однако он может быть полезен не только программистам, но и всем людям, работающим с кодом или простым текстом». При использовании регулярных выражений человеку придется работать с литералами и метасимволами. Это два существенно различающихся по своей сущности понятия. Литералы – это обычные символы, т.е. при записи в строках регулярного выражения они интерпретируются так, как они записаны. Примером литералов в регулярных выражениях может быть любая буквенная последовательность. В свою очередь, метасимволы интерпретируются при поиске особым образом. Примером может служить символ «*», который задает последовательность любого количества литералов.
Под занавес уходящего года предлагаю традиционно вспомнить, про какие интересные возможности и особенности работы с PostgreSQL мы рассказали в нашем блоге.
Если не видели дайджест за прошлый год — время наверстать упущенное!
Как Java разработчики, мы знакомы с концепцией сборки мусора. Наши приложения постоянно генерируют мусор, и этот мусор тщательно очищается сборщиками CMS, G1, Azul C4 и другими типами сборщиков.
Однако история не заканчивается на Java куче. На самом деле, это только начало.
В этой статье мы создадим простое Java-приложение, которое использует реляционную базу данных для пользовательских данных и твердотельные накопители (SSD) в качестве устройства хранения. Далее мы рассмотрим, как приложение генерирует мусор на уровне базы данных и SSD при выполнении логики приложения.
Примечание переводчика. В статье речь идет о Java-приложении. Поэтому название не совсем точное. Но так было в оригинале. :(
В одной из предыдущих статей я описал Push-based Outbox Pattern (шаблон исходящих сообщений на основе push с логической репликацией Postgres). Идея заключается в том, чтобы сохранить исходящее сообщение (например, событие) в той же транзакции базы данных вместе с изменением состояния. Благодаря этому мы гарантируем, что сообщение не будет потеряно, а наш бизнес-процесс будет продолжаться и станет согласованным.
Postgres может помочь и проинформировать нас, когда добавляется новое сообщение. Мы можем использовать встроенный механизм журнала упреждающей записи (WAL, Write-Ahead Log) вместе с логической репликацией.
PostgreSQL 16: Часть 3 или Коммитфест 2022-11
Вышел очередной обзор Павла Лузанова. Самое интересное из первых коммитфестов можно прочитать в предыдущих статьях серии: 2022-07 (ru / en), 2022-09 (ru / en).
Postgres-сообщество и образование
Что для вас PostgreSQL-комьюнити?
Живёт своей жизнью затея Райана Буза (Ryan Booz) - его Пятнецы (PGSQL-Phridays). На 3-м этапе этого флеш-моба ход Пэта Райта (Pat Wright). В отличие от обычных пятниц и PG-пятнец Шона Томаса, PGSQL-пятнецы случаются раз в месяц, и эта, 3-я пятнеца в 2022-м последняя. И вот вопрос: желающих приглашают ответить на вопрос: What is the PostgreSQL community to you?
В прошлой статье "Пример использования диапазонного типа данных" я на реальном примере рассмотрел, чем может быть полезен специальный тип для хранения диапазонов которые существует в PostgreSQL. В комментариях поступило предложение пойти дальше и воспользоваться типом box. Т.е. сохранить диапазон в виде объекта геометрии. Немного непривычно. Но сказано - сделано! Плюсы и минусы хранения КВС ОСАГО в виде box рассмотрю в заметке. Публикация является дополнением к указанной статье. Так же я подготовил все 4 вариант схем внутри демки с docker, поэтому примеры можно позапускать у себя. Кому ближе видео версия, то в конце заметки есть ссылка на полное видео данных публикаций на Youtube.
В связи с обострением вопросов импортозамещения многие задумываются о переходе на системы, позволяющие заменить зарубежные аналоги, или уже его начали. Мы решили поделиться с вами 7-летним опытом установки и эксплуатации системы Linux + PostgresSQL + «1C» на 300 онлайн-пользователей.
Авторы статьи:
Стрижевский Александр – начальник ИТ-отдела АО «123 авиаремонтный завод»* («123 АРЗ»)
Малышев Дмитрий – разработчик в ВЦ «Раздолье», «1С»-эксперт по технологическим вопросам
*АО «123 АРЗ» - одно из ведущих предприятий по ремонту и техническому обслуживанию транспортных самолётов военной и гражданской авиации России. Широкий спектр услуг с применением передовых технологий, тесное сотрудничество с разработчиками авиационной техники, адекватность потребительскому спросу и высокое качество ремонта – главные приоритеты предоставляемых услуг. Нам доверяют ремонт авиационной техники не только российские, но и зарубежные авиакомпании, расположенные на трёх континентах.
Начнём с опыта установки и эксплуатации системы Linux.
Сегодня использование альтернатив Microsoft не имеет каких-то нерешаемых проблем или серьёзных рисков. Комбинация Linux + PostgresSQL является хорошей платформой для информационной системы на базе программных продуктов «1С», но так было не всегда.
На сегодняшний день существует большое количество различных систем управления базами данных - СУБД, от коммерческих до открытых, от реляционных до новомодных NoSQL и аналогичных.
Одним из лидеров направления СУБД является PostgreSQL и ее различные ответвления, о некоторых из которых мы рассмотрим подробнее.
В этой статье мы начнем говорить о СУБД PostgreSQL, рассмотрим отличия редакций и некоторые особенности архитектуры, а также процесс установки. Но начнем мы с небольшого ликбеза для того, чтобы читатели плохо знакомые с терминологией баз данных могли быстро войти в курс дела.
Итак, схемой мы будем называть логическое объединение таблиц в базе данных, а сама БД это физическое объединение таблиц. Индекс - отношение, которое содержит данные, полученные из таблицы или материализованного представления. Его внутренняя структура поддерживает быстрое извлечение и доступ к исходным данным.
Еще один важный термин, это первичный ключ - частный случай ограничения уникальности, определенной для таблицы или другого отношения, которое также гарантирует, что все атрибуты в первичном ключе не имеют нулевых значений. Как следует из названия, для каждой таблицы может быть только один первичный ключ, хотя возможно иметь несколько уникальных ограничений, которые также не имеют атрибутов, поддерживающих значение null.
Ну и наконец, наверное, самый распространенный термин - транзакция это комбинация команд, которые должны действовать как единая атомарная команда. То есть, все они завершаются успешно или завершаются неудачно как единое целое, и их эффекты не видны другим сеансам до завершения транзакции, и, возможно, даже позже, в зависимости от уровня изоляции. Соответственно, если выполнение хотя бы одной команды внутри транзакции завершилось ошибкой - вся транзакция завершится ошибкой.
Привет! Я Андрей Непряхин, руководитель направления QA в AGIMA. Вот уже год как мы работаем над мобильным приложением платформы Финуслуги, созданной Московской биржей. Это первая и единственная платформа личных финансов в России. За этот год мы освоили целый ряд новых технологий, поняли, как обеспечивать качество крупного финтех-проекта, но главное — научились работать в огромной команде. Как мы сделали процесс тестирования измеримым, а взаимодействие с разработчиками прозрачным — расскажу в этой статье.
Возможность горизонтального масштабирования это одно из важнейших нефункциональных требований индустрии в последнее время. Рост бизнеса со стороны IT выглядит чаще всего как рост нагрузки и цены отказа системы. Нам всем хочется создавать такие приложения, которые будут одинаково быстро и стабильно работать как с сотней, так и с сотней тысяч клиентов. Для этого необходимо еще на стадии проектирования закладывать потенциал для масштабирования, одним из способов которого является шардирование.
Мы на пальцах рассмотрим что такое шардирование, как оно помогает в масштабировании и даже рассмотрим тот самый этап «роста».
Продолжаем изучать исходный код PostgreSQL
В этот раз исследуем главный цикл сервера:
- Принятие входящих подключений;
- Проверка окружения;
- Обработка упавших воркеров.
Доброго времени суток. Решил поделиться опытом апгрейда через репликацию. Порыскав немного нашел написанного не мало на просторах Хабра, теории и практики, но в моем случае есть небольшое отличие ну и плюс актуальные версии, в общем думаю лишним не будет, а если кому-то даже частично будет полезно то вообще блеск. Итак приступим …
Недолго рассмотрев сложившуюся ситуацию предложил ребятам метод апгрейда через репликацию, для них никаких сложностей лишь один раз перезапустить приложение с изменением имени базы в коннекторе. Это позволит за раз сделать все что необходимо с учетом всех условий. Объяснил что разработчикам нужно наверно даже больше уделить внимание тестированию того что может выстрелить в новой версии самого 14 PosgreSQL - возможно изменение синтаксиса SQL, или свежий баг на лини сопряжения «база - ОС», или особенность драйвера, в общем нужно протестировать работу всего функционала и ухо держать востро, ну а я сделаю все максимально гладко со своей стороны.
Соответственно на тесте постарался процедуру обкатать и проиграть в различных вариантах и ситуациях. Да и конечно было ограничение - на сервере не было дискового пространства на 8 баз суммарно, разве что на 3 хватило. Короче есть ограничение по месту. Да и сразу скажу, что в моей базе партиций не было, поэтому стоит это учесть и внести изменения в скрипты, если требуется !
Задача у команды стояла такая - нужно разделить одну базу на 8 отдельных баз по внутреннему индикатору- ID проекта (в процессе работы проект разделился на признаку и все жило в пределах одной базы). Так же у меня была своя задача апгрейда с 13 на 14 версию PostgreSQL. Была просьба от команды сделать это с минимальный простоем и совсем хорошо если за один присест, а не разбивая частями по 2-3 базы за итерацию.
Достаточно часто при проектировании схемы БД возникает задача сохранить по основной сущности некоторый набор простых второстепенных данных.
Например, это могут быть ФИО сотрудников, принимающих участие во встрече, список приложенных к сообщению файлов или перечень отгружаемых по документу позиций.
Во всех этих случаях мы заранее понимаем, что список этот меняется редко и ни индексировать эти данные, ни искать по ним, ни извлекать отдельно от основной сущности (встречи, сообщения или документа), мы не захотим.
Давайте посмотрим, какие варианты хранения таких данных мы можем использовать в PostgreSQL, и какой из них окажется в разы более эффективным.
Некоторые базы данных такие, как Microsoft SQL Server, IBM Db2, а также PostgreSQL начиная с 11 версии – предлагают прибегнуть к оператору include для генерации индекса. Представление данного функционала в PostgreSQL (исходная статья вышла 30.04.2019) послужило поводом для этого объёмного рассуждения о работе с оператором include.
Содержание:
1) Напоминание: btree-индексы
2) Напоминание: Index-only сканирование
3) Оператор include
4) Фильтрация по полям в include
5) Уникальные индексы при использовании include
6) Сравнение
7) PostgreSQL: Никакой фильтрации до проверки области видимости
Здравствуйте, читатели хабра! Читайте в этой статье - развенчание мифов об асинхронном программировании в Python! Действительно ли асинхронная модель - более производительная? И как обстоят дела с драйверами баз данных?
На картинке - скриншот бенчмарков от авторов драйвера asyncpg. Как Вы можете догадаться, автор этой статьи с ними не согласен.
Некоторые читатели знают из моих предыдущих статей о моих (вполне успешных!) попытках сделать асинхронную версию django. Я решил прекратить работу над ней - столько труда напрасно! Читайте - и не делайте так.
Стандарту WSGI 19 лет (c хвостиком). Выясняем, есть ли ещё куда развиваться приложениям с блокирующим вводом-выводом в 2022.
Представим, что у вас есть некоторая табличка статистики, куда вы периодически скидываете таймстамп последнего "текущего" состояния в паре координат - например, (ID организации, ID сотрудника).
Как больно наступить на грабли в совсем простом, казалось бы, запросе?
