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

> man chroot

+1

Правда что там будет с шареной памятью , если mysql использует SysV IPC ?

> титан Рейзер хотел сразу сделать "по человечески" а именно оптимальная FS низкого уровня а поверх нее плагины для семантики/синтаксиса и для метаданных. То есть решить вопрос кардинально и на века.

Ага, и всё это - в ядре. Воистину титанический труд.

ИМХО, не предназначались плагины ReiserFS для сортировки фотографий по метаданным. Если это надо - делай себе ФС через FUSE, а еще лучше - просто стандартизируй формат метаданных в EA, и будет всем щастье.

>>> Файл есть строка в таблице базы данных. Вы говорите глупость.

>>Ась? Я могу выборку из нескольких таблиц сделать. Что там будет файл?

>Таблица - есть директория. Пожалуйста: grep qwery -r dir1 dir2

Бл*, ну дибилизм. Нужно вытащить всех людей с фамилией начинающейся на "Пу", и улицей начинающейся на "З", с их средней и максимальной ЗП.

SELECT peoples.people_id, peoples.name, Avg(salary) , Max(salary) FROM streets INNER JOIN peoples ON streets.street_id = peoples.street_id INNER JOIN salary ON peoples.people_id = salary.people_id

GROUP BY peoples.people_id, peoples.name, peoples.soname, streets.street_name HAVING (((peoples.soname) Like 'Пу%') AND ((streets.street_name) Like 'З%'));

Это достаточно простой пример для тех, кто плотно работает с СУБД. А теперь пример того же на ФС (помним про fk, constraints, indexes)

> > man chroot

> +1

> Правда что там будет с шареной памятью , если mysql использует SysV IPC ?

Просто нужно использовать правильный chroot-на-стероидах http://linux-vserver.org/ или http://openvz.org/

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

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

А в чем проблема? Создаете /home/user/data/su-33 и кладете в его расширенные аттрибуты все те данные, в расширенные аттрибуты файла "истребители" кладете (или в сам файл) путь /home/user/data/su-33.

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

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

>Бл*, ну дибилизм. Нужно вытащить всех людей с фамилией начинающейся на "Пу", и улицей начинающейся на "З", с их средней и максимальной ЗП.

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

> Нужно вытащить всех людей с фамилией начинающейся на "Пу", и улицей начинающейся на "З", с их средней и максимальной ЗП. > А теперь пример того же на ФС (помним про fk, constraints, indexes)

Если далеко не ходить, OQL, SPARQL, XQuery/XPath

Хотя проще в каком-нибудь навигационном язычке запросов, что-то вроде

People.SelectFieldsOnRegex('Family','Пу*').SelectFieldsRegex('Street','З*').Agg egateField('Salary', 'avg','max')

Здесь People -- это постепенно параметризуемый closure, который выдает нужные данные лениво, при обращении к нему (вида списка хешей с ключами avg, max)

Проще смотрится?

Ну правда надо еще написать это навигационное АПИ, объектное или функциональное.

При этом "индексы"= лениво вычисленные ФЗ с соотв. параметрами

Ну или см. пример от r с кложурами на Яве: http://www.linux.org.ru/view-message.jsp?msgid=2224488&page=1#2226995 , правда синтаксис -- тихий ужас.

> как вкручивать все эти красоты в стандартный юниксовый VFS.

хм, у нас есть целых два варианта: 1) как в /proc/, /proc/someproc/fd/filedescriptor, filedescriptor -- ссылка на нужный файл. Теперь представим, что эта ссылка -- не fd, в хардлинк. Вот и получили "вытаскивание нужных файлов по запросу" 2) как в dbus, протоколе 9P в plan 9 : есть какие-то стандартизированные "метаданные", к которым происходит обращение

> придумывать разные расширения файлового API

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

>anonymous (*) (24.12.2007 16:41:54)

Вопрос а где тут JOIN файлов ИЛИ вы предлашаете делать денормализацию? Это такой процесс из-за которого данные, что можно положить в 100 разьезжаются до Gb-тов в виде одного CSV-плэйн файла.

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

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

Откройте для себя расширенные аттрибуты файлов - работа с ними описана в стандарте POSIX.

> а где тут JOIN файлов

Внутре у неё, в кложурах. Можно строить "индекс" динамически, по параметрам в запросе, или если запросы не меняются, статически, через аспекты (читать Книжника http://www.ispras.ru/~knizhnik/abstract.ps.gz http://www.ispras.ru/~knizhnik/dissertation.ps.gz )

Выделяются запросы, выделяются параметризации "кложуров", потом через аспекты эти индексы поддерживаются и обновляются.

> Можно строить "индекс" динамически, по параметрам в запросе, или если запросы не меняются, статически, через аспекты

Ура, каждому запросу - по оптимальному индексу!

Мечтатели, блин.

Что, ручную расстановку индексов по хинтам в профилировщике нельзя выполнить автоматизированно?

>>> Можно строить "индекс" динамически, по параметрам в запросе, или если запросы не меняются, статически, через аспекты

>> Ура, каждому запросу - по оптимальному индексу!

> Что, ручную расстановку индексов по хинтам в профилировщике нельзя выполнить автоматизированно?

'строить "индекс" динамически, по параметрам в запросе' - заметь слово 'строить'. Если это не значит 'создавать' - то что это значит? "Расставлять хинты"? Или "каша в глове"? Или что?

> Если это не значит 'создавать' - то что это значит?

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

Допустим, теперь нет SQL, ОО БД с навигацией и кложурами. Но индексы всё равно надо делать, вот и делаем их автоматизированно, автоматически анализируя планы типичных запросов.

И почему тут собственно нельзя автоматически назначить "каждому запросу - по оптимальному индексу!" на заданных типичных запросах на заданных типичных данных? простой анализ, недоСППР вроде

>Просто нужно использовать правильный chroot-на-стероидах
>http://linux-vserver.org/ или http://openvz.org/

Бугага. Это не честно ;) Это очень удобно, сам юзаю везде где могу, но это не честно :) - по условиям задачи chroot обычный и патчей въядро не педусмотрено.

Но кстати с 2.4.x ядерами работает Usermode Linux. Так что для тех случаев когда апгрейд непредусмотрен все не так страшно как человек тут расписывал.

>ИМХО, не предназначались плагины ReiserFS для сортировки фотографий по
>метаданным. Если это надо - делай себе ФС через FUSE, а еще лучше - >просто стандартизируй формат метаданных в EA, и будет всем щастье.

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

Просто стандартизировать формат метаданных в EA это костыль :p или в лучшем случае элемент. Он же предлагал именно что максимальную гибкость в области EA, что бы даже если что-то непредусмотрели можно было все дописать.

И кстати ИМХО его плагины, во всяком случае часть, были очень даже юзерспейс. В общем идея трансляторов Хурда бродит как призрак
коммунизма довольно давно :)

Но вот "допиши fuse" вы в чем то правы. Просто Рейзер фактически предлагает несколько другой интерфейс к системе, у него свой "fuse".
Идея(одна из) именно в том чтобы каждая программа могла свои данные быстро экспортить в единое пространство файло используя аналог fuse.

Сейчас кстати можно и реализовать его задумки используя fuse для синтаксиса и вызова плагинов работающих с метаданными, стандарный ext3 для хранения данных и какой нибудь postgres/mysql для среды выполнения плагинов. Прямой доступ к разделу с данными закрыть для сохранения data integrity , обращатся только через соотвествубющий fuse.

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

Данные=объекты.

"We have persistent objects, they're called files" (c) Ken

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

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

> Просто стандартизировать формат метаданных в EA это костыль :p

В той же мере, что и все стандарты.

> идея трансляторов Хурда бродит как призрак коммунизма довольно давно :)

Это всего лишь механизм реализации - вещь важная, но не главная.

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

Скорее всего да - там рассматривался интерфейс к почте через ФС, в том числе.

> А я о плагинах к реальной ReiserFS4.

Это другая область, действительно.

Плагины к реальной РейзерФС4 делались с расчетом их "прямо сейчас" применения в реальных проектах реальных заказчиков. А это серверы для всяких хитрых интернет сервисов, ИМХО.

Но учитывая куда поперала дискуссия все скорее ближе к теории идеальной FS в вакумме :) , нет ?

> Это всего лишь механизм реализации - вещь важная, но не главная.

Чую что ты не совсем прав :) а доказать не могу ;) Этот механизм реализации с практической точки зрения направляет развитие в нужном русле и открывает новые пути. Требования к плагину в ядре не сравнить с юзерспес модулем - второй может (и должен) заюзать каждый пупкин пишущий очередной "прасмотарщег кортиног с музекой" :)

> Но учитывая куда поперала дискуссия все скорее ближе к теории идеальной FS в вакумме :) , нет ?

Нет. То, что здесь обсуждается, даже нельзя назвать ФС. Это скорее "SQL-сервер, реализующий еще и open(2)".

>> Это всего лишь механизм реализации - вещь важная, но не главная.

>Чую что ты не совсем прав :) а доказать не могу

Я прав. Всё, о чем говорилось в этой ветке, можно реализовать через FUSE - уже сейчас, не дожидаясь HURD, не трогая ядро вообще.

> даже нельзя назвать ФС. Это скорее "SQL-сервер, реализующий еще и open(2)".

скорее, внешний интерфейс ФС к объектному хранилищу нижнего уровня, в SQL или в объектах с навигационным языком запросов и кложурами, или в GIT-блобах с прямым доступом. Что там будет на нижнем уровне -- можно выбрать по обстановке.

> Всё, о чем говорилось в этой ветке, можно реализовать через FUSE - уже сейчас, не дожидаясь HURD, не трогая ядро вообще.

От ядра таки нужен inotify. Когда его обрабатывать, чтобы реализовать индексы, вопрос неясен -- или сразу или отложенно лениво при обращении к запросу.

В Хурд-трансляторах красива унификация, что ресурсы однозначно идентифицируются в соотв. пространстве имён. С другой стороны, например псевдотерминалы или /dev/cons, /dev/window в Plan9 ссылаются на _разные_ ресурсы, эффективно разруливая общие ресурсы уже на этом уровне. Ядру остаётся только мультиплексировать файлы-ресурсы отображая разные /dev/windowXX в нужный в контексте соотв. процесса. Всё равно каждый процесс видит только свой виртуальный /dev/window

Лучше бы нужный API "верхнего уровня" для работы с метаданными обсудили.

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

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

>> Всё, о чем говорилось в этой ветке, можно реализовать через FUSE - уже сейчас, не дожидаясь HURD, не трогая ядро вообще.

> От ядра таки нужен inotify

Он УЖЕ есть. И FUSE тоже УЖЕ есть. Всё есть - реализовывай gitfs хоть сейчас.

> Лучше бы нужный API "верхнего уровня" для работы с метаданными обсудили.

Их уже 2 - SQL и EA.

>Всё есть - реализовывай gitfs хоть сейчас.

Я в курсе, просто описываю явно требования к ядру, зависимости.

> Их уже 2 - SQL и EA

МЕТАданными? я собственно про юзер-левел, теги, категории, правила обработки категорий, булевы операции над категориями, индексы для быстрого поиска. Тут пока много неясного и нестандартизированного, придется сесть и расписать.

метаданные вне контекста какой-то онтологии описывать сложно, значит нужен какой-то стандарт описания онтологии и её метаданных. RDF уже есть готовый, видел и какой-то FUSE по RDF. Но он довольно громоздкий.

Так тебе нужен был API или определение самих метаданных? Это малость разные вещи.

> Тут пока много неясного и нестандартизированного, придется сесть и расписать.

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

> Так тебе нужен был API или определение самих метаданных?

нужно что-то вроде API/протокола "общей шины" для метаданных, как dbus стал для управления десктопными приложениями, только для данных. Что-то вроде этого, что ли http://www.freedesktop.org/wiki/Specifications/shared-filemetadata-spec

> И в этом - главное

просто это должно быть на уровне общих спецификаций, а то Logic FS -- само по себе, KDE4/Nepomuk -- само по себе, RDF в Мозилле, Гном, MacOSX/Spotlight -- сами по себе.

Повторяется ситуация как с десктопами (была), dbus/dcop.

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

угу, у 64бит базы 32 битный инсталер, настоящий "энтерпрайс"...

Уж не намекаете ли вы на то, что оракелевский инсталлер - глобально и надёжно?

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

Поржал от души, спасибо.

Думается что обреченность коммерческих баз зависит более от поддержки оных всякого рода софтовыми компаниями.
Если все написатели операционных дней банков, всяких там CRM/ERP перепишут софт свой с oracle на postgresql - тогда дааа, будет "обреченность".

Тогда уже не обречённость а капец настанет, что есть существенно разные вещи.

> Но кстати с 2.4.x ядерами работает Usermode Linux. Так что для тех случаев когда апгрейд непредусмотрен все не так страшно как человек тут расписывал.

это тот, который fedora с 2.6.24rc5 ? отличное, отличное решение :)

> это тот, который fedora с 2.6.24rc5 ? отличное, отличное решение :)

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

> Есть рабочие альтернативы ФС?

Лет ...нцать как есть. man OS/400 детко. :)

Грубо говоря - в OS/400 как таковой файловой системы нет, ее место занимает DB/2. Впрочем деления на дисковую и оперативную память там тоже в привычном нам смысле отсуствует...

И вся это конструкция - не просто рабочая, а очень хорошо рабочая. AS/400 - одни из самых надежных и стабильных систем для хранения и обработки данных (СУБД) на рынке.

Хорош Flame :))) ocp dba