Гугловый аккаунт у меня есть, но этого оказывается мало:


Давно заметил - отечественные разработчики, даже опенсорс, зачастую страдают неизлечимой паранойей Так что спасибо за информацию, что ничего хорошего не планируют. Нафига тогда вообще конференция? Или по итогам конференции оказалось, что поддержка xml и полнотекстовый поиск это еще не все, что нужно от современной СУБД?..

Спасибо, хотя мы могли бы и в формате рассылки почитать.

Я бы пожалуй добавил к перечисленным вопросам еще парочку - о поддержке in-memory баз и таблиц (без журнала транзакций) и репликации между disk-based и in-memory таблицами, в т.ч. возможность при останове постгреса сбрасывать in-memory таблицы и базы на диск, а при запуске - считывать с диска (как на локальном постгресе, так и на удаленном).

Не уверен, что это кому-то интересно именно в постгресе - традиционно задача решается с помощью различных встраиваемых СУБД.
Сам я очень хотел бы увидеть в постгресе возможность подключать различные движки для хранения данных, как сейчас это сделано с процедурными языками, - тогда репликация и работа in-memory перестанет быть проблемой. Например, создал таблицу in-memory на движке mnesia, а этот движок умеет распределенную работу. Создал таблицу на движке эскулайт - можно сделать реплику нужных данных и отправить прямо в браузер (мозилла умеет с эскулайт работать). Конечно, работа планировщика постгреса станет нетривиальной, поскольку придется взаимодействовать с планировщиками подключенных движков, но это окупится неограниченным масштабированием полученной системы.

Andrey Daeron
Думаю планировщик станет настолько нетривиальным, что Ваши жалобы на нестабильность/непредсказуемость плана выполнения покажутся десткой забавой )))

Если ограничиться возможностью выборки только из таблиц одного типа, то можно просто передавать запрос планировщику соответствующего движка. Связывать разные типы таблиц можно на уровне функций на том или ином языке, благо их поддерживается множество. А использование стохастических методов в движке СУБД имхо тупиковый путь. Но про планировщик я ничего не говорил, поскольку подавляющее большинство проектов не нуждаются в мощном планировщике (уж если мускуль справляется, то и текущего планировщика постгреса с избытком хватит). Сейчас планировщик постгреса не умеет эффективно работать с результатами выполнения функций (те запросы, что я приводил, активно используют различные функции на pltcl), но это спорный вопрос, нужна ли такая функциональность в принципе. Возможно, более адекватным решением стало бы встраивание постгреса в систему анализа, но постгрес такую возможность не поддерживает.

А самое пожалуй важное - увидеть план развития постгреса на ближайшие 5 лет. Для корпоративного ПО такой план просто необходим.

MasterZiv
Поглядите на MySQL, там всё равно только два движка используются,
и то - не одновременно (одни - один, MyISAM, другие - другой, Inno)


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

К чему это приведет - сложно сказать. А вот отсутствие плана разработки точно ни к чему хорошему не привело и не приведет. Имхо движок постгреса и так в свалку превращают поддержкой разных xml и fts, которые были модулями и должны были ими остаться. Жизнеспособность же модулей из contrib вызывает сомнения, хотя в какой-то версии постгреса когда-то они работали (непонятно, правда, насколько успешно).

iz MBGИмхо движок постгреса и так в свалку превращают поддержкой разных xml и fts, которые были модулями и должны были ими остаться.

Совершенно неверное мнение. Поглядите на то, как сейчас Том Лейн противится включению PL/Proxy в ядро и поймете, что свалкой движок, который так принципиально охраняется высококлассными разработчиками, назвать ну уж никак язык не поворачивается. Главное, все, что включается в ядро, включается туда не из каких-нибудь маркетинговых соображений, а во благо пользователей. Мне лично и огромному количеству проектов, в которых я участвую, от ФТС в ядре только польза. И я считаю, что самые популярные контрибы должны плавно мигрировать в ядро, чтобы многочисленные пользователи не мучились с их установкой. Да, еще не забывайте, что многим фичам вы можете сделать --disable.

Postgres 8.1 - 2.8 Mb, 8.3 - 3.6 Mb. Для сравнения, кстати, initrd.img-2.6.24-1-686 "весит" 5.8 Mb. Это уже слишком большой объем кода. А ведь стоит еще учесть те дополнительные библиотеки, которые вызываются модулями или функциями.

Если вам нужен полнотекстовый поиск, вы могли собрать постгрес с его поддержкой. А мне вот этот поиск не нужен, но собрать постгрес без его поддержки я не могу - судя по объему патчей, принятых для интеграции fts, был перелопачен чуть ли не весь код.

Открытое ПО тем и ценно, что дает почти полный контроль (конечно, время ограничено, будь то время на разработку или изучение документации и исходников). Например, понадобится мне реализовать криптацию данных на уровне страниц данных с помощью российских криптоалгоритмов (это одно из требований для некоторых видов сертификации продукта) - я не смогу это сделать в постгресе. В эскулайте такая работа займет у меня несколько недель времени, но она осуществима. Если же такая задача встанет для проекта на постгресе - это катастрофа, поскольку потребует замены СУБД. Полнотекстовый поиск, думаю, мне понадобится через несколько месяцев - но я предпочту сделать стеммер для поддержки морфологии русского языка для эскулайт, пользуясь словарем и affix-файлом для русского языка из ispell (в постгресе есть и другие возможности в моделе полнотекстового поиска, но это как пример). Это займет одну-две недели, но на фоне нескольких лет поддержки проекта это совсем немного. Зато я получу модуль, который можно модифицировать, не переделывая саму СУБД, скорость работы которого можно оценить независимо от СУБД и т.п. И так думаю не только я - PostGIS уже имеет аналог - spatialite для sqlite, есть полнотекстовый поиск fts3 для sqlite и целая куча более мелких модулей (как пример - модуль поддержки операций над ipv4 адресами я написал и протестировал за один день, собрал эскулайт с ним и все это не потребовало особенных усилий). Поиск - это хорошо, но без поддержки collation уже начинаются проблемы, а уж для добавления собственного стеммера пересобирать постгрес...

Если вы посмотрите внимательно, то расширений к постгресу совсем немного для проекта, развивающегося более двух десятилетий. А те расширения, что есть, зачастую недоделаны и лежат в контрибах. В частности, потому, что требуют модификации постгреса для своей быстрой и/или стабильной работы. Получается "черный ящик" вместо расширяемого проекта. Вот вам результаты включения избыточного кода в ядро системы. Я бы с удовольствием сделал расширения, необходимые мне в постгресе, но черта с два их удастся нормально "прицепить" в виде сторонних модулей - тот же cube и пр. требуют поддержки в ядре, иначе овчинка выделки не стоит. Попытки менять ядро системы тоже бывает проваливаются - вспомним pgCluster.

С точки зрения пользователя все может не так заметно, но при отсутствии разработчиков чем вы собираетесь пользоваться?..

Andrey Daeron MBG
А самое пожалуй важное - увидеть план развития постгреса на ближайшие 5 лет. Для корпоративного ПО такой план просто необходим.
Т.е. Вы всерьёз собираетесь строить свои планы опираясь на планы развития свободного продукта?
Я не к тому, что постгрес будет/небудет развиваться и достоин/недостоин быть СУБД в корпоративе, но доже роадмепы Мелкомягких, Ораклов и т.д. весьма плавающи.

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

izMBG, вы все понятно разъясняете, во многом я с вами согласен. Но вы все же представляете очень редкое меньшинство. Не каждый возьмется писать полнотекстовый поиск в SQLite самостоятельно.

Разработчик модуля известен и доступен в рассылке и по почте; над чем сейчас идет работа, известно; как подключить свое расширение для поиска, разработчик подробно объяснил в рассылке, когда был задан соответствующий вопрос. Также известно, что есть несколько человек, кто готов помочь с тестированием (не русского языка, разумеется, но это не важно). Плюс код компилируется как загружаемая библиотека (или вместе с движком, при желании).

Вот хотелось бы и для постгреса чтоб была подобная инфраструктура для разработки. И перевод документации тут явно не поможет, поскольку язык общения в рассылках и по почте - английский. Чтобы этого добиться, нужно четко определить цели и задачи проекта. Если пять лет назад я знал, как позиционировать постгрес, то теперь уже затрудняюсь - открытых проектов стало очень много, да и требования с каждым годом растут. Слоган "самая продвинутая из открытых СУБД" уже ни о чем не говорит, ведь есть и более быстрые, и меньшие по размеру, и имеющие больше модулей, и умеющие распараллеливаться, и работающие на кластере...

Что касается соответствия стандарту SQL, то тут, признаться, не могу сравнивать - в основном работа идет из приложений через биндинги к тому или иному языку, через psql запускаю только скрипты, а там стараюсь не мудрить, иначе себе дороже - через год-другой разбираться в запутанном sql. Да еще и постгрес (как и эскулайт) давно обвешал наборами своих функций, сразу и не вспомнишь, что из стандартного комплекта. Года четыре назад постгрес действительно прекрасно соответствовал стандарту, так что будем считать, что и сейчас так оно и есть. Но вот биндинги к постгресу весьма посредственные, приходится свои обертки писать. А ведь, как говорится, "театр начинается с вешалки".

Прошу прощения, что вытаскиваю эту тему снова, но появилась новая информация к размышлению. См.
http://www.opennet.ru/opennews/art.shtml?num=17234

Лучшие СУБД по оценке SD Times:


Кажется, комментарии излишни.

Author the new one
Конечно. Вот SQL Anywhere новый вышел. Он позиционируется как мелкий сервер на побегушках, между прочим. Просто сравните:

http://www.sybase.com/files/White_Papers/Sybase_SQLAnywhere_Top10newFeatures_wp.pdf

Ух ты, Unload to variable и Openstring я тоже хочу. Буду думать, как это в эскулайте сделать.

Author the new one MBGУх ты, Unload to variable и Openstring я тоже хочу. Буду думать, как это в эскулайте сделать.

А Immediate Materialized Views - не? Мегавещь же. А MERGE?

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

Materialized Views всех видов реализуются виртуальными таблицами или триггерами, если не находится готовой реализации, делается своя. Ага, на С надо писать, но в этом есть свои прелести.

MERGE вообще не понял зачем, это и так реализуется стандартными запросами.

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