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

[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), если категории могут быть вложенными (в этом случае, 
кластеризация проводится несколько раз по количеству уровней в дереве). 
Запоминаем, где был сигнал, подаем следующий документ.

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

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

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

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

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

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