PostgreSQL *

В последние месяцы проблематика миграции работающих систем на open-source решения для хранения данных захватила умы отечественных разработчиков. Особой популярностью в роли целевой платформы пользуется PostgreSQL. Причин тому можно назвать несколько:

1. Пребывающая у всех на слуху политика импортозамещения, внедряемая правительством;
2. Популяризация PostgreSQL силами энтузиастов и развитие российского сообщества благодаря таким мероприятиям как PG Day и PGConf;
3. Расширение функциональных возможностей PostgreSQL, позволяющих разработчикам строить гибкие и «schema-less» приложения, не теряя при этом всех преимуществ СУБД, таких как честные транзакции, отказоустойчивость, возможности масштабирования и др.

Нам удалось убедиться в эффективности PostgreSQL несколько лет назад. Внедрение СУБД позволило ликвидировать серьезный технологический кризис на одном из крупных проектов компании. Подробный рассказ об этой success story состоялся на PG Day’14 Russia, прошедшем в прошлом году в Санкт-Петербурге. С тех пор нам довелось попробовать базу данных для решения широкого спектра проблем.

10-11 апреля в Ульяновске состоится крупнейшая в регионах России IT-конференция «Стачка». Coub ходил на Стачку в прошлом году, не смог пропустить ее и в этом. Мы не только будем на ней присутствовать, но и привезем с собой несколько докладов.

Ранее я писал, как включить поддержку jsonb в postgres/psycopg2. Сегодня экспериментировал с тем, как запрашивать данные в колонках типа JSON.
На эту тему есть документация, но мне было не совсем понятно, как работают различные операции:

CREATE TABLE json_test (
  id serial primary key,
  data jsonb
);

INSERT INTO json_test (data) VALUES 
  ('{}'),
  ('{"a": 1}'),
  ('{"a": 2, "b": ["c", "d"]}'),
  ('{"a": 1, "b": {"c": "d", "e": true}}'),
  ('{"b": 2}');

Наш стартап Olery был основан почти 5 лет назад. Мы начали с единственного продукта, Olery Reputation, который был создан агентством, занимавшимся разработкой на Ruby. Всё это выросло в набор различных продуктов. Сегодня у нас есть ещё Olery Feedback, API для Hotel Review Data, виджеты для вставки на сайты и многое другое.

Всего у нас работает 25 приложений (все на Ruby) – некоторые из них в вебе (Rails или Sinatra), но в основном это фоновые приложения для обработки данных.

Хотя нам есть, чем гордиться, есть у нас одна проблема, которая всё время висела где-то в фоне – база данных. Изначально мы использовали MySQL для важных данных (пользователи, контракты, и т.д.) и MongoDB для хранения обзоров и других данных, которые легко можно было бы восстановить в случае утери. Сначала всё работало неплохо, но по мере роста мы начали испытывать проблемы, в особенности с MongoDB. Некоторые из них возникали в сфере взаимодействия БД с приложениями, некоторые – непосредственно у самой БД.

К примеру, в какой-то момент нам надо было удалить миллион документов из MongoDB, а позже вставить. В результате работа базы застопорилась на несколько часов. Потом нам пришлось запускать repairDatabase. И сама починка тоже заняла несколько часов.

Так уж случилось, что последнее время приходилось заниматься оптимизацией и масштабированием различных систем. Одной из задач было масштабирование PostgreSQL. Как обычно происходит оптимизация БД? Наверное, в первую очередь смотрят на то, как правильно выбрать оптимальные настройки для работы и какие индексы можно создать. Если обойтись малой кровью не вышло, переходят к наращиванию мощностей сервера, выносу файлов журнала на отдельный диск, балансировке нагрузки, разбиению таблиц на партиции и к всякого рода рефакторингу и перепроектированию модели. И вот уже все идеально настроено, но наступает момент, когда всех этих телодвижения оказывается недостаточно. Что делать дальше? Горизонтальное масштабирование и шардинг данных.

Так уж случилось, что с Oracle организация наша работает давно и плотно. Сам я познакомился с Oracle Database ещё во времена 6-ой версии и, с тех пор, какого либо дискомфорта не испытывал. Всё испортили рыночные отношения. С недавних пор, мы начали замечать, что Заказчик гораздо благосклоннее смотрит на наши проекты если в них используются бесплатные СУБД. О портации одного из таких проектов и будет мой рассказ... 

В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.

С 6 по 7 февраля в бизнес-центре Digital October в Москве пройдёт конференция PGCONF.RUSSIA 2015, одним из организаторов которой я являюсь. PostgreSQL — одна из наиболее перспективных современных свободно распространяемых СУБД, активно развивающаяся и во многих случаях уже не уступающая флагману коммерческих СУБД Oracle, а в чем-то и превосходящая его. При этом что Postgres распространяется по очень свободной лицензии, близкой к BSD и MIT-лицензиям, позволяющей делать с ним что угодно — даже продавать от своего имени. Поэтому нет препятствий в создании на базе постгреса коммерческих СУБД и прикладных систем, и этим многие пользуются. Это, в свою очередь, дает возможность участвовать в разработке большему количеству людей, и активнее подпитываться новыми идеями. На страницах данного поста мы расскажем о том, как возникла и развивалась эта СУБД, каковы её сильные и слабые стороны, в том числе с точки зрения широкого распространения.

В одном из проектов, в которых я учавствовал, возникла задача определения временной зоны по текущей геолокации пользователя. На backend приходила запись, создаваемая пользователем с помощью смартфона. Время приходило не в UTC, но в параметрах содержались координаты.
Конечно, существуют готовые сервисы (например The Google Time Zone), но все они платные или сильно ограничены по функционалу. Вот я и решил написать собственный сервис.

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

До девятой версии в PostgreSQL для создания «теплого» резервного сервера использовался WAL archiving. В версии 9.0 появилась потоковая репликация с возможностью создания «горячего» read-only сервера. В следующей версии PostgreSQL 9.4 появится новый функционал для создания потоковой репликации под названием replication slots.

Для моего проекта понадобилось построить пешеходные маршруты и считать их длину.
Я решил эту задачу с помощью pgrouting, который в свою очередь опирается на postgis.
Postgis — это расширение к Postgresql, реализующее стандарт OpenGis.
В данном расширении содержится обширный функционал для работы с пространственными данными.
Это позволяет писать интересные приложения.
В частности, OpenStreetMap использует postgis для отображения своих карт.
Постараюсь рассказать о том, как выглядят в postgis, импортированные osm карты.

При работе над одним проектом возникла необходимость написать некое подобие тестовой системы. Задача формулировалась примерно так:

• из N записей в базе необходимо выбрать m (3-5) случайных строк в серии из k выборок (преимущественно k=2).

А теперь то же самое человеческим языком: из таблицы нужно два раза выбрать по 3-5 случайных записей. При этом не должно быть дубликатов и выборка должна происходить случайным образом.

Первое, что приходит в голову:

 SELECT *
  FROM data_set
  WHERE id NOT IN (1,2,3,4, 5)
  ORDER BY random()
  LIMIT 5;

И это даже будет работать. Вот только цена такого решения…

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

Приветствую, Хабр!

В этой статье я расскажу о том, как мы боролись с проблемой быстрого роста размера таблиц в базе данных в высоконагруженной EMS системе. Свою изюминку добавляет то, что проблема решалась для двух баз данных: Oracle и Postgre. Заинтересовавшихся прошу под кат.

Доброго времени суток! Не за горами релиз PostgreSQL 9.4 и нелишним будет пройтись по некоторым новшествам, привнесённым в этой версии. В статье будут рассмотрены (по большей части, касаемые клиентской модели):

• изменения в автообновляемых представлениях
• изменение в материализированных представлениях
• команда ALTER SYSTEM для установки конфигурационных параметров
• опция WITH ORDINALITY для функций, возращающих набор строк
• новые функции для агрегированных данных
• улучшения для индексов GIN и GiST
• улучшенный вывод команды EXPLAIN
• разогрев кэша
• триггеры для внешних таблиц
• изменения для json и новый тип данных jsonb

Привет хабр! В этой статье не будет глубокого анализа json типа в PostgreSQL или очередных бесполезных попыток сравнить данную возможность PostgreSQL с NoSQL базами данных типа MongoDB. Я просто расскажу про то, как использовать Hibernate и PostgreSQL json. Думаю кому-нибудь это может оказаться полезно.

Объект внутри сущности

Предположим у вас есть реляционная модель данных. Вполне может возникнуть ситуация, что для некоторых из сущностей необходимо хранить какой либо объект(документ, если хотите). Конечно можно расширить для этого объекта модель данных одной(а может и несколькими) сущностью, или просто хранить этот объект в виде массива байт. Но у PostgreSQL уже достаточно давно появился тип данных json способный хранить json объект в соответствии с RFC 4627. Стало интересно, как это можно использовать, и какие возможности это может дать. При первом обращении к google я нашел несколько неструктурированных постов и Q&A которые что-то объясняли, но не давали полной картины. Немного потыкавшись и разобравшись что к чему, я пришел к выводу что использование этих полей очень удобно, и решил создать маленькую библиотечку, которая упростит использование json типов. Ниже я расскажу как ей пользоваться, ну и еще немного сравнения с первыми приходящими на ум альтернативами.

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

Первая книга уже довольно давно существует, и некоторым из Вас может быть известна. «Работа с PostgreSQL: настройка и масштабирование» (четвертое издание) рассказывает, что такое PostgreSQL база данных и как много полезного можно делать с помощью неё. В книге обновились разделы про репликацию (новые Londiste, Bucardo, BDR), добавлены новые расширения и примеры использования их. Также сделана чистка разделов с правкой на актуальные версии базы данных.

PostgreSQL это современная, динамично развивающаяся СУБД с очень большим набором возможностей которые позволяют решать самый широкий спектр задач. Использование PostgreSQL как правило относится к очень критичному сегменту ИТ инфраструктуры который связан с обработкой и хранением данных. Учитывая особое место СУБД в инфраструктуре и степень критичности возложенных на нее задач, возникает вопрос мониторинга и надлежащего контроля за работой СУБД. В этом плане PostgreSQL обладает широкими внутренними средствами сбора и хранения статистики. Собираемая статистика позволяет получить довольно подробную картину о том что происходит под капотом в процессе функционирования СУБД. Эта статистика хранится в специальных системных таблицах-представлениях и постоянно обновляется. Выполняя обычные SQL запросы в эти таблицы можно получать разнообразные данные о базах, таблицах, индексах и других подсистемах СУБД.
Ниже я описываю способ и средства для мониторинга PostgreSQL в системе мониторинга Zabbix. Мне нравится эта система мониторинга поскольку предоставляет широкие возможности для реализации самого кастомного мониторинга самых разных систем и процессов.

Много информации в сети по Zabbix, много и шаблонов самописных, хочу представить на суд аудитории свои модификации.
Zabbix — очень удобный и гибкий инструмент мониторинга. Хочешь — сотню мониторь, хочешь — тысячу станций, а не хочешь — следи за одним сервером, снимай сливки во всех разрезах. Буду не против отдать на github, если кто коллекционирует схожие.



Так случилось, что решили мы выложить на хостинг базу данных с оберткой из php-fpm+nginx. В качестве БД — postgres. Мысли собирать данные о работе машины были еще до покупки хостинга — это нужно, это полезно! Волшебным пенделем к внедрению системы послужили тормоза жесткого диска на нашей VDS станции — в начале скриптом каждую минуту кладем время и замерянную скорость в файл, а потом в экселе строим графики, сравниваем как было/стало, снимаем количественную статистику. И это всего один параметр! А вдруг виноват не VDS, а наши приложения, которые на нем работают. Вобщем, мониторить надо много, мониторить надо удобно!