А давайте про базы данных

У кого 11 уже в проде?

У кого 11 уже в проде?

У меня 10

Но не совсем в проде, пока ещё без нагрузки.

У меня 10

Но ведь 10 уже год

Верно...

100500 субд. можно же на файлах все хранить

Нет. С выходом PostgreSQL 11 "вам не нужна никакая другая СУБД" (С).

Переносим нашу базу с оракла на постгрес.

У кого 11 уже в проде?

А если в ПГ критичные данные, которые нельзя превращать в тыкву? И даунтайм на восстановление не предусмотрен?

Нет. С выходом PostgreSQL 11 "вам не нужна никакая другая СУБД" (С).

тогда надо предупредить мусикель мсскуэль оракл и десятки форков

А давайте про базы данных

Так а как она будет в проде, если она ещё в бете? ?

Но ведь 10 уже год

Да и 10-ку мне тоже пришлось оправдывать, дескать зачем нам нововведения непроверенные.

тогда надо предупредить мусикель мсскуэль оракл и десятки форков

Они уже в курсе ?

Да и 10-ку мне тоже пришлось оправдывать, дескать зачем нам нововведения непроверенные.

А много осталось переносить?

А много осталось переносить?

4к таблиц, ещё кучу всякого

Что-то обрежем, что-то перепишем, что-то вынесем из БД

4к таблиц, ещё кучу всякого

4k таблиц?! Ого.

4k таблиц?! Ого.

Да, тяжелое наследие. К тому же там куча блоб и клоб в оракле.

Да, тяжелое наследие. К тому же там куча блоб и клоб в оракле.

А есть такой человек в вашей организации, который удерживает в голове схему такой БД?

А есть такой человек в вашей организации, который удерживает в голове схему такой БД?

Конечно есть. Там специфично всё разбито по схемам, много схем с повторяющейся структурой.

Конечно есть. Там специфично всё разбито по схемам, много схем с повторяющейся структурой.

Не представляю себе как такую БД эффективно сопровождать.

Не представляю себе как такую БД эффективно сопровождать.

Приходится, что поделать.

Приходится, что поделать.

Рефакторить ? У вас сейчас шанс есть что-то улучшить. Или там шансов нет? ?

Рефакторить ? У вас сейчас шанс есть что-то улучшить. Или там шансов нет? ?

Ну вот как раз при переходе хотят многое упростить.

Пдскажите, в постгре можно как-то логировать запросы, котоыре выполнялись на сервер за последнее время? В MSSQL точно такое можно было сделать, точнее там можно было вытянуть их из кеша планов, AFAIK В постгре как я понял нету ничего встроенного, может какой-то плагин есть?

Пдскажите, в постгре можно как-то логировать запросы, котоыре выполнялись на сервер за последнее время? В MSSQL точно такое можно было сделать, точнее там можно было вытянуть их из кеша планов, AFAIK В постгре как я понял нету ничего встроенного, может какой-то плагин есть?

"log_statement = 'all'" и т.п.

"log_statement = 'all'" и т.п.

спасибо)

спасибо)

Хмм... а может, Вы что-то типа https://www.postgresql.org/docs/current/static/pgstatstatements.html имели в виду? В общем, посмотрите, что из этого Вам было нужно. :)

жаль что оно будет в текстовом файле. ан е в табилчке))

ERROR: pg_stat_statements must be loaded via shared_preload_libraries

жаль что оно будет в текстовом файле. ан е в табилчке))

Кто "оно"? Логи — да (хотя можно сделать их csv, и читать с помощью соответствующего FDW — всё это есть в документации). А pg_stat_statements создаёт view. > ERROR: pg_stat_statements must be loaded via shared_preload_libraries Да, действительно, должен быть загружен именно так. ;)

Кто "оно"? Логи — да (хотя можно сделать их csv, и читать с помощью соответствующего FDW — всё это есть в документации). А pg_stat_statements создаёт view. > ERROR: pg_stat_statements must be loaded via shared_preload_libraries Да, действительно, должен быть загружен именно так. ;)

Спасбо вам! Этот екстеншен, то что надо, пожалуй оставлю его включенным, пока. Надеюсь не сильно заимпактит на скорсть. P.S. про FDW знаю, но как-то про них не подумал)

Спасбо вам! Этот екстеншен, то что надо, пожалуй оставлю его включенным, пока. Надеюсь не сильно заимпактит на скорсть. P.S. про FDW знаю, но как-то про них не подумал)

В FDW, кстати, есть прямо готовый пример: https://www.postgresql.org/docs/current/static/file-fdw.html#id-1.11.7.24.14

как предусмотрительно с их стороны ?

Доброго времени суток! https://blogs.sungeek.net/unixwiz/2018/09/02/centos-7-postgresql-10-patroni/ В этой статье пишут всего об одном haproxy и etcd, скажите, а что будет, если сам haproxy упадет? Тогда коннекты к бд ни через что не будут "ходить"? Как в таком случае делают? haproxy + corosync?

@a114x будет жить. Поприветствуем!

Нет. С выходом PostgreSQL 11 "вам не нужна никакая другая СУБД" (С).

Почему?

Почему?

встроенные возможности nosql

Почему?

Это уже было ясно с внедрением JSON в ядро. А внедрению JSON в ядро предшествовала возможность внедрения в ядро Hstore, с котором уже тогда было понятно, что в Postgres есть полноценный, индексируемый движок ключ/значение. Зачем что-то ещё?

memory storage key-value? undo log для апдейтов в таблице?

Это уже было ясно с внедрением JSON в ядро. А внедрению JSON в ядро предшествовала возможность внедрения в ядро Hstore, с котором уже тогда было понятно, что в Postgres есть полноценный, индексируемый движок ключ/значение. Зачем что-то ещё?

Мне не ясно, когда стоит использовать json. Люблю когда всё нормализовано. Можно несколько примеров, когда json оправдан?

memory storage key-value? undo log для апдейтов в таблице?

?

hstore в memory или на диске?

JSON оправдан в случае полуструктурированных данных.

Когда у разных объектов может быть разный набор свойств.

hstore в memory или на диске?

Это решается директивой TABLESPACE.

Это решается директивой TABLESPACE.

Окей

memory storage key-value? undo log для апдейтов в таблице?

undo log уже в 11 будет?

JSON оправдан в случае полуструктурированных данных.

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

JSON оправдан в случае полуструктурированных данных.

Можно всё-таки примерчик, а то я как-то не понимаю. Т.е. не можешь определиться, массив у тебя или строка? Не понятно вообщем.

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

А Вы пострайтесь получать от процесса удовольствие ?

Это уже было ясно с внедрением JSON в ядро. А внедрению JSON в ядро предшествовала возможность внедрения в ядро Hstore, с котором уже тогда было понятно, что в Postgres есть полноценный, индексируемый движок ключ/значение. Зачем что-то ещё?

> Зачем что-то ещё? Много зачем, нет? А только для key/value (по идее) всё равно лучше что-то специализированное.

Можно всё-таки примерчик, а то я как-то не понимаю. Т.е. не можешь определиться, массив у тебя или строка? Не понятно вообщем.

Любой класс объектов, например, человек, может описываться великим множеством свойств. В случае использования полуструктурированных типов не обязательно знать эти свойства в момент проектирования БД. Свойства человека описываются одним единственным столбцом типа JSON.

Вы можете эти свойства тоже не описывать в postgresql и сделать всё нормализованно.

Если вдруг нужна денормализация (ну допустим ооочень удобно) => matview. Миша и Костя из avito рассказывали про это.

Вы можете эти свойства тоже не описывать в postgresql и сделать всё нормализованно.

Представте себе парсер, который извлекает данные и складывает их в виде ключ/значение. Что ему делать, если он встретил данные с ключом, который не предусмотрен схемой БД? ALTER TABLE на лету?

Проектируйте схему изначально так, чтобы это было нормой: create table human_characteristics (name text, values text). Складывайте эти характеристики сюда.

Проектируйте схему изначально так, чтобы это было нормой: create table human_characteristics (name text, values text). Складывайте эти характеристики сюда.

Ещё раз, это не всегда возможно.

Ещё раз, это не всегда возможно.

Я просил хороший примерчик. Пока не вижу, к сожалению.

Представте себе парсер, который извлекает данные и складывает их в виде ключ/значение. Что ему делать, если он встретил данные с ключом, который не предусмотрен схемой БД? ALTER TABLE на лету?

Выдать ошибку, скорее всего? Ну или ALTER TABLE (и другой DDL) "на лету", если очень хочется... хотя это странно.

Я просил хороший примерчик. Пока не вижу, к сожалению.

Т.е. здоровая денормализация абсолютно не допустима вообще? (вот с самого начала понял что тема холиварная, чего лезу)))

Проектируйте схему изначально так, чтобы это было нормой: create table human_characteristics (name text, values text). Складывайте эти характеристики сюда.

Это ещё хуже, если я правильно понял идею. :(

Я просил хороший примерчик. Пока не вижу, к сожалению.

У вас может быть и тип объекта неизвестен. И human_characterisic уже превратиться в object_characteric и пошло поехало усложнение системы. А можно просто взять JSON.

А потом приходят к БД с 4к таблиц ?

Это ещё хуже, если я правильно понял идею. :(

Чем?

Выдать ошибку, скорее всего? Ну или ALTER TABLE (и другой DDL) "на лету", если очень хочется... хотя это странно.

Это дорого (DDL на лету). Ошибка тут вообще не причём - парсер свою работу выполнил, данные извлёк, ключ определил, данные определил.

У вас может быть и тип объекта неизвестен. И human_characterisic уже превратиться в object_characteric и пошло поехало усложнение системы. А можно просто взять JSON.

А можно просто взять MySQL постарее (или вовсе sqlite), что бы можно было хранить всякий мусор без этих никому не нужных проверок. ;) Нет, ну в самом деле... Вы сравниваете яблоки с апельсинами.

Это дорого (DDL на лету). Ошибка тут вообще не причём - парсер свою работу выполнил, данные извлёк, ключ определил, данные определил.

Вот как Вы это посчитали, а? Экономическое обоснование имеется? ;)

Хех. Тут даже думать не надо, чтобы понять, что ALTER TABLE + INSERT гораздо дороже INSERT в любом случае.

Чем?

Да Вы лучше конкретизируйте модель, а то вдруг я не так понял...

А можно просто взять MySQL постарее (или вовсе sqlite), что бы можно было хранить всякий мусор без этих никому не нужных проверок. ;) Нет, ну в самом деле... Вы сравниваете яблоки с апельсинами.

Мне не понятно о чём Вы.

Хех. Тут даже думать не надо, чтобы понять, что ALTER TABLE + INSERT гораздо дороже INSERT в любом случае.

Сколько $ стоит INSERT, а сколько ALTER TABLE? (Меня вообще шокируют такие аргументы, если честно.) Да мне ровным счётом плевать на производительность того, что не решает мою задачу!

JSON оправдан в случае полуструктурированных данных.

да? и почему тогда есть операции сравнения?

Сколько $ стоит INSERT, а сколько ALTER TABLE? (Меня вообще шокируют такие аргументы, если честно.) Да мне ровным счётом плевать на производительность того, что не решает мою задачу!

Ну а меня шокирует целосообразность ALTER TABLE из под приложения вместо банального INSERT в поле с JSON по его прямому назначению.

https://www.postgresql.org/docs/9.4/static/functions-json.html

да? и почему тогда есть операции сравнения?

Чтобы сравнивать.

спасибо, кеп

спасибо, кеп

Ну серьёзно.

Мне не понятно о чём Вы.

О том, что описываемая Вами задача это "запихнуть в базу любой мусор, неважно, что там". Указанные СУБД очень помогают в её решении. Но структурированные данные, обычно, совсем не мусор. И если что-то пытается вставить то, что база запрещает (чего нет в схеме) — это ошибка вставляющего.

О том, что описываемая Вами задача это "запихнуть в базу любой мусор, неважно, что там". Указанные СУБД очень помогают в её решении. Но структурированные данные, обычно, совсем не мусор. И если что-то пытается вставить то, что база запрещает (чего нет в схеме) — это ошибка вставляющего.

Не мусор, а динамически описываемые объекты.

@Irina_shv будет жить. Поприветствуем!

Я изначально предполагал, что все характеристику будут текстовые, числовые (иногда тоже можно в виде текста представить). Ну а далее вставлеете insert into table h_c ('расса', 'афроамериканец'), ('длинный', '1'), ('съел апельсинов', '10'), ('вес', '55.123'), ('массив', 'element1'), ('массив', 'element2'). В примере типы: строка, булево значение, число, не целое число, массив. UPDATE. Вероятно придётся колонку с типом ещё добавить.

О том, что описываемая Вами задача это "запихнуть в базу любой мусор, неважно, что там". Указанные СУБД очень помогают в её решении. Но структурированные данные, обычно, совсем не мусор. И если что-то пытается вставить то, что база запрещает (чего нет в схеме) — это ошибка вставляющего.

Есть набор операций для работы с этими данными. Эти данные индексируются. Эти данные легко десериализуются и т.д.

Я изначально предполагал, что все характеристику будут текстовые, числовые (иногда тоже можно в виде текста представить). Ну а далее вставлеете insert into table h_c ('расса', 'афроамериканец'), ('длинный', '1'), ('съел апельсинов', '10'), ('вес', '55.123'), ('массив', 'element1'), ('массив', 'element2'). В примере типы: строка, булево значение, число, не целое число, массив. UPDATE. Вероятно придётся колонку с типом ещё добавить.

Массивы не индексируются в отличии от JSON.

Массивы не индексируются в отличии от JSON.

Где вы там видите массив?

Ну а меня шокирует целосообразность ALTER TABLE из под приложения вместо банального INSERT в поле с JSON по его прямому назначению.

Просто это другая задача. Если кому-то надо хранить какие-то данные, о структуре которых СУБД не нужно заботиться... для этого давно есть BLOB-ы.