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

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

Первая вообще никак не влияет, у ней своя ниша. А вторые с отставанием на ~5лет слизывают с Oracle фичи ;) Безусловно собирая по ходу дела многие неокрепшие умы.

мне не известны приценденты миграции с Oracle на MSSQL на основании объективных (да и субъективных тоже) причин.

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

SELECT `names` FROM `files` WHERE `mime` = 'audio/mpeg' AND (`last_access` - `first_access`)/`play_count` < 86400;

или

UPDATE `files` SET `owner` = 'Balancer' WHERE `author` = 'Balancer';

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

гы-гы oracle files появилось еще во времена oracle9i, так что возрадуйтесь пришествию идеала :)

Minotauros.

>- Если бы это было кому-то надо

Это нужно массе проектов. Сейчас каждый проект, занимающийся музыкой, фотографией, заметками, каталогизацией страдает тем, что добавляет свой слой файловых метаданных. ID-тэги для mp3, EXIF для JPEG, названия, категории, тэги и т.д. и т.п... Одни велосипеды, каждый каталогизатор - обязательно однотипная sqlite-база и т.п.

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

> далеко не единственный

приведите другие.

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

увы, это так. Мы еще не в том состоянии когда произвольную инсталляцию oracle можно взять и заменить на OSS DBMS. Однако, опенсорсники могут атаковать с флангов.

Далеко не каждый клиент oracle нуждается во всех его фичах сразу cобранных в одном месте. Большинство имеет узкую задачу и обходится частью функционала. Если мы возьмем это обстоятельство, тот факт, что oracle недешевое удовольствие, и то, что исходники opensource dbms доступны для хаканья, вместе складывается революционная ситуация :-)

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

Вопрос в запросах по ним.

> И хуже интеграция с *nix. FreeTDS ужасно глючит, долго держащиеся коннекты зависают, транзакции обрываются и т.д..

Во FreeTDS глючить нечему, оно чуть сложнее телнета устроено. Это глючит МС-овское поделие. У меня коннект к SyBase (из которого мс свой сервер и слепила) через FreeTDS не отваливается уже второй месяц. Как в продакшн запустил.

>увы, это так. Мы еще не в том состоянии когда произвольную инсталляцию oracle можно взять и заменить на OSS DBMS. Однако, опенсорсники могут атаковать с флангов.

давайте лучше mssql атаковать с флангов. Сделать к постгресу такую же гуйню как mssql management console и собирать неокрепшие умы.

>Из той пропаганды, что говорилась о WinFS понял, что лучше все-таки beagle.

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

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

Я бы сказал, что порядки скорости выдачи отличались бы в разы :)

>за что платить? за яву?

Платить в любом случае нужно разработчкам и за железо.

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

Прошу Вас, ознакомьтесь с лицензиями на Oracle. То, что Вы написали - глупость. Стоимость *лицензионного* Оракла начинается от 0 долларов.

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

Наймите нормального DBA. Право слово, ну почему у других нет таких страшных проблем с репликацией?

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

Именно поэтому при проектировании больших биллинговых систем в архитектуру не закладывается смена СУБД - в этом нет смысла.

>за что платить? за яву?

Платить в любом случае нужно разработчкам и за железо.

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

Прошу Вас, ознакомьтесь с лицензиями на Oracle. То, что Вы написали - глупость. Стоимость *лицензионного* Оракла начинается от 0 долларов.

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

Наймите нормального DBA. Право слово, ну почему у других нет таких страшных проблем с репликацией?

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

Именно поэтому при проектировании больших биллинговых систем в архитектуру не закладывается смена СУБД - в этом нет смысла.

Итого. User-space daemon, слушающий изменения через inotify, имеющий SQL DBMSы, раскиданные по подмаунченным устройствам, в которых лежат таблицы похожие на то, что все имеют в sqlite... типа таблица mp3-x c id3-полями, жпегов с exif-полями, общая супер-таблица с символьными тегами.

И интерфейс для запросов по заданным/или всем подмаунченным дискам.

Устроит?

>>Мы еще не в том состоянии когда произвольную инсталляцию oracle можно взять и заменить на OSS DBMS.

Исключительно в целях повышения образованности, "Мы" это кто?


>>мы возьмем это обстоятельство, тот факт, что oracle недешевое удовольствие

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

>>мы возьмем это обстоятельство, тот факт, что oracle недешевое удовольствие

Дело в том, что программирование и алгоритмы СУБД несколько отличается от писания ядра, и тем более прикладного ПО в сторону наукоемкости и фундаментальных трудов. Не все тут так просто, иначе бы тот же постгресс действительно бы вытеснил Oracle. Ан нет. Копнешь по глубже, и все.. то там full scan, то то там... Не может еше никто с ораклом коркурировать в больших базах и оптимизаторе :(

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

Всё конечно зависит от специфики, но лучше бы Вы почитали Книжника про GOODS и СУБД в памяти (описание GOODS, диссертация про ООБД в памяти). В двух словах если сравнивать СУБД с полноценными ОС с защитой памяти, "тяжёлыми процессами", его подход -- что-то вроде экзоядра, которое мультиплексирует просто ресурсы, а абстракции файл это или БД или объекты -- откладывает на уровень приложения. Простое маленькое С++ API к ООБД, встраиваемый движок недоБД, в котором нет SQL, но есть индексы, и за счет этого обеспечивается очень быстрая работа по занесению/обработке данных. Но индексами и обработкой надо озаботиться вручную.

Гибкость SQL фактически в том, что мы можем одинаково легко написать произвольный SELECT, SQL-движок сам откомпилирует запрос, подберёт план запроса и индексы, но эта гибкость не нужна, если запросы -- однотипны и не меняются, а логика и так работает на сервере приложений. Пожертвовав этой гибкостью (которая нужна реже чем основная работа, занесение и обработка данных), можем получить более быструю работу в основном оперативном режиме.

То есть для OLTP применений.

Хотя если у Вас СУБД нужна в основном для анализа, и отчёты меняются часто -- SQL проще.

> Ну и транзакции - это только часть того, что нужно. Как насчет ФС с триггерами? :)

что должен делать триггер? поддерживать индексы или запускать какое-то действие? в какой-то мере, их эмулируют live queries, если бы еще было стандартизированная поддержка этих queries на уровне над FS :))

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

Я не скажу за оркал, потому как просто не помню, мало ковырялся, но IBM DB2 например умеет устранять прослойку в виде ФС бежду БД и физическим носителем, и размещать БД на блочном носителе нативно (фактически как СУБДФС, в пустой неразмеченый раздел). Производительности от этого становится только лучше. Советую ознакомиться.

> Ага. А когда потребуется ACID-ность, то что делать? Файловая система разве что D даёт.

хинт: git-репозиторий реализует ACID-ность над ФС? В какой-то мере.

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

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

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

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

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

Странные разработчики. Но с другой стороны, ключевое слово - "всю". Да, безусловно, ВСЮ бизнес-логику упихать в БД такая же утопия, как и вынести вовне.

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

>Я не скажу за оркал, потому как просто не помню, мало ковырялся, но IBM DB2 например умеет устранять прослойку в виде ФС бежду БД и физическим носителем, и размещать БД на блочном носителе нативно (фактически как СУБДФС, в пустой неразмеченый раздел).

оракел тоже с сырыми партициями умеет работать.

> хинт: git-репозиторий реализует ACID-ность над ФС? В какой-то мере.

хинт: нет.

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

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

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

Можно еще элегантнее, устроить что-то вроде Logic FS ( to google). Лениво вычисленные данные-файлы, адресация как в обычной ФС, и перевычисление данных при запросе нужных данных.

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

Например. запросы выполняются по пути вроде /proc/upyachka/category/чячло+попячса, при этом промежуточные данные вычисляются лениво и используются для следующих запросов. Индексы = вспомогательные промежуточные данные запроса, который выполнять как вычисление ленивой функции, по требованию.

>>- Если бы это было кому-то надо

>Это нужно массе проектов. Сейчас каждый проект, занимающийся музыкой, фотографией, заметками, каталогизацией страдает тем, что добавляет свой слой файловых метаданных. ID-тэги для mp3, EXIF для JPEG, названия, категории, тэги и т.д. и т.п... Одни велосипеды, каждый каталогизатор - обязательно однотипная sqlite-база и т.п.

http://en.wikipedia.org/wiki/Logic_File_System

осталось собственно стандартизировать метаданные, ввести вроде того, чем стала LHS для обычных дистрибутивов Линукса, и встроить реализацию этой идеи в каждый DE, каждое приложение и каждый дистрибутив :-)

>Итого.

...

>Устроит?

Вполне. В комплекте с FS с расширенными атрибутами это и будет полноценной DBFS.

> Копнешь по глубже, и все.. то там full scan, то то там... Не может еше никто с ораклом коркурировать в больших базах и оптимизаторе :(

я знаю 2 случая, когда postgre не использует индекс, а делает "то там full scan, то то там". это если под full scan мы понимаем прямой пербор записей, без использования индекса. это slect count(*)и выборки из таблиц, в которых 3 записи :)

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

>>Устроит?

>Вполне. В комплекте с FS с расширенными атрибутами это и будет полноценной DBFS.

Осталось утрясти мелкие детали реализации, стандартизировать метаданные и понять, с какой радости всё это названо FS :D

какой-нибудь SQUID или мейлсервер не задосит ли такого демона при частом обновлении своих файлов? А если хотим индексировать содержимое кеша/почту?

>Осталось утрясти мелкие детали реализации, стандартизировать метаданные и понять, с какой радости всё это названо FS :D

Потому что _в описанной реализации_ это всё равно костыль. Функционал этой системы призван _расширить_ отсутствующее в нынешних FS. Чем, скажем, поиск файла по имени в подкаталоге отличается от поиска по определённому атрибуту? И если рассматривать описанное не в виде костыля, а в виде полноценной системы - оно окажется "встроенным в ФС".

То, что функционал костыля может удовлетворить - не должно означать, что это уже не костыль :)

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

extended noatime :)

Сделать 2 колоночки : требования к ФС | требования к реляционной бд

Заметить, что, несмотря на некоторые общие вещи, различия принципиальные.

> Чем, скажем, поиск файла по имени в подкаталоге отличается от поиска по определённому атрибуту?

Обобщая, чем поиск файла по "физическому пути" отличается от поиска по "логическому пути" (как в Plan 9, где /dev/cons был у каждого приложения свой), от пути в пространстве имён других приложений (как трансляторы в GNU/Hurd, какая разница что пространство имён /proc/upyachka -- транслятор, который возникает только по запросу, при обращении), от лениво вычисленного пути Logic File System, от URL, наконец, если все эти разные пути адресуют ОДИН И ТОТ ЖЕ объект (файл) ?

>наконец, если все эти разные пути адресуют ОДИН И ТОТ ЖЕ объект (файл) ?

Ты не поверишь, но у меня уже много лет во фреймворке у одного и того же объекта могут быть разные URL. И родителей может буть у каждого объекта более одного. И всё это прекрасно работает :)

...

Путь - не более чем простой атрибут. При чём в виде множества значений, а не одного. Грубо говоря - хранится в отдельной таблице "путь -> id_объекта".

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

Картина маслом: сидит юзер-домохозяйка и расставляет хинты в профайлере для DBFS. =)

> Ты не поверишь

охотно верю :)

> Путь - не более чем простой атрибут. При чём в виде множества значений, а не одного. Грубо говоря - хранится в отдельной таблице "путь -> id_объекта".

или, "путь -> id_объекта" -- вычисляется и является функциональной зависимостью. В таблицу не загонишь, а ленивыми вычислениями -- вполне.

> Сейчас каждый проект, занимающийся музыкой, фотографией, заметками, каталогизацией страдает тем, что добавляет свой слой файловых метаданных. ID-тэги для mp3, EXIF для JPEG, названия, категории, тэги и т.д. и т.п... Одни велосипеды, каждый каталогизатор - обязательно однотипная sqlite-база и т.п.

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

>Ну никак не вижу связи между исполнителем трека и моей фоткой с последнего отпуска.

Атрибуты - разные. Но механизм их хранения - един. Так зачем лепить кучу несовместимых костылей и велосипедов?

>Поэтому для них разные каталогизаторы, хранящие данные в разных базах.

Каталогизаторы - разные. Работа должна быть - одна. Чтобы я мог фотку описать в F-Spot, потом перенести её в другое место (в идеале, кстати, "путей" - вообще никаких не должно быть, только иерархия тэгов), и посмотреть с параметрами в GQView или digiKam.

Сейчас такого нет _нигде_. Если ты перенёс файл вне программы-каталогизатора - требуется пересканирование ФС. А совместимости между разными программами почти нет вообще.

> Я не скажу за оркал, потому как просто не помню, мало ковырялся, но IBM DB2 например умеет устранять прослойку в виде ФС бежду БД и физическим носителем, и размещать БД на блочном носителе нативно (фактически как СУБДФС, в пустой неразмеченый раздел). Производительности от этого становится только лучше. Советую ознакомиться.

В Oracle это тоже предпочтительный вариант. У СУБД свои кеши в памяти, свои оптимизаторы, которые работают весьма эффективно и лучше, чем ФС знают какой именно блок читать с диска и какую запись в памяти оставлять.

> И родителей может буть у каждого объекта более одного. И всё это прекрасно работает :)

А вот это уже интересно, зачем это понадобилось, можно пример, где это используется. Наследование экземпляров объектов, составные классы? Вроде такого примера: http://www.software-lab.de/dbui.html (совмещение классов динамически, в runtime, на основе связей между объектами, много к многим) ?

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

Су-33 относится к "Истребителям", "Продукции КнААПО", "Разработан в ОКБ Сухого", является "Палубным самолётом" и т.п. :) Поскольку это не просто тэги, а иерархические тэги ("Типы самолётов", "Производственные объединения", "Конструкторские бюрю") и т.п. - получается множественная иерархия.

...

Используется, естественно, на сайте. Хотя очень бы хотелось такую же систему - в локальной ФС. Чтобы все файлы по этому же Су-33 хранить в одном каталоге без симлинков (хотя это фигня), а "переносе" файлов автоматически обновлялись и все привязки (что уже намного важнее).

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

>SELECT `names` FROM `files` WHERE `mime` = 'audio/mpeg' AND (`last_access` - `first_access`)/`play_count` < 86400;

>или

>UPDATE `files` SET `owner` = 'Balancer' WHERE `author` = 'Balancer';

по-моему, в OQL это записывалось бы менее громоздко :)

> Хотя очень бы хотелось такую же систему - в локальной ФС. Чтобы все файлы по этому же Су-33 хранить в одном каталоге без симлинков (хотя это фигня), а "переносе" файлов автоматически обновлялись и все привязки (что уже намного важнее).

А чем хардлинки не подходят?

> очень бы хотелось такую же систему - в локальной ФС. Чтобы все файлы по этому же Су-33 хранить в одном каталоге без симлинков (хотя это фигня), а "переносе" файлов автоматически обновлялись и все привязки (что уже намного важнее).

Придумался какой-то навороченный GIT. Есть content-addressable memory, объекты доступны по GUID-ам = хешу содержимого. Это лежит по пути /proc/upyachka/blobs/4916d7d9d003b01cea8ca89b5ebc8c8c (md5sum или sha1sum).

Обращение к объектам-блобам производится по "категориям" вида /proc/upyachka/moovies/names/Piraty.Silikonovoi.Doliny.avi , /proc/upyachka/query/billy_g+steve_jobs+"pirate flag"+"world domination"+бабло , /proc/upyachka/classes/moovies/производственный_роман+компьютерщики , /proc/upyachka/imdb/moovies/by_actors/Noah_КакТамЕго , /proc/upyachka/playlists/for_mplayer/today

При этом один объект может относиться к разным категориям. Категории могут быть программными, правилами, запросами. Оперируем не самими блобами/файлами/объектами, а правилами, по которыми определяется принадлежность к категории, категориями. Симлинков-привязок нет, всё генерируется "на лету", по запросу.

>Прошу Вас, ознакомьтесь с лицензиями на Oracle. То, что Вы написали - глупость. Стоимость *лицензионного* Оракла начинается от 0 долларов.

да ты-то походу и не покупал его никада. только девелопиш и не понимаеш почему нормальных людей пугает столько платить.

>Платить в любом случае нужно разработчкам и за железо.

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

>А чем хардлинки не подходят?

Тем, что у меня систематизированные данные на около восьми HDD на пяти машинах под NFS + сменные носители (HDD + CD/DVD) + SSHFS на три-четыре машины.

> Ну никак не вижу связи между исполнителем трека и моей фоткой с последнего отпуска

Придет к тебе жена фотки смотреть и скажет, "а помнишь, мы тогда фотографировались и ещё эта вот музыка играла" ?

>Стоимость *лицензионного* Оракла начинается от 0 долларов.

ентерпрайз едишн (поправьте если это даже стандарт) начинается с 15к за проц. причем каждый год идёт доплата. это ж поставить 10 серверов на оракле можно замок купить с привидением. в то время как поставить 2 сервера на оракле и 8 на жяве совершенно другие деньги, вполне подъёмные для среднего бизнеса.

>Придумался какой-то навороченный GIT.

Самый прикол, что я нечто подобное буду делать, как дойдут руки, под fuse для Tellico. Т.е. каталог с подкаталогами - категориями/исполнителями/жарнами - и там файлы с mime, для которых будут генератор превьюшек по обложкам из той же БД Tellico и клик по которым будет запускать фильм, буде таковой найдётся на несменных носителях, или будет предлагать вставить "DVD № XXXXX из коробки XX", буде такового на винте не найдётся.

Но это - немного из другой оперы, а вот соответствующий fuse над dbfs - мог бы быть весьма похож ;)

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

> Су-33 относится к "Истребителям", "Продукции КнААПО", "Разработан в ОКБ Сухого", является "Палубным самолётом" и т.п. :) Поскольку это не просто тэги, а иерархические тэги ("Типы самолётов", "Производственные объединения", "Конструкторские бюрю") и т.п. - получается множественная иерархия. Используется, естественно, на сайте.

Хорошо, что на сайте, а не по бухгалтерии проводите.

> Самый прикол, что я нечто подобное буду делать, как дойдут руки,

во, блин, одинаковые мысли приходят в разные головы. Я подбирался со стороны "положить кеш SQUID в GIT, сделать семантический ScrapBook общий для всех браузеров в системе, или там каталогизатор для CD с настраиваемой семантикой", ну и застрял где-то на фазе прототипирования. Понравились идеи от GIT, Logic FS, Plan9, XFind (ссылки битые), XPath over FS ( http://xmlhack.ru/protva/xquery/ ) , Qt Patternist http://labs.trolltech.com/blogs/category/labs/internet/patternist/ (пример как раз с XML/XSLT над FS). Где-то видел и пример XML над FUSE.

Самое зрелое, IMHO, взять что-то общее от xmlhack + Logic FS + GIT.

Были мысли как раз по каталогизатору дисков: допустим, собираем мы диски к журналам, подбираем новый софт (ну нету анлим интернета, например). Насобирали несколько десятков по 3-4 вида журнала, у каждого -- своя структура каталогов. Эту структуру хочется описать единообразно, каким-то XML+XSLT+свой препроцессор, и хранить софт с дисков в единой базе (с категориями, тегами, версиями софта), делать архивы на какую-то глубину.

При этом у нас XML файла,с описанием содержимого, как в диске к LinuxFormat нет, его составит сама программа по заданному XML преобразования ФС в метаданные, который юзер может сам составить в каком-то визуальном билдере.

Правда, реализация так и застряла на уровне идей и прототипов :(

см. также: http://uucode.com/texts/xfind/index.html