FreemanZAV
Про Firebird слышал?

Это который code fork оупенсорсного интербэйса? Слышал, конечно. ИМХО более перспективная затея чем Постгрес потому что версионность реализована толковее (вакуум не нужен), когда (и если) вылечат детские болячки. Был еще и российский проект Yaffil, по сути оптимизированный хак оупенсорсного интербэйса. Они вроде даже code merge собирались делать. Предлагать нечто интербэйсоподобное сегодня в качесве "взрослой СУБД" - по меньшей мере несерьезно. Масштабировать такое решение можно только через "scale out" а не "scale up". Чтобы масштабировать такое решение "по взрослому" придется замастырить программно-аппаратную приблуду вроде Байнета. А это задача по сложности как минимум сопоставимая с написанием новой СУБД.

Вообще, я лично так вижу оупенсорсные СУБД:
1. CA OpenIngres, MySQL MaxDB (aka SapDB) - наиболее "взрослые" в смысле что на них можно сделать реальный серьезный проект, например что-нибудь автоматизировать.
2. MySQL который с ядром от InnoDB. Ниче база, хотя мягко говоря "не свободна от недостатков". Будущее туманно ввиду покупки Ораклом InnoDB.
3. Interbase - образные, потенциал безусловно есть, но лечить надо очень многое. По сути - есть задел аналогичный коммерческим СУБД на 1989 год.
4. Постгрес - его лечить "дохлый номер". Там идеология порочная в принципе, по хорошему ее надо поменять, а СУБД переписать. Написать "с нуля" скорее всего дешевле. Миша Стоунбрэйер вообще лопух каких мало.

DocAl 1024
по сабжу. а на кой черт делать свою субд в россии? ради идеи? ф топку. как
коммерческий продукт? не окупится. в противном случае уже сделали бы. там
одни расходы на ниокр какие будут... не, не окупиться.
*******************
например у военных там где нельзя применять вражеские компоненты - никакие
откаты не пройдут. Значит можно хоть свой вариант линукса протолкнуть.
Вдругих областях конечно проще купить чем создавать

У военных УЖЕ есть свой вариант линукса.)
Зовётся МСВС
СУБД, кстати, тоже есть.
Вояки форканули код от Red Hat с ядром 2.4.x, не мудрствуя лукаво. СУБД-то Линтер-ВС небось?

Yo.!!2Зл0й

зря вы так о postgres, пусть с вакумом но его можно юзать на серьезных задачах, firebird же это нечто - там нет лога транзакций, там бэкап может оказаться "невостановимым" , там delete from test where test.ID in (select id from test GROUP BY id HAVING count(id)>1); удалит совсем не то что вы думаете (отсутсвует cursor stability), нет нормальной поддержки smp и тот же вакум, просто там каждая сесия чистит за других.
так что с потенциалом там все гораздо груснее ...

К Firebird лог вроде прикручивают с помощью посторонней приблуды. По уму эта приблуда должна быть интегрирована в СУБД что скорее всего со временем произойдет. Работы там непочатый край. Косяки с реализацией SQL есть в любой СУБД, вопрос в том на сколько это мешает жить. ИМХО идея где читающая сессия чистит мусор - правильнее чем вакуум, но по уму хранить версии надо не в блоках данных а в логах, которые можно выборочно кешировать. По идеологии проблем с SMP в интербэйсе нет, просто написано криво. В общем из Firebird можно сделать нормальную СУБД, но придется немало потрудиться. На сегодня это в лучшем случае - полуфабрикат. С постгресом все гораздо хуже т.к. фич и кода гораздо больше, причем на "кривой" идеологии хранения версий в страницах данных.

Вообще, в написании ядра СУБД (обработка транзакций), того самого "изюма из булки" дальше всех продвинулись ребята из InnoDB. Поэтому Оракл их и купил "от греха подальше".

guest_20040621> 1. CA OpenIngres, MySQL MaxDB (aka SapDB) - наиболее "взрослые"
> в смысле что на них можно сделать реальный серьезный проект,
> например что-нибудь автоматизировать.

И много для них сторонних open source разработок?

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


guest_20040621
> 4. Постгрес - его лечить "дохлый номер".

Для 90% проектов он подойдет в том виде, который есть. И мигрировать с/на
PostgreSQL - элементарно.
Идеология реализации версионности в Постгрес - порочна в принципе. Это - не лечится. Причем у постгреса "запущенный" случай болезни, когда поверх столько всего написано что поменять уже ничего нельзя.

DocAl Зл0й
Вояки форканули код от Red Hat с ядром 2.4.x, не мудрствуя лукаво. СУБД-то Линтер-ВС небось?
"Да" по обоим пунктам. И даже не надо мне рассказывать родословную этого "Линтера-ВС", их-то устраивает, и ладно.)

Знаем мы как их "устраивает". Их уже "устраивал" истребитель И-153бис в 1941 г. и танк БТ. Это "устаивает" дорого обошлось, но это уже оффтопик. Как человек служивший в армии и хорошо знакомый с оборонной промышленностю СССР, я крайне скептически отношусь к способностям российских военных принимать правильные решения, уж извините. "Кто в армии служил - тот в цирке не смеется" не зря говорят. К тому же у меня брат и отец - офицеры ВВС СССР, поэтому я очень трезво, без эмоций оцениваю сложившуюся ситуацию.

Yo.!!что-то не пойму какая разница кто чистит версии отдельный процесс vacuum или читающий запрос ?? эфект тормозов все равно одинаковый.
и в чем проблема у постгрес выковырять это вакум из отдельного процесса и прикрутить к читающему процессу ? (хотя это имхо теже яйца)

Фишка в том что необходимость в вакууме совпадает с "тормозами" и нагрузкой. То есть когда фекалии уже попали в вентилятор, принимать превентивные меры уже поздно. Поезд уже ушел. В Интербэйсе читающая транзакция чистит мусор что естественным образом регулирует и распределяет нагрузку. Решение хотя и элегантное, но все равно - "прошлый век". Версии данных в страницах (блоках) данных лежать не должны. Этот дизайн порочен в принципе.

dimitr- не понимаю, как можно считать "CA OpenIngres, MySQL MaxDB (aka SapDB)" взрослыми, если их реальных внедрений на порядки меньше, чем прочих. Их недостатков просто никто не знает.

- про InnoDB - не смешно. Какие бы хорошие идеи там не лежали, но реализация ужасная (в сравнении с теми же PGSQL/FB). Таких тормозов при серьезной нагрузке я ни у кого из конкурентов не видел.

- PGSQL "порочен" ровно настолько, насколько и IB/FB. Версионная архитектура у них практически идентична. С вакуумом был врожденный косяк - это да, но его уже почти вылечили.

- камраду Yo! предлагаю рассказать всем про реализацию версионника с отсутствующей как класс сборкой мусора (и, соответственно, без тормозов)

На самом деле на Ингресе и SapDB сделано до фига всяких проектов по сравнению с оупенсорсными СУБД. С Ораклом и DB2 мы их не сравниваем, там ежу понятно все. Мы их сравниваетм с PostGreSQL, MySQL-innoDB, FB/IB.

Про реализацию версионника без сборки мусора я вам и без Yo! расскажу. Различные версии записи держать в одной странице (блоке) совсем не обязательно. В страницах (блоках) можно держать одну версию данных, а историю писать в лог. Еще историю можно кэшировать, с тем чтобы быстро удовлетворять запросы которым она нужна для согласованного чтения. Подробнее рекомендую почитать книжку Тома Кайта про Оракл - там все написано. Еще подробнее - Оракловую доку.

guest_20040621> Пока не много

То есть они существуют? ;) Пару ссылок Вас не затруднит привести?

> оба эти проекта в оупенсорс вышли буквально "вчера"

Насколько я помню, MySQL MaxDB - не вчера. И, судя по результатам поиска на sf, за все время существования ажиотажа не вызвала.


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

guest_20040621
> Ничего, скоро Оракл начнет давить MySQL, тогда любители халявы
> забегают как тараканы. И деваться им будет особо некуда.

Я - не "любитель халявы". Но реальной альтернативы PostgreSQL не вижу. Что-то просмотрел?
Я бы на него смотрел в последнюю очередь.

DocAl dimitr
- про InnoDB - не смешно. Какие бы хорошие идеи там не лежали, но реализация ужасная (в сравнении с теми же PGSQL/FB). Таких тормозов при серьезной нагрузке я ни у кого из конкурентов не видел.
А вы точно умеете их готовить? Не утверждаю, что InnoDB верх совершенства, но каких-то выдающихся тормозов не замечал, при адекватной настройке, разумеется.

А он у вас с включенной версионностью настроен или поверх MyISAM? MySQL быстр пока транзакции не поддерживает, а как он начинает их поддерживать - начинает тормозить.