Проприетарные СУБД обречены?

>К чему приводит хранение бизнес-логики cнаружи, можно видеть на примере поделий типа 1С

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

> В чем разница между реплицированием нескольких БД в один сервер (как я понял, это то, о чем ты говорил) и реплицированием нескольких БД в несколько серверов, запущенных на одной физической машине?

хороший вопрос :) сейчас - ни в чём. за исключением того, что несколько вирт. серверов будут просить чуть больше ресурсов, чем одна СУБД. ну и параметры вирт. машинам придётся подкручивать аккуратно, чтобы в нужный момент об лимиты не стукнуться.

что качается филиалов, то бывают (и часто) ситуации, когда на удалённой площадке старая система (ещё с ядром 2.4.х :) ), и речи о виртуализации не идёт. ну и систему, естественно, никто менять не собирается в ближайшем будущем.

> бывают (и часто) ситуации, когда на удалённой площадке старая система (ещё с ядром 2.4.х :) ), и речи о виртуализации не идёт

А почему нельзя запустить 2 сервера в одной ОС? Если я правильно помню, тот же Оракул умеет запускать несколько экземпляров на одной машине. Для резервирования такого должно хватить.

> ну и систему, естественно, никто менять не собирается в ближайшем будущем.

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

> А почему нельзя запустить 2 сервера в одной ОС? Если я правильно помню, тот же Оракул умеет запускать несколько экземпляров на одной машине. Для резервирования такого должно хватить.

можно и mysql на разных портах, с разными datadir и.т.п. просто неудобно поддерживать этот зоопарк потом. виртуальная машина лучше, как ни крути.

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

Постгрес и СКЛлайт в итоге всех порвут!

реляционные дб обречены в временной перспективе! а что делают производители? конечно вставляют костыли из обьектов and etc... реляционная дб рулит для бугалтеров у которых нативное представления данных - таблицы. сейчас уже появляется туева хуча задачь на которых нужно хранить знания, а проше с ними работать представляя как граф... будуйшее на дб на основе вариаций на тему нейронных сетей. а производители цепляются за деньги вложеные в проекты и пытаются добится эволюционного роста. скоро придет реляциякапец!

>- Приведи пример операции, которую ФС на PostgreSQL делала бы лучше
>чем например

Например "Найти все файлы, размером больше 2 Мб". Уверен, что скорость выдачи результата отличалась бы в разы :)

> теперь о репликации. slony1 (trigger based replication) вполне "готовы к продакшн использованию".

Даже хуже :) - у команды Postgres Inc. такая традиция, после двух лет работы продукта в продакшине, зачастую в каком-нибудь HiEnd-e, отдавать всем остальным. slony один из них :)

А нормальные кейсы под свободные субд бывают ? уровня oracle designer ?

> люди, создающие велосипеды grep'ами и придумывающие структуру "БД" из файлов и директорий - неужели вы реально думаете что умнее тех же MySQL которые этим последние 10 лет занимаются?

Пока в MySQL не появится индексированного поиска по тексту с NEAR, вполне могу так думать :). А 99% других фич, которые есть, мне не нужны.

Голыми grep'ами не занимаюсь, создаю свои индексы в файлах, и грепаю только в индесках :).

> Поиск видео-фильмов по винту. В фс пришлось бы просмотреть заголовки всех файлов - смотреть не совпадает ли он с заголовком какого-нить известного формата хранения видео. В базе у тебя скорее всего будет функциональня зависимость: file_type <-- file_id

Чтобы в базе была фукц зависимость - ее надо создать. Точно так же на файловой системе можно создать файл с индексом этой зависимости.

>> Поиск видео-фильмов по винту. В фс пришлось бы просмотреть заголовки всех файлов - смотреть не совпадает ли он с заголовком какого-нить известного формата хранения видео. В базе у тебя скорее всего будет функциональня зависимость: file_type <-- file_id

> Чтобы в базе была фукц зависимость - ее надо создать. Точно так же на файловой системе можно создать файл с индексом этой зависимости.

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

>>К чему приводит хранение бизнес-логики cнаружи, можно видеть на примере поделий типа 1С

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

Самое забавное, что и 1С никто переписывать не собирается :) И то и то непросто, но логика внутри базы создаётся в разы или даже на порядки быстрее и работает надёжнее.

> реляционные дб обречены в временной перспективе! а что делают производители? конечно вставляют костыли из обьектов and etc...

За реляционными БД стоит теория множеств. А что стоит за объектными? В общем пока за объектными чего-то определённого не встанет реляционные будут жить.

P.S. Кстати в топик про СУБД против ФС. В SLAC по-моему пытались внедрить для хранения данных объектную СУБД Objectivity. Вложили кучу денег в покупку, а затем два года писали интерфейс к данным и отлавливали баги этого проприетарного поделия, а затем опять же два года откатывались на просто root-файлы. Вот так использование объектов дискредитирует саму идею СУБД.

>Твои проблемы на Metalinke разжеванны уже как два года. Нет бабла на Metalink? Верю. Но то, что нет способности прочитать, что 10g EE не сертифицирован для юбунты говорит о том, что Оракл тебе нафиг не нужен.

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

Перечитал посты, убедился в одной старой мысли.

1) Многим пользователям не нужны базы данных - они с помощью скриптов, какой-то матери и прочего колдовства делают все на уровне файлов. Остальные простые пользователи жутко довольны PostgreSQL, MySQL. 2) Для хранения метаданных, данных таких информационных порталов как linux.org.ru открытве субд справляются - подтверждается практикой. 3) Открытые субд развиваются.

4) Все ведущие коммерческие субд работают под Linux. Причем не `частично` работают, а полностью и стабильно 5) Тот же Oracle предоставляет версию для разработчиков бесплатно. 6) Недовольные говорят о неприменимости открытых субд в больших сложных базах для большого бизнеса.

В целом ситуацию на рынке субд считаю вполне нормальной и стабильной. За что платят пользователи Oracle и DB2 тоже видно. Смены HDD на что-то еще в ближайшем будущем не ожидаю. Можно даже сказать, что в этой области я даже счастлив и доволен.

>на больших объемах мало что спасает, и если для вас критичны производительность по отношению к надежности и объему данных, то Вы не поставите Firebird, MySQL на терабайтные БД.... тупо захлебнутся :(

PostgreSQL вполне спокойно переваривает многотерабайтные базы

>Разве что только полупроприетарный MySQL движется в сторону этих фич с достаточной быстротой.

Для начала мускулю нужно добраться до уровня постгреса... а это ему еще долгое время не светит

> Вообще, данные без жесткой поддержки referential integrity просто никому не нужны.

Гугловский индекс и www вообще (со всеми их висящими ссылками) никому не нужны?

>Это bullshit. Хостеры под фрюниксами работают. Просто мускуль - пропиаренное глюкавое говно.

Еще возможно потому, что до 8-ки постгрес ставился и настраивался довольно своеобразно. У мускуля было все очень просто и прозрачно

> Ни одна серьезная биллинговая система (банки, опсосы) не хранит логику вне БД, и уж тем более - не использует логику файловой системы. К чему приводит хранение бизнес-логики cнаружи, можно видеть на примере поделий типа 1С: огромный сетевой трафик из-за того что данные гоняются по сто раз туда-обратно, кривая работа с большим количеством пользователей, тяжелые фронтэнды, слабая/неочевидная связанность данных внутри БД, отсутствие единой точки входа в базу, и прочие "прелести".

интересно, как вы вообще предлагаете жить на этом свете? Запихать все данные мира в одну большую супер БД ?

"слабая/неочевидная связанность" - это реальность, данная нам в ощущениях, в очень многих областях. Биллинг, с его изолированным мирком, это скорее исключение, чем правило.

> Еще возможно потому, что до 8-ки постгрес ставился и настраивался довольно своеобразно. У мускуля было все очень просто и прозрачно

Гхмм. Как раньше для PostgreSQL был apt-get, так и сейчас есть. В чём своеобразие?

а в постгресе есть хотя бы базовый набор аналитики? ну хоть самая малость? (нее, это не в укор, для себя, хочу знать) вот например сумма с подытогами в оракле...

sum (balance) over (partition by contract order by date)

ну, как-то так, по памяти пишу, под рукой сиквелпласа нет проверить правильность написания, но суть именно такая.

про keep и dense_rank наверное нет смысла спрашивать, так?

> можно и mysql на разных портах, с разными datadir и.т.п.

кстати, скажу честно, у меня так не получилось сделать ни разу. но ходят слухи, что "у кого-то получилось". если эти "кто-то" случайно читают lor :), то пусть не держат тайное знание в себе :)

> а в постгресе есть хотя бы базовый набор аналитики?

если только написать ф-ции ручками. на pl/pg(чтоугодно). в коробке нет.

> а в постгресе есть хотя бы базовый набор аналитики?

ну и http://www.postgresql.org/about/news.653, правда что там реально продаёт cybertec мне неизвестно.

я знаю, что на lor бывают люди с postgresmen.ru. они должны быть более информированны в данном вопросе. эксперты, ау :)

> А что, файловая система может сама поддерживать такой индекс при изменении данных? В любой СУБД это легко делается на тригерах.

Индекс поддерживается скриптом/либо короткой suid прогой, который
_кладет_ данные. Права доступа на запись в fs в релевантные директории даются только скрипту.

С другой стороны, более элегантно - можно написать демона который будет следить за директориями через inotify и апдейтить индексы :)

> Вообще, данные без жесткой поддержки referential integrity просто никому не нужны.

Мне нужны. У меня такие данные. Апдейт раз в неделю, остальное время read-only. Сами данные и referencы в них проставляются сторонними организациями и могут иногда быть битыми или опечатками, и с этим надо жить.

> В чем прелесть СУБД - так это в том что можно сделать обновление данных без обновления индексов невозможным.

Да прелестей может быть много, только мне они либо не нужны, либо я их сделал поверх файловой системы - например локи.

>> А что, файловая система может сама поддерживать такой индекс при изменении данных? В любой СУБД это легко делается на тригерах.

> Индекс поддерживается скриптом/либо короткой suid прогой, который _кладет_ данные. Права доступа на запись в fs в релевантные директории даются только скрипту.

Т.е. писать может только скрипт? А если программа будет модифицировать?

> С другой стороны, более элегантно - можно написать демона который будет следить за директориями через inotify и апдейтить индексы :)

И такой демон всегда будет идти с запаздыванием. Как результат - будут промежутки времени когда мндекс не соответствует данным.

>> Вообще, данные без жесткой поддержки referential integrity просто никому не нужны.

> Мне нужны. У меня такие данные. Апдейт раз в неделю, остальное время read-only. Сами данные и referencы в них проставляются сторонними организациями и могут иногда быть битыми или опечатками, и с этим надо жить.

Это весьма и весьма частный случай, и совсем непонятно - зачем это делать на ФС.

>> В чем прелесть СУБД - так это в том что можно сделать обновление данных без обновления индексов невозможным.

> Да прелестей может быть много, только мне они либо не нужны, либо я их сделал поверх файловой системы - например локи.

Поздравляю - славный получился велосипед. Есть преимущества?

>Давно пора, как водрузить 64 bit энтырпрайз оракл 10g на 64 бит убунту это просто атас. Пинание его 32х битных хвостов меня несколько утомило, потому я больше с этим ничего общего иметь не хочу. Привет постгрес.

ты похоже даже руководство не осилил прочитать, там довольно-таки однозначно написано какие пакеты должны быть установлены.

> Ну а санкам заплатить денег за саппорт аппсервера (см. на пиар glassfish), который у них есть, а не ораклу/межделмашу за саппорт их базы.

Предполагаемые суммы фстудию. Кстати, сервер приложений опенсорсный, и если ты большой гуру, можешь пилить сам. ИМЕЕШЬ ПРАВО. С оракулом/межделмашем это не прокатывает :(((

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

Ошибки в реализации бизнес-логики есть всегда и везде, если только программный комплекс - не "Hello, World".

>отлаживать многоэтажные процедуры на (transact|pl)sql не самая тривиальная задача, да. а во многих случаях и просто невозможная.

Гибернейт и прочие абстракторы предназначены лишь для упрощения работы с БД. Трудоемкость разработки бизнес-логики зависит не столько от инструмента, сколько от решаемых задач. И чем сложнее задача - тем больше объем обрабатываемых данных и их сложность. Гонять огромное количество данных из БД в сервер приложений и обратно очень дорого (как по ресурсам, так и по времени выполнения) и не имеет смысла если необходимые вычисления можно сделать в самой БД.

>зато хранение бизнес-логики внутри базы это конечно верх рациональности.

Это - разумный компромисс.

>в итоге превращающийся в стойки с серверами СУБД,

Ну так в случае внешнего обсчета будет не стойка с серверами БД, а стойка с серверами приложений. В сущности, принципиальной разницы нет.

>ежедневный секс с репликациями

Если проект спроектирован и разработан криво, а обслуживают его лентяи и неучи - то да, так оно и есть. Наивно полагать что при таком подходе смена технологии хоть что-то изменит.

>, кучу денег на лицензии и

Увы, мир таков, что платиить придется в обоих случаях. Я, сколько не работал, не видел ни одной Opensource биллинговой системы ни для банка, ни для опсоса. :)

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

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

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

Перейти за пять минут с Oracle на DB2, Informix или Постгрес и обратно, не получится ни с каким абстрактором, если конечно проект - не "чиста уэб-магазин па прадаже семок" на 15 таблиц и без связанности между ними.

>Еще возможно потому, что до 8-ки постгрес ставился и настраивался довольно своеобразно. У мускуля было все очень просто и прозрачно

Постгрес, начиная с версии 7.0.X (2001 год), отлично ставился и настраивался. Даже в те времена никаких проблем с работой ни в RedHat 7, ни во FreeBSD 4.X с Постгресом не было.

>> Естественное сохранения дополнительных метаданных, индексация по любому ключу, полнотекстовый поиск, естественное создание aliasов для групп директорий и файлов как в VMS :)

> - Вы случайно не из команды WinFS?

WinFS тихо заглохла после напоминания Саном о своих патентах на ZFS и их несовместимости с микрософтовской схемой лицензирования :)))

Зато появилась "транзакционная NTFS" которая, я так понимаю, сделана на движке SQL Server. То-то будет производительность и масштабируемость!!! :))) Лицензирование ФС по числу процессорных ядер -- новое слово в маркетинге софта :)))

- Если бы это было кому-то надо, неужели это бы не спортировали из VMS хотя бы в NT?

Тогда стояла задача, чтобы всё вертелось на 16 МБ памяти, и из ядра системы выкинули всё, что можно и нельзя, в том числе безопасность.

В Висте "безопасность" начали привинчивать, но НЕ оригинальную VMSную (хотя лицензия на неё у МС есть), а костыли, в результате появилась САМАЯ РЕСУРСОЁМКАЯ ОС В ОТРАСЛИ (И САМАЯ СЛОЖНАЯ В АДМИНИСТРИРОВАНИИ) 8-0 Десктопная ОС еле поворачивается на машине, на которой межет без проблем вертеться аппсервер явы под солярой клиентов так на 1000 :))) Сильно :))) То ли ещё будет :)))

хибер гоняет гиганское кол-во данных из субд и на тяжелых нагрузках просто не вытягивает если вынесен на другую машину.

Minotarus.

>> Если бы это было кому-то надо, неужели это бы не спортировали из VMS хотя бы в NT?

>Тогда стояла задача, чтобы всё вертелось на 16 МБ памяти, и из ядра системы выкинули всё, что можно и нельзя, в том числе безопасность.

Безопасность из ядра не выкинули (по крайней мере, не всю). VMS вертелась и на меньшем объеме памяти, чем 16М.

>> зато хранение бизнес-логики внутри базы это конечно верх рациональности.

> Это - разумный компромисс.

ну не всей же. иначе мелкое изменение в одной хранимой процедуре может привести к плохо предсказуемым последствиям :)

>>ежедневный секс с репликациями

> Если проект спроектирован и разработан криво, а обслуживают его лентяи и неучи - то да, так оно и есть. Наивно полагать что при таком подходе смена технологии хоть что-то изменит.

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

> Тогда стояла задача, чтобы всё вертелось на 16 МБ памяти,

На 4-х. Хе-хе. Былинные времена.

>Увы, мир таков, что платиить придется в обоих случаях. Я, сколько не работал, не видел ни одной Opensource биллинговой системы ни для банка, ни для опсоса. :)

за что платить? за яву? не нужно. а вот за оракл платить за каждый сервер огого. элементарная экономия.

>Если проект спроектирован и разработан криво, а обслуживают его лентяи и неучи - то да, так оно и есть. Наивно полагать что при таком подходе смена технологии хоть что-то изменит.

не надо даже сравнивать секс с репликациями с чем-либо еще.

>Перейти за пять минут с Oracle на DB2, Informix или Постгрес и обратно, не получится ни с каким абстрактором, если конечно проект - не "чиста уэб-магазин па прадаже семок" на 15 таблиц и без связанности между ними.

зато если засунуть логику в базу, перейти не получится и за 5 лет. даже если это веб-магазин по продаже семок.

вообще есть такое понятие - краснаглазые ораклисты. видимо товарищ один из них.

>>зато если засунуть логику в базу, перейти не получится и за 5 лет. даже если это веб-магазин по продаже семок.

Верно. И все такое. Но, можно один вопрос.
А зачем куда то уходить? У вас есть данные по кончине оракла как компании или ПО ?

> Верно. И все такое. Но, можно один вопрос. > А зачем куда то уходить? У вас есть данные по кончине оракла как компании или ПО ?

Неужели не очевидно, что возможность куда-то уйти - единственный способ как-то воздействовать на Oracle, в плане цен, исправления багов, наличия саппорта и тд???

>вообще есть такое понятие - краснаглазые ораклисты. видимо товарищ один из них.

если и есть то явно они стоят на пару ступенек выше твоего развития ...

>за что платить? за яву? не нужно. а вот за оракл платить за каждый сервер огого. элементарная экономия.

что ты в этом понимаешь дитетко ? постгре конкурирует с ораклом лишь на самом начальном секторе малого бизнеса - там бесплатного oracle XE хватает на 80% задач что решает постгрес, при этом предоставляя гораздо больше фич (от автономных транзакций до матвью), лучший оптимизатор и т.п.
те 20% где не канают ограничения XE редакции есть oracle se1, стоит $5K на проц и окупается за пару месяц тем, что предоставляет нормальный функционал в то время как посгресу приходится изобретать велосипет в пустую проедая деньги.

сегодня энтерпрайз выглядит так:
http://oraclemind.blogspot.com/2007/08/forrester-dbms-market-overview.html

>зато если засунуть логику в базу, перейти не получится и за 5 лет. даже если это веб-магазин по продаже семок.

лапоть, ты кроме фокспро с чем-то имел дело ?
syabse ASE - прородитель microsoft t-sql, практически визардом мигрируется. enterprisedb клон постгреса пытается pl/sql супортить полностью, то же самое с клонами firebird, есть клоны супортящие часть pl/sql.

Minotauros.

>возможность куда-то уйти - единственный способ как-то воздействовать на Oracle, в плане цен, исправления багов, наличия саппорта и тд???

я подозреваю что на Оракел больше влияют db/2 и mssql в плане предотвращения борзения.

>>Увы, мир таков, что платиить придется в обоих случаях. Я, сколько не работал, не видел ни одной Opensource биллинговой системы ни для банка, ни для опсоса. :)

>за что платить? за яву? не нужно. а вот за оракл платить за каждый сервер огого. элементарная экономия.

на индусов, которые будут бесконечно латать тоскливый EJB.

>Неужели не очевидно, что возможность куда-то уйти - единственный способ как-то воздействовать на Oracle, в плане цен, исправления багов, наличия саппорта и тд???

далеко не единственный и совершенно не действенный когда речь идет о субд которая на 5-10 лет опережает ближайших соперников и имеет гораздо больший разрыв с опенсоурсом.
у postgres есть клон enterprisedb который почти супортит большую часть фич oracle8i и его pl/sql, однако массовой миграции не наблюдается. постгресу еще прийдется править архитектурные косяки в реализации MVCC со сборкой мусора, на это уйдут годы, только тогда он сможет реально соревноватся с oracle8i (пусть и без части фич)

ЗЫ. oracle8i это 98 год ...

Minotauros.

>субд вообще обречены, с повсеместным переходом с магнитных хардов на электронные быстрее будет прочитать и распарсить файл с диска, нежели тащить коллосальный костыль в лице субд

В идеале - ФС == СУБД

>>Неужели не очевидно, что возможность куда-то уйти - единственный способ как-то воздействовать на Oracle, в плане цен, исправления багов, наличия саппорта и тд???

Нет. Это не только не очевидно, но и с высоты лет и опыта - несколько напоминает войну с ветряными мельницами.
Так и вижу, HelloWordшики с ЛОРа заставляют снизить цену на Oracle ;)


Особенно забавно читать про "наличие саппорта" ;)

если откинуть все предрассудки, скажите, как бы Вы видели свое воздействие на Oracle ?
Вы хоть в asktom или на форуме oracle хоть голос когдато подавали? Вас оставили без внимания?