Pull to refresh

Comments 108

таблица партициирована (или как это правильно сказать по-русски?).

партиционирована?
Я слышал четыре разных варианта )
партиционирована
партициирована
партицирована
секционирована
секционирована, мне кажется, более точно отражает суть по-русски
Компания Postgres Professional использует термин «Секционирование». Думаю, в этом вопросе можно признать их приоритет в русскоязычной терминологии.
«суть по-русски»? секционирована, партиционоирована — нужно импортозамещать: расчленена, разделена
вот, кстати, сегментирование имхо подходит лучше всего

"… Сегмент

3. Один из многих однородных члеников тела нек-рых животных, а также один из однородных участков како-го-н. органа (спец.). С. червя.
...."
UFO just landed and posted this here
Да, они повсюду. Но проблема тут нескольки иная. Если же вместо митинг можно (и нужно) сказать совещание, то для некоторых терминов нет особо технических вариантов. Ну то есть сплит брейн можно назвать разделением мозга, но сомневаюсь что так лучше и вряд ли будет понятнее.

Вот так бывает читаешь русскую документацию, а там какая нибудь расчлененка. И понять не можешь, о чем говорит автор. И какой выход? В скобках указывать что именно имеется ввиду? А смысл тогда переводить.


Переводить термин можно, когда он уже имеет устойчивый аналог.

ну есть аналог НЖМД и НГМД. Но это как-то из области «кто знает в чем связь между карандашом и кассетой, тот спинеры не покупает».
С другой стороны — а откуда им взяться этим «устойчивым аналогам» если их не насаждать с самого начала?
ИМХО переводить надо в самом начале, когда термин только появляется. Потом поздно уже. Бывало пару раз что бросал русский мануал (ладно, ладно, русскую документацию) и читал в оригинале, только потому что термины переведены и приходится мысленно переводить их обратно а то не понятно.
таки англицизмы ;)
Секционирована, хорошо подходит, всегда использую.
UFO just landed and posted this here
Секционирование это, читайте в любых учебниках по базам данных.
Identity column — это очень хорошо. А как она будет себя вести, если сделать вставку в таблицу с конкретными PK? Как обычная секвенция или счетчик сдвинется самостоятельно?

Хороший вопрос.
А ещё, случаем, не ли такой кучи ограничений, как в Sql Server.
Типа нельзя сделать для таблицы с identity действие insert… select…
И т.д.

Пользуясь случаем, спрошу — какие есть свободные реализации репликации Master-Master?
пользуясь случаем, спрошу — а зачем вам Master-Master?
Например для масштабирования операций на запись.
а можно подробнее? вот например ситуация: есть сервер А, он «мастер», допустим, его сторадж успевает k транзакций на запись в минуту. далее мы добавляем в кластер сервер Б, он тоже «мастер», сторадж у него аналогичный, и нагрузку мы на него даём аналогичную. далее мы наблюдаем падение производительности локальных транзакций на сервере А до ~k/2 (производительность осталась прежней, просто добавилась нагрузка с реплики). это уже масштабирование или нет? я понимаю как master-master помогал в старых версиях mysql (там всё в процессор упиралось), но postgres уже 10 лет назад точно масштабировался на любое количество ядер CPU, так что к нему это не относится.
Давно-ли Postgres научился распараллеливать исполнение запроса на несколько ядер, как это делает MySQL?

Недавно. С 9.6 начали параллелиться несколько определённых операций в одном запросе, в 10-ке их количество увеличилось.

Вопросы такого рода откровенно холиварные, ибо прослеживается четкая тенденция что не появляется в Постгрес — появляется «недавно», и еще совсем недавно она не умела то, что Мускул во всю умела лет десять назад (в прямом смысле). А зато Постгрес)) Судя по всему набросить удалось весьма.
UFO just landed and posted this here
а можно пример какой-то или баг-репорт, хочу посмотреть?
UFO just landed and posted this here
печаль какая. но как я понимаю, это проявляется или на очень длинных запросах или на тех, чьи данные были удалены с мастера прямо во время запроса на слейв?
UFO just landed and posted this here
Совсем недавно использовал Bucardo для репликации M-S, но, судя по обилию how-to в интернете, его чаще используют как раз для M-M репликаций.
поддержка 1с скоро?

оптимизатор запросов вначале делает отбор для простых условий, а потом для сложных как для 1с?

Тут вам дорога к Postgres Professional — у них были специальные сборки для 1С (но 10-ки пока не видать): https://postgrespro.ru/products/1c

Обещали скоро сделать.
И 1С опять будет вставлять свои костыли в код PostgreSQL?
Уж лучше пусть 1С научится работать с PostgreSQL как он есть. И всем будет проще. И PostgreSQL можно будет ставить из официальных пакетов и дистрибутивов. Речь о пакетах для linux.
тут проблема не платформы, а наследия языка.
1с изначально не поддерживала работу с версионниками поэтому в постгресс всталяется костыль для поддержки.
+ меняется оптимизатор запросов для более эффективной работы с запросами 1с.

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

Если ошибаюсь, пожалуйста поправьте.
Забавная штука. Архитектура у 1с очень хороша. Помню как на семёрке писал на высоконагруженном сервере toysql оптимизации выигрывая 2-3 раза. В 8, особенно в 8.1 они попытались всё это включить в движок. Но на пол пути у них что-то пошло не так (у меня есть одно большое предположение в лице корпорации из Редмонда, которое «попросило» сделать «не так»). В общем они не стали серьёзно допиливать до практически натива, а решили сделать упор на «кросс-платформенность» где самые красивые цифры у MS server+МSSQL
Поэтому можно бесплатно поставить Linux Server+ Postgresql, а можно MS server+МSSQL. ПРАКТИЧЕСКИ во всех задачах, кроме 1с первая связка будет производительнее. Но для 1с, даже если вы не верите в теории заговора — вторя будет быстрее.
Последние годы Linux Server+ Postgresql связка сильно отзывчевее.
Поддержу предыдущего комментатора.
В стиле КО: для настройки и там и там нужны прямые руки.
Я как то раз больше часа пытался объяснить 1с-программисту что такое внешние ключи и зачем они нужны. Как можно назвать хорошей архитектуру где контроль целостности реализован через дикие костыли?
А зачем нужны внешние ключи? (шутка).
Нет, ну серьезно. Поиграйтесь их построителем запросов.
У них архитектура предметно-ориентированная, что имеет свое отражение во внутреннем языке запросов, который суть обычный sql-select со всеми join, unit и т.п., только переведенными на русский. Вот только при более глубоком взгляде — очень много технических деталей скрыто под капотом. Вроде и sql-запросы, но протечек абстракции там меньше. Регистры скрывают свою реализацию, просто логика. У таблиц (документы, справочники и т.п.) есть подтаблицы, т.е. по сути движок неявно добавляет join-ы там где это надо, а мы строим запрос исходя только из бизнес-логики.

Резюмируя — внешние ключи это конечно очень важно, но… не для одинэсника.
Я понимаю что мой комментарий будет явно непопулярным в данной теме, но не все люди пишут на ассемблере. Не все пишут sql-запросы. Я например оказавшись в голом окружении сразу пишу себе какой-то простенький ORM. Я не в восторге от всего что сделали 1С, но общее направление у них верное — как можно больше технических деталей скрыть от прикладного разработчика. Ему предметную область понимать… освободите его хоть от технических подробностей).
Философия «каждая кухарка может программировать 1с» у них лежит в основе, но она себя не оправдала.
Во первых вы явно не сталкивались с глюками транслятора всей этой билеберды в SQL. Было дело мы полгода ждали лечения бага join. Кроме того уж незнаю что они там вытворяют но у меня есть отчетик который на sql выполняется секунду, а в 1с 25 минут. Вы считаете это нормальным?

«не для одинэсника»: вот потому одинэсники пишут какие то дикие костыли там, где все прочие ставят внешний ключ и не мучаются. А уж какое веселье наступает когда есть несколько табличных частей ссылающихся друг на друга, уухх…
И уж простите, но их конструктор почти неюзабелен на более менее крупных запросах.

ЗЫ у меня вообще есть подозрение что 1с более менее работает в крупных компаниях только за счет покрывающих индексов MsSQL
ЗЫЗЫ по поводу перевода на русский: я незнаю как вам но мне особую боль доставляет вспоминать «объединить» это join или union.
Философия «каждая кухарка может программировать 1с» у них лежит в основе, но она себя не оправдала.

Еще как оправдала. Покажите мне конкурента у которого другая философия и такой же масштаб клиентской базы (разумеется в их нише). Каждая кухарка здесь не в контексте просто низкого порога вхождения (по аналогии с киллерфичей пхп), а скорее по аналогии с Keyword Driven Testing и прочими подходами когда эксперта в предметной области ставят как можно ближе к коду.
Во первых вы явно не сталкивались с глюками транслятора всей этой билеберды в SQL.

Не сталкивался, признаюсь. Единственный мой опыт с 1с это поддержка РИБ на 65 удаленных узлов с обменом по фтп, файловым и некоторым самопальным гибридом из файлового и фтп с использованием пхп (да, это была конфигурация «Управление НазваниеОрганаВласти 8.0» и была закрытая, с обменом с базой в главке, а я поддерживал только областную структуру). База была адовая, сделана задней левой. «Разработчик» ориентировался изначально на аналогичную структуру в другой области, но там вообще несоизмеримые масштабы. Я к ним ездил по обмену опытом. Их начальник собирал на совещание всех инспекторов в одном кабинете. А у нас все начальники отделов в актовом зале не помещались. Ну и половины техпроцессов у них не было. Но хочу Вам сказать что хоть я лично и пострадал от «кухарки», но это нисколичко не аргумент против самого концепта. У того же 1с есть не только рядовые «специалисты» (или профессионалы? давно это было), у них есть уровни сертификации для разработки сложных проектов и там вполне вменяемый пипл тусуется. В моем случае это чисто проблема откатинга а не самого 1с. (Ну и конечно же в нашем случае 1с даром не сдался, он мало что решал из задач, зато лицензии таскать на каждое рабочее место..).

Я еще раз сделаю акцент — я не защищаю их реализацию, у меня у самого к ней много вопросов. Я просто поддерживаю их идеологию.
Кроме того уж незнаю что они там вытворяют но у меня есть отчетик который на sql выполняется секунду, а в 1с 25 минут. Вы считаете это нормальным?

Неа. Ненормально. Отчетик сами писали или левый «специалист»? ИМХО большая проблема 1с в том что они в своей сертификации ограничивают франчей снизу, но забывают об ограничении сверху. У них есть требования по минимальной квалификации чтобы лезть под капот, и даже по сути продавать полноценные коробки, но вот ограничения «если ты криворукий нуб без особой бумажки, то даже не пытайся писать собственную конфу или существенно допиливать существующую а то договор расторгнем и штрафов навешаем» — у них нет. И от этого все беды (не все, но многие).
вот потому одинэсники пишут какие то дикие костыли там, где все прочие ставят внешний ключ и не мучаются.

Неверное сравнение. Правильно так: «вот поэтому одинэсники пишут какие-то костыли там, где все прочие говорят: эй, программист, почему ты такой бестолковый, мне нужно вот эту штучку сложить с вот этой штучкой и распечатать так как требуется в нормативке».
И уж простите, но их конструктор почти неюзабелен на более менее крупных запросах.

Мы точно об одном и том-же говорим? Возможно я уже путаю терминологию. Я говорю не о query-bilder или объектной форме запроса данных из их скриптов, а о GUI-интерфесе. Он очень удобный и простой, и его возможности уходят далеко за пределы того что способен мысленно объять человек которому нужен такой конструктор. Тем более Если конфигурация делалась руками а не ногами. Я в нем делал трехэтажные запросы без проблем (join над юнионами из join-ов, да, без этого было никак, конфигурация была уж слишком сильно «откатовая»). И переделывал их тоже довольно глубоко в нем. Например спокойно накинуть еще четвертый уровень вложенности с групповыми операциями).
Вообще у меня техпроцесс был примерно такой:
1) набросать общую структуру в построителе
2) дописать мелочи типа сложных условий и т.п. в редакторе запроса (можно и в построителе, но тут уж быстрее руками чем мышкой)
3) отладить и отдать эникейщикам
4) дальше по обстоятельствам, или тупо выгрузка в эксель с допилкой, или добавляли свои условия, сортировки, группировки, в конструкторе, или я потом собирал полноценную обработку с красивым выводом

ЗЫЗЫ по поводу перевода на русский: я незнаю как вам но мне особую боль доставляет вспоминать «объединить» это join или union.

Это мне как раз вообще без вазелина вошло. Равно как и их «Если… то ..» и прочее. Буквально недели две на перестройку ушло. Мучения доставляло когда пишешь одновременно и на 1с и на чем-то нормальном, и помногу — были проблемы с клавиатурными автоматизмами, например знаки препинания разные и т.п.
Кстати а разве в запросах нельзя писать по нормальному? Насколько я помню скриптовый язык у них можно что анлийские ключевые слова использовать что русские, но не пробовал и не уверен что это касается запросов.
Еще как оправдала. Покажите мне конкурента у которого другая философия и такой же масштаб клиентской базы (разумеется в их нише). Каждая кухарка здесь не в контексте просто низкого порога вхождения (по аналогии с киллерфичей пхп), а скорее по аналогии с Keyword Driven Testing и прочими подходами когда эксперта в предметной области ставят как можно ближе к коду.

Исторически им уж так повезло. Хоть от 1с я не в восторге но их конкуренты еще хуже.

Неа. Ненормально. Отчетик сами писали или левый «специалист»? ИМХО большая проблема 1с в том что они в своей сертификации ограничивают франчей снизу, но забывают об ограничении сверху. У них есть требования по минимальной квалификации чтобы лезть под капот, и даже по сути продавать полноценные коробки, но вот ограничения «если ты криворукий нуб без особой бумажки, то даже не пытайся писать собственную конфу или существенно допиливать существующую а то договор расторгнем и штрафов навешаем» — у них нет. И от этого все беды (не все, но многие).

Отчет писал Специалист с большой буквы. Я проверял что он сделал.

Мы точно об одном и том-же говорим?

Об одном, но вы говорите об относительно простых вещах. У нас на 1с написана хитрая софтина учета с кучей табличных частей и вот по ней отчеты ну просто запредельно веселые.

В общем и целом я специализируюсь на разных утилитах оперирующих данными 1с при этом саму 1с никак не трогающих. Web-отчетики всякие хитрые, реестры платежей и прочее и прочее. И от того как 1с использует бд у меня волосы на голове шевелятся. Пусти начинающего php кодера к бд он и наверное умнее будет.
Исторически им уж так повезло. Хоть от 1с я не в восторге но их конкуренты еще хуже.

И майкрософт исторически повезло, и apple, и вордпрессу.
Клиентоориентированность и эргономика? Нет, лишь дело исторического случая.
Не поймите меня превратно. Яблоки скурвились, виндоус кривые а вордпресс — пережиток прошлого. Но в основе их успеха не случай или откаты, а исключительно удачные стратегические решения по основным принципам и подходам. К 1с у меня тоже много претензий, но сходу я их внятно не опишу. Но все эти компании для своего времени делали отличные решения и выбирали именно то, что было нужно рынку в то время.
Об одном, но вы говорите об относительно простых вещах. У нас на 1с написана хитрая софтина учета с кучей табличных частей и вот по ней отчеты ну просто запредельно веселые.

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

Да никто и не спорит что в свое время они сделали удачные вещи в удачное время. Но сейчас 1с жрет непозволительно много времени. Кроме того она полна совершенно идиотских решений за безумные деньги. Чтобы с ней работать в более-менее сложном случае нужно купить штук 5 конфигурация и то их универсальный кривой интерфейс ест ну очень много времени. Пример: если вы работаете с одеждой то вы поймаете на своем пути столько пней, столько веселья… Справедливости ради не они одни этим грешат. Я на презентациях всевозможных ERP прошу при мне завести для примера пуховик с сеткой размеров: как правило уходит 30-60 минут уходит на это дело и приходит понимание, что продукт совершенно неюзабелен в этом случае.

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

А вот тут как раз проблемка, ибо работа с кучей связанных табличных частей сопряжена со строительством заводика по производству костылей.
Кроме того:
— На Null не проверить
— составные индексы по бд не сделать
— функциональные индексы не используются
— да собственно даже в бд ничего не сделать, ибо все изменения вносятся через drop table

Я понимаю, что нынче политика: купите еще сервер. Но у меня при слове 1с-кластер начинает глаз дергаться.

И причем так везде. У нас с маленькой бд через обработку «выгрузка на сайт» выгрузка идет минут 20, а напрямую 0.2 секунды.
Интерфейс кассы на одну запись расходует минуты 2, а веб морда моя 20 секунд итд
Ну то что они переросли границы здравого смысла текущей архитектуры то да. То что они делают переусложненные конфигурации — тоже да. Но в своей основе архитектура была неплоха, и построитель — лучшее из того что я видел.
А так то да, 1с это как вордпресс).
Ну по построителю мне вас не понять, мне неудобно, я руками SQL пишу намного быстрее.

1с скорей с битриксом в сравнение идет, столько же бессмысленности и беспощадности.
Не впадайте в ошибку выжившего. То, что они так неплохо выжили на текущий момент, вовсе не обязательно говорит об их достоинствах. Могло действительно так повезти. И с большой вероятностью, именно так и повезло, во множестве важных деталей.
Ну повезло и «угадали потому что старались» конечно близки, но фундаментально отличаются. У 1с и других названных мною корпораций явно прослеживается парадигма максимального упрощения работы для всех. Для клиента, для франчей. Даже сами франчи/партнеров тоже важная часть идеологии.
А вы УстановитьПривилегированныйРежим(истина) делали?
можно ваш код в студию?
Это ничем особо не поможет, там достаточно сложные связи и ресурсов свободных немеряно. Код нельзя, он собственность клиента и итоговый запрос к бд просто невероятных размеров.
Если кто не в курсе, то 1С можно запустить и с interbase (или как оно сейчас)? По крайней мере, лет 10 назад было можно.
Я не буду советовать что никогда в жизни не делать. Просто поделюсь своим опытом. В одной достаточно большой, по нашим меркам (вся прибалтика), конторе есть зоопарк легаси, который крутится на интербейзе. «внезапно» база стала сыпаться, сервера стали виснуть и появились иные неприятности. Чего только не пробовали… Меняли сервера, версии, клиентов,…

Столкнулись с тем, что поддержки нет вообще. Отвечают по пол года в стиле «ничем не можем помочь, даже за деньги». Вызвали «крутого специалиста» из другой страны, которого рекомендуют сами интербейзы. Он посмотрел, сказал что «а фиг его знает почему оно ломается». У него есть какие-то приоритеты в тикетах разработчиков интербейза, но второй год результата ноль.

Теперь факты — проблемы не решены. Поддержка молчит. Спасаемся сложной системой бакапов-восстановлений каждые 15 минут. И срочно переписываем легаси. Я такого беспредела как поддержка «энтерпраиз уровня» базы не видел нигде и никогда за достаточно богатую айти жизнь. В один прекрасный день база просто перестает отвечать, не восстанавливается. Информации «что, собственно случилось-то?» — нет… Логи более чем бесполезны. Думайте сами стоит ли связываться, но если кто-то сейчас решает «а не выбрать ли мне интербейз для чего-то серьёзного» — полистайте гугль на предмет какие там бывают проблемы, посмотрите на даты этих самых проблем.

Просто личный опыт, ничего личного. Наболело. Если этот комментарий кто-то прочитает и задумается — возможно я только что спас людей от ранней седины.
Думаю, это и стоило подозревать, учитывая, что, после появления мускула и постгреса, интербейз исчез где-то за горизонтом.
Нативные запрос работает в десятки раз быстрее чем 1с транслированный в SQL. В самой 1с жуткий бардак, оптимизировать это бесполезно

Пакеты для линукс прекрасно ставятся из репозиторирия postgrespro — за что им низкий поклон. Вот бы ещё наконец для линукс дистрибутивов 1с сделали репозиторий. PeterG есть хоть какая то надежда? А то как то репозиторий для себя одного лениво становится поддерживать. А открыть доступ нельзя — атата за распространение.

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

В общем вы правы. Смысла во внешних ключах нет.
2. 1с может запрещать что угодно, но в рамках использования своего софта, а что мне делать с бд я как нибудь решу без них.

Нет смысла? прикольно. А как вы реализуете каскадные изменения связанных данных?
Суть не в рваных ссылках а в согласованности данных. Контроль согласованности на уровне приложения это невероятных размеров костыль.Частный случай: on update cascade, on delete restrict
Согласованность ≡ отсутствие рваных ссылок. Это и есть ваш on delete restrict
А on update cascade для суроогатных первичных ключей и их внешних ключей вообще не нужен, на они и ключи, и суррогатные.

P.S. Холивар на предмет составных естественных ключей, которым оно иногда може и бывает нужно, я здесь разжигать не хочу.
О как, действительно, упустил я этот момент.
Партиционирование… Как насчёт вырезки? Это ж самое правильное и вкусное русское слово!
раздел — вполн ттрадиционный перевод для partition/partion
А как же «разбиение»? Возьмите перевод того же Disk space partitioning — Разбиение диска.

Это процесс, а как назвать результат? Разбитый диск?

Разметка. Размеченный диск.

Диск то может и размеченный, а вот таблица точно нет

Простите, а что, теорию СУБД уже не преподают или не читает никто? 0_о
Во всех профильных книгах секционированию посвящают хотя бы маленькую главу.
Так, ну ладно, «вырезка» слишком будоражит умы =)
Тогда добавим немного пресмыкающихся: СРЕЗ. Собственно, оно так и есть, и даже вроде как логика аналогичная питону. Дай мне таблицу и я тебе срежу искомый кусок.
UFO just landed and posted this here

И опять про postgrespro https://github.com/postgrespro/postgres_cluster
Со слов Олега Сергеевича, если ничего не путаю, в их коммерческой версии есть и мультимастер для продуктива.

Ну понятно, что нормального мультимастера пока нет и раньше 12-13 версии pg его ждать глупо. По поводу костыльной реализации мультимастера на базе логической репликации здесь и сейчас… можете попробовать на двух серверах создать родительскую таблицу с двумя партициями. Ключом партицирования будет id сервера. На первом сервере при вставке в родительскую таблицу данные попадут в первую партицию, на втором сервере — во вторую. Первая партиция на втором сервере будет подписана на первую партицию на первом сервере. Вторая партиция на первом сервере будет подписана на вторую на втором. По факту такая конструкция может пережить сплит брейн за счёт того, что данные вносятся на каждом сервере в свою партицию и уникальность им обеспечит id сервера (поэтому конфликтов не возникает). Ну и делать такие вещи есть смысл не через нативное партицирование десятки, а через pathman. Но это так, теория, подобные костыли я не проверял.

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

Можно. И даже нужно. Под мои задачи ограничения не существенны. Мне, например, на данный момент через питон приходится делать выборки по меткам времени, а их может быть неопределённое число, скажем, чуть ли не каждая минута за годовой интервал. Приходится костылить с существенным объёмом данных — выбрать всё согласно некоторому ключу, а потом программно делать срез из большого массива. Теперь я могу решить эту проблему одной строчкой и экономить драгоценную память (для SoC это очень существенно).
Пробовал 10 версию ещё с беты, в целом приятно, но пока пришлось откатиться на 9.6, т.к. Doctrine DBAL пока не умеет работать с новым видом хранения сиквенсов, а следовательно, ломаются миграции (генерация).
Если кто-то хочет знать, когда починят, то можно подписаться на этот баг.
А что надо знать и кем поработать чтобы хорошо разбираться в тех терминах, что описаны для Postgrade? ( секционирование, репликация) — как отойти от среднего уровня — ?
Это админы учат?
А Вы скачайте копию и попробуте запустить. Пoтом пройдитесь по пакету контроля качеством,. Помню первые две трети разобрал и многому научился.

Там огромное количество самых простеньких на вид запросов, пока не наткнетесь на один, который вылетает с ошибкой. Ну и как пройдетесь по цепчке сопровождения дефектов, чтобы понять «почему», считай 50% науки освоили. Потом за каждые оставшиеся 10 придется уже платить сединой. А за последние 10 воюют все профессионалы.

Ну а там и до репликации доберётесь, если не сами, то если заказчик на проэкте потребует.
Всё конечно замечательно. Но планируется переход на отечестенные продукты. Есть замечательная база «Линтер», от работы с которой я лично получаю огромное удовольствие последние несколько месяцев.

Сильной стороной Постгресса была и остается MVCC.

В конечном итоге, сегодня все производители СУБД вынуждены признать превосходство этой модели и внедрить её поддержку, некоторые после десятков лет вращения пятой точкой.

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

Т. е. процесс внедрения ПО с открытым кодом сегодня находится перед развилкой, где одна команда людей, не боящихся писать на Си системный код может произвести скачек в области восприятия Постгресса.
Кстати, PostgresPro вроде имеет свой сертифицированный форк. А расскажите про Линтер, что за зверь такой? А то в интернетах про него внятных технических подробностей не нашёл при поверхностном поиске. И раз вы сказали, что сильная сторона pg — это mvcc, то что тогда у Линтера? Блокировщик?
Скачал пробную копию с узла Релэкс. Выполнил процедуру инсталяции. Нашел учетную запись SYSTEM\MANAGER, и пока гоняю запросы, копирую из тюториал процедуры, запускаю утилиты.Всё это на моих домашних Win — 10.

Первое и самое яркое впечатление — все запросы отвечают с бешенной скоростью. Как человек с богатым опытом, скорость ответа заметна невооруженным глазом и первый индикатор класса базы.

Второе, все утилиты работают безупречно. Рабочий стол — конфетка, вылизан дочиста, писать запросы удовольствие. Сравнивая с десятком рабочих столов, от самых дорогих до SQL Workbench My SQL, собранного из исходников GitHub с кастом тулсами собственной добавки, этот самый легкий в общении и никогда не вываливается, от слова «вообще».

Если делаю ошибки, система отвечает внятными оповещениями. Процесс базы, сервис, выполняется уже несколько месяцев без нареканий. Запуск сервиса происходит молниеносно.

Отличная документация, отполированная и по содержанию и по презентации. В каждой детали изделия чувствуется класс разработчика.

Пожалуй самым трудным было добраться до странички чтобы скачать копию. У меня не очень цепкий взгляд и заняло какое — то время оглядеться на узле Релэкс. Но дальше все гладко.

Такие вот впечатления.

С Вашего разрешения сегодня позднова — то, посмотрю реализацию управления запросами и отвечу завтра.
«Боги…»

Верующий…
Вчера найти ответ на Ваш вопрос не удалось. Но в процессе поиска нашел одну интересную фишку «автоматическая индексация данных», задаётся опцией на уровне базы данны в административной утилите.

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

В общем то это надо ещё проанализировать, но складывается впечатление, что эти опии позволяют выбирать между, если не MVCC, то «мягким», «жестки» и по возможности взаимонезависимым распределением структур занятых защитой целостности данных в потоке на уровне клиента. Своеобразный подход, который больше нигде не видел. И потому не обратил внимание.
Согласно руководству «Архитектура СУБД» на сайте Линтер linter.ru/ru/documentation
Раздел «Многоверсионная модель данных»
— Начиная с версии 6.1, СУБД ЛИНТЕР поддерживает многоверсионную модель данных.
— Реализация на уровне архитектуры позволяет обращаться к ядру СУБД Линтер в канале соединения по выбору с многоверсионной моделью данных, либо моделью доступа с блокировками. В свою очередь, многоверсионая модель доступа к данным предлагает выбор между блокирующей ( pessimistic ) и не блокирующей ( optimistic ) моделями доступа к данным конкурирующих запросов.
Из истории PTC (производитель программного обеспечения)

( Материал из Википедии — свободной энциклопедии )

PTC: Публичная компания, Листинг на бирже NASDAQ: PTC
Основание: май 1985, 31 год назад
Прежние названия: Parametric Technology Corporation
Основатели: Самуэл Гейсберг, Майк Пейн
Расположение: Нидем, Массачусетс, Соединённые Штаты Америки
Ключевые фигуры: Дональд К. Гриерсон (председатель совета директоров), Джеймс Хеппельманн (президент, генеральный директор) [1]
Отрасль: CAD/CAM/CAE/ PLM Software/ ALM/ SLM/ IOT
Продукция:PTC Creo, PTC Windchill, PTC Mathcad, PTC Integrity, PTC Servigistics, [1], [2]
Операционная прибыль: ▼ 41,6 млн долларов (2015)[2]
Чистая прибыль: ▼ 48 млн долларов (2015)[2]
Число сотрудников: 5982 (2016)[2]
Дочерние компании: PTC (Canada)[d]
Сайт: ptc.ru.com
PTC, Inc (прежнее название Parametric Technology Corporation)

ru.wikipedia.org/wiki/PTC_(%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F)

2009 — Приобретение Relex Software с целью получения инженерного ПО для расчета надежности.[13]

То есть на сегодня Линтер это один из отделов частного предприятия полной ответственности, который рекламирует производство интеллектуальной матчасти для Министерства Обороны Российской Федерации ( пакет Линтер Бастион ).

Ну дела. А я тут понимаете ли, учу «отечественное программное обеспечение».
Сидим на pg 10 с 3ей беты на продакшене, в первую очередь из за встроенного партицирования, полет отличный. Печально что логическая репликация не поддерживает репликацию схемы

Интересно, насколько вероятно что "логическая репликация" сможет сходу заменить skytools… :)

Вот не люблю я эти версии Х+1, в них непонятны milestones. Если на разницу 8 и 9 смотрели как вверха на скалу, которую надо забраться, потому что нас ждёт куча новых фич; то между 10 и 11 будет разница неочевидная. И чем плохо было обновление для фиксов с 10.х.1 на 10.х.2 версию?
Когда читал статью думал речь идет о переходе на semver, но после вашего комментария засомневался…

На самом деле теперь нумерация стала ближе к SemVer, а главное — логичней. Старая нумерация: MAJOR1.MAJOR2.PATCH, новая — MAJOR.PATCH. Т.е. 9.6 — это был мажорный релиз после 9.5, несовместимый с ним по формату внутренней структуры файлов БД. Минорных релизов в понимании SemVer у PostgreSQL попросту нет. Цифру MAJOR1 скорее меняли по каким-нибудь праздникам, нежели из соображений обратной совместимости — логика там вроде бы и есть, но она не очень очевидная (так, 9.1 от 9.0 отличалась едва ли не сильнее, чем 9.0 от 8.4, хотя я тогда только начинал работать с постгре и помню плохо). Обратную совместимость поддерживают очень далеко в прошлое (приложению написанному под 8.4 вроде можно и сейчас подсунуть свежий постгрес и всё будет ок).

Секционирование осталось старое — основанное на наследовании таблиц, а в релизе просто добавили синтаксический сахар
Очень хочется вешать foreigin key на наследованные таблицы. Подозреваю, что в 10 это все еще не работает.
Sign up to leave a comment.

Articles