gifts2017

Хранение файлов в NoSQL СУБД CouchDB

Опубликовал Юрий Хрипачёв (hrip) в раздел Обмен - Обмен с другими системами

В данной публикации приводится пример использования документо-ориентированной NoSQL СУБД CouchDB для хранения файлов и доступа к ним из базы 1С:Предприятия 8.2

Идея использования внешней базы данных появилась после того как столкнулся с необходимостью размещения большого количества файлов (Сканы документов, конструкторско-технологическая документация. Всего около 10 Гб.) в базе УПП с привязкой к справочникам и документам. И соответственно при их размещении стандартными средствами в Хранилище дополнительной информации начал увеличиваться размер самой базы и размеры архивных копий.

Решил использовать для хранения файлов NoSQL СУБД CouchDB т.к. для данной задачи нет необходимости в использовании реляционных СУБД. CouchDB является документо-ориентированной СУБД, не требующей описания данных. Все данные в базе данных хранятся в виде записей (документов). Любая запись (документ) в базе данных может содержать произвольное количество полей и вложений (файлов).

Доступ к данным осуществляется через REST интерфейс по протоколу HTTP. Все данные передаются в JSON формате.

Скачать CouchDB можно здесь, а прочитать хорошую статью для начального знакомства с СУБД можно здесь.

 

Установка и настройка СУБД.

Установка СУБД очень простая - со всеми пунктами соглашаемся и жмем "Далее".

После установки запускаем консоль администрирования СУБД (Futon)

Создаем новую базу данных

Присваиваем ей имя

Создаем пользователя с административными правами

Назначаем ему имя и пароль

Теперь нам требуется создать две функции, которые обеспечат возможность получать содержимое и версию документа.

Для этого выбираем вид "Temporary view"

Пишем код функции для получения содержимого документа СУБД (параметром будет идентификатор документа в СУБД, которым является GUID объекта из базы 1С).

Сохраняем функцию в СУБД

Теперь пишем код функции для получения версии документа СУБД

Тоже сохраняем функцию в СУБД

 

Работа с базой данных 1С.
Далее можно запускать демонстрационную базу 1С, которая может подключаться к созданной базе данных.

База данных состоит из справочников "Настройки для подключения к СУБД CouchDB" и "Справочник данных", а также общей формы "Просмотр файлов содержащихся во внешней СУБД" и общего модуля "NoSQL".

Для доступа к данным используются COM объекты "WinHttp.WinHttpRequest.5.1", "ADODB.Stream" и разработан парсер данных в формате JSON.

Справочник "Настройки для подключения к СУБД CouchDB"

Справочник "Справочник данных"

Элемент справочника "Справочник данных"

Форма "Просмотр файлов содержащихся во внешней СУБД"

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

 

Просмотр содержимого СУБД.

После довавления файлов, через консоль администрирования (Futon) можно просмотреть новые документы идентификаторы которых равны GUID элементам справочника "Справочник данных".

и можно просмотреть содержимое самих документов

Сохраненные функции тоже являются документом базы данных и их содержимое можно просмотреть или изменить

Важной особенностью СУБД CouchDB является то что она поддерживает версионирование документов. И поэтому любой файл даже после случайного удалению можно восстановить

Для удаления всех старых версий документов служит операция "Compact & CleanUp..." в базе данных.

 

Заключение.

Был показан пример настройки СУБД CouchDB, организован доступ к ней из базы 1С для возможности работы с файлам.

Разработан парсер данных в формате JSON (находится в общем модуле NoSQL).

Скачать файлы

Наименование Файл Версия Размер
Архивная копия базы данных 1С 56
.dt 35,25Kb
06.08.12
56
.dt 35,25Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Lo Fi (frai) 06.08.12 20:32
Планировал около полугода назад такое решение. тогда руки не дошли.
Хотелось бы узнать как организовал бекап для этой базы?
2. Максим Костиков (mkostya) 06.08.12 20:52
Это пять, как раз сегодня об этом думал... ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО, за то что выкладываете такие вещи это опыт и время... вообщем бегу пилить под себя)))
3. Юрий Хрипачёв (hrip) 06.08.12 21:34
(1) frai, для бекапа необходимо остановить службу сервера СУБД и скопировать файл ИмяБазыДанных.couch из папки "C:\Program Files\Apache Software Foundation\CouchDB\var\lib\couchdb"
4. Babys (babys) 07.08.12 01:04
(1) frai, на win серверах есть теневое копирование, это бекап без освобождения файла.
5. Roman Biblbox (mr zafod) 07.08.12 07:25
Когда выбирали NoSQL хранилище, почему склонились именно к Couch? MongoDB не пробовали?
6. Юрий Хрипачёв (hrip) 07.08.12 07:56
(5) mr zafod, Читал про него, но не пробовал. В плане надежности они приблизительно одинаковые. Работать СУБД будет в режиме очень низкой нагрузки, поэтому производительность тут не критична. Мне понравилась идея с доступом по http протоколу, да и консоль администрирования удобная.
7. Юрий Хрипачёв (hrip) 07.08.12 07:57
(4) babys, если честно даже не знал такую возможность, надо почитать будет.
8. Александр Шкураев (salexdv) 07.08.12 09:11
Зачетно! А как со скоростью работы такого рещения по сети? Притормаживает на клиентских машинах или нет? Какого размера пробовали передавать на клиентскую машину документы?
9. Юрий Хрипачёв (hrip) 07.08.12 09:31
(8) salexdv, Скорости хватает - приблизительно так же как и при копировании файлов по сети. Пробовал передавать файлы до 40 Мб. Средний размер файла у меня 1-10Мб. И передаются по сети (загружаются в СУБД или открываются) в среднем 1-5 сек. (зависит от размера файла, загруженности сервера).
10. Сергей Вн (EmpireSer) 07.08.12 09:39
А зачем вообще использовать любой вид БД для хранения файлов?
NTFS, FAT и т.д. - и есть форма NoSQL базы данных. Так зачем было создавать дополнительную оболочку одной БД над другой?
И конечно (4) babys правильно упомянул про "теневое копирование".
Конечно http доступ к данным в БД "как бы" хорошо, но это угроза безопасности. Из этого же разряда http и ftp в Oracle. Если данные в пределах 1С можно залогировать, проверить права доступа, то делать это уже и в БД - огромная проблема.
11. Евгений Сосна (pumbaE) 07.08.12 09:44
Когда смотрел couchdb была проблема с репликацией именно вложений в документ, т.е. при репликации на другие сервера (по факту планы обмена) для вложений не сохранялись версии в случаи конфликтов.
Подскажите как сейчас с этим делом, если знаете.
12. Александр Шкураев (salexdv) 07.08.12 09:51
(10) А вы пробовали хранить 400-500 тыс. файлов, например, картинок просто в папке и обращаться к ней по сети?
Нет можно, конечно, организовать хранение и в папке в виде дерева, тогда обращение будет шустрее, но СУБД, имхо для этого больше подходит.
13. Сергей Вн (EmpireSer) 07.08.12 10:22
(12) salexdv, у Вас хорошее статья.
Мне просто интересны обоснования...
1. А зачем нужно обращение из сети? И из какой сети? В безопасной среде делают так, что только 1С сервер может получать данные от такого сервера/БД. Иначе всегда будет существовать вероятность, что кто-то использует уязвимость БД и ему даже не нужно будет взламывать сервер с 1С, что бы залить "что-то нехорошее". Вот из-за чего http и ftp доступы к данным в БД это "сахар", который может принести очень много проблем. Намного проще организовать защищённое общения сервера 1С с БД по зашифрованному TCP каналу.
2. А если подумать о том, как БД хранят данные и если это файлы и они часто заменяются, удаляются, добавляются - то это ужас. Вот БД типа "файловая" как раз именно для этого создана и оптимизирована. Тут тебе и контроль доступа, и можно сделать логирование обращений, модификаций, добавлений. Короче - всё для файлов и только ради них.
14. Александр Шкураев (salexdv) 07.08.12 10:30
(13) Статья не моя ))
Я про то, что когда файлы хранятся просто на диске, а не в СУБД, и этих файлов очень много - обращение к диску занимает гораздо больше времени, чем чтение из БД.
А ограничение и логирование http тоже легко настроить, так что не вижу тут серьезной угрозы безопасности )))
15. Борис Скворцов (gaglo) 07.08.12 11:01
(14)
когда файлы хранятся просто на диске, а не в СУБД, и этих файлов очень много - обращение к диску занимает гораздо больше времени, чем чтение из БД

Ну когда 400-500 тысяч файлов в одной папке - верю. Но если сделать хоть относительно сбалансированное дерево каталогов - то с чего бы открытие файла по полному имени занимало больше времени, чем извлечение записи из БД, даже если она и антиSQL?
По безопасности я особых угроз не вижу. Разве что до файлов может добраться кто угодно любым проводником, а в БД залезть - надо иметь некое спецсредство. И преимуществ перед файловым хранением пока не вижу. Версионирование, быть может? Так в статье оно свелось к
файл даже после случайного удалению можно восстановить
- а это, кажется, должен обеспечить бэкап...
16. Сергей Вн (EmpireSer) 07.08.12 11:05
(14) salexdv, ну так Вам повезло, что Вы получили скорость обращения к файлам в БД быстрее, чем к диску.
Если серьёзно отнестись к системе хранения в файловом варианте, то можно получить потрясающие скорости. По сути это тоже самое, что оптимизация БД, т.к. если вдаться в дебри низкоуровневого хранения данных в БД, то мы напоримся на те же проблемы файлового доступа. Просто файлов меньше и они "жирнее", но сама БД хранит в них и бинарные данные файлов и свои журналы, метаинформацию и т.п., БД так же сталкиваются с фрагментацией, дают свои накладные расходы на организацию поиска.
Лично я для такой задачи оптимизировал бы сам сервер с файлами, отключил бы избыточность и т.п.

А про http - то я не зря спросил про сеть, т.к. я не понял как организуется получение файла из БД.
Тут файл на клиент передаёт сама БД по http или через сервер 1С?
17. Евгений Сосна (pumbaE) 07.08.12 11:12
Использую сервер ftp для таких случаев.
18. Сергей Вн (EmpireSer) 07.08.12 11:16
(15)

...Версионирование, быть может?...

Если это бинарные данные, то и возможностями ОС это можно сделать. Если организована версионность хранения текстовых файлов (любого вида), то лучшим формой "БД" тогда будет оптимизированные под версионность: SVN, CVS, Git и т.д. - тоже можно назвать "версионной БД".

По мне: лучше использовать то, что максимально оптимизировано под данную задачу. Если, конечно, это можно использовать.
19. Евгений Сосна (pumbaE) 07.08.12 11:21
(18) EmpireSer, SVN, CVS, Git хранят состояние версии для всей базы, а не для каждого отдельного документа. CouchDB/MongoDB вообще интересна своей репликацией и возможнстью разрешения конфликтов. В теории можно поставить в настройках, что состояние документа будет "сохранен", только тогда, когда этот документ расползется на несколько серверов.
20. Roman Biblbox (mr zafod) 07.08.12 11:31
(16) EmpireSer, Вы видели в работе, например, связку nodeJS + mongoDB (или + CouchDB или +Redis)? Скорость отдачи статики просто колоссальна. NoSQL - идеальное хранилище для документов, музыки, видео и тд. Если же Вы хотите делать сложные агрегации или выборки с условиями и join'ми - то NoSQL проигрывает обычным реляционным SQL базам данных.
21. Юрий Хрипачёв (hrip) 07.08.12 12:36
Хотелось бы, как я считаю, перечислить плюсы данного решения:
1. Хранение файлов просто на диске разложенных по папкам считаю неправильным т.к. можно любыми средствами ОС или программами их изменить или удалить. СУБД гарантирует доступ к данным только специальными средствами (здесь это обычные http запросы GET, PUT и DELETE).
2. СУБД поддерживает возможность авторизованного доступа к данным. Я не предлагал выкладывать СУБД в интернет (если кому то это будет необходимо, тогда придется серьезно разбираться с настройкой безопасности). У меня она используется в локальной сети.
3. Если надо будет устанавливать права на файлы для доступа из 1С, то это тоже возможно. т.к. документ СУБД может содержать любую информацию (например данные о пользователе его создавшем или о группе пользователя и т.д.).
4. Скорость поиска данных в базе и их отдача у NoSQL СУБД очень высокая (их поэтому и используют часто как хранилища).
5. Есть возможность делать бекап (писал здесь(3) hrip,). Есть возможность получить доступ к удаленным файлам без манипуляций с восстановлением копии базы извлечением файла оттуда и помещением его в рабочую базу (версионирование).
6. Можно СУБД разместить при необходимости на другом физическом сервере.
7. При использовании такой связки 1С и CouchDB не увеличивается размер базы 1С и бекапов. Для CouchDB достаточно иметь всего один актуальный бекап (т.к. в нем будут содержаться все версии документов с их вложениями).
22. Сергей Вн (EmpireSer) 07.08.12 12:44
(19) pumbaE, спасибо. Этот вопрос я изучу подробнее (как будет время).
(20) mr zafod, к сожалению не видел... (убрано)


... Скорость отдачи статики просто колоссальна. ...

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

Но опять же, я тут размышляю именно из предположения: файлы меняются часто, клиент 1С может файлы добавить напрямую в БД, безопасность сети может быть уязвима.
23. Сергей Вн (EmpireSer) 07.08.12 13:01
(21) hrip, спасибо за разъяснение. Но прошу сразу прощение за:
1. Доменная архитектура. Очень простая организация ограничения доступа как к 1 файлу, так и ко множеству. У нас в организации именно так и работает разграничение по сетевым ресурсам. Все компьютеры в домене. И только спец. средствами с вирусной архитектурой можно получить доступ "куда нельзя".
2. Доменная архитектура тоже использует авторизованный доступ.
3. Как я понял клиент запрашивает сам нужные файлы из БД, 1С только передаёт ссылки.
4. Тут возразить нечего. Но удивлён - какой поиск данных, если все ссылки на данные располагаются в 1С?
5. Кхм... Резервное копирование Windows и доступ через "Предыдущие версии" !?
6. Ну DNS ни кто тоже не отменял.
7. Тоже самое при файловой архитектуре. В 1С ведь можно хранить только путь.

Очень жалко, что я сейчас не владею понятиями низкоуровневого хранения данных в этих БД. Весь мой опыт касался MS SQL и Oracle и у них именно хранение бинарных данных не оптимально. Я именно про хранение данных на носителе информации в служебных файлах БД.
24. Сергей Вн (EmpireSer) 07.08.12 13:07
Вот если бы NoSQL базы могли работать как "чистая ОС" или создавали свою файловую архитектуру на жёстком диске (а не использовали ту, что уже размещена на диске), или внедряли свой низкоуровневый драйвер доступа к кластерам ЖД - то я бы даже "не пикнул".
Но тут явная "надстройка" над возможностями тех же серверных ОС. ОС всё равно нужна, так почему не выжить из уже данных ею механизмов максимум?
25. Юрий Хрипачёв (hrip) 07.08.12 13:09
(22) EmpireSer, Возможно при очень большом количестве запросов к базе производительность как то и будет падать, но этот проект не высоконагруженный (я очень сомневаюсь что все мои 100 пользователей будут одновременно получать и сохранять файлы в базу, хотя может даже и это не вызовет снижение производительности).
Доступ к файлам осуществляется непосредственно из 1С (про безопасность доступа из 1С я написал здесь (21) hrip,).
А если пользователь пытается добавить новый файл в базу, а версия документа СУБД уже изменилась, то ему будет выдан отказ и просьба обновить (заново получить с сервера) список файлов.
Ну и про безопасность. Если в моей локальной сети вдруг появится человек, который может положить CouchDB, то он сможет положить и всё остальное. Я думаю это вопрос уже немного из другой плоскости.
26. Юрий Хрипачёв (hrip) 07.08.12 13:19
(23) EmpireSer, Логика работы такая что 1С передает запрос вида
http://localhost:5984/documents/_design/doc/_view/files?key="0f64f1fb-ab0e-11e1-a055-080027004cb0" где ключом является GUID элемента справочника и получает список файлов хранящихся в документе с id равным GUID
Для открытия файла содержащегося в документе например
http://localhost:5984/documents/0f64f1fb-ab0e-11e1-a055-080027004cb0/ИмяФайла.jpg
и получает файл который сохраняется в temp и открывается соответствующим приложением
Ну я тоже как то не особо владею знаниями о низкоуровневом хранении данных :-)
27. Сергей Вн (EmpireSer) 07.08.12 13:49
(25)

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

Я тут не совсем про производительность говорил, а про производительность при сильной фрагметации данных в служебных файлах БД. Любая база данных размещает свои таблицы в особых служебных файлах, которые для ОС "просто файлы". Бинарные данные имеют не маленький размер, поэтому выделение блока в этом служебном файле для данных работает как "размер блока >= размеру файла". Если после этого добавить в БД ещё один файл и удалить предыдущий - то образует "незанятое пространство". Его БД может сразу "сжать" или подождать "что будет дальше". А вот если потом в БД добавить файл большего размера, чем был удалённый, и пустого блока >= размеру нового файла нет, то БД может выделить или новый фрагмент, в который полностью уместит файл, или попытается его распределить по пустым блокам.
Тот же самый "бардак" мы видим обычно на наших компах.
И как и в БД, так и в ОС существует как ручные так и автоматическое убирание "пустот".


Доступ к файлам осуществляется непосредственно из 1С (про безопасность доступа из 1С я написал здесь (21) hrip,).


(убрано, из-за разъяснения)


А если пользователь пытается добавить новый файл в базу, а версия документа СУБД уже изменилась, то ему будет выдан отказ и просьба обновить (заново получить с сервера) список файлов.

Механизмы версификации на уровне БД - интересно. До этого встречал их только на уровне приложения (или сервера).


Ну и про безопасность. Если в моей локальной сети вдруг появится человек, который может положить CouchDB, то он сможет положить и всё остальное. Я думаю это вопрос уже немного из другой плоскости.

Если не считать, что 1С хранит "корпоративную тайну", то проблем нет.
А если считать - то многие из решений "просто, но со вкусом" могут стать "дыркой".
28. Сергей Вн (EmpireSer) 07.08.12 13:55
(26) hrip, а как происходит добавление файла в хранилище? Сама БД, минуя сервер, сможет произвести PUT запрос при указании ?
29. Юрий Хрипачёв (hrip) 07.08.12 14:07
(27) EmpireSer, База данных - это по любому файл на диске. Внутреннюю структуру этого файла я не знаю. Знаю что NoSQL СУБД оптимизированы для работы с большими объемами данных.
Контроль осуществляется на уровне приложения (клиента 1С). Когда получается список файлов, получается и версия документа СУБД и перед записью нового файла она сравнивается с текущей версией в СУБД.
1С тоже может запросто стать "дыркой". По моему в большинстве баз 1С пароли такие что их подобрать особого труда не составит (не во всех конечно). Я не рассматривал вопросы серьезной настройки безопасности т.к. она мне просто не требовалась и я соответственно эту тему не разбирал. Вот например самый простой вариант защиты файлов - поместить в архив под пароль или зашифровать каким нибудь ключом перед загрузкой на сервер. Вариантов защиты если она очень нужна можно придумать много.
30. Юрий Хрипачёв (hrip) 07.08.12 14:12
(28) EmpireSer, PUT запрос делается непосредственно из клиентской части 1С к СУБД CouchDB
Вот пример кода из демо базы

Stream = Новый COMОбъект("ADODB.Stream");
Stream.type = 1;
Stream.Open();
Stream.LoadFromFile(ПутьКФайлу);

Транспорт = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");
Транспорт.Open("PUT", УдалитьПробелы(СтрокаСоединения) + "/" + СокрЛП(ИмяФайла) + "?rev=" + rev, 0);
Транспорт.SetCredentials(ПараметрыСоединения.ИмяПользователя, ПараметрыСоединения.Пароль, 0);
Транспорт.setRequestHeader("Content-length", ФайлнаДиске.Размер());
Транспорт.setRequestHeader("Content-type", Заголовки.Получить("Content-type"));
Транспорт.Send(Stream.Read());

где строка соединения равна например
http://localhost:5984/documents/b5a1b704-dd49-11e1-b509-e70be848db45/Картинка.jpg?rev=5-9b34313f006c1c2edadf40ff8a0368c3
31. Сергей Вн (EmpireSer) 07.08.12 14:30
(29) (30) hrip, простите, что я так привязался. Но я на месте сисадмина такой сети и указания директора "ни каких утечек данных" "таких" 1С-ков (т.е. таким образом организующих взаимодействие) "бил бы палкой".
Но я не сисадмин и сам 1С-ник :)))

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



Надеюсь хоть вот такое проделать нельзя?

Т.е. перезаписать саму библиотеку libcurl.dll
32. Сергей Вн (EmpireSer) 07.08.12 14:37
Отредактировал предыдущий ответ.
Видно я ошибочно предположил, что сама библиотека "libcurl.dll" тоже может приехать к клиенту. А как понял, её использует "CouchDB" "внутри себя" что бы перезаписывать данные?
33. Александр Прокопенко (alprk) 07.08.12 14:44
Причем здесь libcurl.dll вообще?
34. Юрий Хрипачёв (hrip) 07.08.12 14:45
(31) EmpireSer, Файл (например libcurl.dll) лежит на диске и чтобы его записать какими нибудь "левыми" средствами в базу надо как минимум знать id (b5a1b704-dd49-11e1-b509-e70be848db45), текущую версию (5-b5a1b704dd4911e1b509e70be848db45) документа СУБД ну и конечно же имя пользователя и пароль для доступа к базе (Транспорт.SetCredentials(ПараметрыСоединения.ИмяПользователя, ПараметрыСоединения.Пароль, 0); )
Если кто то всё это знает то надо бить уже админа за то что делает легкие пароли или пользователей которые не умеют их хранить.
У меня моя сеть защищена снаружи очень хорошо (тут я не волнуюсь). А внутри у меня, ну кроме тех кому положено знать, и не слышали таких слов как CouchDB, NoSQL, PUT или GET запросы и т.д.
Поэтому минимума защиты "от дурака" мне хватает.
35. Юрий Хрипачёв (hrip) 07.08.12 14:46
(33) alprk, вообще не причем. Это просто файл который попался мне для примера и я его положил в базу и привел для примера строку соединения. Вместо него можно просто вставить ИмяФайла.Расширение
36. Юрий Хрипачёв (hrip) 07.08.12 14:49
Изменил в комментарии (30) hrip, имя файла на Картинка.jpg для того чтобы название библиотеки libcurl.dll никого в заблуждение не вводило. Это просто может быть любой файл
37. Сергей Вн (EmpireSer) 07.08.12 15:20
(34)
Один из самых хороших способов "ворваться" в защищённую сеть - это компрометировать одного из пользователей этой сети. Хоть червём в почте, хоть через интернет, хоть соц. инженерией.


А внутри у меня, ну кроме тех кому положено знать, и не слышали таких слов как CouchDB, NoSQL, PUT или GET запросы и т.д.

И очень хорошо, что у Вас мало кто знает про устройство сети. Но если у Вас, в 1С, будут храниться секретные данные, которые могут дать возможность конкурентам "похранить фирму", и кто-то захочет их получить - то это взаимодействие может стать одной из "нужных дырочек".

Тут пароли знать не нужно - они сами светятся в запросе. Самое главное для злоумышленника - каким либо образом проникнуть на один из компьютеров в сети и иметь возможность получать от "жертвы" ответы. А тогда можно собрать информацию о сети, запросах, бд и т.д.
Тут явно сработает атака "Man-in-the-Middle" и делай её хоть в ответ сервера 1С, хоть в ответ от БД. А тут уж делай что хочешь.

(35) (36)
Забыли про библиотеку. Реально вводила в заблуждение. Вот тока (26):

и получает файл который сохраняется в temp и открывается соответствующим приложением

Тут просто обязательно пинать админов, что бы обновления ОС ставились вовремя. А то doc документики, jpeg картинки с переполнением буфера и захватом управления ОС - не редкое явление.

=====
Как всё устроено - я хорошо понял, но ни кому такое рекомендовать не буду (организация доступа к данным БД по протоколам http или ftp с возможностью какой либо модификации данных)
38. Алекс Ю (AlexO) 07.08.12 15:23
1. Смысл хранить какие-то данные во внешней базе, если в 1С они не используются никак, кроме как "а вот набор картинок из другой базы"?
2. Смысл доступа к файлам из 1С к какой-то другой базе, если версионирование - все равно в той сторонней базе?
3. Смысл использовать какие-то NoSQL, когда можно организавать новую базу на существующем SQL (не думаете же вы, что все будут затевать с файловой 1С?) и хранить там все, что угодно.
hrip, дайте вразумительные ответы и приведите, пожалуйста, примеры использования такого хранения. Не теоретического.
39. Юрий Хрипачёв (hrip) 07.08.12 15:33
(37) EmpireSer, Ну что могу сказать, при наличии очень секретной информации и таких требований к безопасности вам наверное надо придумывать какие то другие средства для хранения файлов и доступа к ним. Может быть и подойдет данная СУБД после каких либо настроек. Увы я не специалист по безопасности чтобы вам квалифицированно ответить на все вопросы.
Ну если к вам в сеть вломиться специалист который может сделать всё что вы описали, то ему по моему будет пофиг что ломать CouchDB, MS SQL или файловую 1С
40. Евгений Сосна (pumbaE) 07.08.12 15:45
(39) hrip, в couchdb вы можете настроить только доступ к базе. К отдельным документам к сожалению нет, соответственно для контроля надо делать трехзвенку...
41. Юрий Хрипачёв (hrip) 07.08.12 15:53
(38) AlexO, В принципе можно и не хранить данные таким образом. Вариантов много. Можно использовать стандартный механизм 1С (Хранилище доп. информации), можно хранить все файлы в папках, а в 1С хранить только путь к файлу, можно хранить в какой либо базе на SQL сервере.
В моей демо базе не реализована возможность получать версии документов (всегда получается последняя версия), хотя это можно сделать. Я использую такую базу для хранения файлов (подключаюсь к ней из УПП)и если кто то удалил файл случайно я могу его восстановить через консоль администрирования зная id документа в базе (т.е. GUID элемента в 1С). Может попозже дойдут руки и сделаю доступ к версиям из 1С.
За данную СУБД кстати денег платить не надо и она потребляет мало ресурсов (ну по крайней мере в таком режиме работы).
База данных не требует описания данных, как реляционные СУБД. Можно в любом документе СУБД создать любое количество полей и прикрепить любое количество вложений.
Для доступа к данным не нужны никакие драйвера.
Ну и вот здесь (21) hrip, уже писал про плюсы использования.
А выбор за вами что использовать, вариантов много.
Я лишь предложил один из них.
42. Юрий Хрипачёв (hrip) 07.08.12 16:00
(40) pumbaE, ну почему же нельзя. к документу СУБД можно прикрепить любую информацию (можно создать любое количество полей) например о пользователе создавшем документ или о группе пользователей. т.е. собственно контроль будет на стороне приложения клиента.
Хотя я с настройкой безопасности сильно и не разбирался, мне хватило типовых. Может там что нибудь и есть.
43. Алексей (LelikOFF) 08.08.12 00:37
Неоднократно вставала проблема хранения документов сканов и прочего в базе, нужно попробовать
спасибо за статью
44. Сергей (Che) Коцюра (CheBurator) 08.08.12 01:44
так, ту нарисовались апологеты теневого копирования... может кто-нибудь мне объяснит чем достигается целостность данных и НЕОСТАНОВ базы при теневом копировании когда копируемый файл пишется на диск - с ним активно работает база данных - в это же время выполянется теневое копирование...?
.
внятного ответа на вышеобозначенные вопросы - я не нашел...
45. Николай (realm) 08.08.12 03:00
Спасибо автору за классный вариант решения проблемы хранения файлов с удобным доступом из 1С. От постоянных добавлений "сканов" документов база пухнет чрезмерно. Давно подумывал над вариантами "исключения" не объектов 1С из основной базы. Хранить файлы в одном хранилище/базе намного удобнее, чем иметь десятки и сотни тысяч файлов, которые и бэкапить-то неудобно.
46. aspirator 23 (aspirator23) 08.08.12 07:29
У MS SQL есть возможность хранить большие файлы в filestream. Рассматривалась эта возможность для хранения?
Сам столкнулся с необходимостью хранения больших файлов. Выбираю вариант хранения.
Предложенное автором решение интересно, поэтому хотелось бы рассмотреть его в сравнение с filestream.
47. Юрий Хрипачёв (hrip) 08.08.12 07:59
(46) aspirator23, Нет такую возможность не рассматривал.
Я уже выше писал почему выбрал данную СУБД:
1. Надежность (ну по крайней мере по отзывам);
2. Скорость поиска и отдачи данных клиенту;
3. Доступ по http без использования драйверов;
4. Нет необходимости создавать в БД таблицы и при необходимости смогу к любому документу базы данных добавить любое количество полей;
5. Версионирование документов БД;
6. Удобное администрирование;
7. Денег платить не надо;
8. Ну и очень интересно было изучить что такое NoSQL.
48. Владимир Каракозов (karakozov) 08.08.12 08:47
Данный материал несомненно полезный, по крайне мере есть еще одно решение для хранения файлов и документов в ИБ.Есть решение конечно такое как Хранилище, но задачи бывают разные.Взято на заметку. Плюс автору.
49. maksim.s (Gandalf Белый) 08.08.12 08:57
Большое спасибо автору статьи! Было очень интересно ознакомиться с подобным решением, т.к. за NoSQL базы услышал впервые и раньше с ними не работал.
50. Евгений Сосна (pumbaE) 08.08.12 09:38
(44) CheBurator, а где тут обсуждалось про теневое копирование? В CouchDB отдельный процесс реплицирует данные на другой сервер. При этом ответственность за проверку окончания транзакции возложена на клиента, т.е. то что мы POST запросом отправили в базу документ(с файлом или без) и сервер ответил OK, не означает что транзакция завершилась успешно. Клиент должен дополнительно проверить, записался ли этот документ или нет...
51. mezzo forte (mezzoforte) 08.08.12 10:24
Интересно, спасибо за статью.
52. Юрий Хрипачёв (hrip) 08.08.12 10:26
(50) pumbaE, Я думаю т.к. http сервер встроен в СУБД, то он возвращает ответ уже после завершения транзакции (удачного или нет) и никаких доп проверок не надо. т.е. ответа сервера достаточно
53. Алекс Ю (AlexO) 08.08.12 10:38
(41) hrip,
База данных не требует описания данных, как реляционная СУБД

тогда противоречит
и она потребляет мало ресурсов

т.к. в такой (объектная она, что ли?) СУБД априори будет больше занимать место (и требовать на свою обработку ресурсов) те же самые данные, которые "оптимизированы" по типу данных в реляционных СУБД - именно в силу того, что в вашей СУБД все типы данных - универсальные.
Можно в любом документе СУБД создать любое количество полей

Прямо уж и любое?
Для доступа к данным не нужны никакие драйвера.

Если даже ваша СУБД и использует "свою" FS, то на доступ к ней - нужны драйвера. 1С - это не ОС.
В моей демо базе не реализована возможность получать версии документов (всегда получается последняя версия), хотя это можно сделать.

вот когда сделаете - поставлю плюс за полезность. А пока - чисто "игрушка" :)
54. aspirator 23 (aspirator23) 08.08.12 10:39
(52)
1.Есть ограничение на размер базы данных? Размер одиночно загруженного файла?
2.Можно ли провести сравнение скорости загрузки очень больших файлов в базу?
Например: загрузить файл размером 1Гб в СУБД и просто скопировать этот же файл в каталог лежащий там где и СУБД. Это не с целью покритиковать, а с целью оценить скорость работы этого варианта для себя.
55. Алекс Ю (AlexO) 08.08.12 10:39
(44) CheBurator,
и НЕОСТАНОВ базы при теневом копировании когда копируемый файл пишется на диск

теневое копирование - вообще тормоза жуткие, по-крайней мере, в реализации Microsoft :)
В Линухе оно аналогичное как-то более человечно...
56. Алекс Ю (AlexO) 08.08.12 10:39
(45) realm,
От постоянных добавлений "сканов" документов база пухнет чрезмерно.

Храните в ОС и давайте ссылки на файлы. Делов-то.
57. Алекс Ю (AlexO) 08.08.12 10:43
(47) hrip,
4. Нет необходимости создавать в БД таблицы и при необходимости смогу к любому документу базы данных добавить любое количество полей;

чудес не бывает. Если у вас автоматом добавляется "неограниченное" количество полей (в чем я тоже сомневаюсь - понятие "неограниченное" не относится к используемому в системах хранения данных), то редактировать/удалить - тоже без задействовования интерфейса администрирования?
58. Алекс Ю (AlexO) 08.08.12 10:46
(50) pumbaE,
а где тут обсуждалось про теневое копирование? В CouchDB...

это не про CouchDB, а ответ на посты (4) и (10), начатые
(4) babys,
на win серверах есть теневое копирование, это бекап без освобождения файла.

не означает что транзакция завершилась успешно. Клиент должен дополнительно проверить, записался ли этот документ или нет...

А что, в SQL не так?
59. Алекс Ю (AlexO) 08.08.12 10:49
(52) hrip,
http сервер встроен в СУБД

на скорость работы и качество контроля записи "встроенность" http-сервера не влияет - разве что только отсутствует необходимость "подвязки" стороннего http-сервера.
А так - это сродни тому, как если рассуждать "где быстрее команда выполнится - когда задать её через консоль или по красявому интерфейсу?"
60. Алекс Ю (AlexO) 08.08.12 10:51
(54) aspirator23,
1.Есть ограничение на размер базы данных?

Скорей всего, "стандартные" 2-4-10 Гб для бесплатных баз на xSQL.
hrip, верно? :)
2.Можно ли провести сравнение скорости загрузки очень больших файлов в базу?
Например: загрузить файл размером 1Гб в СУБД и просто скопировать ...

aspirator23, разницы не будет ни в какой СУБД - FS сама по себе "оптимизированная СУБД" для хранения файлов, и в худшем для FS случае - разницы не будет никакой.
61. игорь ром (djd.sf) 08.08.12 11:04
(60) поскольку aspirator23 спрашивал про CouсhDB, то неверно. это база данных с открытым исходным кодом и ограничений по использованию нет(на размер базы), разве что ограничения файловой системой. вообще она используется несколько для других целей, - основное её достоинство это достаточно прозрачный механизм синхронизации данных и поэтому её используют для хранения распределенных данных. на какой-то(не помню точно) конференции доклад делали по использованию её в системе сбора данных со счетчиков, которые разбросаны удаленно друг от друга.
aspirator23, разницы не будет ни в какой СУБД - FS сама по себе "оптимизированная СУБД" для хранения файлов, и в худшем для FS случае - разницы не будет никакой.

я так не думаю, но спорить с вами не стану.
62. Алекс Ю (AlexO) 08.08.12 11:08
(61) djd.sf,
я так не думаю, но спорить с вами не стану.

не путайте обработку данных и запись-чтение на хранение.
Или думаете, что доступ к "собственной" FS у какого-то CouсhDB будет быстрее и лучше, чем у коммерческих ОС? Своя FS введена туда единственно из-за удобства использования для себя "как хочу, так и верчу".
63. Юрий Хрипачёв (hrip) 08.08.12 11:11
(53) AlexO, По поводу потребления ресурсов. Средняя загрузка ЦП при работе СУБД 0.5-4%, при добавлении файлов иногда подскакивает 10-30% на пару секунд (размер базы уже 8 Гб).
Вам хватит 100 полей в документе? На 102 устал добавлять. Мне хватает.
Для доступа к СУБД не нужны драйвера! использую "WinHttp.WinHttpRequest.5.1". Пробовал и стандартное для 1С HTTPСоединение - получилось всё кроме загрузки файла в СУБД.
Да версионирование из 1С не реализовано. Может быть попозже попробую сделать. но возможность восстановить удаленный файл всё равно есть через консоль администрирования.
Для вас может и игрушка, а я сделал и пользуюсь!
64. Алекс Ю (AlexO) 08.08.12 11:20
(63) hrip,
Для доступа к СУБД не нужны драйвера! использую "WinHttp.WinHttpRequest.5.1".

не мытьем, так катаньем :) Все равно используется пусть и встроенный, но "драйвер" ОС.
Но через HTTP заносить данные - это же жутко долго.. считайте, вы все переводите в текст и передаете в базу...
65. Юрий Хрипачёв (hrip) 08.08.12 11:32
(62) AlexO, Я согласен что от железа, ОС и ФС очень много зависит, надо сравнивать производительность СУБД на одинаковом оборудовании, сравнивать одинаковые операции
Но и задача под которую я предлагаю использовать СУБД не требует большого быстродействия.
66. Юрий Хрипачёв (hrip) 08.08.12 11:39
(64) AlexO, Только что попробовал загрузить файл 30Мб
В CouchDB - 6 Сек.
В расшаренную папку - 4 сек
В хранилище доп информации УПП (крутиться на MS SQL) - 11 сек.
Хотя конечно это тоже всё относительно.
67. Юрий Хрипачёв (hrip) 08.08.12 11:50
(54) aspirator23, Из клиента 1С грузятся файлы размером до 100 Мб. Если больше то ругается на нехватку памяти. А в саму СУБД грузил и по 500Мб через консоль.
Про сравнение скорости я только что написал в (66) hrip,
68. Алекс Ю (AlexO) 08.08.12 11:50
(66) hrip,
В хранилище доп информации УПП (крутиться на MS SQL) - 11 сек.

Ну, вы бы его еще сначала через Лос-Анджелес послали в MS SQL "ложиться" :)
1С - это ж полновестная и жесточайшая по хранению и обработке данных.
В CouchDB - 6 Сек.
В расшаренную папку - 4 сек

да, тут я с вами полностью согласен:
(60) AlexO,
разницы не будет ни в какой СУБД - FS сама по себе "оптимизированная СУБД" для хранения файлов, и в худшем для FS случае - разницы не будет никакой.
69. Юрий Хрипачёв (hrip) 08.08.12 11:52
(68) AlexO, Стандартный механизм 1С для хранения файлов без изобретения всяких "велосипедов"
70. Алекс Ю (AlexO) 08.08.12 11:56
(69) hrip,
нет, я не про это - а про саму концепцию обработки данных в 1С.
Вот тут Приложение к публикации: "Давайте забудем о свертке БД?" hogik описал подробно, плюс качественные комменты.
71. Юрий Хрипачёв (hrip) 08.08.12 13:11
(70) AlexO, Обязательно почитаю.
А собственно из-за чего всё и затевалось то. У нас есть возможность использовать для хранения 2 варианта -это стандартный 1С и свои "костыли".
А костыли могут быть минимум 3-х видов:
1. Файлы на диске, а в базе пути к файлам;
2. SQL СУБД;
3. NoSQL СУБД.
Причины по которым я выбрал CouchDB я уже описывал.
Я нигде не пытался доказать, что это самое лучшее из всех решений и эта СУБД обладает самым максимальным быстродействием.
Данное решение позволяет довольно удобно работать с файлами, оно не очень сложно в реализации (самая большая сложность была - это написать парсер JSON)и скорость работы больше чем у стандартных механизмов 1С (указываю сразу, что я не делал контрольных примеров с хранением файлов напрямую на дисках или хранением в SQL СУБД и соответственно не замерял их производительность).
Ну а использовать данное решение или нет - это личное дело каждого.
Как минимум полезно знать что есть NoSQL СУБД, какими возможностями они обладают, и как с ними можно работать.
72. Сергей Вн (EmpireSer) 08.08.12 13:13
(66)

В CouchDB - 6 Сек.
В расшаренную папку - 4 сек
В хранилище доп информации УПП (крутиться на MS SQL) - 11 сек.


А кто нибудь сейчас помнит, что стоит за "расшаренная папка"? За ней крутится обычные серверные механизмы (просто встроенные в ядро), как и у http, ftp и т.д. серверов.
Скорость загрузки файлов в "расшаренная папка", http, ftp - должна практически совпадать, т.к. они все используют механизмы контроля доступа, логирования, а сами файлы пишут через бинарные потоки.
А скорость записи файла в NoSQL и SQL БД будут всегда выше, т.к. необходимо так же дополнительно рассчитывать экстенты служебных файлов на приращение данных. Т.е. в худшем случаи будет выделено "размер принимаемого файла <= размеру блока для его хранения". Это можно избежать создав сразу "супер гигантскую" пустую базу.

(64)

Но через HTTP заносить данные - это же жутко долго.. считайте, вы все переводите в текст и передаете в базу...


Там данные упаковываются и передаются отдельным потоком. Они не преобразуются в текст.
А если передавать файлы методом POST - то тогда будет преобразование в строку.
73. Юрий Хрипачёв (hrip) 08.08.12 13:20
(72) EmpireSer, Я же написал что всё относительно т.к. шара на которую копировал, CouchDB и 1C сервер - это разные машины.
Ну я и вроде данный проект не предполагает использовать СУБД в режиме, когда будут совершаться десятки тысяч транзакций в секунду.
Файлы на сервер передаются методом PUT.
74. OBEH (OBEH) 08.08.12 14:09
Кто-нибудь пробовал хранить данные в самой MS SQL базе?
Не там, где лежат данные баз 1С, а в отдельной таблице.
Ведь, если есть в конторе MS SQL то зачем еще использовать
какую-то другую СУБД.
Тем более, для простого хранения и вынимания файлов.
75. Алекс Ю (AlexO) 08.08.12 15:26
(74) OBEH,
а что пробовать, берите и храните.
76. OBEH (OBEH) 08.08.12 16:52
(75) Хорошо. А пример этого самого хранения есть?
77. Алекс Ю (AlexO) 08.08.12 17:02
(76) OBEH,
примеры записи в SQL есть здесь на сайте.
78. KV1s (KroVladS) 08.08.12 17:32
79. OBEH (OBEH) 09.08.12 03:13
80. OBEH (OBEH) 09.08.12 03:49
Мда. Совсем забыл, что у меня база в postgreesql на Linux
81. KV1s (KroVladS) 09.08.12 08:38
(80) OBEH,
Под PostgreSQL ни один из вариантов у меня к сожелению не получилось запустить нормально :(
82. Алекс Ю (AlexO) 09.08.12 09:34
(80) OBEH,
Кто-нибудь пробовал хранить данные в самой MS SQL базе?

Мда. Совсем забыл, что у меня база в postgreesql на Linux

крупно ошиблись... :)
83. Александр Прокопенко (alprk) 09.08.12 09:44
Я не понимаю зачем использовать CouchDB для хранения файлов. Но если задачу можно свести к алгоритму Map-Reduce, то стоит заморочиться, давно планирую такое мероприятие, именно с CouchDB.
84. Юрий Хрипачёв (hrip) 09.08.12 10:02
(83) alprk, Функция MAP там и так используется. А зачем использовать именно CoucDhB (по крайней мере я так считаю) я уже писал здесь (21) и здесь (47).
85. Алекс Ю (AlexO) 09.08.12 10:09
(84) hrip,
ждем основательных доработок "под ключ" :)
тогда и вопросов не возникнет - если будет удобное решение.
86. Юрий Хрипачёв (hrip) 09.08.12 10:34
(85) AlexO, А в чём неудобность то? Ну разве только как вы писали, что хочется версионирования из 1С. Это да можно будет попробовать сделать.
87. Борис Скворцов (gaglo) 09.08.12 10:51
(71)
Как минимум полезно знать что есть NoSQL СУБД, какими возможностями они обладают, и как с ними можно работать.

Это правда. НО! Всё время хочется, чтоб минимумом не ограничивались. Ну есть они, и с ними можно... А где обсуждение границ применимости? Где описание круга задач, в которых данный подход явно предпочтительнее, и наоборот, где он неуместно выглядит? В списке из (47) из восьми "причин выбора данной СУБД" семь на самом деле отвечают на вопрос "почему и эту СУБД тоже можно использовать в этой задаче"; и только пункт 8 - действительно причина для конкретного выбора...
88. Юрий Хрипачёв (hrip) 09.08.12 11:17
(87) gaglo, А я по моему границы применимости и круг задач не пытался описать, я показал вариант применения данной СУБД для решения конкретной задачи.
"почему и эту СУБД тоже можно использовать в этой задаче"

Так же можно сказать и обо всех остальных СУБД. Их все тоже можно использовать для решения задачи хранения файлов.
А для вас что является критерием выбора СУБД (применительно к этой задаче)?
89. Борис Скворцов (gaglo) 10.08.12 08:48
(88) ...я чувствую непонимание меня собеседником... Попробую объясниться.
А я по моему границы применимости и круг задач не пытался описать

Я это заметил. Я считаю отсутствие этого - недостатком статьи.
А для вас что является критерием выбора СУБД (применительно к этой задаче)?

Ну, не я взялся решать "эту" задачу. Кстати, сама задача явно недостаточно описана в статье. И это я считаю недостатком.
А вот моё непонимание упирается вот во что: в (71) вы как автор уже чётко расписали:
...есть возможность использовать для хранения 2 варианта - это стандартный 1С и свои "костыли".
А костыли могут быть минимум 3-х видов...

Недостатки "Хранилища", оно же "стандартный 1С" - в статье выписаны и мне понятны. Решение перейти к костылям - понятно. Выбор вида костылей - непонятен. И неочевиден. И в статье не описан. А на вопрос, всплывший в (10) -
...зачем вообще использовать любой вид БД для хранения файлов?

лично я ответа не заметил.
А без этого - статья выглядит безликой новостью, каких полно на всяких порталах. "Есть вот такая программа, она может вот что...". Безусловно похвально вложение личного опыта: "Я попробовал, она действительно может!" Не могу одобрять отсутствие аналитической части вида "Она может то-то и то-то, что у таких-то её конкурентов не получается или выходит хуже..."
И получается: минусовать статью не за что. А плюсовать неохота...
90. Андрей Чуйков (andpal) 10.08.12 08:53
(24) EmpireSer,
так почему не выжить из уже данных ею механизмов максимум?

вероятно, выжать :-)
91. Сергей Вн (EmpireSer) 10.08.12 10:20
(90) andpal,

вероятно, выжать :-)

Хоть я и русский, но мой русский до сих пор хромает :-) Нужно было слушаться маму и делать школьные домашние задания :-)

По теме:
Из-за этой раздачи я полез в дебри NTFS и нашёл очень много полезного: есть механизмы мгновенного поиска без индексирования, отслеживание изменений, и возможность к папке/файлу добавить всё что душе угодно, и идентификаторы разделов и файлов/папок, и уникальные глобальные идентификаторы, и расширенные атрибуты файлов...
Т.е. используя этот "низкий уровень" можно натворить такое, что через проводник не увидишь и ни какая "нашлёпка" (Oracle, MS SQL, MySQL, CouchDB, mongoDB) уже не нужна будет.
92. Андрей Чуйков (andpal) 10.08.12 11:31
(91) EmpireSer, мне близка ваша позиция, файловая система - база файлов.
Вот если бы NoSQL базы могли работать как "чистая ОС" или создавали свою файловую архитектуру на жёстком диске (а не использовали ту, что уже размещена на диске), или внедряли свой низкоуровневый драйвер доступа к кластерам ЖД - то я бы даже "не пикнул".
Но тут явная "надстройка" над возможностями тех же серверных ОС. ОС всё равно нужна, так почему не выжАть из уже данных ею механизмов максимум?

Как и в 1С, кое-кто не освоив, не изучив логику и возможности конфигурации делают "велосипеды".
Но пусть будет много всяких решений, для кого-то они проще и эффективней, к тому же использовать
этот "низкий уровень"
совсем не тривиально.
У вас есть рабочий пример?
93. Сергей Вн (EmpireSer) 10.08.12 11:58
(92) andpal,

совсем не тривиально.
У вас есть рабочий пример?

Всегда забываю: что значит "тривиально"?

И рабочий пример чего? Например этого?
94. Юрий Хрипачёв (hrip) 10.08.12 13:54
(89) gaglo, Я решал конкретную задачу и соответственно только ее и описал в статье, но в статье есть ссылки на источники где можно более подробно прочитать за данную СУБД.

Причина выбора "костылей" действительно в статье мало была описана, но в комментариях я по моему довольно подробно описал в (21) и (47). Если вы считаете, что их недостаточно для выбора, то хотел бы услышать все таки ваше мнение о том какими критериями надо руководствоваться при выборе СУБД.

на вопрос
...зачем вообще использовать любой вид БД для хранения файлов?

я написал ответ в (21).

Не спорю, в статье маловато аналитики. Будет время постараюсь отредактировать статью и доработать демо базу, учитывая все услышанные пожелания.
95. Борис Скворцов (gaglo) 13.08.12 11:13
(94) "...а мы упрямы..." Ну что ж, срублю ещё долю старбакса.
столкнулся с необходимостью размещения большого количества файлов (Сканы документов, конструкторско-технологическая документация. Всего около 10 Гб.) в базе УПП

По-моему, это неконкретное описание конкретной задачи. Большое количество - это сколько? 500 тыщ, как промелькнуло в одном комменте (не вашем)? Средний размер файла? Частота его обновления? Частота обращений к нему? Лично я не понял даже, "сканы документов и конструкторско-технологическая документация" - это два существенно разных типа файлов или это такое пояснение одного термина другим.
в статье есть ссылки на источники где можно более подробно прочитать за данную СУБД

В первый же раз не поленился, прошел по ссылке за словом "здесь". Так же как и в вашей статье - проблема выбора никак не освещается. Отсюда, видимо, в комментах от одного и того же Алексея идет то "скоро NoSQL захватит мир))", то "заметил печальный факт. в CouchDB нельзя обновить только одно свойство документа. необходимо посылать весь документ целиком, что крайне неудобно и ужасно для производительности." (Кстати, это правда?)
Наконец, по поводу списка в (21):
Пункт 1 - субъективен, оспаривать его не буду, но он - единственный, обосновавший отказ от попыток хранения внешних файлов именно в файловой системе.
2 - "альтернативная" авторизация - не факт, что вообще нужна; может, недостаток конкретности в описании задачи?
3 - почему это не сделать внутри 1С?
4 - рассказ о том, что из СУБД можно считать файл быстрее, чем просто из файловой системы? Неочевидно.
5,6 и 7 - выглядят одинаково верными для любого из трех костылей.
И моё-таки мнение насчёт "какими критериями надо руководствоваться при выборе СУБД" выглядит примерно так: "для данной задачи надо обойтись без СУБД".
А подробнее:
0. "Не должно множить сущее без необходимости" (с) Оккам.
1. У нас уже есть сервер, на нём файловая система, и СУБД, и база 1С (а может, два и более серверов, по которым всё распределено разными способами...)
2. Надо хранить много файлов, в базе 1С это неудобно. Что делать?
3. Попробовать наладить хранение в файловой системе. (Костыль №1, знаете ли.)
4. Если п.3 не получается - разобраться, почему.
5. Если п.4 не получается - попробовать наладить хранение в той же СУБД, но в отдельной базе. (Костыль №2.)
6. Если п.5 не получается - разобраться, почему.
7. Если п.6 не получается - призвать на помощь совсем другую СУБД. (Костыль №3.)
8. Продолжать не буду...
96. Юрий Хрипачёв (hrip) 14.08.12 09:09
"...а мы упрямы..."
несогласие с вашим мнением это есть упрямство?

Попробую подробно ответить на ваши вопросы.
Текущий размер используемой базы 8Гб, документов в СУБД 1700, Средний размер хранимого файла 1-10Мб. Сколько всего файлов в базе я не считал.
О том что проект невысоконагруженный я уже писал, т.е. частота обращений очень низкая и такими параметрами как частота обращений можно пренебречь (обычная база 1с - 100 пользователей, работа с файлами - это не основная работа).
Чем отличаются сканы от конструкторской и технологической документации? Ничем кроме расширений файлов! т.е. в УПП к элементам справочников "Номенклатура", "Спецификации номенклатуры", "Технологические карты производства" прикреплены описание тех. процессов , инструкции, паспорта, чертежи и т.д.

"скоро NoSQL захватит мир))"
это вообще чье то личное мнение в комментариях, которое никак не отражено ни в моей статье, ни в статье на которую я ссылаюсь.

В CouchDB действительно обновляется весь документ и это сказывается на размере базы и времени его обновления. Но в данном случае речь не идет о высокопроизводительном web сервере где совершаются тысячи или десятки тысяч транзакций в секунду.

Почему не хранить файлы просто на диске в файловой системе я писал уже.
Если хранить файлы в непосредственно в базе ("Хранилище дополнительной информации"), то начнет увеличиваться размер базы и бекапов. Об этом я тоже писал.
Про какую то альтернативную авторизацию я и не писал. я писал о том что СУБД поддерживает авторизацию по логину и паролю и для данной задачи этого вполне достаточно. И если кому то нужно устанавливать права на файлы, то я писал что в СУБД вместе с файлами можно сохранять любую доп. информацию, с которой потом как то будет можно работать (у меня это не реализовано в демо базе).
О том что СУБД быстрее файловой системы я вообще не писал! Где вы это взяли?

"для данной задачи надо обойтись без СУБД"
это ваше мнение. Я вас не заставляю использовать мое решение!

"Не должно множить сущее без необходимости" (с) Оккам.

Ну насчет надежности хранения файлов в СУБД вы наверное спорить не будете. Версионирование тоже штука полезная.
В данной СУБД не требуется проектировать структуру базы (таблицы, хранимые процедуры, триггеры) и для данной задачи очень подходит.
Для того чтобы внедрить и использовать мое решении требуется максимум минут 30: это установить саму СУБД, написать пару простеньких функций, объединить конфигурацию демо базы со своей и вывести на формы нужных объектов кнопки для открытия списка файлов.
Причем тут без разницы какую вы СУБД используете (MS SQL, PostgreSQL, Oracle), или вообще у вас файловая база - работать будет везде. Затрачиваться на покупку ПО тоже не надо.
Это в дополнение к тому что я уже писал о плюсах использования данной СУБД.
97. KV1s (KroVladS) 16.08.12 11:58
(80) OBEH, (81) KV1s,
С PostgreSQL разобрался вот обсуждение
98. Борис Скворцов (gaglo) 16.08.12 16:32
(96) ...вы обиделись? Напрасно!
На нашей фирме есть похожая задача. Фирма торгует электротехнической продукцией. Поставщики предоставляют нам сертификаты на свою продукцию, мы по требованию покупателей снабжаем их копиями сертификатов. Для этого сканы сертификатов привязаны к номенклатуре. Каждый сертификат накрывает много номенклатурных позиций, всего сканов около 400. Новый сертификат - явление редкое, скажем, раз в полгода. Обращения на чтение - несколько раз в неделю. Сканы хранятся просто в файловой системе, а в 1С - полные имена файлов.
Внедрение решения заняло когда-то минут 20, насчет надежности - ни один сертификат не пропадал и не повреждался неведомым врагом, бэкап делается пофайлово, затрат на покупку чего-нибудь вроде ПО не несли, всё и так работает. Версионированием в данном случае и не пахнет, так оно и не требовалось.
Заметив статью, сначала подумал, что в своё время мы что-то прощёлкали... Прочитав, и поучаствовав в обсуждении - больше так не думаю.
Слово "упрямы" я отношу не к несогласию с моим мнением, но к неумению - или нежеланию - отстаивать своё.
Вот возьмем чисто (96).
документов в СУБД 1700.... Сколько всего файлов в базе я не считал.

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

Не выдавать военной тайны! Раз в месяц или раз в столетие... (Видно, что подробный ответ может быть неконкретным...)
Про какую то альтернативную авторизацию я и не писал. я писал о том что СУБД поддерживает авторизацию по логину и паролю

1С тоже поддерживает авторизацию "по логину и паролю". Я считаю её основной. Потому что 1С в данном случае - основная система. Если во внешней СУБД есть другой логин и другой пароль - это будет вторая авторизация. Альтернативная!
О том что СУБД быстрее файловой системы я вообще не писал! Где вы это взяли?

Смотрим в (21) "плюсы данного решения: ... 4. Скорость поиска данных в базе и их отдача у NoSQL СУБД очень высокая". Каюсь, домыслил. Потому что не представляю "плюсы решения вообще", а только плюсы "данного решения по сравнению с другими". А с какими другими? Наверное... Вы и сами знаете - я про костыль №1. Но иначе, извините, не понимаю.
Я вас не заставляю использовать мое решение!

Ну да. Но мог бы убедить. Но не смог. Или не захотел. Я вообще-то про себя думаю, что убедить меня можно. Но убедительными доводами. Хотя бы внешне убедительными.... Не сложилось.
В любом случае благодарю за потраченное на меня время.
99. Dimon (klel) 16.08.12 22:15
Большое спасибо за описание как можно все это сделать =) теперь можно воспользоваться разработкой и что то свое придумать :)