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

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

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

>> Не раскрыто чем MSSQL таки лучше или только тем, что в данном предложении идёт за Oracle. Чем блокировочник может быть лучше версионника?

> Тем, что не тратит память на версии, которые все равно не будут нужны ?

Поэтому не работаем, а тормозим?

http://en.wikipedia.org/wiki/Pick_operating_system
http://en.wikipedia.org/wiki/MUMPS

>> Не раскрыто чем MSSQL таки лучше или только тем, что в данном предложении идёт за Oracle. Чем блокировочник может быть лучше версионника?

>Тем, что не тратит память на версии, которые все равно не будут нужны ?

Они нужны чтобы не блокировать селекты в паралельной сессии.

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

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

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

> Алексей Борзов http://www.inp.nsk.su/~baldin/PostgreSQL/Alexey/Alexey.html объясняет это отсутствием порта на win32

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

>> Не раскрыто чем MSSQL таки лучше или только тем, что в данном предложении идёт за Oracle. Чем блокировочник может быть лучше версионника?

>Тем, что не тратит память на версии, которые все равно не будут нужны ?

> Они нужны чтобы не блокировать селекты в паралельной сессии.

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

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

Боже упаси - я уже и не помню даже с какой стороны к альтернативной системе подойти, но алиасы по группе директорий реально удобно. VMS более совершенная чем Unix система по множеству параметров, но

а) закрытая

б) в каком-то смысле имеет монолитное окружение, правда это во многом искупается великолепным help.

> Поэтому не работаем, а тормозим?

Нет, не работаем. И не тормозим. Просто вешаем к херам всех клиентов, потому как mysqldump базу в пару гигов сливает.

Хотя, есть умельцы которые через репликацию мускуль бэкапят. Впрочем, мускульщики все через задний проход делают.

>>>> Не раскрыто чем MSSQL таки лучше или только тем, что в данном предложении идёт за Oracle. Чем блокировочник может быть лучше версионника?

>>>Тем, что не тратит память на версии, которые все равно не будут нужны ?

>> Они нужны чтобы не блокировать селекты в паралельной сессии.

>Параллельные сессии сами по себе редко нужны. Если памяти под версии выжрано столько, что система ушла в непрерывное свопление, то поставленный при этом рекорд числа параллелльных сессий никого не впечатлит.

оракел вроде бы хранит старые версии в сегментах отката, а не в ОЗУ?

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

Для случаев когда мало памяти есть SQLite :) IMHO на сколько я помню историю вопроса именно не осилили, хотя могу ошибаться.

>за целостностью данных нормальные фс и так следят, а логика в базе не нужна

фс следит за целостью самой себя, а не данных

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

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

> оракел вроде бы хранит старые версии в сегментах отката, а не в ОЗУ?

ну да. и лазание за ними похоже на свопление

>фс следит за целостью самой себя, а не данных

Смотря какая ФС.

> Смотря какая ФС.

Есть фс с триггерами и внешними ключами?

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

Какой тяжелый набор слов - это все и есть файловая система, простая, без излишков. Подобные задачи мало того, что никогда не нужны, но тем не менее выполняются. Использование простейших расширенных аттрибутов (наверное даже minix это поддерживает) решает _все_ вопросы.

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

>Есть фс с триггерами и внешними ключами?

С ключами конечно есть - практически все уже давно поддерживают расширенные аттрибуты. Триггеры не везде - механизм ранзакций есть только в "продвинутых".

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

Господа знающие, если я ошибаюсь (мне бы действительно этого хотелось), поправьте. Только давайте на берегу договоримся, не путать понятия "может/умеет" и "готово к продакшн использованию".

> Триггеры не везде - механизм ранзакций есть только в "продвинутых"

Назовешь пару-тройку ФС с транзакциями? И хоть одну - с триггерами?

> Какой тяжелый набор слов - это все и есть файловая система, простая, без излишков. Подобные задачи мало того, что никогда не нужны, но тем не менее выполняются. Использование простейших расширенных аттрибутов (наверное даже minix это поддерживает) решает _все_ вопросы.

Не только атрибутов. Кроме того просили сравнить с ext2. Для того чтобы выполнить эти, а также кучу других пожеланий (которые на самом деле реально нужны) придётся фактически написать СУБД с нуля. И нафига спрашивается, когда это уже есть? В том числе и полнотекстовый поиск tsearch2 с морфологией.

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

У неоднократно ругаемого здесь мускуля есть же бинлог, который может сойти как за инкрементальный бэкап, так и дифф.

> фс следит за целостью самой себя, а не данных

учи матчасть.

>Назовешь пару-тройку ФС с транзакциями? И хоть одну - с триггерами?

zfs, btrfs, xfs.

В первой можно даже (по крайней мере в todo это было с год назад) создавать собственные транзакции, и были разговоры о портировании sql транзакционного движка на нативный движок zfs.

> В первой можно даже (по крайней мере в todo это было с год назад) создавать собственные транзакции, и были разговоры о портировании sql транзакционного движка на нативный движок zfs.

Осталось подождать когда туда встроят полнотекстовый поиск и будет почти как PostgreSQL :)

>> фс следит за целостью самой себя, а не данных

> учи матчасть.

Внешние ключи?

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

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

>Не только атрибутов. Кроме того просили сравнить с ext2. Для того чтобы выполнить эти, а также кучу других пожеланий (которые на самом деле реально нужны) придётся фактически написать СУБД с нуля. И нафига спрашивается, когда это уже есть? В том числе и полнотекстовый поиск tsearch2 с морфологией.

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

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

>Внешние ключи?

Повторю, расширенные аттрибуты поддерживает подавляющее большинство современных ФС. Например beagle там хранит статус обработки файла, ecryptfs хранит ключи и т.п.

>Назовешь пару-тройку ФС с транзакциями? И хоть одну - с триггерами?

> zfs, btrfs, xfs.

>В первой можно даже (по крайней мере в todo это было с год назад) создавать собственные транзакции, и были разговоры о портировании sql транзакционного движка на нативный движок zfs.

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

>Осталось подождать когда туда встроят полнотекстовый поиск и будет почти как PostgreSQL :)

Любители могут запускать grep и получать массу удовольствия. В Linux есть beagle, который есть по сути оптимизированный select.

Не нужно путать хранение данных и удобные утилиты работы с ними. Хранение в файловой системе прямее, чем в базе данных (хотя бы потому, что данные доступны стандартыми средствами без дополнительных sql'ных приложений), упралвение ими в простейшем случае в файловой системе удобнее, для создания же логики требуется немало потрудиться, в СУБД для этого и придумали расширенный SQL.

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

В zfs/btrfs/xfs любой доступ на запись (не уверен насчет чтения) есть атомарная транзакция - 'ls' работает с ФС на уровне транзакций.

В zfs эта абстракция экспортирована наружу, т.е. любое приложение, которому нужна подобная логика, может использовать библиотеку. В качестве примера предлагалось портировать sql'ный транзакционный движок (mysql или posgresql) на нативный zfs'овский. Чем закончилось дело не знаю...

Проприетарные СУБД обречены, венде капец, ...
Форум любителей фантастики млин...
Робин Гуды от программирования...
Бесплатный сыр бывает только в яйцерезке.
А ёжики кололись но все равно лезли на кактусы :))

> Назовешь пару-тройку ФС с транзакциями? И хоть одну - с триггерами?

> zfs, btrfs, xfs.

btrfs еще не существует, xfs - использует транзакции внутри себя, для поддержания своей целостности (но это делают все журналируемые ФС), насчет предоставления пользователю API для задания границ транзакций нигде инфы не нашел. ZFS для Линукса нет, так что неинтересно.

Как насчет ФС с триггерами (и индексами _пользовательских_ данных - индексы каталогов и прочего не в счет) - для Линукс и Win32, не VMS или MVS.

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

Локально, возможно, а по сети какая разница?

> У ext2 есть расширенные аттрибуты.

И кто этим пользуется?

>tsearch с морфологией прекрасно прикручивается к любой директории, так что файловая системя как раз на порядки удобнее при добавлении внешних обработчиков.

Это серьёзно? Ссылку можно?

> Другое дело, что ФС может быть заметно медленнее базы данных на некоторых задачах. Да и писать логику на sql сейчас проще, чем создавать специальный сервер приложений. Более того я знаю на каких задачах: на задачах создания реляционных хранилищ данных (читай любых в которых нужно делать поиск). Время*квалификация затраченное на написание и доводку до вменяемого использования в случае ФС требуется на порядки больше.

>> фс следит за целостью самой себя, а не данных

>учи матчасть.

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

>>Внешние ключи?

>Повторю, расширенные аттрибуты поддерживает подавляющее большинство современных ФС. Например beagle там хранит

Ну если Beagle - это файловая система, тогда вопросов нет. Хотя тогда можно и Posgres отнести к ФС :D

> Любители могут запускать grep и получать массу удовольствия. В Linux есть beagle, который есть по сути оптимизированный select.

Первый очень медленный, а от использования второго у меня осталось масса отрицательных эмоций.

> Не нужно путать хранение данных и удобные утилиты работы с ними.

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

>Более того я знаю на каких задачах: на задачах создания реляционных хранилищ данных (читай любых в которых нужно делать поиск). Время*квалификация затраченное на написание и доводку до вменяемого использования в случае ФС требуется на порядки больше.

ebay использует собственный сервер приложений, а не логику в базе данных. Причина проста: для ebay это проще, быстрее, а главное, это работает быстрее. Для них. Для других проще sql.

>tsearch с морфологией прекрасно прикручивается к любой директории, так что файловая системя как раз на порядки удобнее при добавлении внешних обработчиков.

>Это серьёзно? Ссылку можно?

http://openfts.sourceforge.net/

Несовсем "прекрасно", но тем не менее.

>> У ext2 есть расширенные аттрибуты.

>И кто этим пользуется?

beagle для хранения ключей и статусов.

>>Повторю, расширенные аттрибуты поддерживает подавляющее большинство современных ФС. Например beagle там хранит

>Ну если Beagle - это файловая система, тогда вопросов нет. Хотя тогда можно и Posgres отнести к ФС :D

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

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

Пожалста: вводим три новых функции, files_trx_start(), сommit/ rollback. Если приложение сделало какие-то изменения (создание/запись/удаление файлов) и было убито до того как оно вызвало commit - данные должны быть откачены на их начальное состояние.

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

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

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

> beagle это приложение, использующее ключи, которые хранятся в файловой системе для каждого объекта. Вы ошибочно придираетесь к формату предложения, в котором это описано.

Это не я придираюсь, это вы вкладываете во фразу "поддержка ключей в ФС" необычный смысл: в моем понимании, "поддержка ФС" - это что-то вроде ISAM/VSAM в MVS, и аналогичной возможности (не помню, как называется) в VMS.

>> Любители могут запускать grep и получать массу удовольствия. В Linux есть beagle, который есть по сути оптимизированный select.

>Первый очень медленный, а от использования второго у меня осталось масса отрицательных эмоций.

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

>> Не нужно путать хранение данных и удобные утилиты работы с ними.

>Угу, например возможности легко задавать правила как эти данные хранить, проверять и обрабатывать.

Легко это только тем, кто постоянно работает с sql, приведенный в качестве примера ebay с вам не согласен.

>Это не я придираюсь, это вы вкладываете во фразу "поддержка ключей в ФС" необычный смысл: в моем понимании, "поддержка ФС" - это что-то вроде ISAM/VSAM в MVS, и аналогичной возможности (не помню, как называется) в VMS.

Дык, это та же ниша, что и написанная на sql транзакция в базе данных - это же можно сделать для ext2 и xattrs, beagle сделал для себя, MVS сделал API 'для всех'.

> ebay использует собственный сервер приложений, а не логику в базе данных. Причина проста: для ebay это проще, быстрее, а главное, это работает быстрее. Для них. Для других проще sql.

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

>>Это серьёзно? Ссылку можно?

>http://openfts.sourceforge.net/

>Несовсем "прекрасно", но тем не менее.

Не знал. Интересно.

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

>Пожалста: вводим три новых функции, files_trx_start(), сommit/ rollback. Если приложение сделало какие-то изменения (создание/запись/удаление файлов) и было убито до того как оно вызвало commit - данные должны быть откачены на их начальное состояние.

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

>Пожалста: вводим три новых функции, files_trx_start(), сommit/ rollback. Если приложение сделало какие-то изменения (создание/запись/удаление файлов) и было убито до того как оно вызвало commit - данные должны быть откачены на их начальное состояние.

Кстати, так все транзакции в файловых системах и работают. Даже в журналируемой ФС без транзакций такое возможно.

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

Этого, IMHO, мало. Файл как сущность вещь лишняя.

>> ebay использует собственный сервер приложений, а не логику в базе данных. Причина проста: для ebay это проще, быстрее, а главное, это работает быстрее. Для них. Для других проще sql.

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

It depends, google и прочие с подобными объемами вряд ли смогут работать с обычной базой данных. ФС опять же проще и надежнее (когда-нибудь пробовали вытащить данные из файлов убитых баз данных?).

Дело вкуса, я так считаю...

>>Угу, например возможности легко задавать правила как эти данные хранить, проверять и обрабатывать.

>Легко это только тем, кто постоянно работает с sql, приведенный в качестве примера ebay с вам не согласен.

Про ebay я уже отписался, а по поводу постоянной работы с SQL не согласен. Это легко при любом раскладе, потому что SQL - это просто :) хотя Кодд им был не доволен.