На самом деле прошло уже два дня, но статью на Хабр никто до сих пор не написал, так что придется мне устранять это упущение, что и делаю с удовольствием.
Итак, что же нового в этой версии PostgreSQL?
Во-первых, изменилось само версионирование. До "десятки" мы наблюдали множество минорных версий 9.x, которые выходили примерно раз в год и при этом вносили серьезные, далеко не минорные изменения. Поэтому с версии 10 было принято решение сделать нумерацию 10, 11, 12 и т.д. Кстати, MySQL, похоже пошел по тому же пути, прыгнул с 5.7 на 8.0
Ладно, это всё мелочи, перейдем к существу вопроса
Логическая репликация
Это то, чего все ждали давным-давно. Замена различным расширениям а ля slony (репликация на триггерах) и другим костылям.
Теперь вы можете из коробки делать репликацию отдельных таблиц на другие базы.
Репликация делается с помощью команд CREATE PUBLICATION и CREATE SUBSCRIPTION. Всё достаточно просто.
Понятно, что фича достаточно новая, поэтому на данный момент в логической репликации отсутствуют некоторые фичи.
- нет репликации схемы/DDL
- нет репликации сиквенсов
- не реплицируется команда TRUNCATE
Тем не менее это все равно огромный шаг вперед, в каких-то случаях можно выкинуть slony!
Партиционирование
Если раньше партиции можно было накостылять через наследование таблиц, то в десятке появилось для этого встроенное средство, которое называется declarative partitioning.
Для этого у главной таблицы добавляется ключевое слово PARTITON BY RANGE (или LIST), которое говорит, что эта таблица партициирована (или как это правильно сказать по-русски?).
У конкретных партиций с помощью выражения PARTITION OF ... FOR VALUES FROM (...) TO (...) задается диапазон их данных.
У партиций есть ряд ограничений, которые стоит иметь в виду, прежде чем использовать на продакшене: Limitations of declarative partitioning in PostgreSQL 10
Identity columns
Если вкратце, то появилась возможность писать
id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEYвместо
id serial PRIMARY KEY Что это дает?
Дело в том, что слово serial — это грубо говоря алиас к конструкции DEFAULT nextval('имя сиквенса'). Т.е. по сути таблица отдельно, сиквенс отдельно. Это бывает удобно, а бывает нет. Например, это приводит к тому, что если вы даете права на вставку в таблицу (GRANT INSERT), вам приходится еще отдельно давать гранты на сиквенс.
Кстати, новая запись соответствует стандарту SQL.
Прочее
- Улучшился паралеллизм, в частности Parallel Bitmap Heap Scan, Parallel Index Scan, Parallel Merge Join и т.д. Подробно можно прочесть в блоге Роберта Хааса
- Улучшена производительность физической репликации
- Hash-индексы стали реплицируемы
- Поддержка полнотекстового поиска на jsonb колонках
- SCRAM-аутентификация
- улучшенная поддержка работы с xml
- улучшен планировщик запросов при использовании join: если планировщик поймет, что объединенные строки не могут произвести в джойне больше одной строки, то можно не тратить лишнее время на поиск других строк. Примеры запросов можно посмотреть в тестах этого комита
Полный список изменений можно посмотреть здесь.
Если кто-то уже успел попробовать v10 в бою, поделитесь, плиз, своими впечатлениями в комментариях.
UPDATE. Есть мнение, что система версий не очень. Надо было называть PostgreSQL X, чтобы быть в тренде :)
Focushift
партиционирована?
varanio Автор
Я слышал четыре разных варианта )
партиционирована
партициирована
партицирована
секционирована
Vplusplus
секционирована, мне кажется, более точно отражает суть по-русски
Mn0g0kratn0Ub1ennbIyNaGT
Компания Postgres Professional использует термин «Секционирование». Думаю, в этом вопросе можно признать их приоритет в русскоязычной терминологии.
win32nipuh
«суть по-русски»? секционирована, партиционоирована — нужно импортозамещать: расчленена, разделена
andrbars
сегментирована?
varanio Автор
вот, кстати, сегментирование имхо подходит лучше всего
"… Сегмент
…
3. Один из многих однородных члеников тела нек-рых животных, а также один из однородных участков како-го-н. органа (спец.). С. червя.
...."
masterspline
part — это часть. Поэтому партиционирована — «разделена на части», просто «разделена» или «расчленена» (я за расчлененную таблицу, но, полагаю, что такой термин не приживется).
Ipeacocks
Да, они повсюду. Но проблема тут нескольки иная. Если же вместо митинг можно (и нужно) сказать совещание, то для некоторых терминов нет особо технических вариантов. Ну то есть сплит брейн можно назвать разделением мозга, но сомневаюсь что так лучше и вряд ли будет понятнее.
r-moiseev
Вот так бывает читаешь русскую документацию, а там какая нибудь расчлененка. И понять не можешь, о чем говорит автор. И какой выход? В скобках указывать что именно имеется ввиду? А смысл тогда переводить.
Переводить термин можно, когда он уже имеет устойчивый аналог.
Mendel
ну есть аналог НЖМД и НГМД. Но это как-то из области «кто знает в чем связь между карандашом и кассетой, тот спинеры не покупает».
С другой стороны — а откуда им взяться этим «устойчивым аналогам» если их не насаждать с самого начала?
ИМХО переводить надо в самом начале, когда термин только появляется. Потом поздно уже. Бывало пару раз что бросал русский мануал (ладно, ладно, русскую документацию) и читал в оригинале, только потому что термины переведены и приходится мысленно переводить их обратно а то не понятно.
Nashev
таки англицизмы ;)
sormon
Секционирована, хорошо подходит, всегда использую.
guai
пока в тексте не появится еще и «sectioning» :)
batyrmastyr
Секционирование это, читайте в любых учебниках по базам данных.
Focushift
так partition, с n на конце, первый вариант.
Упс, не туда опять.
Corpsee
Identity column — это очень хорошо. А как она будет себя вести, если сделать вставку в таблицу с конкретными PK? Как обычная секвенция или счетчик сдвинется самостоятельно?
CherAlexV
Хороший вопрос.
А ещё, случаем, не ли такой кучи ограничений, как в Sql Server.
Типа нельзя сделать для таблицы с identity действие insert… select…
И т.д.
mihmig
Пользуясь случаем, спрошу — какие есть свободные реализации репликации Master-Master?
mrobespierre
пользуясь случаем, спрошу — а зачем вам Master-Master?
miolini
Например для масштабирования операций на запись.
mrobespierre
а можно подробнее? вот например ситуация: есть сервер А, он «мастер», допустим, его сторадж успевает k транзакций на запись в минуту. далее мы добавляем в кластер сервер Б, он тоже «мастер», сторадж у него аналогичный, и нагрузку мы на него даём аналогичную. далее мы наблюдаем падение производительности локальных транзакций на сервере А до ~k/2 (производительность осталась прежней, просто добавилась нагрузка с реплики). это уже масштабирование или нет? я понимаю как master-master помогал в старых версиях mysql (там всё в процессор упиралось), но postgres уже 10 лет назад точно масштабировался на любое количество ядер CPU, так что к нему это не относится.
funca
Давно-ли Postgres научился распараллеливать исполнение запроса на несколько ядер, как это делает MySQL?
Envek
Недавно. С 9.6 начали параллелиться несколько определённых операций в одном запросе, в 10-ке их количество увеличилось.
struvv
Потому что master slave работает по принципу — отменяй любые запросы на слейв потому что он мешает(!) накатываться wal логу на реплику, либо отставай от мастера все больше
mrobespierre
а можно пример какой-то или баг-репорт, хочу посмотреть?
struvv
конечно можно — при выключенном feedback
забыл-название-ошибки — запрос выполняется долго и мешает накатить wal
и третья опция — база отстала и отвалилась
mrobespierre
печаль какая. но как я понимаю, это проявляется или на очень длинных запросах или на тех, чьи данные были удалены с мастера прямо во время запроса на слейв?
struvv
На запросах, которые мешают реплике накатывать wal лог. Репликация в постгре это восстановление из аварии, просто бесконечное и wal берётся из мастера. Wal может быть невозможно накатить когда запрос на реплике использует те строки, что уже удалены из мастер, например.
Проблема возникает как раз тогда, когда нужна реплика — при нагрузке на неё и мастер
Strangerx
Совсем недавно использовал Bucardo для репликации M-S, но, судя по обилию how-to в интернете, его чаще используют как раз для M-M репликаций.
erwins22
поддержка 1с скоро?
оптимизатор запросов вначале делает отбор для простых условий, а потом для сложных как для 1с?
Envek
Тут вам дорога к Postgres Professional — у них были специальные сборки для 1С (но 10-ки пока не видать): https://postgrespro.ru/products/1c
yuriybz
Обещали скоро сделать.
erwins22
спасибо.
xRay
И 1С опять будет вставлять свои костыли в код PostgreSQL?
Уж лучше пусть 1С научится работать с PostgreSQL как он есть. И всем будет проще. И PostgreSQL можно будет ставить из официальных пакетов и дистрибутивов. Речь о пакетах для linux.
erwins22
тут проблема не платформы, а наследия языка.
1с изначально не поддерживала работу с версионниками поэтому в постгресс всталяется костыль для поддержки.
+ меняется оптимизатор запросов для более эффективной работы с запросами 1с.
Переписывать всю платформу из за того, что кто то хочет чистый постгес не думаю что кто то будет.
Если ошибаюсь, пожалуйста поправьте.
akadone
Забавная штука. Архитектура у 1с очень хороша. Помню как на семёрке писал на высоконагруженном сервере toysql оптимизации выигрывая 2-3 раза. В 8, особенно в 8.1 они попытались всё это включить в движок. Но на пол пути у них что-то пошло не так (у меня есть одно большое предположение в лице корпорации из Редмонда, которое «попросило» сделать «не так»). В общем они не стали серьёзно допиливать до практически натива, а решили сделать упор на «кросс-платформенность» где самые красивые цифры у MS server+МSSQL
Поэтому можно бесплатно поставить Linux Server+ Postgresql, а можно MS server+МSSQL. ПРАКТИЧЕСКИ во всех задачах, кроме 1с первая связка будет производительнее. Но для 1с, даже если вы не верите в теории заговора — вторя будет быстрее.
erwins22
Последние годы Linux Server+ Postgresql связка сильно отзывчевее.
ievgen
Поддержу предыдущего комментатора.
В стиле КО: для настройки и там и там нужны прямые руки.
Kwisatz
Я как то раз больше часа пытался объяснить 1с-программисту что такое внешние ключи и зачем они нужны. Как можно назвать хорошей архитектуру где контроль целостности реализован через дикие костыли?
Mendel
А зачем нужны внешние ключи? (шутка).
Нет, ну серьезно. Поиграйтесь их построителем запросов.
У них архитектура предметно-ориентированная, что имеет свое отражение во внутреннем языке запросов, который суть обычный sql-select со всеми join, unit и т.п., только переведенными на русский. Вот только при более глубоком взгляде — очень много технических деталей скрыто под капотом. Вроде и sql-запросы, но протечек абстракции там меньше. Регистры скрывают свою реализацию, просто логика. У таблиц (документы, справочники и т.п.) есть подтаблицы, т.е. по сути движок неявно добавляет join-ы там где это надо, а мы строим запрос исходя только из бизнес-логики.
Резюмируя — внешние ключи это конечно очень важно, но… не для одинэсника.
Я понимаю что мой комментарий будет явно непопулярным в данной теме, но не все люди пишут на ассемблере. Не все пишут sql-запросы. Я например оказавшись в голом окружении сразу пишу себе какой-то простенький ORM. Я не в восторге от всего что сделали 1С, но общее направление у них верное — как можно больше технических деталей скрыть от прикладного разработчика. Ему предметную область понимать… освободите его хоть от технических подробностей).
Kwisatz
Философия «каждая кухарка может программировать 1с» у них лежит в основе, но она себя не оправдала.
Во первых вы явно не сталкивались с глюками транслятора всей этой билеберды в SQL. Было дело мы полгода ждали лечения бага join. Кроме того уж незнаю что они там вытворяют но у меня есть отчетик который на sql выполняется секунду, а в 1с 25 минут. Вы считаете это нормальным?
«не для одинэсника»: вот потому одинэсники пишут какие то дикие костыли там, где все прочие ставят внешний ключ и не мучаются. А уж какое веселье наступает когда есть несколько табличных частей ссылающихся друг на друга, уухх…
И уж простите, но их конструктор почти неюзабелен на более менее крупных запросах.
ЗЫ у меня вообще есть подозрение что 1с более менее работает в крупных компаниях только за счет покрывающих индексов MsSQL
ЗЫЗЫ по поводу перевода на русский: я незнаю как вам но мне особую боль доставляет вспоминать «объединить» это join или union.
Mendel
Еще как оправдала. Покажите мне конкурента у которого другая философия и такой же масштаб клиентской базы (разумеется в их нише). Каждая кухарка здесь не в контексте просто низкого порога вхождения (по аналогии с киллерфичей пхп), а скорее по аналогии с Keyword Driven Testing и прочими подходами когда эксперта в предметной области ставят как можно ближе к коду.
Не сталкивался, признаюсь. Единственный мой опыт с 1с это поддержка РИБ на 65 удаленных узлов с обменом по фтп, файловым и некоторым самопальным гибридом из файлового и фтп с использованием пхп (да, это была конфигурация «Управление НазваниеОрганаВласти 8.0» и была закрытая, с обменом с базой в главке, а я поддерживал только областную структуру). База была адовая, сделана задней левой. «Разработчик» ориентировался изначально на аналогичную структуру в другой области, но там вообще несоизмеримые масштабы. Я к ним ездил по обмену опытом. Их начальник собирал на совещание всех инспекторов в одном кабинете. А у нас все начальники отделов в актовом зале не помещались. Ну и половины техпроцессов у них не было. Но хочу Вам сказать что хоть я лично и пострадал от «кухарки», но это нисколичко не аргумент против самого концепта. У того же 1с есть не только рядовые «специалисты» (или профессионалы? давно это было), у них есть уровни сертификации для разработки сложных проектов и там вполне вменяемый пипл тусуется. В моем случае это чисто проблема откатинга а не самого 1с. (Ну и конечно же в нашем случае 1с даром не сдался, он мало что решал из задач, зато лицензии таскать на каждое рабочее место..).
Я еще раз сделаю акцент — я не защищаю их реализацию, у меня у самого к ней много вопросов. Я просто поддерживаю их идеологию.
Неа. Ненормально. Отчетик сами писали или левый «специалист»? ИМХО большая проблема 1с в том что они в своей сертификации ограничивают франчей снизу, но забывают об ограничении сверху. У них есть требования по минимальной квалификации чтобы лезть под капот, и даже по сути продавать полноценные коробки, но вот ограничения «если ты криворукий нуб без особой бумажки, то даже не пытайся писать собственную конфу или существенно допиливать существующую а то договор расторгнем и штрафов навешаем» — у них нет. И от этого все беды (не все, но многие).
Неверное сравнение. Правильно так: «вот поэтому одинэсники пишут какие-то костыли там, где все прочие говорят: эй, программист, почему ты такой бестолковый, мне нужно вот эту штучку сложить с вот этой штучкой и распечатать так как требуется в нормативке».
Мы точно об одном и том-же говорим? Возможно я уже путаю терминологию. Я говорю не о query-bilder или объектной форме запроса данных из их скриптов, а о GUI-интерфесе. Он очень удобный и простой, и его возможности уходят далеко за пределы того что способен мысленно объять человек которому нужен такой конструктор. Тем более Если конфигурация делалась руками а не ногами. Я в нем делал трехэтажные запросы без проблем (join над юнионами из join-ов, да, без этого было никак, конфигурация была уж слишком сильно «откатовая»). И переделывал их тоже довольно глубоко в нем. Например спокойно накинуть еще четвертый уровень вложенности с групповыми операциями).
Вообще у меня техпроцесс был примерно такой:
1) набросать общую структуру в построителе
2) дописать мелочи типа сложных условий и т.п. в редакторе запроса (можно и в построителе, но тут уж быстрее руками чем мышкой)
3) отладить и отдать эникейщикам
4) дальше по обстоятельствам, или тупо выгрузка в эксель с допилкой, или добавляли свои условия, сортировки, группировки, в конструкторе, или я потом собирал полноценную обработку с красивым выводом
Это мне как раз вообще без вазелина вошло. Равно как и их «Если… то ..» и прочее. Буквально недели две на перестройку ушло. Мучения доставляло когда пишешь одновременно и на 1с и на чем-то нормальном, и помногу — были проблемы с клавиатурными автоматизмами, например знаки препинания разные и т.п.
Кстати а разве в запросах нельзя писать по нормальному? Насколько я помню скриптовый язык у них можно что анлийские ключевые слова использовать что русские, но не пробовал и не уверен что это касается запросов.
erwins22
А вы УстановитьПривилегированныйРежим(истина) делали?
можно ваш код в студию?
Praksitel
Если кто не в курсе, то 1С можно запустить и с interbase (или как оно сейчас)? По крайней мере, лет 10 назад было можно.
vdasus
Я не буду советовать что никогда в жизни не делать. Просто поделюсь своим опытом. В одной достаточно большой, по нашим меркам (вся прибалтика), конторе есть зоопарк легаси, который крутится на интербейзе. «внезапно» база стала сыпаться, сервера стали виснуть и появились иные неприятности. Чего только не пробовали… Меняли сервера, версии, клиентов,…
Столкнулись с тем, что поддержки нет вообще. Отвечают по пол года в стиле «ничем не можем помочь, даже за деньги». Вызвали «крутого специалиста» из другой страны, которого рекомендуют сами интербейзы. Он посмотрел, сказал что «а фиг его знает почему оно ломается». У него есть какие-то приоритеты в тикетах разработчиков интербейза, но второй год результата ноль.
Теперь факты — проблемы не решены. Поддержка молчит. Спасаемся сложной системой бакапов-восстановлений каждые 15 минут. И срочно переписываем легаси. Я такого беспредела как поддержка «энтерпраиз уровня» базы не видел нигде и никогда за достаточно богатую айти жизнь. В один прекрасный день база просто перестает отвечать, не восстанавливается. Информации «что, собственно случилось-то?» — нет… Логи более чем бесполезны. Думайте сами стоит ли связываться, но если кто-то сейчас решает «а не выбрать ли мне интербейз для чего-то серьёзного» — полистайте гугль на предмет какие там бывают проблемы, посмотрите на даты этих самых проблем.
Просто личный опыт, ничего личного. Наболело. Если этот комментарий кто-то прочитает и задумается — возможно я только что спас людей от ранней седины.
Praksitel
Думаю, это и стоило подозревать, учитывая, что, после появления мускула и постгреса, интербейз исчез где-то за горизонтом.
Kwisatz
Нативные запрос работает в десятки раз быстрее чем 1с транслированный в SQL. В самой 1с жуткий бардак, оптимизировать это бесполезно
ievgen
Пакеты для линукс прекрасно ставятся из репозиторирия postgrespro — за что им низкий поклон. Вот бы ещё наконец для линукс дистрибутивов 1с сделали репозиторий. PeterG есть хоть какая то надежда? А то как то репозиторий для себя одного лениво становится поддерживать. А открыть доступ нельзя — атата за распространение.
Kwisatz
Я дико извиняюсь, но 1с используют БД чуть ли не как файловое хранилище. Более тупое и примитивное использование хорошей БД и вообразить себе сложно. Им бы сначала научиться использовать составные индексы и внешние ключи.
erwins22
Составные индексы используются давно и хорошо описаны в документации,
а какой прирост производительности дают внешние ключи или это фишка нужная для языков неинтегрированных с БД?
Nashev
Внешние ключи — это защита от дурака (их БД сама рвать не даёт, не допускает делать ссылок в никуда) и немножко само-документированности в БД. И то и другое — вкусно и удобно, хотя в контексте собственного словаря данных на уровне 1С второе несколько теряет актуальность. И да, добавляет накладные расходы на их отработку. Вроде как небольшие.
erwins22
1. ссылки в никуда часто необходимы во время обменов как временное явление иначе транзакция может стать слишком большой.
2. 1с по лицензионному соглашению запрещает лезть ручками в базу если работает параллельно 1с. Особенности грязного чтения.
В общем вы правы. Смысла во внешних ключах нет.
Butylkus
Партиционирование… Как насчёт вырезки? Это ж самое правильное и вкусное русское слово!
varanio Автор
Нарезка тогда уж
SoulAge
Разделка!
Или филирование! ;)
kalininmr
раздел — вполн ттрадиционный перевод для partition/partion
Workanator
А как же «разбиение»? Возьмите перевод того же Disk space partitioning — Разбиение диска.
r-moiseev
Это процесс, а как назвать результат? Разбитый диск?
redmanmale
Разметка. Размеченный диск.
batyrmastyr
Простите, а что, теорию СУБД уже не преподают или не читает никто? 0_о
Во всех профильных книгах секционированию посвящают хотя бы маленькую главу.
Butylkus
Так, ну ладно, «вырезка» слишком будоражит умы =)
Тогда добавим немного пресмыкающихся: СРЕЗ. Собственно, оно так и есть, и даже вроде как логика аналогичная питону. Дай мне таблицу и я тебе срежу искомый кусок.
F0iL
Я так понимаю, репликация только в одну сторону работает? То есть что-то типа упомянутого выше master-master, или хотя бы поочередную смену ролей (сегодня publish на первом сервере, а subscribe на втором, завтра меняемся, и чтоб ничего не развалилось при split-brain'е) реализовать не получится?
ievgen
И опять про postgrespro https://github.com/postgrespro/postgres_cluster
Со слов Олега Сергеевича, если ничего не путаю, в их коммерческой версии есть и мультимастер для продуктива.
darthunix
Ну понятно, что нормального мультимастера пока нет и раньше 12-13 версии pg его ждать глупо. По поводу костыльной реализации мультимастера на базе логической репликации здесь и сейчас… можете попробовать на двух серверах создать родительскую таблицу с двумя партициями. Ключом партицирования будет id сервера. На первом сервере при вставке в родительскую таблицу данные попадут в первую партицию, на втором сервере — во вторую. Первая партиция на втором сервере будет подписана на первую партицию на первом сервере. Вторая партиция на первом сервере будет подписана на вторую на втором. По факту такая конструкция может пережить сплит брейн за счёт того, что данные вносятся на каждом сервере в свою партицию и уникальность им обеспечит id сервера (поэтому конфликтов не возникает). Ну и делать такие вещи есть смысл не через нативное партицирование десятки, а через pathman. Но это так, теория, подобные костыли я не проверял.
Mn0g0kratn0Ub1ennbIyNaGT
Заодно можно и в Википедии страницу про PostgreSQL обновить :-)
Nashev
Спасибо за разрешение. Однако, напоминаю: Википедия: Правьте смело
Pilat
И как всегда основной вопрос — как перевести термин, а можно ли вообще пользоваться новым механизмом партиций, учитывая его ограничения.
Butylkus
Можно. И даже нужно. Под мои задачи ограничения не существенны. Мне, например, на данный момент через питон приходится делать выборки по меткам времени, а их может быть неопределённое число, скажем, чуть ли не каждая минута за годовой интервал. Приходится костылить с существенным объёмом данных — выбрать всё согласно некоторому ключу, а потом программно делать срез из большого массива. Теперь я могу решить эту проблему одной строчкой и экономить драгоценную память (для SoC это очень существенно).
skobkin
Пробовал 10 версию ещё с беты, в целом приятно, но пока пришлось откатиться на 9.6, т.к. Doctrine DBAL пока не умеет работать с новым видом хранения сиквенсов, а следовательно, ломаются миграции (генерация).
skobkin
Если кто-то хочет знать, когда починят, то можно подписаться на этот баг.
ottonturk
А что надо знать и кем поработать чтобы хорошо разбираться в тех терминах, что описаны для Postgrade? ( секционирование, репликация) — как отойти от среднего уровня — ?
Это админы учат?
Miron2
А Вы скачайте копию и попробуте запустить. Пoтом пройдитесь по пакету контроля качеством,. Помню первые две трети разобрал и многому научился.
Там огромное количество самых простеньких на вид запросов, пока не наткнетесь на один, который вылетает с ошибкой. Ну и как пройдетесь по цепчке сопровождения дефектов, чтобы понять «почему», считай 50% науки освоили. Потом за каждые оставшиеся 10 придется уже платить сединой. А за последние 10 воюют все профессионалы.
Ну а там и до репликации доберётесь, если не сами, то если заказчик на проэкте потребует.
Miron2
Всё конечно замечательно. Но планируется переход на отечестенные продукты. Есть замечательная база «Линтер», от работы с которой я лично получаю огромное удовольствие последние несколько месяцев.
Сильной стороной Постгресса была и остается MVCC.
В конечном итоге, сегодня все производители СУБД вынуждены признать превосходство этой модели и внедрить её поддержку, некоторые после десятков лет вращения пятой точкой.
Слабым местом была и остается файловая система и регулятор потоков, основанный на мало — экономичной модели Юникса. Хотя появился новый класс задач, для которого сейчас любят, в рекламных целях, использовать слово «облако», эконмичность управления потоками для которого, по крайней мере на сегодня, не существенна, а вот возожность эффективного управления распределением запросов, и гибкость этого управлеия, главное.
Т. е. процесс внедрения ПО с открытым кодом сегодня находится перед развилкой, где одна команда людей, не боящихся писать на Си системный код может произвести скачек в области восприятия Постгресса.
darthunix
Кстати, PostgresPro вроде имеет свой сертифицированный форк. А расскажите про Линтер, что за зверь такой? А то в интернетах про него внятных технических подробностей не нашёл при поверхностном поиске. И раз вы сказали, что сильная сторона pg — это mvcc, то что тогда у Линтера? Блокировщик?
Miron2
Скачал пробную копию с узла Релэкс. Выполнил процедуру инсталяции. Нашел учетную запись SYSTEM\MANAGER, и пока гоняю запросы, копирую из тюториал процедуры, запускаю утилиты.Всё это на моих домашних Win — 10.
Первое и самое яркое впечатление — все запросы отвечают с бешенной скоростью. Как человек с богатым опытом, скорость ответа заметна невооруженным глазом и первый индикатор класса базы.
Второе, все утилиты работают безупречно. Рабочий стол — конфетка, вылизан дочиста, писать запросы удовольствие. Сравнивая с десятком рабочих столов, от самых дорогих до SQL Workbench My SQL, собранного из исходников GitHub с кастом тулсами собственной добавки, этот самый легкий в общении и никогда не вываливается, от слова «вообще».
Если делаю ошибки, система отвечает внятными оповещениями. Процесс базы, сервис, выполняется уже несколько месяцев без нареканий. Запуск сервиса происходит молниеносно.
Отличная документация, отполированная и по содержанию и по презентации. В каждой детали изделия чувствуется класс разработчика.
Пожалуй самым трудным было добраться до странички чтобы скачать копию. У меня не очень цепкий взгляд и заняло какое — то время оглядеться на узле Релэкс. Но дальше все гладко.
Такие вот впечатления.
С Вашего разрешения сегодня позднова — то, посмотрю реализацию управления запросами и отвечу завтра.
AlexWinner
> позднова — то
Боги…
Miron2
«Боги…»
Верующий…
gonzazoid
Язычник
Miron2
Вчера найти ответ на Ваш вопрос не удалось. Но в процессе поиска нашел одну интересную фишку «автоматическая индексация данных», задаётся опцией на уровне базы данны в административной утилите.
Так же обратил внимание на возможность выбора степени предвосхищения конфликтов параллельных потоков при соединении.Можно выбрать между пессимистичным, оптимистичнм и авто — транзакционным подходом управляющего потоками.
В общем то это надо ещё проанализировать, но складывается впечатление, что эти опии позволяют выбирать между, если не MVCC, то «мягким», «жестки» и по возможности взаимонезависимым распределением структур занятых защитой целостности данных в потоке на уровне клиента. Своеобразный подход, который больше нигде не видел. И потому не обратил внимание.
Forbidden
Сидим на pg 10 с 3ей беты на продакшене, в первую очередь из за встроенного партицирования, полет отличный. Печально что логическая репликация не поддерживает репликацию схемы
mva
Интересно, насколько вероятно что "логическая репликация" сможет сходу заменить skytools… :)
alexdon
varanio, поправьте ссылку на CREATE PUBLICATION
www.postgresql.org/docs/10/static/sql-createpublication.html
varanio Автор
спасибо, поправил
Olehor
спасибо автору
romy4
Вот не люблю я эти версии Х+1, в них непонятны milestones. Если на разницу 8 и 9 смотрели как вверха на скалу, которую надо забраться, потому что нас ждёт куча новых фич; то между 10 и 11 будет разница неочевидная. И чем плохо было обновление для фиксов с 10.х.1 на 10.х.2 версию?
Mendel
Когда читал статью думал речь идет о переходе на semver, но после вашего комментария засомневался…
Envek
На самом деле теперь нумерация стала ближе к SemVer, а главное — логичней. Старая нумерация: MAJOR1.MAJOR2.PATCH, новая — MAJOR.PATCH. Т.е. 9.6 — это был мажорный релиз после 9.5, несовместимый с ним по формату внутренней структуры файлов БД. Минорных релизов в понимании SemVer у PostgreSQL попросту нет. Цифру MAJOR1 скорее меняли по каким-нибудь праздникам, нежели из соображений обратной совместимости — логика там вроде бы и есть, но она не очень очевидная (так, 9.1 от 9.0 отличалась едва ли не сильнее, чем 9.0 от 8.4, хотя я тогда только начинал работать с постгре и помню плохо). Обратную совместимость поддерживают очень далеко в прошлое (приложению написанному под 8.4 вроде можно и сейчас подсунуть свежий постгрес и всё будет ок).
xclusn
Вероятно, будет уместно дополнить эту новость ссылкой на русский перевод документации к PostgreSQL 10:
postgrespro.ru/docs/postgresql/10
ZOXEXIVO
Секционирование осталось старое — основанное на наследовании таблиц, а в релизе просто добавили синтаксический сахар