мимоходом

[avva]

Интересно, а почему современные операционные системы не предоставляют возможности писать внутрь файла, раздвигая его? Т.е. запись в режиме insert, а не overwrite?

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

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

Comments

[nine_k]

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

Но кому файлы с дырками нужны, более-менее понятно; кому нужен эффективный append, тоже понятно. Кому нужен insert? Не знаю :)

[avva.livejournal.com]

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

[dimrub.livejournal.com]

Базам данных - пожалуй, что нет. Они работают либо с fixed length fields, либо с блобами, на которых такие операции никто, наверное, не производит.

Возможно, XSLT такой in-place editing был бы кстати.

[avva.livejournal.com]

Ну а представь, что тебе хочется вставить энное количество новых fixed length fields в середину файла.
Если это быстрая операция, то индексация во многом упрощается: ты вставляшь данные там, где они должны быть (скажем, согласно главному индексу), а не добавляешь в конец файла.

[jsn.livejournal.com]

заметим, при такой вставке у Вас сползают все индексы всего, что было после вставляемого куска, и все они должны быть перестроены, и все процессы, которые эти индексы держат в бошках, должны их перечитать -- индексация реально сильно усложняется и удорожается.
кроме того, использование частично заполненных блоков в середине файла увеличит размеры inode и indirection блоков в два-три раза, и да, начисто сломает mmap() [и понятие block device-а вообще, кажется], очень сильно усложнит и удорожит lseek(2) [ровно те же проблемы, что и с индексами], при активном использовании может вызывать значительную фрагментацию внутри файла, что сделает read(2) и write(2) неэффективными, и т.д., и т.п.

[avva.livejournal.com]

да, да, всё верно. Но всё равно, можно ведь помечтать? ;-)

Re: Reply to your comment...

[jsn.livejournal.com]

да-да, конечно -- к сожалению, этот аргумент пришёл мне в голову уже
после того, как я отправил коммент :)

[dr-tambowsky.livejournal.com]

Я думаю, что особенной пользы это бы не принесло. Требуется усложнение ядра файловой системы, причём функциональность нужна (?) только для весьма специфических приложений ("базы данных"), а отразится overhead на всех приложениях. Как бы быстро не работали сейчас файловые системы - этим ведь и пользуются вовсю, в памяти ничего не держат и подгружают данные/конфигурацию/классы динамически прямо с диска, в такой ситуации overhead противоречит классовым интересам пролетариата. Далее, даже для "баз данных" выгода не столь очевидна: как Вы сами правильно заметили, нужен индекс. При наличии же индекса и файловой системы с произвольным доступом, не всё ли равно где лежит запись, в конце или в начале? Индексация не упрощается. Записи должны идти строго по порядку в ситуации когда индекса нет вообще и индексация вычисляется из наивных соображений - это уже не база данных а невесть что, вместо "упрощения" мы заработали серьёзное ограничение. Разумеется "произвольный доступ" - это интерфейс, в конец файла лазать дольше, но это уже оптимизация. В большинстве ситуаций Вам всё равно нужно будет динамически определить нагрузку и, теоретически, переписать файл так, чтобы наиболее часто запрашиваемые записи были в начале. По-моему, так делают редко, а главное - это разовая операция, не имеющая отношения к "индексу" и смежному расположению "соседних" записей. Единственный пример, где "insert" был бы удобен, который я могу придумать - это, как раз, не база данных, а безындексный "плоский" файл - простой текстовый документ. В этой ситуации было бы круто вписать только что вставленную строчку сразу на нужное место. Но по сравнению с мировой революцией - это тоже мелочь. Тем более, что в типичных приложениях если уж текст редактируется, то настолько интенсивно, что держать промежуточные результаты нужно в буфере.

Одним словом, не нужно это всё трудовому народу, по-моему

[109.livejournal.com]

fixed length fields! это какие базы - dBase, что ли? все нормальные rdbms испокон веков со строками переменной длины работают.

[alll]

И испокон веков в пособиях по оптимизации пишут: чтобы уменьшить нагрузку - используйте записи фиксированой длины. Хотя в эпоху гигавсего на такие мелочи внимание обращать не принято.

[109.livejournal.com]

и вас, конечно, не затруднит дать линк на производителя rdbms, где написано про такую "оптимизацию"?

Re: вас, конечно, не затруднит

[alll]

Хм? Затруднит, конечно - равно как затруднит дать линк на таблицу умножения. Впрочем, навскидку: For MyISAM tables, if you don't have any variable-length columns (VARCHAR, TEXT, or BLOB columns), a fixed-size record format is used. This is faster but unfortunately may waste some space.

Re: вас, конечно, не затруднит

[109.livejournal.com]

во-первых, ссылка на эту фразу будет http://dev.mysql.com/doc/mysql/en/Data_size.html, а не то, что вы дали. во-вторых, там прямо первым предложением раздела написано "One of the most basic optimizations is to design your tables to take as little space on the disk as possible. This can give huge improvements because disk reads are faster". видите фразу "huge improvements"? надо объяснять, что строка переменной длины занимает меньше места, чем фиксированной? таблица умножения my ass.

и, конечно, я не имел в виду это поделие на базе dbasoподобных таблиц. я имел в виду нормальную базу данных, читай: оракл, ms sql server, или на худой конец db2.

Re: вас, конечно, не затруднит

[alll]

Пожалуй, нам лучше остаться каждому при своем заблуждении.
[break]

Re: вас, конечно, не затруднит

[109.livejournal.com]

да пожалуйста, оставайтесь при своём заблуждении.

[auto194419.livejournal.com]

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

нелинейный видеомонтаж - да, но как-то не сложилось.

[finger6.livejournal.com]

Серьёзные базы данных подчастую не работают над файловой системой, а пишут напрямую в блочные устройства (block devices) параллельно ФС, но не над ней.

[lazha.livejournal.com]

Ретроактивные логи.
Текстовики, например xml-word документ.