[Comm] Мысль по поводу организации общего файлохранилища (для обсуждения)

[Comm] Мысль по поводу организации общего файлохранилища (для обсуждения)

[Денис Черносов]

Навеяно вот этой статьей и экспериментами с Ruby On Rails и
вдохновением от wiki-технологий:

http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_%D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2

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


Причины:
1) отсутствие общепринятых паттернов файловой иерархии для большинства
случаев (включая соглашения об именовании файлов и каталогов и
разделения доступа к ним). Их не предлагают по умолчанию в таких
продуктах, как Samba или Nfs (примеры настройек для папок верхнего
уровня не в счет - это просто специализация файлопомоек) и этому не
учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому
что её нет нигде.
2) отсутствие автоматических средств для быстрой организации
умолчальных деревьев каталогов, выставления прав на них, заполнения и
актуализации метаинформации о содержимом каталогов, автоматическом
перемещении, переименовании, удалении файлов и каталогов. Нет смысла
обвинять пользователей в том, что они не хотят выполнять изо дня в
день работу более подходящую для роботов.

При наличии формализованных соглашений, становится возможным создание
скриптов на все случаи жизни (как это сделано в Ruby On Rails).
Остается только один вопрос - как, не порождая новых сущностей (хотя
бы на стороне клиента) и зависимостей реализовать это на базе samba,
nfs, ftp.
Очевидно, через адресацию - несуществующий адрес воспринимается, как
команда и при осмысленности этой команды и наличии достаточных прав на
её выполнение - вуаля!
Что интересно - можно прикручивать этот модуль для отработки именно
несуществующих адресов, а это практически не повлияет на
быстродействие системы в целом. А в качестве доп. вкусностей еще
мечты: при наличии проблем, диагностическое сообщение (возможно с
предугадываниями, типа "наверное вы хотели вот этого" и/или
подсказками - "если хотите того, то начните сначала с этого").

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

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

Что скажете? Баян? Утопия?

Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения )

[Yuri Bushmelev]

В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a):
> Навеяно вот этой статьей и экспериментами с Ruby On Rails и
> вдохновением от wiki-технологий:
>
> http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%
>D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_%
>D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2
>
> Проблема:
> Чаще всего общие файлохранилища превращаются в файлопомойки, в которых
> даже хозяева файлов не могут разобраться. Это и перерасход места и
> потери рабочего времени на поиск и многочисленные дублирования со
> всеми вытекающими. Плюс целый букет проблем из области безопасности:
> трудности с настройками резервного копирования утечка корпоративных
> секретов, нелицензионный софт и пиратский медиаконтент и т.п.
> Отказ от файловых систем в пользу систем документооборота не всегда
> оправдан, поскольку накладывает достаточно много других ограничений и
> лишает традиционных преимуществ - понятность абстракции, высокое
> быстродействие и т.п.

Прям постановка проблемы из текста моей диссертации, которую я бросил, 
написав три главы и кусок кода.

> Причины:
> 1) отсутствие общепринятых паттернов файловой иерархии для большинства
> случаев (включая соглашения об именовании файлов и каталогов и
> разделения доступа к ним). Их не предлагают по умолчанию в таких
> продуктах, как Samba или Nfs (примеры настройек для папок верхнего
> уровня не в счет - это просто специализация файлопомоек) и этому не
> учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому
> что её нет нигде.

А вы представляете себе типовые паттерны на все случаи жизни с учетом 
субъективности каждого пользователя ресурса? Если так, то вам, совершенно 
определенно, можно выступать с семинарами по логической организации 
корпоративных хранилищ данных. И это не шутка :)

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

Тоже сильно похоже на кусок из моего диссера :)

> При наличии формализованных соглашений, становится возможным создание
> скриптов на все случаи жизни (как это сделано в Ruby On Rails).
> Остается только один вопрос - как, не порождая новых сущностей (хотя
> бы на стороне клиента) и зависимостей реализовать это на базе samba,
> nfs, ftp.

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

> Очевидно, через адресацию - несуществующий адрес воспринимается, как
> команда и при осмысленности этой команды и наличии достаточных прав на
> её выполнение - вуаля!
> Что интересно - можно прикручивать этот модуль для отработки именно
> несуществующих адресов, а это практически не повлияет на
> быстродействие системы в целом. А в качестве доп. вкусностей еще
> мечты: при наличии проблем, диагностическое сообщение (возможно с
> предугадываниями, типа "наверное вы хотели вот этого" и/или
> подсказками - "если хотите того, то начните сначала с этого").

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

> Что скажете? Баян? Утопия?

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

Я занимался частным случаем "помойки" для реализации хранилища документации. 
Там попроще, поскольку внутри есть текст, который можно классифицировать. 

Берем "помойку", проводим частотный анализ текста в каждом документе, 
выбираем N наиболее частоупотребимых слов в ресурсе (за исключением 
стоп-слов) и подаем на вход кластеризатора (в моем случае - нейронная сеть 
в режиме кластеризатора). Выходов у сети либо по количеству категорий, если 
дерево категорий одноуровневое, либо некоторое фиксированное число 
(например, 7), если категории могут быть вложенными (в этом случае, 
кластеризация проводится несколько раз по количеству уровней в дереве). 
Запоминаем, где был сигнал, подаем следующий документ.

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

Далее, нейронная сеть переключается в режим классификатора (отключаем 
обучение). Новые документы заливаются в спул, там их подхватывает 
классификатор, считает частотность и прогоняет ее через нейронку. По 
результатам классификации, документы кладутся в нужный каталог. 
Периодически (в зависимости от частоты появления новых документов) можно 
проводить кластеризацию и сравнивать ее результаты с тем, что есть сейчас. 
Как расхождение превысит некоторый лимит, переупорядочиваем структуру 
каталогов и документов в них (благо, это можно делать автоматизированно).

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

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

Это была моя утопия, от которой я когда-то отказался, потому что потерял 
интерес к теме и занимался на тот момент совсем другими вещами.

-- 
С уважением,
Бушмелев Юрий

Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения )

[Денис Черносов]

10 декабря 2008 г. 14:24 пользователь Yuri Bushmelev
<jay4mail@gmail.com> написал:
> В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a):
>> Навеяно вот этой статьей и экспериментами с Ruby On Rails и
>> вдохновением от wiki-технологий:
>>
>> http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%
>>D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_%
>>D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2
>>
>> Проблема:
>> Чаще всего общие файлохранилища превращаются в файлопомойки, в которых
>> даже хозяева файлов не могут разобраться. Это и перерасход места и
>> потери рабочего времени на поиск и многочисленные дублирования со
>> всеми вытекающими. Плюс целый букет проблем из области безопасности:
>> трудности с настройками резервного копирования утечка корпоративных
>> секретов, нелицензионный софт и пиратский медиаконтент и т.п.
>> Отказ от файловых систем в пользу систем документооборота не всегда
>> оправдан, поскольку накладывает достаточно много других ограничений и
>> лишает традиционных преимуществ - понятность абстракции, высокое
>> быстродействие и т.п.
>
> Прям постановка проблемы из текста моей диссертации, которую я бросил,
> написав три главы и кусок кода.
>
>> Причины:
>> 1) отсутствие общепринятых паттернов файловой иерархии для большинства
>> случаев (включая соглашения об именовании файлов и каталогов и
>> разделения доступа к ним). Их не предлагают по умолчанию в таких
>> продуктах, как Samba или Nfs (примеры настройек для папок верхнего
>> уровня не в счет - это просто специализация файлопомоек) и этому не
>> учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому
>> что её нет нигде.
>
> А вы представляете себе типовые паттерны на все случаи жизни с учетом
> субъективности каждого пользователя ресурса? Если так, то вам, совершенно
> определенно, можно выступать с семинарами по логической организации
> корпоративных хранилищ данных. И это не шутка :)
>
>> 2) отсутствие автоматических средств для быстрой организации
>> умолчальных деревьев каталогов, выставления прав на них, заполнения и
>> актуализации метаинформации о содержимом каталогов, автоматическом
>> перемещении, переименовании, удалении файлов и каталогов. Нет смысла
>> обвинять пользователей в том, что они не хотят выполнять изо дня в
>> день работу более подходящую для роботов.
>
> Тоже сильно похоже на кусок из моего диссера :)
>
>> При наличии формализованных соглашений, становится возможным создание
>> скриптов на все случаи жизни (как это сделано в Ruby On Rails).
>> Остается только один вопрос - как, не порождая новых сущностей (хотя
>> бы на стороне клиента) и зависимостей реализовать это на базе samba,
>> nfs, ftp.
>
> Нужно просто информационные ресурсы раскладывать по каталогам так, чтобы это
> устраивало субъективность всех пользователей помойки.
>
>> Очевидно, через адресацию - несуществующий адрес воспринимается, как
>> команда и при осмысленности этой команды и наличии достаточных прав на
>> её выполнение - вуаля!
>> Что интересно - можно прикручивать этот модуль для отработки именно
>> несуществующих адресов, а это практически не повлияет на
>> быстродействие системы в целом. А в качестве доп. вкусностей еще
>> мечты: при наличии проблем, диагностическое сообщение (возможно с
>> предугадываниями, типа "наверное вы хотели вот этого" и/или
>> подсказками - "если хотите того, то начните сначала с этого").
>
> Тут ничего не могу сказать.. Искусственный интеллект на уровне доступа к
> данным я не рассматривал. Я предпочитаю использовать его на уровне
> публикации ресурсов.
>
>> Что скажете? Баян? Утопия?
>
> Скажу, что такие вещи существуют. Обычно они входят в состав корпоративных
> систем документооборота и стоят много денег. Простейший случай -
> авторубрикаторы. Об их качестве ничего сказать не могу - не трогал.
>
> Я занимался частным случаем "помойки" для реализации хранилища документации.
> Там попроще, поскольку внутри есть текст, который можно классифицировать.
>
> Берем "помойку", проводим частотный анализ текста в каждом документе,
> выбираем N наиболее частоупотребимых слов в ресурсе (за исключением
> стоп-слов) и подаем на вход кластеризатора (в моем случае - нейронная сеть
> в режиме кластеризатора). Выходов у сети либо по количеству категорий, если
> дерево категорий одноуровневое, либо некоторое фиксированное число
> (например, 7), если категории могут быть вложенными (в этом случае,
> кластеризация проводится несколько раз по количеству уровней в дереве).
> Запоминаем, где был сигнал, подаем следующий документ.
>
> В результате, получаем соответствие документов, которые подавались на вход
> кластеризатора, сигналам на его выходе (то есть, категориям). Обзываем
> категории, ориентируясь на смысл сгруппированных документов, создаем
> соответствующее дерево на файловой системе и раскладываем документы
> соответствующим образом.
>
> Далее, нейронная сеть переключается в режим классификатора (отключаем
> обучение). Новые документы заливаются в спул, там их подхватывает
> классификатор, считает частотность и прогоняет ее через нейронку. По
> результатам классификации, документы кладутся в нужный каталог.
> Периодически (в зависимости от частоты появления новых документов) можно
> проводить кластеризацию и сравнивать ее результаты с тем, что есть сейчас.
> Как расхождение превысит некоторый лимит, переупорядочиваем структуру
> каталогов и документов в них (благо, это можно делать автоматизированно).
>
> Вкратце, так. Но это все - чистая теория. Эксперименты я не провел. Поэтому,
> вполне может оказаться, что документы, собранные кластеризатором в одну
> категорию, на самом деле имеют очень мало общего. И для кластеризации
> недостаточно учитывать только частотность слов, но еще придется учитывать
> их взаимное расположение. Все это тащит за собой неслабый матаппарат,
> который я не люблю :)
>
> Для случаев нетекстовой информации (фильмы, музыка, графика, ПО) эта схема
> может быть использована по каким-либо метаданным (тегам, сопроводительным
> файлам и т.д.).
>
> Это была моя утопия, от которой я когда-то отказался, потому что потерял
> интерес к теме и занимался на тот момент совсем другими вещами.
>


Круто!!! Нет, серьезно! У меня были мысли попроще.

1) Интеллект на уровне создания ресурсов - безусловно епархия сис.
админа и руководства. Прописывается в оф. документе и доводится до
каждого. Ну, скажем, /{корзина,бухгалтерия,мультимедиа,шаблоны,home}
2) Первый шаг, он же паттерн, или соглашение: фиксированное <=7-9
жестко заданных каталогов  верхнего уровня. Т.е. каталог верхнего
уровня доступен на запись только админу и вложенные каталоги верхнего
уровня создаются только по бумажке сверху. Которая также доводится до
большинства. Как варианты:
/{актуальное,архив};
/{2008,2007,..};
/{001,002,..};
/{достоверная информация, неполная информация,нужно уточнить};
/{man, howto,info,guide,book,..};
/{конфеденциальное, для интранета, на ftp};
/{самарский филиал,брянский филиал,..};
/{video,audio,games,soft}.
Если основных проектов немного и все долгоиграющие, то можно их лепить
на вершину. В автоматизации не нуждается ибо делается достаточно
редко. В идеале - один раз.

3) Далее идут типовые паттерны для подкаталогов. Например, список ФИО
из какой-то БД, номера от одного до N, даты в любом количестве и
формате, список категорий (также из какой-то БД - это же можно в
скрипте настроить). Общие какие-то параметры можно выделить:
"создавать папку tmp","создавать папку arhiv", "чистить по
расписанию", "чистить по маске" и т.п. Некоторые параметры будут
выполняться немедленно, а другие сохранятся в .metadata и будут
инструкцией для скрипта исполняемого по крону. Начать можно с самого
малого и простого. 2-3 варианта.

И выглядеть это должно как-то так:
----------------------
$ls /smb/srv/media/video
.
..
$cd /smb/srv/media/video/#create/mediapattern/Metallica/
$ls /smb/srv/media/video/Metallica/
.
..
mpeg4/
dvd/
blue-ray/
readme.txt

-----------------------

Т.е. хочется именно попроще - командовать через адресацию. А синтаксис
команд максимально приблизить к вики-движкам и/или RoR.
Сразу же возникает целый веер вопросов. Например, как будет себя вести команда:
$cat /smb/srv/media/video/#create/mediapattern/Metallica/

Но это уже второй вопрос...

> --
> С уважением,
> Бушмелев Юрий
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community

Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения )

[Yuri Bushmelev]

В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a):
> 10 декабря 2008 г. 14:24 пользователь Yuri Bushmelev

> 1) Интеллект на уровне создания ресурсов - безусловно епархия сис.
> админа и руководства. Прописывается в оф. документе и доводится до
> каждого. Ну, скажем, /{корзина,бухгалтерия,мультимедиа,шаблоны,home}

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

-- 
С уважением,
Бушмелев Юрий

Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения )

[Денис Черносов]

10 декабря 2008 г. 15:26 пользователь Yuri Bushmelev
<jay4mail@gmail.com> написал:
> В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a):
>> 10 декабря 2008 г. 14:24 пользователь Yuri Bushmelev
>
>> 1) Интеллект на уровне создания ресурсов - безусловно епархия сис.
>> админа и руководства. Прописывается в оф. документе и доводится до
>> каждого. Ну, скажем, /{корзина,бухгалтерия,мультимедиа,шаблоны,home}
>
> В одной знакомой компании структура каталогов на, так называемых, "общих
> папках" регламентирована корпоративными стандартами. Сначала, вроде бы,
> даже наказывали за несоблюдение. Зато теперь - тишь и благодать. Все знают,
> где что лежит, и что самое главное - что куда класть. Так что, там обошлись
> организационными мерами.
>

Я еще не говорил, что перфекционизм хуже геморроя? Хочется "заглянуть
за горизонт", помечтать... Вдруг найдутся единомышленники.

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



> --
> С уважением,
> Бушмелев Юрий
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community