Хотели бы свой дистанционно управляемый танк? В этой статье я расскажу про общие принципы танкостроения из доступных материалов.
Иван Панченко @x-wao
Пользователь
Приглашаем на PGConf.Russia 2018
4 мин
Очень скоро, а именно 5-7 февраля 2018 г. в Москве будет проводиться одна из основных мировых конференций по СУБД PostgreSQL — PGConf.Russia. В этой статье мы анонсируем основные доклады конференции, и расскажем об особенностях её проведения в этом году.
Разбор задач викторины Postgres Pro на Highload++ 2017
6 мин
На Higload++ 2017 года в Сколково наша компания Postgres Professional снова провела викторину с традиционной раздачей ништяков, в качестве которых выступили билеты на февральский PgConf.Russia 2018.
В этой статье разбираются вопросы викторины.
В этой статье разбираются вопросы викторины.
Осенний Postgres в Райффайзенбанке
1 мин
В понедельник, 13 ноября приглашаем вас в офис Райффайзенбанка, где пройдет очередной PostgreSQL MeetUp. Мероприятие организовано совместно с компанией Postgres Professional.
Мы долго думали, как назвать наше событие, и решили дать ему романтичное название «Осенний Postgres», хотя, скорее всего, осени будет мало и, может, выпадет снег.
Материалы с VLDB, конференции о будущем баз данных
4 мин
Конференция VLDB (Very Large Data Bases, www.vldb.org), как несложно понять из названия, посвящена базам данных. Очень большим базам данных. О чем её название не говорит, так это о том, что там регулярно выступают очень серьезные люди. Много ли вы знаете конференций, где почти каждый год докладывается Майкл Стоунбрекер (Michael Stonebraker, создатель Vertica, VoltDB, PostgreSQL, SciDB)? Не думали ли вы, что было бы здорово узнать, над чем такие люди работают сейчас, чтобы через несколько лет, когда новая база разорвет рынок, не грызть локти?
VLDB — именно та конференция, которую вам нужно посетить, если вы думаете о будущем.
Она вам не очень поможет, если вы выбираете из существующих баз. Там есть небольшая доля industrial докладов (Microsoft, Oracle, Teradata, SAP Hana, Exadata, Tableau (!)), но самое интересное — это исследовательские доклады от университетов. Xотя очень быстро обнаруживается, что в командах университетов есть один-два человека, работающих на Google, Facebook, Alibaba… или перешедших туда сразу после подачи статьи.
Надеюсь, мне удалось вас базово заинтересовать, а теперь давайте пройдемся, собственно, по докладам.
PgConf.Russia 2017 — приглашаем на мартовскую конференцию в Москве
7 мин
В марте в Москве в третий раз пройдет международная конференция PgConf.Russia. В первый раз конференция собрала около 460 участников, во второй — около 600, на те моменты времени это было мировым рекордом для мероприятий, посвященных PostgreSQL, что наряду с высокой информационной насыщенностью программы подтверждает огромный интерес к этой СУБД в России.
Интеграция PostgreSQL с другими СУБД: делаем запросы в MySQL
6 мин
Нередко бывает так, что в большом проекте в силу тех или иных причин — зачастую исторических, хотя бывает по-всякому — его части могут использовать различные СУБД для хранения и поиска критически важных данных. В числе прочего, этому разнообразию способствует конкуренция и развитие технологий, но, так или иначе, взаимодействие между СУБД описывает стандарт SQL/MED 2003 (Management of External Data), который вводит определение Foreign Data Wrappers (FDW) и Datalink.
Первая часть стандарта предлагает средства для чтения данных как набора реляционных таблиц под управлением одного или нескольких внешних источников; FDW также может представлять возможность использовать SQL-интерфейс для доступа к не SQL данным, таким, как файлы или, например, список писем в почтовом ящике. Вторая часть, Datalink, позволяет управлять удаленным SQL-сервером.
Эти две части были реализованы еще в PostgreSQL 9.1 и называются FDW и dblink соответственно. FDW в PostgreSQL сделан максимально гибко, что позволяет разрабатывать wrapper'ы для большого количества внешних источников. В настоящее время мне известны такие FDW, как PostgreSQL, Oracle, SQL Server, MySQL, Cassandra, Redis, RethinkDB, Ldap, а также FDW к файлам типа CSV, JSON, XML и т.п.
В нашей статье мы поговорим о том, как настроить подключение PostgreSQL к MySQL и эффективно выполнять получающиеся запросы.
PostgreSQL на русском всерьёз и надолго
5 мин
Свершилось!
Наша компания официально завершила перевод документации PostgreSQL текущей версии на русский язык и в этой публикации мы хотим поведать, как это было. Мы также хотели бы рассказать о пути, который мы прошли для достижения этой цели (и какие направления мы перепробовали), но это, пожалуй, тема для отдельной статьи.
Перевод самого PostgreSQL на русский язык начался в далёком 2001 году, тогда вышла только версия postgresql 7.1, и в самом postgresql усилиями в том числе и наших разработчиков только появлялась возможность локализации сообщений (см. тут). Впервые перевод сообщений на русский был включён в версию 7.2, вместе с переводами на французский, немецкий, шведский, китайский и чешский.
Становимся контрибьютером в PostgreSQL
9 мин
Туториал
В этой статье я хотел бы рассказать о том, как выглядит процесс разработки PostgreSQL глазами одного из контрибьютеров в этот самый PostgreSQL. Заниматься разработкой этой СУБД я начал в декабре 2015 года, когда устроился работать в компанию Postgres Professional. То есть, не так уж давно. А значит, еще свежи воспоминания о моментах, которые поначалу казались мне не вполне очевидными. Хотелось бы их законспектировать, чтобы новым людям, приходящим в нашу команду, а также всем тем, кто желает попробовать себя в роли разработчика открытой реляционной СУБД, было легче. Я расскажу о том, как выглядит процесс разработки PostgreSQL, какие инструменты я использую в своей повседневной работе, как следует оформлять патчи, и так далее. Заинтересовавшихся прошу проследовать под кат.PostgreSQL в Azure. Часть 1
7 мин
Туториал
Этой статьей мы начинаем цикл заметок об использовании PostgreSQL в Microsoft Azure.
Первая статья будет об установке и настройке кластера PostgreSQL:
- Знакомство с ресурсами Azure
- Управление через azure cli
- Выбор подходящего хранилища
- Сборка классической связки ведущий-ведомый в одной группе доступности
Опасный target="_blank"
2 мин
Большинство создают внешние ссылки через target="_blank" и не знают одного интересного нюанса — страница, на которую мы попадем таким образом, получит частичный контроль над ссылающейся на нее страницей через js свойство window.opener.
Через window.opener.location мы сможем сделать редирект на, к примеру, фишинговую страницу. Это своего рода tabnabbing, только более продвинутый. Так как жертва меньше всего ожидает подмены страницы, в открытой ранее, доверенной вкладке браузера.
Через window.opener.location мы сможем сделать редирект на, к примеру, фишинговую страницу. Это своего рода tabnabbing, только более продвинутый. Так как жертва меньше всего ожидает подмены страницы, в открытой ранее, доверенной вкладке браузера.
Курс «Hacking PostgreSQL» — уже скоро
4 мин
Привет всем!
Сегодня я рада анонсировать курс “Hacking PostgreSQL” из 16 занятий, на которых мы вместе будем исследовать особенности архитектуры открытой СУБД и вносить изменения на уровне исходного кода. Курс будет проходить в Москве, на площадке компании Postgres Professional. Начало курса запланировано на февраль 2016 года. Лекции начнутся сразу после февральской конференции pgconf.ru и будут проходить один раз в неделю вечером. Видеозаписи и материалы лекций мы будем выкладывать по мере обработки.
Курс собран из личного опыта разработчиков нашей компании, материалов с конференций, статей и вдумчивого чтения документации и исходников. В первую очередь он адресован начинающим разработчикам ядра PostgreSQL. Но он будет интересен и DBA, которым иногда приходится влезать в код, и просто всем неравнодушным к архитектуре большой системы, желающим узнать “А как это работает на самом деле?”
Приглашаем на PGConf 2016 — российскую PostgreSQL конференцию
4 мин
3-5 февраля 2016 г. в Москве на площадке Известия-холл (Пушкинская площадь, 5) пройдет международная российская конференция PgConf.Russia 2016. Конференцию организует российское сообщество PostgreSQL при поддержке спонсоров. Генеральный партнер PGConf.RU 2016 — компания Postgres Professional, золотым партнером стала компания Avito.
Эта конференция организуется в Москве уже второй раз. В феврале 2015 г. PGConf.RU собрала 460 участников, став крупнейшим в мире форумом, посвященным PostgreSQL.
Основные темы конференции:
Эта конференция организуется в Москве уже второй раз. В феврале 2015 г. PGConf.RU собрала 460 участников, став крупнейшим в мире форумом, посвященным PostgreSQL.
Основные темы конференции:
- Масштабируемость, производительность, безопасность PostgreSQL.
- Разработка ядра PostgreSQL. Внутреннее устройство. Текущие и будущие проекты.
- Живой опыт практического использования PostgreSQL в России и за рубежом. Внедрение, миграция, разработка приложений. Доклады «с полей».
- Кластер. Отказоустойчивые и масштабируемые системы на базе PostgreSQL
- PostgreSQL в России. Российское сообщество. Образование. PostgreSQL в задачах импортозамещения и достижения технологической независимости.
PostgreSQL на многоядерных серверах Power 8
13 мин
Аннотация
При помощи московского представительства компании IBM мы провели тестирование производительности последних версий СУБД PostgreSQL на серверах Power8, изучили масштабируемость зависимость производительности от количества одновременных запросов, нашли узкие места ограничивающие производительность, предложили новые технические решения и добились рекордной производительности.
Введение
В ряде задач практически неограниченного масштабирования по объему обрабатываемых транзакций можно достичь, используя распределённые системы, в которых тем или иным способом поток транзакций распределяется на большое количество серверов. Такое масштабирование часто называют “горизонтальным”. Однако, универсального распределенного решения не существует, кроме того, распределённость имеет свою цену. Архитектура системы должна заранее проектироваться как распределённая. Распределенные системы менее гибки, чем монолитные, к тому же они сложнее в эксплуатации и требуют более высокой квалификации персонала. Одни задачи легче поддаются распараллеливанию, другие — сложнее. Поэтому спрос на высокопроизводительные монолитные системы существует, и достижение возможно лучших результатов по производительности в рамках одного сервера было и остается важной задачей. Это часто называют “вертикальным масштабированием”.
Сущность проблем, возникающих при параллельной обработке большого количества транзакций в монолитных и распределенных системах, одинакова — это конкуренция между транзакциями за доступ к одним и тем же ресурсам. Говоря просто, отдельные процессы работают параллельно и независимо до тех пор, пока не выстраиваются в очередь к какому-либо общему ресурсу (а это может быть как аппаратный ресурс, так и элемент информации, хранящийся в базе данных) и не начинают ожидать друг друга.
Для решения таких проблем существуют механизмы управления доступом к ресурсам — использование блокировок, а также пригодные в некоторых случаях неблокирующие (lock-free) подходы. Рост производительности этих механизмов, а также детализация блокировок дает возможность снизить издержки, связанные с одновременным (конкурентным) доступом.
При этом, если в распределённых системах узким местом оказывается, как правило, сеть, то в монолитных системах, близких к пиковой производительности, её рост ограничивается именно упомянутыми механизмами управления одновременным доступом.
Календарь для JIRA с открытым исходным кодом
3 мин
Здравствуйте, дорогие хабражители! Сегодня мы бы хотели рассказать о календаре, который используем в JIRA. Не так давно мы обновили его, а так как статьи о нем никогда и не было, то решили написать о нем в целом, а не только об изменениях. Подробности под катом.
А вот про Sphinx 3.0
6 мин
Вот вы там все сидите и ничего не знаете, а мы, тем временем, пилим помаленьку мега-релиз поискового движка Sphinx за номером 3.0. Грядет ряд больших переделок. Часть из них, как полагается, ещё даже как следует не начата. Однако большая часть уже скорее готова, чем нет. А отдельно взятые изменения даже протекли в публичную ветку 2.3. Так что, пожалуй, настало время вкратце начинать рассказывать, чего ожидать в светлом будущем: надеюсь, не столь отдалённом. Кому интересно почитать, все под кат; кому послушать, приходите на meetup в эту субботу. Если совсем вкратце, то: прощай, концепция дополняющего основную базу движка; привет, хранилище документов, тотальный RT, репликация, REST и ряд других известных ключевых слов.
Состоялась встреча по продуктам Atlassian в Москве
4 мин
21 апреля мы организовали в Mail.Ru Group мероприятие для обмена опытом использования JIRA и других продуктов Atlassian — Moscow Atlassian Meetup.
Событие было запланировано на 19 часов, но посетители начали собираться уже за полчаса до начала. В ожидании докладов кто-то подключался к Wi-Fi, а кто-то наливал себе кофе. Когда все собрались, зал был полон — на встрече было более 100 человек, еще 200 наблюдали за происходящим с помощью онлайн-трансляции. В этом посте я хочу опубликовать видеозаписи и слайды докладов, а также подробнее рассказать о самих докладах.
Автоматизация работы редакции контентных проектов
Первый доклад на конференции был мой. Я рассказывал о том, каким образом с помощью JIRA и разработанного нами плагина удалось автоматизировать часть рутинной работы редакции.
Редакция — это люди, которые обеспечивают наши контентные проекты (Леди Mail.Ru, Hi-Tech Mail.Ru и др.) материалами. Обеспечивают — значит заказывают статьи у внешних и внутренних авторов, оплачивают их, размещают на сайте и затем анализируют статистику.
Сначала мы реализовали учет каждого материала — от заказа до оплаты в виде JIRA Issue. Это позволило вести списки статей на дашборде вместо традиционных записей в блокноте или почте. Кроме того, мы подключили наш Calendar Plugin для наглядного отображения редакционного плана.
Событие было запланировано на 19 часов, но посетители начали собираться уже за полчаса до начала. В ожидании докладов кто-то подключался к Wi-Fi, а кто-то наливал себе кофе. Когда все собрались, зал был полон — на встрече было более 100 человек, еще 200 наблюдали за происходящим с помощью онлайн-трансляции. В этом посте я хочу опубликовать видеозаписи и слайды докладов, а также подробнее рассказать о самих докладах.
Автоматизация работы редакции контентных проектов
Андрей Молчанов, Mail.Ru Group
Первый доклад на конференции был мой. Я рассказывал о том, каким образом с помощью JIRA и разработанного нами плагина удалось автоматизировать часть рутинной работы редакции.
Редакция — это люди, которые обеспечивают наши контентные проекты (Леди Mail.Ru, Hi-Tech Mail.Ru и др.) материалами. Обеспечивают — значит заказывают статьи у внешних и внутренних авторов, оплачивают их, размещают на сайте и затем анализируют статистику.
Сначала мы реализовали учет каждого материала — от заказа до оплаты в виде JIRA Issue. Это позволило вести списки статей на дашборде вместо традиционных записей в блокноте или почте. Кроме того, мы подключили наш Calendar Plugin для наглядного отображения редакционного плана.
Релиз NGINX 1.8 и 1.9
2 мин
Перевод
С радостью объявляем о выходе новых релизов NGINX 1.8 стабильной (stable) ветки и NGINX 1.9 основной (mainline) ветки, в рамках которой будет продолжаться разработка новой функциональности. Новые ветки релизов заменяют 1.6 и 1.7 соответственно.
За последний год в 1.7 было выпущено 12 версий, и все новые возможности, которые в них появились, теперь доступны в 1.8, включая:
Полный список нововведений за последний год можно посмотреть в логе изменений для 1.8.
За последний год в 1.7 было выпущено 12 версий, и все новые возможности, которые в них появились, теперь доступны в 1.8, включая:
- Проверку SSL сертификатов бэкендов — Призвана защитить соединения с upstream-серверами от MITM-атак;
- Логирование в syslog — Позволяет передавать логи по сети посредством UDP-сообщений;
- Пулы потоков для выполнения блокирующих операций ввода-вывода — Увеличивают производительность NGINX в ситуациях, когда блокировка на чтении с диска неизбежна;
- Новый метод балансировки нагрузки “hash” — Позволяет выбирать сервер из группы базируясь на хэше от произвольной переменной;
- Небуферизированный прием тела запроса — Позволяет передавать запрос на бэкенд сразу, не дожидаясь окончания приема тела запроса целиком.
Полный список нововведений за последний год можно посмотреть в логе изменений для 1.8.
Плохо документированные особенности Linux
8 мин
Привздохнув, произнесла:
«Как же долго я спала!»
Когда-то, впервые встретив Unix, я был очарован логической стройностью и завершенностью системы. Несколько лет после этого я яростно изучал устройство ядра и системные вызовы, читая все что удавалось достать. Понемногу мое увлечение сошло на нет, нашлись более насущные дела и вот, начиная с какого-то времени, я стал обнаруживать то одну то другую фичу про которые я раньше не знал. Процесс естественный, однако слишком часто такие казусы обьединяет одно — отсутствие авторитетного источника документации. Часто ответ находится в виде третьего сверху комментария на stackoverflow, часто приходится сводить вместе два-три источника чтобы получить ответ на именно тот вопрос который задавал. Я хочу привести здесь небольшую коллекцию таких плохо документированных особенностей. Ни одна из них не нова, некоторые даже очень не новы, но на каждую я убил в свое время несколько часов и часто до сих пор не знаю систематического описания.Все примеры относятся к Linux, хотя многие из них справедливы для других *nix систем, я просто взял за основу самую активно развивающуюся ОС, к тому же ту, которая у меня перед глазами и где я могу быстро проверить предлагаемый код.
Обратите внимание, в заголовке я написал «плохо документированные» а не «малоизвестные», поэтому тех кто в курсе прошу выкладывать в комментариях ссылки на членораздельную документацию, я с удовольствием добавлю в конце список.
Очень большой Postgres
9 мин
Так уж случилось, что последнее время приходилось заниматься оптимизацией и масштабированием различных систем. Одной из задач было масштабирование PostgreSQL. Как обычно происходит оптимизация БД? Наверное, в первую очередь смотрят на то, как правильно выбрать оптимальные настройки для работы и какие индексы можно создать. Если обойтись малой кровью не вышло, переходят к наращиванию мощностей сервера, выносу файлов журнала на отдельный диск, балансировке нагрузки, разбиению таблиц на партиции и к всякого рода рефакторингу и перепроектированию модели. И вот уже все идеально настроено, но наступает момент, когда всех этих телодвижения оказывается недостаточно. Что делать дальше? Горизонтальное масштабирование и шардинг данных.
