[Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения )
Yuri Bushmelev
=?iso-8859-1?q?jay4mail_=CE=C1_gmail=2Ecom?=
Ср Дек 10 13:24:59 MSK 2008
В сообщении от Среда 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), если категории могут быть вложенными (в этом случае,
кластеризация проводится несколько раз по количеству уровней в дереве).
Запоминаем, где был сигнал, подаем следующий документ.
В результате, получаем соответствие документов, которые подавались на вход
кластеризатора, сигналам на его выходе (то есть, категориям). Обзываем
категории, ориентируясь на смысл сгруппированных документов, создаем
соответствующее дерево на файловой системе и раскладываем документы
соответствующим образом.
Далее, нейронная сеть переключается в режим классификатора (отключаем
обучение). Новые документы заливаются в спул, там их подхватывает
классификатор, считает частотность и прогоняет ее через нейронку. По
результатам классификации, документы кладутся в нужный каталог.
Периодически (в зависимости от частоты появления новых документов) можно
проводить кластеризацию и сравнивать ее результаты с тем, что есть сейчас.
Как расхождение превысит некоторый лимит, переупорядочиваем структуру
каталогов и документов в них (благо, это можно делать автоматизированно).
Вкратце, так. Но это все - чистая теория. Эксперименты я не провел. Поэтому,
вполне может оказаться, что документы, собранные кластеризатором в одну
категорию, на самом деле имеют очень мало общего. И для кластеризации
недостаточно учитывать только частотность слов, но еще придется учитывать
их взаимное расположение. Все это тащит за собой неслабый матаппарат,
который я не люблю :)
Для случаев нетекстовой информации (фильмы, музыка, графика, ПО) эта схема
может быть использована по каким-либо метаданным (тегам, сопроводительным
файлам и т.д.).
Это была моя утопия, от которой я когда-то отказался, потому что потерял
интерес к теме и занимался на тот момент совсем другими вещами.
--
С уважением,
Бушмелев Юрий
Подробная информация о списке рассылки community