После полугода разработки представлена (http://permalink.gmane.org/gmane.comp.db.postgresql.announce...) первая бета-версия СУБД PostgreSQL 9.2, в которой проведена значительная работа по увеличению производительности и масштабируемости, как горизонтальной (распределение нагрузки на несколько серверов), так и вертикальной (оптимальная работа на больших мощных серверах).
Ключевые улучшения (http://www.postgresql.org/docs/devel/static/release-9-2.html):
- Поддержка (http://www.postgresql.org/docs/devel/static/datatype-json.html) типа данных JSON и встроенные средства для манипулирования данными в формате JSON, что позволяет создавать гибридные документо-реаляционные базы данных. Дополнительно представлен набор сопутствующих функций для преобразования массивов и строк в JSON-представление;
- Новые типы (http://www.postgresql.org/docs/devel/static/rangetypes.html) для определения диапазонов (INT4RANGE, INT8RANGE, NUMRANGE, TSRANGE, TSTZRANGE и DATERANGE), которые могут быть использованы в календарях, временных рядах и аналитических приложениях;
- Расширение возможностей оператора ALTER, упрощающих изменение и обновление структуры работающей БД. Снижение числа ситуаций, когда необходимо перестроение индексов и таблиц при выполнении ALTER TABLE. Поддержка выражения "IF EXIST", позволяющего игнорировать действие если элемент не существует (например, "ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar"). Добавлены выражения: ALTER FOREIGN DATA WRAPPER / RENAME, ALTER SERVER / RENAME, ALTER DOMAIN / RENAME;- Поддержка каскадных репликаций, при которых допускается репликация между slave-серверами (ранее slave-сервер мог получать данные только от master-сервера). Возможность создания территориально распределённых реплицированных резервных БД;
- Включение в поставку утилиты pg_receivexlog для архивирования изменений в файлах xlog по мере записи данных, не дожидаясь окончания полного формирования xlog-файла;
- Многочисленные оптимизации производительности, в том числе:
- Режим сканирования только по индексам при котором scan-операции манипулируют только содержимым индекса, не обращаясь к базовым таблицам;
- Расширены возможности масштабирования работающих только на чтение конфгураций, поддерживается задействование до 64 процессорных ядер и обеспечения производительности на одном сервере на уровне 300 тысяч запросов в секунду;
- Ускорены операции записи данных, включая выполнение групповых коммитов;
- Снижена нагрузка на CPU.URL: http://permalink.gmane.org/gmane.comp.db.postgresql.announce...
Новость: http://www.opennet.me/opennews/art.shtml?num=33851
Да простится мне моя невежественность!
А возможно ли ожидать от postgresql при работе с 1Сv8 блокирования аналогично MSSQL?
нет, потому что разная архитектура - постгрес версиооник, а мсскл блокировочник
> нет, потому что разная архитектура - постгрес версиооник, а мсскл блокировочникВы уверены в сказанном?
уверен
1. Начиная с MS SQL 2005 уже есть версионность, какая-никакая.
2. 1С приделала еще один режим блокировок в своем сервере приложений, как раз позволяющий работать правильно с версионниками.
Мне 2-х лет хватило. Больше не возникает желания работать с MSSQL. Тогда еще 7-я версия была и следующая, уже не помню версию. Не думаю, что синтаксис хранимых процедур с тех пор стал лучше. Как помнится. Очень медленно работали функции с переменными таблицами. Приходилось постоянно использовать временные таблицы при вызове одной процедуры в другой вместо тривиального select * from func().
Мне хватило одного раза, когда пришлось изменять структуру таблиц делая из простых полей первичные ключи.
Хранимки - это пережиток прошлого, когда кто-то очень "умный" думал, что при помощи SQL можно делать приложения. Из личного примера: СУБД использую исключительно для хранения таблиц и вьюшек. Всё остальное (защита, проверки) делается на уровне сервера приложений. Ну, FK само собой существуют! :) Поэтому перенос такой базы или апгрейд сервера практически ничего не затрагивает. Рекомендую.
Ути пусичка :) Если в твоём мухостранске жтого нет - оно нигде не надо?
Ну дак автоматизация пивного ларька слегка отличается от чего нить телекомовского ...
Кстати да - прийди с такой идеей к телекомовцам :) вышвырнут как накадившего на ковёр Бобика :)(Я когда в их OEM глянул и узрел ~300K writes/sec - слегка поумнел :)
Телекомовцы на MSSQL смотрят не просто косо, а очень косо - это раз.
Два - как раз в телекоме есть тенденция к выносу логики на аппсерверы, поскольку движок БД обычно кластерный либо представляет собой "сборную солянку" из нескольких.
> Хранимки - это пережиток прошлого...Уберите детей с форума. Во первых никто кроме вас не думал что на SQL можно делать приложения, а вот обрабатывать данные - нужно. Вместо того чтобы хранить и обрабатывать данные в одной системе вы рожаете две, чем усложняете общее решение, теряете в производительности (хотя бы за счет вытягивания данных во вне), а также теряете в удобстве (PL языки специально заточены на решение такого рода задач, изначально удобны, а для общесистемных языков как минимум приходится писать обертки, что дополнительное усложнение и снижение производительности)
Тогда непонятно зачем Вам субд. Вы на диск писать не умеете? Поддержка целостности данных при записи через сервер приложений внешними ключами - лишние тормоза на вставке и обновлении.
Чтение трассировки ОРМ при отладке - это вообще ни с чем не сравнимое удовольствие. Ну а про призводительность Вам уже писали.
>>вместо тривиального select * from func().Не могли бы Вы рассказать о СУБД, в которых из процедуры можно вернуть что-то, имеющее отношение к множествам и отличное от курсора.
У Вас даже имя процедуры как бы намекает на непонимание разницы между функциями и процедурами.
> Начиная с MS SQL 2005 уже есть версионность, какая-никакая.Никакая.
>2. 1С приделала еще один режим блокировок в своем сервере приложений, как раз позволяющий работать правильно с версионниками.*35673 строки матов о том КАК они это сделали вырезаны цензурой.*
Только в режиме "управляемых блокировок".
После перехода на управляемый режим блокировок в 1С82, блокировками управляет сервер 1С. В таком режиме даже при работе на PostgresSQL излишних блокировок нет.
Фраза построена так,будто в PostgresSQL есть какие-то 'лишние' блокировки. Это в версионнике то)
Писать бы стоило,что в таком режиме ядро одинэса не создает ненужных блокировок.Ну или что создает только нужные.
Включите управляемый режим блокировок 1с:Предприятие и будет Вам счастье
> Включите управляемый режим блокировок 1с:Предприятие и будет Вам счастьеИ допишите нужный код везде, где требуются блокировки, часто надо перелопатить полконфигурации :)
Вообще-то к Постгрессу это отношение не имеет. 8.2 имеет управляемые блокировки и практически все стандартные конфигурации их уже используют. С управляемыми блокировками Постгресс работает аналогично MS SQL, не блокируя таблицы целиком.
Только MS SQL и DB2 поддерживают автоматические блокировки. Но это далеко не лучший вариант, поэтому новые конфигурации для 1С пишутся с использованием управляемых блокировок уже на уровне платформы что гораздо эффективнее. Из уже готовых конфигураций ручные блокировки используют Бухгалтерия 2 и Управление торговлей 11. Так что обновляйтесь и будет вам счастье.
Замечательно ! Плотно разработка идёт. Очень радует, что есть ТАКИЕ опенсурс решения.
А также радует что есть Enterprise DB, которая такие замечательные продукты внедряет и поддерживает.
Мне пакеты (как в Oracle) нужны. Даже без шифрования.
Для объединения процедур/функций/констант/переменных и т.д. внутри одной сущности.Интересно, когда-нибудь их сделают.....
сделай отдельную схему и объединяй там что хочешь
Отмазка. Пакетные переменные (производительность), инициализация пакета (гибкость), не в курсе? Элементарно поиск по пакету (одному файлу) гораздо проще чем по куче отдельных функций, типов и т.п. Ну и необходимость жесткого указания имени схемы перед именем любого ее объекта (да, да, перед всеми таблицами во from и т.п.) тоже доставляет :)
set search_path никто не отменял
если у меня из одного пакета вызываются функции другого то search_path надо перестраивать перед каждым вызовом? :) (при условии что внутри схемы, объекты в запросах, например таблицы той же схемы, или функции, не содержат префикса в виде имени этой схемы)
> set search_path никто не отменялА хоть какой нить аналог пакетных переменных есть? Простая задача - хочу общий набор переменных/констант, единый для нескольких функций, ну естественно чтобы при исполнении эти значения были рядом (производительность) а не лезть каждый раз в таблицу. Как?
В вашей СУБД, где есть все эти пакетики и т.п., нет никакого поиска по одному файлу. Внутри всё хранится точно так же, в обычных таблицах БД разбитое на множество записей и хз (условно) где физически локализованно. Разницы в физическом представлении здесь практически нет.Использование схемы, конечно, не так удобно как концепция пакетов, но тем не менее вполне юзабильный паттерн. Вы просто беситесь с жиру.
> Ну и необходимость жесткого указания имени схемы перед именем любого ее объекта (да, да, перед всеми таблицами во from и т.п.) тоже доставляет :)
Всё зависит от способа проектирования приложения для СУБД. Эти "неприятности" тоже преодолимы, жёстко всё указывать не является необходимостью.
Да я не говорю что он не юзабельный, приходится юзать, только пакеты реально лучше, логичнее и функциональнее чем этот костыль, и не надо говорить что желание программиста иметь в среде пакеты (модули) это бешение с жиру :)> жёстко всё указывать не является необходимостью
см. ветку выше
> Разницы в физическом представлении здесь практически нетВ физическом ее нигде нет, все 0 да 1 :) А вот с точки зрения конечного программиста, в оракле я открываю пакет, для меня это единый кусок текста, как модуль, с описанием интерфейса, общих переменных, типов, структур и т.п, и элементарно по всему нему Ctrl+F. А что в слоне? как по схеме искать? sql дамп делать и по нему? такое хоть в какомнить фронтенде сделано? (и не надо тут в очередной раз отмазываться что это не проблема слона, он рулит - ему и отвечать)
А я хочу в оракле объект назвать длиной более 200 символов, когда это сделаю?
The system uses no more than NAMEDATALEN-1 bytes of an identifier; longer names can be written in commands, but they will be truncated. By default, NAMEDATALEN is 64 so the maximum identifier length is 63 bytes. If this limit is problematic, it can be raised by changing the NAMEDATALEN constant in src/include/pg_config_manual.h.http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical...
поддержка JSON - жду не дождусь
Уууу... поддержка JSON - это весч! С этим можно мноооого хорошего наворотить. Молодцы разработчики, респект!
> Уууу... поддержка JSON - это весч! С этим можно мноооого хорошего наворотить.Я тоже плотно использую JSON, но только на уровне приложения. А чего хорошего он даст на уровне записей??
Я так понимаю, это элементы NoSQL. Как возможная альтернатива MongoDB итд
Можно нативно хранить произвольные данные (раньше тоже можно было, но приходилось сериализовать в текстовое поле).Можно делать выборки с произвольными данными - эта штука гораздо полезнее. Можно при определенных условиях отдавать в выборке разные поля в JOSN