Сверхбыстрые винчестеры

Balancer> Это когда вместе со службой индексирования? А при чём тут ФС?

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

Balancer> DBFS подразумевает отсутствие отдельного периодического процесса индексирования.

Значит, она следующий шаг.

Balancer> Иначе любую ФС можно считать DBFS.

Если не задаваться вопросом цены процедуры индексирования и поиска - да.

Balancer> В NTFS нет индексного поиска по расширенным атрибутам. Вот у тебя в системе миллион файлов в ста тысячах каталогов. Сколько времени уйдёт на поиск нужного ключа? В случае нормальной DBFS - секунды.

Эт смотря как искать. Я и на NTFS сделаю за несколько сек, если придётся.

Balancer> Не круто, а банально. x86/Windows на десктопе, IE в Интернете, mp3 для музыки, avi в роли контейнера, Си/Си++/Java для разработки... Почти во всех случаях есть лучшие альтернативы. Но применить их сложно. Потому что то, что есть, уже устоялось

Устоялось сравнительно недавно и, скорее всего, не надолго.

Balancer>> Хм. Сколько там sqlite весит? Сотню килобайт? А H2Database? Да, это не СУБД, но «Примитивные запросы SQLя» обеспечивает с лихвой
pokos> Примитивные по тексту запросы могут быть очень напряжными в работе, вот ведь беда.

А это уже совсем другая история. Ты утверждал только «Примитивные запросы SQLя выливаются в такой гемор для ФС, что ёпрст.»

А сейчас уже начал усложнять

...

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

pokos> Того, что примитивными запросами нормальная БД не ограничивается.

А мы и не говорим про Оракл

Balancer>> Так что эта аналогия у тебя уже не в тему. То, что есть Oracle не отменяет стремительного роста популярности того же sqlite
pokos> Exel ещё более популярен, что с того?

Excel - не СУБД. СУБД - это Access. Но он НАМНОГО менее популярен, чем sqlite

Хинт: sqlite сегодня стоит в каждом Firefox 3.x для хранения всего, от кеша и закладок до настроек и истории.

pokos> Тебе ж сказали уже. Где реляционная модель?

1. СУБД - не обязательно реляционная СУБД. Автомобиль - не обязательно грузовой автомобиль...

2. Ты уверен, что WinFS - не реляционная? Я, вот, не видел её, чтобы делать такие утверждения.

Balancer>> DBFS подразумевает отсутствие отдельного периодического процесса индексирования.
Kernel3> Значит, она следующий шаг.

Вот это и будет настоящая DBFS. В смысле - реляционная (раз уж мы до конкретики дошли) DBFS.

И, да, это будет очередной шаг на устранение границы между ФС и БД.

Kernel3> Если не задаваться вопросом цены процедуры индексирования и поиска - да.

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

Kernel3> Эт смотря как искать. Я и на NTFS сделаю за несколько сек, если придётся.

Средствами только одной ФС ?

Kernel3> Устоялось сравнительно недавно и, скорее всего, не надолго.

Ну да. По 15-20 лет некоторые вещи... То у тебя 20 лет - недолго и ненадолго, то долго... Определись

Balancer> 1. Я не говорил, что граница исчезла. Я говорил о тенденции к стиранию этой границы.
Это асимптотический процесс.

Balancer> Э... Так, вроде, давно есть. Даже вот так: http://msdn.microsoft.com/ru-ru/magazine/cc163388.aspx ?
Прекрасно! Сон нарушен.

Balancer> Вот это и будет настоящая DBFS. В смысле - реляционная (раз уж мы до конкретики дошли) DBFS.

Для реляционной маловато всё-таки.

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

Да на цену просто забивать не надо и всё.

Balancer> Средствами только одной ФС ?

Средствами некоего стандартного для данной ОС API.

Balancer> Ну да. По 15-20 лет некоторые вещи... То у тебя 20 лет - недолго и ненадолго, то долго... Определись

Чего тут определяться? По историческим меркам - мало, по мерками ИТ-индустрии - много.

Balancer> А сейчас уже начал усложнять
Сомневаюсь...

Balancer> ...Проблемы начинаются на параллельной работе многих запросов с обновлением - но тут как раз вылезают ограничения связи с ФС.
А ФС-то тут при чём?

pokos>> Exel ещё более популярен, что с того?
Balancer> Excel - не СУБД. СУБД - это Access.
я к тому, что на Excel тоже можно псевдобазу накропать. Но это не значит, что он решит все задачи.

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

Balancer> 2. Ты уверен, что WinFS - не реляционная?
Уверен. Реляции там скрыты и не могут быть использованы снаружи. касаются они журналов ФС.

Надо Мишку звать, чую...

Balancer> Когда я подключаю свой КПК через USB-1(!)...

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

>>"Ск.записи/ск.считывания" На тех, что я выбрал прямо написанно: "Скорость записи 45Мб/сек"
Не то меряешь. На кучке мелких обновлений - просядет. Из-за устройства флеши самой по себе.

Balancer> Не катит. Целиком кладётся в кеш. Или ты о свопе? Ну так своп на SSD глупо класть

Ещё как катит. В raw формате может быть и под сотню мегабайт. А уж панорамы из 10 фотографий убьют кэш на фиг.

Balancer> упоминал.

Не, ты упоминал захват, ИМХО. А монтирование — это другое. А захвать в HD тоже не сахар.

Balancer> Сборка Linux-ядра в tmpfs по сравнению с другими ФС выигрыша не даёт Выигрыш можно получить только на установке.

Это смотря чем собирать. gcc давно не гонится за скоростью трансляции. Но на 4 башковой машине уже заметна разница (4 компилятора одновременно работают) с диска или из памяти.

Balancer> Она в иной плоскости кеширует. Например, результаты запросов. А обновления - ей сказали обновить, она это сделает. Дальше, уже забота ОС. Иначе бы рушилось всё очень уж сильно при отказах

Нет, это не так. Журналирование в ФС пришло из СУБД.

Balancer> Без неё СУБД будет сильно тормозить. Вспомни, как систему тормозил Firefox, когда в него засунули sync на каждый чих ради борьбы с какими-то багами связки sqlite + ext3

Не-а. Нормальная не будет.

Balancer> Нормальная СУБД вообще ничего не знает про файловую систему. Она говорит ОС писать данные, та - пишет. Механизм записи от СУБД скрыт. Может быть это будет мгновеная некешируемая запись. А может - вообще промежуточный слой в tmpfs Или, вообще, БД может быть в tmpfs развёрнута

Нормальная СУБД обычно имеет свою систему (ФС) работы с raw device. Это самый быстрый режим работы. Просто очень не многие могут настраивать СУБД работать в таком режиме и обеспечивать нормальный бэкап и восстановление. Поэтому многие и пользуются ФС.

pokos> Да ну на. Для начала пускай типы данных в ФС заведёт, хотя бы. Про оптимизацию обращений к записям с разными типами внутре я вообще молчу...
А тут ещё и хранение по столбцам есть. А ещё очень эффективное представление NULL в Оракле... Про всякие materialized view я уже и не упоминаю. Ну и расширение SQL-я за счёт внешне подгружаемых библиотек можно забыть.

Mishka> Это смотря чем собирать. gcc давно не гонится за скоростью трансляции. Но на 4 башковой машине уже заметна разница (4 компилятора одновременно работают) с диска или из памяти.

Вот именно на C2Q и собираю С -j5. Т.е. в пять потоков. И разницы между tmpfs и любой другой нормальной FS, даже если это что-то типа ext3 - нету. Именно на сборке. Вот когда сборка завершена и идёт инсталляция результата - тут уже разные FS дают разный результат.

Balancer> Это когда вместе со службой индексирования? А при чём тут ФС? DBFS подразумевает отсутствие отдельного периодического процесса индексирования. Иначе любую ФС можно считать DBFS.

А у тебя индекс в СУБД всегда автоматически доступен?


Balancer> В NTFS нет индексного поиска по расширенным атрибутам. Вот у тебя в системе миллион файлов в ста тысячах каталогов. Сколько времени уйдёт на поиск нужного ключа? В случае нормальной DBFS - секунды.

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

Balancer> Э... Так, вроде, давно есть. Даже вот так: http://msdn.microsoft.com/ru-ru/magazine/cc163388.aspx ?
Это не то. Это, вообще говоря, стыдно назвать транзакциями. У транзакция времён царя гороха, когда только внутренние вещи СУБД понимались, как необходимые для транзакций, теперь есть модель данных. Вот любое нарушение целостности в этой области, включая и фунциональные зависимости (и foreign key тут только малая часть их, а по хорошему, тут уже нормальные формы 4 и 5), определяются тем, кто пишет изменения. Скажем, в нашей базе есть чёткое условие статистики, элемента произведшего её, элемента, о котором её собрали, некоторые данные по адресам (мы говорим о сети) и диалогам разбивается на две большие транзакции — адреса и диалги — без адресов нет диалогов, а значит, если не прошло обновление адресов, то должны ёкнуться диалоги — пример вложенной транзакции наоборот — сначала адрес, а потом диалог. Вторая — полный набор статистики и элементов. Но второй шаг ссылается на первый. Если первый не прошёл, то второй не должен пройти в том случае, если в таблицах раньше адресов и диалогов не было. Иначе должен завершиться. Вот таких соотношений ФС не будут уметь поддерживать очень долго. Если не всегда.

Kernel3> ФС поддерживает уникальные ID для индексируемых данных. Можно и без них, да. Но будет собственно дольше и геморройнее.

Каких? Пока только текстовых. А как описать заголовок того же executable, чтобы найти только нужные версии программ?

Kernel3> Значит, она следующий шаг.

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

Balancer>> В NTFS нет индексного поиска по расширенным атрибутам. Вот у тебя в системе миллион файлов в ста тысячах каталогов. Сколько времени уйдёт на поиск нужного ключа? В случае нормальной DBFS - секунды.

Mishka> Нормальная СУБД обычно имеет свою систему (ФС) работы с raw device. Это самый быстрый режим работы.

А примеры таких СУБД?

upd. Ммм, всё, уже нашёл.

Блин, я негодуЭ! Только высказал мыслю о том, что СУБД нужна спецФС, как оказывается, что такую уже придумали, разработали и внедрили. Всё до нас украли.

HolyBoy> А примеры таких СУБД?

Ну, с Информиксом только так и работали. С Ораклом пока нет — поскольку в состав продукта входит эмбедед, то никто не хочет отвечать за администрирование таких баз и Ораклу надо больше денег платить.

HolyBoy> upd. Ммм, всё, уже нашёл.
HolyBoy> Блин, я негодуЭ! Только высказал мыслю о том, что СУБД нужна спецФС, как оказывается, что такую уже придумали, разработали и внедрили. Всё до нас украли.

Я уже в 1995 году с Информиксом так работал.

Да уж....открыл я тему про офисный компьютер...

Mishka> Ну, с Информиксом только так и работали.
Да, Информикс летал со страшным свистом. Шустрая база была.

Balancer> Э... Так, вроде, давно есть. Даже вот так: http://msdn.microsoft.com/ru-ru/magazine/cc163388.aspx ?
Кстати, я тут прочитал повнимательней.
Дык, я не о том спрашивал-то! Текст про наличие транзакций как таковых. Это тоже гуд, но я-то просил возможность отката.
Мишка пояснил примерно в том же направлении, я скажу попроще. Требуется возможность отменить состоявшуюся транзакцию по пост-условию, например, результату другой транзакции.

Wyvern-2> Да уж....открыл я тему про офисный компьютер...
Да не горюй! Просто у некоторых есть застарелые мозоли, а ты наступил невзначай...

Wyvern-2>> Да уж....открыл я тему про офисный компьютер...
pokos> Да не горюй!

СчаЗ Слезами по пояс обливаюсь
Вывод я сделал: надо немного подождать, подкрасться с тылу и реализовать задумку Оно того стоит.

AGRESSOR> Ник, у тебя что, память и проц (с шиной) самые быстрые, что ты вдруг именно в работу хардов уперся?

Ну, если хочется быстрого старта приложений, то винты тормозили всегда И сейчас тормозят. Даже если это SATA II на древнем P4-2,8ГГц

Balancer> Ну, если хочется быстрого старта приложений, то винты тормозили всегда И сейчас тормозят. Даже если это SATA II на древнем P4-2,8ГГц

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