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

XML над FUSE: см. http://xmlhack.ru/texts/07/xquery_libferris/xquery_libferris.html

IBM поглотила создателя СУБД SolidDB
Компания IBM объявила о приобретении компании Solid Information Technology, занимающейся разработкой проприетарной СУБД SolidDB и хранилища SolidDB для MySQL, распространяемого в рамках лицензии GPL.
http://www.opennet.ru/opennews/art.shtml?num=13407

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

Поясни, что значит "дела интерфейсные"? GUI каталогизатора?

насколько я вижу интерфейс (АПИ) такого уровня хранения -- правила для категорий, автоматическая обработка по правилам, несколько равноправных пространств имён, как минимум одно пространство с адресацией по содержимому.

А ФС как раз могла бы стандартизовать метаданные-категории, как Linux Hierarhy Standart для FS , способ обработки запросов, кеширование запросов/обработку индексов, архивирование/проксирование данных.

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

ну слушайте, я не могу проводить исследование TCO ради поста на ЛОРе.

> Без общих слов и с учетом доходов компания исполюзущих продукты Oracle.

Доходы использующих oracle, естественно, позволяют им это делать :). Если мы говорим об удешевлении, имеет смысл смотреть на тех, кто не использует oracle, хотя он им бы пригодился.

> Дело в том, что программирование и алгоритмы СУБД несколько отличается от писания ядра, и тем более прикладного ПО в сторону наукоемкости и фундаментальных трудов.

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

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

full scan - а это кому как! массивно-параллельный full scan может еще и получше чем умные индексы будет!

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

Ну и почемууууу это никто не использует? Что мешает какому нибудь Apple сделать это ФС по умолчанию для новых маков? Все дураки?

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

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

Это не костыль. Это модульность. Атрибуты все равно придется складывать в одно место на диске, чтобы запрос по атрибутам не заставлял шариться по всему диску. И что плохого, если это "одно место" будет оформлено в виде каталога с sqlite/mysql/postgres'овскими базами?

Как уже заметили, эта фс-с-атрибутами

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

- не должна индексировать всякие временные файлы, и подчиняться прочим правилам.

вы предлагаете все это в ядро, в драйвер ext2 запихать?

>вы предлагаете все это в ядро, в драйвер ext2 запихать?

1. Почему ext2? Скажем, насколько я наслышан, Ханс Райзер в 4-ю версию ReiserFS очень многое из этого заложил :)

2. Неужто тот же sqlite стал таким толстым? :) А он обеспечит 99% от того, что требуется от ДБФС.

3. Ну да, модульность. Пусть модулем ядра будет :)

> Как уже заметили, эта фс-с-атрибутами > - должна знать о всяких типах файлов, с возможностью расширения и тд.

То есть, если я делаю свое приложение, со своим типом файлов, то мне и фс придется патчить?

> 2. А sqlite обеспечит 99% от того, что требуется от ДБФС.

Вот чего бы не устроить выездную сессию ЛОРа на каком-нибудь http://www.wikidot.com/ или http://pastebin.ru/ или какой-нибудь вики для составления ТЗ и спеков, "что нам требуется от ДБФС".

Какое-то АПИ верхнего уровня, семантика, стандартизированные метаданные, прозрачное отображение на что уже есть. Реализовать через FUSE или /proc/upyachka/...

Разные уровни хранения нижнего уровня, то ли это реляционное SQL, то ли объектное, то ли вот эта ерунда с LogicFS+GIT blobs.

+ Расписать в этой вики, что есть из аналогов (аннотированное ФС, семантический десктоп, KDE4/Nepomuk), и почему это нас не устраивает.

> То есть, если я делаю свое приложение, со своим типом файлов, то мне и фс придется патчить?

IMHO, нужно как с дататайпами в Амиге или БеОС: приложение регистрирует плагин к ФС (дататайп), после чего любое *другое* приложение может пользоваться этим плагином.

>Офигеть. Что-бы значит сделать горячий бэкап надо отрубить твою перделку? Об инкрементальном бекапе страшно тебя и спрашивать

Это решаемо, почитай доку по LVM

зы: Блин не думал что ввяжусь в эту разборку темболее за нелюбителя СУБД :)

>> Как уже заметили, эта фс-с-атрибутами > - должна знать о всяких типах файлов, с возможностью расширения и тд.

> То есть, если я делаю свое приложение, со своим типом файлов, то мне и фс придется патчить?

Вот и я о том же. Система имеет части, которым явно не место в ядре:

- парсер всяких файлов (ID3 теги, EXIF info, title pdf'ок и т д)

- движок выполнения запросов

- правила, что индексировать и когда (возможно, надо не все на лету индексировать, а то будет как в vista - копируешь фотки, а тут начинаются тормоза - индексировать полезло)

все это надо вытащить в userspace.

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

Я работаю с Ораклом с 2000 год, так что не надо мне рассказывать про политику лицензирования Oracle. Получить *лицензионный* Оракл можно по цене от 0 баксов и до бесконечности, в зависимости от типа лицензии, количества клиентских подключений и используемого комплекса ПО.

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

В очередной раз прошу Вас прочитать про типы лицензий на продукты Oracle. http://www.oracle.com/corporate/pricing/pricelists.html

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

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

Интересно, а господа, предрекающие гибель СУБД вообще знают, что такое транзакции? И что такое ACID? Особенно D из ACID -- Durability? И как они собираются реализовывать транзакции на файловой системе? Я не знаю такого системного вызова, который обеспечит атомарную синхронизованную запись в несколько файлов разом. Так что господам поклонникам файловых систем придётся вести свой собственный лог транзакций. А там и вся остальная инфраструктура типичной СУБД подтянется...

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

Думаешь, это сложно? Ну давай сэмулируем в git над ФС. git commit = "атомарная синхронизованная запись в несколько файлов разом", changeset, который однозначно идентифицирует транзакцию. Хеш над хешем -кодом блобов в content-addresable memory, блобов-файлов, которые входят в транзакцию.

> * Atomicity (атомарность): любые части (подоперации) транзакции либо выполняются все, либо не выполняется ни одной такой части.

в git: хеш changeset'а, фиксирующего изменения нескольких частей (файлов). Commitы атомарны, в отличие от CVS.

> * Consistency (непротиворечивость): по окончанию транзакция оставляет данные в непротиворечивом состоянии.

в git: фиксируются такие changeset'ы, которые соответствуют какой-то непротиворечивой конфигурации файлов (объектов, данных)

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

в git: фиксация в feature branch?

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

в git: теги на зафиксированные транзакции , "тег на релизную ветку"

Так что вроде бы всё присутствует, с соотв. ограничением семантики и полит. решениями, когда фиксировать коммиты.

> быстрее будет прочитать и распарсить файл с диска

прочитать может и быстрее, ключевое слово -- "распарсить". В БД лежит уже распарсенное и правильно типизированное, синтаксически и семантически, ограничениями целостности например.

>А там и вся остальная инфраструктура типичной СУБД подтянется...

её необязательно засовывать в "движок БД", можно вынести наружу: http://xmlhack.ru/archives/2007/12/000229.html

> в git

> в git

> в git

> в git

Дружище, это не про тебя придумали пословицу "When all you have is a hammer, everything looks like a nail?". Почему из кучи прог, обеспечивающих транзакционность, тебе так глянулся именно Git?

оракл жыф!! =)

>это не про тебя придумали пословицу

:-) когда гвоздь можно просто быстро забить молотком, зачем искать микроскоп ^W перфоратор и гвоздодёр, 2 в одном?

> Почему из кучи прог, обеспечивающих транзакционность, тебе так глянулся именно Git?

память, адресуемая по содержимому и уникальные цифровые подписи (хеши) commit'ов. Это практически готовый id транзакции. Ну и работает он довольно быстро, годится для практических применений.

> Почему из кучи прог, обеспечивающих транзакционность, тебе так глянулся именно Git?

плюс, этот хеш, по которому адресуются блобы в Git - готовый OID, Object ID. Соответственно, персистентные объекты в файлах и представление объектов в памяти можно устроить прозрачно единообразно.

А ты не тот анонимус, который предлагал заменить адреса на GUID'ы для решения проблемы TLB flush в микроядрах?

ну я. А что? Я кстати, понял, что я хотел тогда сформулировать -- экзоядро с системой адресации в расчете на минимизацию коллизий вирт. адресов. Насколько я понял из педивикии, в PPC как раз хеши в MMU и получались. Локальность кеша конечно фиговая, но не там надо было подкручивать, а в области определения указателей, как теги в защищённом режиме Эльбруса.

мысль, кстати, в тему. а GUIDами у нас будут хеши блобов, которые лежат в GIT :)

такой мини-STM :)

> ну я. А что?

Стиль тот же.

> в PPC как раз хеши в MMU и получались.

Можно сказать и так.

>Стиль тот же.

всё, ты меня деанонимизировал, придётся регаться :)))

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

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

Гхмм. Доки на тему как сделать make и make install? Не припоминаю что-то проблем начиная ещё с 6ой версии.

> В том, что есть системы, отличные от дебиана и для разборки с постгресом нужно читать доки

Нафиг такие системы.

Офигеть.

Вообще говоря все то что вы сейчас рассказывали про DB FS уже давным давно сказал Ханс Рейзер в своей эпохальной статье на namesys.org, не знаю жива она еще или нет :) Он и свой рейзерфс затеял как реализацию этой концепции.

И против большинства возражений типа "а нп блобах БД сасут" были найдены адекватные ответы.

PS
Вы только спорить начали а он уже ООО открыл денег взял, четыре версии FS написал и под суд попал. Титан :) :) :) :)

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

Ты лучше помолчи про оптимизатор Оракла на больших объёмах. Хинты они ввели не от хорошей жизни и не от хорошего оптимизатора.

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

>хинт: нет.

Насчет AID я, наверное, даже соглашусь, хотя с git не работал. А вот с точки зрения "C" git даёт довольно мало, например согласованность двух файлов никак не гарантирована.

Господа, а меня из вышеперечисленного интересует примерно следующее:

Господа, а меня из вышеперечисленного интересует примерно следующее:
А почему все типы файлов нельзя передовать примерно следующим образом (ну по интернету например). Архив (gz,bz2) в котором лежат два файла (один - xml, второй - бинарник или текстовый файл).
Например: mp3
В первом файле: 
----
Тип: тип_мп3_версия1.1
Поле1: koi8-r (поле например определяет кодировку)
Поле2: Дэцл
Поле3: Крутой песняк
Поле4: Крутой альбом
.....
Поле12: VBR
Поле13: lame,mad (и т.д.)
....
----
Во втором: просто файло бинарное со сжатым звуком.

Описание "тип_мп3_версия1.1" хранится где нибудь на MegaCoolFreeStandarts.org. Если оно не установлено у пользователя на компе, то скачивается оттуда, и комп начинает понимать что это за порево. Если комп не понимает, то хотябы выдаёт что это тип такой-то, его понимает такой-то софт, такие то библиотеки.

Если файло текстовое, то содержание примерно следующее:
В первом файле:
Поле1: тип_С_programm_1.2
Поле2: en_US (кодировка компа откуда это ушло)
Во втором файле: собственно текст

Всё это для расположения в инете например или для переноса между машинами (разными платформами... )

Далее - софт. загрузился файл, если тип на данный момент не известен - файл во временное хранилище (типа UnknownFileType), из инета - загружается файло - описание (предварительно спросив :) )обновляется таблица в базе ответственная за тип возможного контента, бинарное файло - добавляется в табло с блобами, описание - в табло с описаниями, и связь описания с блобом. Если файло текстовое - то производится индексирование для быстрого поиска. После этих нехитрых махинаций, представьте в командной строке:

grep -t С_prog "void huyoid()"
или
find -t Video,mpeg,avi -size + 100M
find -t pdf -text "zhopa" | xargs evince
ну и т.д. как мозг позволит.

Мысль дальше - понятие группы файлов :) типа папок или архива :)

А при полном переходе на такую хрень: Файл1: ----- Type: Linux_library Name: libmp3lame Version: 1.1.1.1 Arch: x86_64 Deplist: lib1(version),lib2(version) ----- Файл2: бинарник

Не всемирный ли кайф наступит? :) Если их держать на LibsForge.org? :)

Ну а так как Остапа понесло, и группы файлов упоминались :) то на WorldOfDistros.org файлы: Debian_4.1.grp :) bubuntOS_8.6.grp

Ну остапа всё ещё прёт, по этому:
Файл1:
Тип: Linux_Shared_Library
glibc: 2.6
...
....
:)

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

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

а что не так с репликацией в MySQL ?

> А вот с точки зрения "C" git даёт довольно мало, например согласованность двух файлов никак не гарантирована.

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

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

Статью читал, не осуждаю.

Райзер, конечно, Титан, но позиционирование -- слишком системное, непонятное простой домохозяйке, только поисковику какому-нибудь.

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

> Архив (gz,bz2) в котором лежат два файла (один - xml, второй - бинарник или текстовый файл).

изобретаем ресурсные форки в HFS и папки-бандлы?

> Тип: тип_мп3_версия1.1

тип указывать надо в 2 видах: mime и

> Описание "тип_мп3_версия1.1" хранится где нибудь <..>. Если оно не установлено у пользователя на компе, то скачивается оттуда, и комп начинает понимать <.. или..> хотябы выдаёт что это тип такой-то, его понимает такой-то софт, такие то библиотеки.

изобретаем дататайпы в Амиге/БеОС , кодеки в Windows, индексаторы в Vista/Beagle?

дататайпы = системный плагин для создания новых, редактирования старых, конвертирования другого типа в этот тип файлов.

Практически дататайп=индексатор (для поиска)+кодек(для чтения) + конвертор(для записи) + стандартизированное АПИ для чтения/записи/конвертирования

> Если файло текстовое, то содержание примерно следующее:

+ file_id.diz, BibTex :: abstract , ISBN или как-то так =)

> представьте в командной строке:

> find -t Video,mpeg,avi -size + 100M

пример почти дословный из ссылки про xfind (давал выше), там было:

/find -xpath '/bin/*[@size > /bin/bash/@size]'

дополнительно к @size вводим @mimetype

> ну и т.д. как мозг позволит.

например, архивирование этой "метабазы", репликацию на другой компьютер =)

> понятие группы файлов

= категория. Файлы метим тегами, файлы с одинаковыми тегами образуют категорию (ручную). Или описываем правило, live query типа: "все файлы mkv <= 400M = категория онемэ", потом обращаемся к файлам по категории "онемэ"

И оперируем правилами automagically, а не папками вручную =)

> Файл1: > Тип: Linux_Shared_Library > glibc: 2.6

изобретаем манифесты в assembly-cборке в .NET?

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

>кстати, скажу честно, у меня так не получилось сделать ни разу.
man chroot

> vtVitus

кстати, и Ваши "распределённые блоги" с такими GIT-блобами реализуются довольно естественно.

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

>на WorldOfDistros.org файлы: Debian_4.1.grp :) bubuntOS_8.6.grp

0install - дистр? кстати, да, нужен. Странно что его ещё никто не сделал.

>Райзер, конечно, Титан, но позиционирование -- слишком системное,
>непонятное простой домохозяйке, только поисковику какому-нибудь.

Ну насчет домохозяйки вы немного загнули. Спорящий "нужен ли DB FS" народ влегкую кидается страшными словами простую домохозяйку
точно пугающими. И по этому вполне способен осилить - статья то в общем то понятная и с примерами.

А самое смешное что дискуссия как раз и ставит вопросы уже поставленные и в общем то отвеченные - дело за реализацией, хотя бы кривой и косой. Просто титан Рейзер хотел сразу сделать "по человечески" а именно оптимальная FS низкого уровня а поверх нее плагины для семантики/синтаксиса и для метаданных. То есть решить вопрос кардинально и на века.

Соответственно единственный серьезный неотвеченный вопрос в топике так и не всплыл - а именно как вкручивать все эти красоты в стандартный юниксовый VFS. Ответ то на него к сожалению дело будущего - придется пробовать разные варианты и придумывать разные расширения файлового API. Что само по себе полная ж - это же буквально шатает основы классического юникса.
И самое мезкое - для получения хоть сколько нибудь релевантных данных под эти новые API придется патчить существующие проги(точнее их кучу) с целью хотя бы пощупать как оно будет в деле.