LINUX.ORG.RU

PGConf.NN — конференция по PostgreSQL в Нижнем Новгороде

 , , , ,


0

2

30 сентября в Нижнем Новгороде пройдёт PGConf.NN - бесплатная техническая конференция по СУБД PostgreSQL. Организаторы — компания Postgres Professional и ассоциация IT-компаний iCluster. Начало докладов — в 14:30. Место проведения — технопарк «Анкудиновка» (ул. Академика Сахарова, д. 4).

Доклады:

  • «JSON or not JSON» — Олег Бартунов, генеральный директор Postgres Professional;

  • «Обзор возможностей резервного копирования в PostgreSQL и Postgres Pro» — Иван Фролков, ведущий инженер Postgres Professional;

  • «SQL vs NoSQL» — Дмитрий Адмакин, руководитель отдела разработки БАРС Груп.

Регистрация на мероприятие открыта на сайте PGConf: https://pgconf.ru/202109

>>> Подробности



Проверено: hobbit ()

Прошу прощения у ТСа, что при подтверждении удалил картинку, она красивая, но на главной ЛОРа занимала совершенно несоразмерное место. Между отправкой в мини-новости и удалением картинки я выбрал меньшее, на мой взгляд, зло: полноразмерная новость, но без картинки. Желающие посмотреть картинку могут пройти по ссылке «Подробности».

А новость интересная. Сейчас PostgreSQL — считай, «дефолтная реляционная СУБД».

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от hobbit

Кстати да, интересно как много сейчас не PG реляционных баз данных используется в проде, если это не legacy проект? У меня, на последних местах работы, ни в моей ни в смежных командых никто не использовал мускул, марию или что-то подобное. Я не говорю про всякие почтовые сервера, где применяют собственные решения.

Aswed ★★★★★ ()
Ответ на: комментарий от Turbid

Ссылку было бы неплохо.

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

hippi90 ★★★★★ ()
Ответ на: комментарий от hippi90

я работал на контору, где informix еще на sun-ках крутился. потом пришел linux и дешевое серверное железо. но они даже и не думают переезжать на db2, хотя, их постоянно и упорно пытаются перевести.

dummy ★★ ()
Ответ на: комментарий от hippi90

Ссылку было бы неплохо.

Я их перепутал с Ростелеком

Но там в комментариях:

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

Еще информация по Сберу.

И Росатом опять же.

Turbid ★★★★★ ()
Последнее исправление: Turbid (всего исправлений: 3)
Ответ на: комментарий от hobbit

Сейчас PostgreSQL — считай, «дефолтная реляционная СУБД».

Миллионы мускулов не могут с тобой согласиться.

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от Turbid

В Ростелекоме и Сбере да и вообще в телекоммуникационных и финансовых отраслях как сидели так и сидят на Oracle DB. Уходят в некритических для бизнеса областях - типа БигДата, Аналитика, приложения уровня департамента. Oracle DB - является лучшей системой управления реляционными базами данных в мире - это даже не оспаривается. Но вот ценовая и технологическая политика Oracle совершенно идиотская. Поэтому правильно народ убегает от них.

anonymous ()
Ответ на: комментарий от hippi90

Забавно, как вы все игнорируете MS SQL, который по факту нынче самая продвинутая база в мире и скорей всего самая распространённая в коммерческих установках.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Но вот ценовая и технологическая политика Oracle совершенно идиотская.

Для биг-бизнеса вполне нормальная ценовая политика, альтернативы по факту в общей стоимости затрат (на лицензии, интеграцию, поддержку) могут оказаться существенно менее выгодными.

vincent ()
Ответ на: комментарий от kilokolyan

Разумеется дефолтная это mysql с форками, по количеству установок думаю в разы опережает всё остальное, вместе взятое. Какие-то другие базы (ну ещё кроме SQLite) встречаются только в древнем legacy (из до-mysql времён), либо в весьма крупных проектах, каких мало.

Только вот

имеет достаточную производительность, трату памяти и простоту изнутри

причина кажется не в этом. Была бы в этом - пользовались бы быстрым, простым и легковесным MyISAM, но нет они пользуюся ненужным болотом InnoDB (оно действительно *совсем* не нужно для 99% пользователей mysql).

firkax ()

Выглядит печально.

Доклад с обсуждением интеграции веб-дичи в базу (JSON or not JSON), доклад с скорее всего пачкой банальностей (SQL vs NoSQL) видимо для тех же веб-писетелей что и JSON, ну и единственное по делу (ну, точнее, есть шанс что под таким названием будет что-то полезное) - это про рещервное копирование, но! речь не про PostgreSQL, а про некое PostgresPro, которое ещё недавно пиарилось интеграцией базы с блокчейнами и какой-то криптовалютой. Впрочем, неудивительно - ведь вся «конференция» организована как раз этим PostgresPro.

firkax ()
Ответ на: комментарий от firkax

веб-дичи в базу (JSON or not JSON)

JSON уже давным-давно к вебу имеет весьма косвенное отношение. Это универсальный формат структурированной информации.

некое PostgresPro, которое ещё недавно пиарилось интеграцией базы с блокчейнами и какой-то криптовалютой

Я вот смотрю на их гитхаб и вижу там дофига всего (в том числе про резервное копирование). Но тебя почему-то только блокчейны и криптовалюта зацепили.

hobbit ★★★★★ ()
Ответ на: комментарий от kto_tama

Кровавый энтерпрайз постепенно начинает убегать от оракла

это в основном жмотьё с промытыми мозгами про какую-то там бесплатность, а потом такие с кровавыми слезами обратно пытаются смигрировать если ещё не пошли ко дну

anonymous ()
Ответ на: комментарий от hobbit

JSON уже давным-давно к вебу имеет весьма косвенное отношение. Это универсальный формат структурированной информации.

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

вижу там дофига всего

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

firkax ()
Ответ на: комментарий от firkax

Задача базы - хранить данные максимально эффективно, занимая минимум места на хранение и времени на обработку, и то и то достигается только двоичным форматом.

И это правильно. Потому что всякие XML, JSON - это форматы обмена информацией в текстовом виде между приложениями, а не эффективного хранения и поиска информации. Терпеть это непотребство не могу в реляционных базах.

anonymous ()
Ответ на: комментарий от firkax

что за ребуты и откуда они на продакшн сервере? что потерялось? одна строчка из последнего инсерта?

Есть 1К серверов, на них по несколько дисков и инстансов mysql для хранения чего-то простого уровня key=value. mysql как расходный материал, ими всё обмазано. Иногда, допустим, какой-то дата-центр вырубает. Или у сервака инфаркт жопы. Или админ случайно убил процесс. Редко, но бывает. Поднимаемся - базы нет, всё перекошено, данные в неконсистентном состоянии.

kilokolyan ()

Вяленько как-то, тоскливо. Виден кризис и деградация отрасли после 2014 года. Раньше была движуха, всевозможные акции, цены снижались постоянно. А знаменитая акция mail.ru - 1 ТБ облака бесплатно и навсегда!!! Но уже в 2018 о «навсегда» в одностороннем порядке забыли и тихонько-подленько облако порезали и данные удалили, прислав письма о неактивности. А люди там свои данные хранили, коллекции фоток и прочего.

anonymous ()
Ответ на: комментарий от kilokolyan

Мда, ну речь же не про это шла. У больших систем всё может быть иначе, но их крайне мало, а я писал про массовость.

Но тем не менее. «Базы нет, всё перекошено» - это вопрос скорее к дисковому хранилищу и к ОС (при неожиданном падении железа; если же случайно убили процесс то такого вообще не может случиться). Сам по себе движок MyISAM такое организовать не может. Максимум - будут затёрты те данные (те строки), где велась запись в последнее время, и repair table пофиксит все неконсистентности.

firkax ()
Ответ на: комментарий от firkax

Сам по себе движок MyISAM такое организовать не может.

Это ясно. Страшно то, что он ничего не делает, чтобы этого избегать. И страшно это будет одинаково что при тыщах серваков, что если юзаешь MyISAM один на своей виртуалке, купленной у reg.ru.

kilokolyan ()
Ответ на: комментарий от anonymous

это в основном жмотьё с промытыми мозгами про какую-то там бесплатность, а потом такие с кровавыми слезами обратно пытаются смигрировать если ещё не пошли ко дну

Ларри, вы забыли залогиниться

Turbid ★★★★★ ()
Ответ на: комментарий от kilokolyan

чтобы этого избегать

Чтобы такого избежать - помогут только бекапы. Отличие MyISAM от InnoDB тут только в одном: при глобальном сбое системы во время перезаписи данных первый может в итоге оказаться и без старых и без новых, а второй хоть какие-то да сохранит. И то, даже против него можно придумать достаточно агрессивный и непродуманный writeback-кеш на уровне дисков, что данные таки потеряются (а чинить innodb-таблицу, которая всё-таки сломалась - намного муторнее, ведь они «никогда не ломаются» и инструментов для починки почти нет, а движок иногда, вместо репорта о проблемах в таблице, просто сегфолтится). Те же данные, которые в перезаписи не участвуют, и так и так останутся целыми - ну может индекс побьётся, но repair table его пересоберёт как будто ничего не было.

что если юзаешь MyISAM один на своей виртуалке

А вот и нет. На виртуалке с базой на меньше 1гб все repair-ы пройдут за меньше 15 минут, и такой даунтайм, опять же для никому не известной виртуалки, будет совсем не критичным, равно как и потеря, например, какого-нить недавно (1 мин) оставленного коммента к фотке. Зато MyISAM работает местами в разы быстрее и не надо тратиться на железо. А вот для крупного проекта (с базой 1тб) и база больше - дольше repair, и требование к аптайму выше (простой в 1 минуту уже может быть плохо).

Но крупному проекту, вместо того чтобы использовать InnoDB, есть уже много других вариантов в виде того же постгреса. И даже в рамках mysql-форков есть например aria.

firkax ()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от anonymous

JSON в БД бывает очень к месту. Простой пример - у тебя интеграция. Ты запрашиваешь информацию, тебе возвращают миллион полей. При этом тебе реально нужно из них 5 штук. Но это сегодня. А завтра может понадобиться ещё 5 штук. В итоге ты кладёшь JSON тупо в отдельный столбец и вытягиваешь из него 5 штук. Если тебе завтра понадобится ещё 5 полей, ты простой миграцией их добавишь и заполнишь нужными данными. Послезавтра тебе для разового отчёта ещё три поля понадобились. Ты их прям из JSON-а вытащил, сделал свой отчёт и забыл. Это очень круто и удобно, когда пригождается и аналога этому нет.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)