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

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

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

Для тех, кто не хочет тратить время, сразу расскажу про полученные выводы. БД PostgreSQL размещенная на btrfs c опцией compress=lzo, сокращает объем бд в двое (в сравнении с любыми ФС без сжатия) и при использовании многопоточного, последовательного чтения, значительно сокращает нагрузку на дисковую подсистему.

В продолжение статьи о теории и практике миграции хранилищ данных на PostgreSQL, мы поговорим о проблемах, с которыми вы можете столкнуться при переезде с распространенной СУБД MySQL. Дабы не утомлять всех лишней риторикой, сегодняшний рассказ будет более тезисный и проблемно-ориентированный.

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

Именно поэтому в предыдущей статье я рекомендовал не тратить время на поиск серебряной пули и написать что-нибудь свое “на коленке”, что действительно работает. Данная статья призвана облегчить написание такого инструмента, указывая на потенциальные изъяны, в наличии которых вы может сравнительно быстро убедиться.

Перейдем к делу.

Цель статьи

Документирование получения системы кросс-компиляции под Linux для Windows x32/x64/static/shared и сборка последней на момент описания Qt 5.4.1 в лайт-версии (для указанных четырех целей). Для себя, глубоко-обожаемого, ну и для пользы обществу.

Назначение

Многие разработчики приходят к выводу, что использование *nix (в частности Linux) более предпочтительно для разработки приложений, используя фрэймворк Qt. И тому есть причины. Qt изначально ориентирована на *nix инструментарий, типа autotool, make, perl… И второй момент, под никсами есть прекрасный инструмент — valgrind, под виндой порта пока его не видел. Ну и последняя причина: просто удобно иметь набор инструментария для создания приложений под различные целевые платформы — в одном месте.

Почему лайт-версия Qt5

Фрэймворк-Qt имеет модульную структуру, но, увы, не совсем совершенную. Некоторые зависимости от внешних библиотек «вешаются» не на модуль, требующий эти библиотеки, а на Qt5Core. Иными словами, нужна вам эта библиотека, или нет — вынь да положЪ в дистрибутив. Пример тому «монстрик» — библиотека ICU. Весит она почти 25 метров! Зависимость вешается, как я упоминал выше, на Qt5Core… а требует ее модуль Qt5WebKit (который по сути в 99% случаев не используется, по крайней мере мной). Что делаем? Вырезаем и отрезаем. Хотите получить фулл-версию Qt5? Об этом упомяну в заключении. Поехали.

Ранее я писал, как включить поддержку 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-лицензиям, позволяющей делать с ним что угодно — даже продавать от своего имени. Поэтому нет препятствий в создании на базе постгреса коммерческих СУБД и прикладных систем, и этим многие пользуются. Это, в свою очередь, дает возможность участвовать в разработке большему количеству людей, и активнее подпитываться новыми идеями. На страницах данного поста мы расскажем о том, как возникла и развивалась эта СУБД, каковы её сильные и слабые стороны, в том числе с точки зрения широкого распространения.

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

• из 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;

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

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

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

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

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

Для тех, кто использует PostgreSQL, есть две новости. Сначала та, что про исправление проблем. Все активные ветки PostgreSQL обновились: 9.3.5, 9.2.9, 9.1.14, 9.0.18 и 8.4.22.

В ветке 8.4.* это заключительное обновление, данная ветка более поддерживаться не будет (если используете, запланируйте апгрейд!)

Самое важное в выпущенных обновлениях:

В PostgreSQL начиная с версии 9.4 появилась поддержка больших страниц. Это очень хорошая новость, с большими страницами я познакомился когда работал с виртуализацией. Коротко о чем же речь. В ОС Linux работа с памятью основывается на обращении к страницам размер которых равен 4kB (на самом деле зависит от платформы, проверить можно через getconf PAGE_SIZE), так вот когда объем памяти переваливает за несколько десятков, а то и сотни гигабайт управлять ею становится сложнее, увеличиваются накладные расходы на адресацию памяти и поддержание страничных таблиц. Для облегчения жизни и были придуманы большие страницы, размер которых может быть 2MB а то и 1GB. За счет использования больших страниц можно получить ощутимый прирост скорости работы и увеличение отзывчивости в приложениях которые активно работают с памятью. Как я уже отметил, впервые я столкнулся с большими страницами при работе с виртуализацией, в частности с KVM. Проведенные в свое время тесты показали что прирост производительности виртуальных машин составил от 7 до 10% (измерялось все это дело синтетическими тестами различных сервисов типа redis/memcache/postgres/etc внутри виртуальных машин). Теперь это появилось в PostgreSQL.

При разработке ПО часто возникают интересные задачи. Одна из таких: работа с гео-координатами пользователей. Если вашим сервисом пользуются миллионы пользователей и запросы к РСУБД происходят часто, то выбор алгоритма играет важную роль. О том как оптимально обрабатывать большое количество запросов и искать ближайшие гео-позиции рассказано под катом.

Введение в PostgreSQL BDR

PostgreSQL это не только стабильная и надежная СУБД но и плюс ко всем это динамично развивающийся продукт, в котором от релиза к релизу появляются самые разные прорывные вещи. В свое время одной из таких технологий была потоковая репликация. Это высокопроизводительная репликация которая позволяет очень легко и дешево масштабировать базу данных на чтение. Используя ее можно создавать надежные конфигурации распределяя нагрузку на чтение между узлами. Однако как я написал выше, продукт развивается, и сегодня в статье речь пойдет о новой технологии BDR (Bi-Directional Replication).

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

Незаметно промелькнул пост о юбилейном GSoC 2014, и наш проект PostgreSQL снова оказался в числе участников. Надо сказать, что если на многие другие проекты есть большой конкурс, то мы похвастаться этим не можем. Будь тому виной высокий порог вхождения и сложность проекта или недостаточно активно проводимая кампания, но нам приходилось даже возвращать неиспользованные slot'ы, так как на них не нашлось достойных претендентов. Как mentor, я не могу выдавать информацию о числе и составе заявок, скажу только, что ситуация меня печалит ещё больше, чем в прошлые годы.

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

• Количеством транзакций порядка 5'000 — 10'000 в секунду
• Объемом примерно в 100ГБ (который бодро растёт)
• Примерно равным количеством операций на чтение/запись
• Преимущественно мелкими транзакциями

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

Я опишу некоторые проблемы, с которыми мы сталкиваемся, и применённые решения. Если кто-то сочтёт это полезным — ради Бога. Если кто-то поправит — я буду только рад обнаружить уязвимость в используемых подходах и увеличить эффективность работы БД. Описанное может быть применено без вмешательства в логику приложения, исключительно путём модификации схемы БД.

Год заканчивается, а я давно не писал заметок о проверке открытых проектов. Мне уже неоднократно предлагали проверить проект PostgreSQL Database Management System. Этим я и занялся. К сожалению, грандиозной и интересной статьи не получится. Я заметил только несколько типовых ошибок. Так что в этот раз получилась совсем небольшая статья.