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

["Денис Черносов" <denis0.ru@gmail.com>]

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