Идея использования внешней базы данных появилась после того как столкнулся с необходимостью размещения большого количества файлов (Сканы документов, конструкторско-технологическая документация. Всего около 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).
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Планировал около полугода назад такое решение. тогда руки не дошли.
Хотелось бы узнать как организовал бекап для этой базы?
Это пять, как раз сегодня об этом думал… ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО, за то что выкладываете такие вещи это опыт и время… вообщем бегу пилить под себя)))
(1) frai, для бекапа необходимо остановить службу сервера СУБД и скопировать файл ИмяБазыДанных.couch из папки «C:Program FilesApache Software FoundationCouchDBvarlibcouchdb»
(1) frai, на win серверах есть теневое копирование, это бекап без освобождения файла.
Когда выбирали NoSQL хранилище, почему склонились именно к Couch? MongoDB не пробовали?
(5) mr zafod, Читал про него, но не пробовал. В плане надежности они приблизительно одинаковые. Работать СУБД будет в режиме очень низкой нагрузки, поэтому производительность тут не критична. Мне понравилась идея с доступом по http протоколу, да и консоль администрирования удобная.
(4) babys, если честно даже не знал такую возможность, надо почитать будет.
Зачетно! А как со скоростью работы такого рещения по сети? Притормаживает на клиентских машинах или нет? Какого размера пробовали передавать на клиентскую машину документы?
(8) salexdv, Скорости хватает — приблизительно так же как и при копировании файлов по сети. Пробовал передавать файлы до 40 Мб. Средний размер файла у меня 1-10Мб. И передаются по сети (загружаются в СУБД или открываются) в среднем 1-5 сек. (зависит от размера файла, загруженности сервера).
А зачем вообще использовать любой вид БД для хранения файлов?
NTFS, FAT и т.д. — и есть форма NoSQL базы данных. Так зачем было создавать дополнительную оболочку одной БД над другой?
И конечно (4) babys правильно упомянул про «теневое копирование».
Конечно http доступ к данным в БД «как бы» хорошо, но это угроза безопасности. Из этого же разряда http и ftp в Oracle. Если данные в пределах 1С можно залогировать, проверить права доступа, то делать это уже и в БД — огромная проблема.
Когда смотрел couchdb была проблема с репликацией именно вложений в документ, т.е. при репликации на другие сервера (по факту планы обмена) для вложений не сохранялись версии в случаи конфликтов.
Подскажите как сейчас с этим делом, если знаете.
(10) А вы пробовали хранить 400-500 тыс. файлов, например, картинок просто в папке и обращаться к ней по сети?
Нет можно, конечно, организовать хранение и в папке в виде дерева, тогда обращение будет шустрее, но СУБД, имхо для этого больше подходит.
(12) salexdv, у Вас хорошее статья.
Мне просто интересны обоснования…
1. А зачем нужно обращение из сети? И из какой сети? В безопасной среде делают так, что только 1С сервер может получать данные от такого сервера/БД. Иначе всегда будет существовать вероятность, что кто-то использует уязвимость БД и ему даже не нужно будет взламывать сервер с 1С, что бы залить «что-то нехорошее». Вот из-за чего http и ftp доступы к данным в БД это «сахар», который может принести очень много проблем. Намного проще организовать защищённое общения сервера 1С с БД по зашифрованному TCP каналу.
2. А если подумать о том, как БД хранят данные и если это файлы и они часто заменяются, удаляются, добавляются — то это ужас. Вот БД типа «файловая» как раз именно для этого создана и оптимизирована. Тут тебе и контроль доступа, и можно сделать логирование обращений, модификаций, добавлений. Короче — всё для файлов и только ради них.
(13) Статья не моя ))
Я про то, что когда файлы хранятся просто на диске, а не в СУБД, и этих файлов очень много — обращение к диску занимает гораздо больше времени, чем чтение из БД.
А ограничение и логирование http тоже легко настроить, так что не вижу тут серьезной угрозы безопасности )))
(14)
Ну когда 400-500 тысяч файлов в одной папке — верю. Но если сделать хоть относительно сбалансированное дерево каталогов — то с чего бы открытие файла по полному имени занимало больше времени, чем извлечение записи из БД, даже если она и антиSQL?
По безопасности я особых угроз не вижу. Разве что до файлов может добраться кто угодно любым проводником, а в БД залезть — надо иметь некое спецсредство. И преимуществ перед файловым хранением пока не вижу. Версионирование, быть может? Так в статье оно свелось к
— а это, кажется, должен обеспечить бэкап…
(14) salexdv, ну так Вам повезло, что Вы получили скорость обращения к файлам в БД быстрее, чем к диску.
Если серьёзно отнестись к системе хранения в файловом варианте, то можно получить потрясающие скорости. По сути это тоже самое, что оптимизация БД, т.к. если вдаться в дебри низкоуровневого хранения данных в БД, то мы напоримся на те же проблемы файлового доступа. Просто файлов меньше и они «жирнее», но сама БД хранит в них и бинарные данные файлов и свои журналы, метаинформацию и т.п., БД так же сталкиваются с фрагментацией, дают свои накладные расходы на организацию поиска.
Лично я для такой задачи оптимизировал бы сам сервер с файлами, отключил бы избыточность и т.п.
А про http — то я не зря спросил про сеть, т.к. я не понял как организуется получение файла из БД.
Тут файл на клиент передаёт сама БД по http или через сервер 1С?
Использую сервер ftp для таких случаев.
(15)
…Версионирование, быть может?…
Если это бинарные данные, то и возможностями ОС это можно сделать. Если организована версионность хранения текстовых файлов (любого вида), то лучшим формой «БД» тогда будет оптимизированные под версионность: SVN, CVS, Git и т.д. — тоже можно назвать «версионной БД».
По мне: лучше использовать то, что максимально оптимизировано под данную задачу. Если, конечно, это можно использовать.
(18) EmpireSer, SVN, CVS, Git хранят состояние версии для всей базы, а не для каждого отдельного документа. CouchDB/MongoDB вообще интересна своей репликацией и возможнстью разрешения конфликтов. В теории можно поставить в настройках, что состояние документа будет «сохранен», только тогда, когда этот документ расползется на несколько серверов.
(16) EmpireSer, Вы видели в работе, например, связку nodeJS + mongoDB (или + CouchDB или +Redis)? Скорость отдачи статики просто колоссальна. NoSQL — идеальное хранилище для документов, музыки, видео и тд. Если же Вы хотите делать сложные агрегации или выборки с условиями и join’ми — то NoSQL проигрывает обычным реляционным SQL базам данных.
Хотелось бы, как я считаю, перечислить плюсы данного решения:
1. Хранение файлов просто на диске разложенных по папкам считаю неправильным т.к. можно любыми средствами ОС или программами их изменить или удалить. СУБД гарантирует доступ к данным только специальными средствами (здесь это обычные http запросы GET, PUT и DELETE).
2. СУБД поддерживает возможность авторизованного доступа к данным. Я не предлагал выкладывать СУБД в интернет (если кому то это будет необходимо, тогда придется серьезно разбираться с настройкой безопасности). У меня она используется в локальной сети.
3. Если надо будет устанавливать права на файлы для доступа из 1С, то это тоже возможно. т.к. документ СУБД может содержать любую информацию (например данные о пользователе его создавшем или о группе пользователя и т.д.).
4. Скорость поиска данных в базе и их отдача у NoSQL СУБД очень высокая (их поэтому и используют часто как хранилища).
5. Есть возможность делать бекап (писал здесь(3) ). Есть возможность получить доступ к удаленным файлам без манипуляций с восстановлением копии базы извлечением файла оттуда и помещением его в рабочую базу (версионирование).
6. Можно СУБД разместить при необходимости на другом физическом сервере.
7. При использовании такой связки 1С и CouchDB не увеличивается размер базы 1С и бекапов. Для CouchDB достаточно иметь всего один актуальный бекап (т.к. в нем будут содержаться все версии документов с их вложениями).
(19) pumbaE, спасибо. Этот вопрос я изучу подробнее (как будет время).
(20) mr zafod, к сожалению не видел… (убрано)
… Скорость отдачи статики просто колоссальна. …
Я не говорил, что статику не выгодно хранить в БД. Я говорил про часто меняющиеся (именно удаление и добавление) файлы могут свести на нет возможности БД из-за фрагментации данных. А механизмы нормализации таблиц можно сравнить с дефрагментацией отдельных каталогов в файловой архитектуре.
Но опять же, я тут размышляю именно из предположения: файлы меняются часто, клиент 1С может файлы добавить напрямую в БД, безопасность сети может быть уязвима.
(21) спасибо за разъяснение. Но прошу сразу прощение за:
1. Доменная архитектура. Очень простая организация ограничения доступа как к 1 файлу, так и ко множеству. У нас в организации именно так и работает разграничение по сетевым ресурсам. Все компьютеры в домене. И только спец. средствами с вирусной архитектурой можно получить доступ «куда нельзя».
2. Доменная архитектура тоже использует авторизованный доступ.
3. Как я понял клиент запрашивает сам нужные файлы из БД, 1С только передаёт ссылки.
4. Тут возразить нечего. Но удивлён — какой поиск данных, если все ссылки на данные располагаются в 1С?
5. Кхм… Резервное копирование Windows и доступ через «Предыдущие версии» !?
6. Ну DNS ни кто тоже не отменял.
7. Тоже самое при файловой архитектуре. В 1С ведь можно хранить только путь.
Очень жалко, что я сейчас не владею понятиями низкоуровневого хранения данных в этих БД. Весь мой опыт касался MS SQL и Oracle и у них именно хранение бинарных данных не оптимально. Я именно про хранение данных на носителе информации в служебных файлах БД.
Вот если бы NoSQL базы могли работать как «чистая ОС» или создавали свою файловую архитектуру на жёстком диске (а не использовали ту, что уже размещена на диске), или внедряли свой низкоуровневый драйвер доступа к кластерам ЖД — то я бы даже «не пикнул».
Но тут явная «надстройка» над возможностями тех же серверных ОС. ОС всё равно нужна, так почему не выжить из уже данных ею механизмов максимум?
(22) EmpireSer, Возможно при очень большом количестве запросов к базе производительность как то и будет падать, но этот проект не высоконагруженный (я очень сомневаюсь что все мои 100 пользователей будут одновременно получать и сохранять файлы в базу, хотя может даже и это не вызовет снижение производительности).
Доступ к файлам осуществляется непосредственно из 1С (про безопасность доступа из 1С я написал здесь (21) ).
А если пользователь пытается добавить новый файл в базу, а версия документа СУБД уже изменилась, то ему будет выдан отказ и просьба обновить (заново получить с сервера) список файлов.
Ну и про безопасность. Если в моей локальной сети вдруг появится человек, который может положить CouchDB, то он сможет положить и всё остальное. Я думаю это вопрос уже немного из другой плоскости.
(23) EmpireSer, Логика работы такая что 1С передает запрос вида
«0f64f1fb-ab0e-11e1-a055-080027004cb0» где ключом является GUID элемента справочника и получает список файлов хранящихся в документе с id равным GUID
Для открытия файла содержащегося в документе например
и получает файл который сохраняется в temp и открывается соответствующим приложением
Ну я тоже как то не особо владею знаниями о низкоуровневом хранении данных 🙂
(25)
Возможно при очень большом количестве запросов к базе производительность как то и будет падать, но этот проект не высоконагруженный (я очень сомневаюсь что все мои 100 пользователей будут одновременно получать и сохранять файлы в базу, хотя может даже и это не вызовет снижение производительности).
Я тут не совсем про производительность говорил, а про производительность при сильной фрагметации данных в служебных файлах БД. Любая база данных размещает свои таблицы в особых служебных файлах, которые для ОС «просто файлы». Бинарные данные имеют не маленький размер, поэтому выделение блока в этом служебном файле для данных работает как «размер блока >= размеру файла». Если после этого добавить в БД ещё один файл и удалить предыдущий — то образует «незанятое пространство». Его БД может сразу «сжать» или подождать «что будет дальше». А вот если потом в БД добавить файл большего размера, чем был удалённый, и пустого блока >= размеру нового файла нет, то БД может выделить или новый фрагмент, в который полностью уместит файл, или попытается его распределить по пустым блокам.
Тот же самый «бардак» мы видим обычно на наших компах.
И как и в БД, так и в ОС существует как ручные так и автоматическое убирание «пустот».
Доступ к файлам осуществляется непосредственно из 1С (про безопасность доступа из 1С я написал здесь (21) ).
(убрано, из-за разъяснения)
А если пользователь пытается добавить новый файл в базу, а версия документа СУБД уже изменилась, то ему будет выдан отказ и просьба обновить (заново получить с сервера) список файлов.
Механизмы версификации на уровне БД — интересно. До этого встречал их только на уровне приложения (или сервера).
Ну и про безопасность. Если в моей локальной сети вдруг появится человек, который может положить CouchDB, то он сможет положить и всё остальное. Я думаю это вопрос уже немного из другой плоскости.
Если не считать, что 1С хранит «корпоративную тайну», то проблем нет.
А если считать — то многие из решений «просто, но со вкусом» могут стать «дыркой».
(26) а как происходит добавление файла в хранилище? Сама БД, минуя сервер, сможет произвести PUT запрос при указании
?
(27) EmpireSer, База данных — это по любому файл на диске. Внутреннюю структуру этого файла я не знаю. Знаю что NoSQL СУБД оптимизированы для работы с большими объемами данных.
Контроль осуществляется на уровне приложения (клиента 1С). Когда получается список файлов, получается и версия документа СУБД и перед записью нового файла она сравнивается с текущей версией в СУБД.
1С тоже может запросто стать «дыркой». По моему в большинстве баз 1С пароли такие что их подобрать особого труда не составит (не во всех конечно). Я не рассматривал вопросы серьезной настройки безопасности т.к. она мне просто не требовалась и я соответственно эту тему не разбирал. Вот например самый простой вариант защиты файлов — поместить в архив под пароль или зашифровать каким нибудь ключом перед загрузкой на сервер. Вариантов защиты если она очень нужна можно придумать много.
(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());
где строка соединения равна например
(29) (30) простите, что я так привязался. Но я на месте сисадмина такой сети и указания директора «ни каких утечек данных» «таких» 1С-ков (т.е. таким образом организующих взаимодействие) «бил бы палкой».
Но я не сисадмин и сам 1С-ник :)))
Просто мой «больной мозг» как такое видит сразу думает: «где утечка данных», «как произвести инжект своего кода в данные», «как сделать массовое поражения всех клиентов и найти привилегированные сессии» и т.д.
где строка соединения равна например
Надеюсь хоть вот такое проделать нельзя?
Т.е. перезаписать саму библиотеку libcurl.dll
Отредактировал предыдущий ответ.
Видно я ошибочно предположил, что сама библиотека «libcurl.dll» тоже может приехать к клиенту. А как понял, её использует «CouchDB» «внутри себя» что бы перезаписывать данные?
Причем здесь libcurl.dll вообще?
(31) EmpireSer, Файл (например libcurl.dll) лежит на диске и чтобы его записать какими нибудь «левыми» средствами в базу надо как минимум знать id (b5a1b704-dd49-11e1-b509-e70be848db45), текущую версию (5-b5a1b704dd4911e1b509e70be848db45) документа СУБД ну и конечно же имя пользователя и пароль для доступа к базе (Транспорт.SetCredentials(ПараметрыСоединения.ИмяПользователя, ПараметрыСоединения.Пароль, 0); )
Если кто то всё это знает то надо бить уже админа за то что делает легкие пароли или пользователей которые не умеют их хранить.
У меня моя сеть защищена снаружи очень хорошо (тут я не волнуюсь). А внутри у меня, ну кроме тех кому положено знать, и не слышали таких слов как CouchDB, NoSQL, PUT или GET запросы и т.д.
Поэтому минимума защиты «от дурака» мне хватает.
(33) alprk, вообще не причем. Это просто файл который попался мне для примера и я его положил в базу и привел для примера строку соединения. Вместо него можно просто вставить ИмяФайла.Расширение
Изменил в комментарии (30) имя файла на Картинка.jpg для того чтобы название библиотеки libcurl.dll никого в заблуждение не вводило. Это просто может быть любой файл
(34)
Один из самых хороших способов «ворваться» в защищённую сеть — это компрометировать одного из пользователей этой сети. Хоть червём в почте, хоть через интернет, хоть соц. инженерией.
А внутри у меня, ну кроме тех кому положено знать, и не слышали таких слов как CouchDB, NoSQL, PUT или GET запросы и т.д.
И очень хорошо, что у Вас мало кто знает про устройство сети. Но если у Вас, в 1С, будут храниться секретные данные, которые могут дать возможность конкурентам «похранить фирму», и кто-то захочет их получить — то это взаимодействие может стать одной из «нужных дырочек».
Тут пароли знать не нужно — они сами светятся в запросе. Самое главное для злоумышленника — каким либо образом проникнуть на один из компьютеров в сети и иметь возможность получать от «жертвы» ответы. А тогда можно собрать информацию о сети, запросах, бд и т.д.
Тут явно сработает атака «Man-in-the-Middle» и делай её хоть в ответ сервера 1С, хоть в ответ от БД. А тут уж делай что хочешь.
(35) (36)
Забыли про библиотеку. Реально вводила в заблуждение. Вот тока (26):
и получает файл который сохраняется в temp и открывается соответствующим приложением
Тут просто обязательно пинать админов, что бы обновления ОС ставились вовремя. А то doc документики, jpeg картинки с переполнением буфера и захватом управления ОС — не редкое явление.
=====
Как всё устроено — я хорошо понял, но ни кому такое рекомендовать не буду (организация доступа к данным БД по протоколам http или ftp с возможностью какой либо модификации данных)
1. Смысл хранить какие-то данные во внешней базе, если в 1С они не используются никак, кроме как «а вот набор картинок из другой базы»?
2. Смысл доступа к файлам из 1С к какой-то другой базе, если версионирование — все равно в той сторонней базе?
3. Смысл использовать какие-то NoSQL, когда можно организавать новую базу на существующем SQL (не думаете же вы, что все будут затевать с файловой 1С?) и хранить там все, что угодно.
hrip, дайте вразумительные ответы и приведите, пожалуйста, примеры использования такого хранения. Не теоретического.
(37) EmpireSer, Ну что могу сказать, при наличии очень секретной информации и таких требований к безопасности вам наверное надо придумывать какие то другие средства для хранения файлов и доступа к ним. Может быть и подойдет данная СУБД после каких либо настроек. Увы я не специалист по безопасности чтобы вам квалифицированно ответить на все вопросы.
Ну если к вам в сеть вломиться специалист который может сделать всё что вы описали, то ему по моему будет пофиг что ломать CouchDB, MS SQL или файловую 1С
(39) в couchdb вы можете настроить только доступ к базе. К отдельным документам к сожалению нет, соответственно для контроля надо делать трехзвенку…
(38) AlexO, В принципе можно и не хранить данные таким образом. Вариантов много. Можно использовать стандартный механизм 1С (Хранилище доп. информации), можно хранить все файлы в папках, а в 1С хранить только путь к файлу, можно хранить в какой либо базе на SQL сервере.
В моей демо базе не реализована возможность получать версии документов (всегда получается последняя версия), хотя это можно сделать. Я использую такую базу для хранения файлов (подключаюсь к ней из УПП)и если кто то удалил файл случайно я могу его восстановить через консоль администрирования зная id документа в базе (т.е. GUID элемента в 1С). Может попозже дойдут руки и сделаю доступ к версиям из 1С.
За данную СУБД кстати денег платить не надо и она потребляет мало ресурсов (ну по крайней мере в таком режиме работы).
База данных не требует описания данных, как реляционные СУБД. Можно в любом документе СУБД создать любое количество полей и прикрепить любое количество вложений.
Для доступа к данным не нужны никакие драйвера.
Ну и вот здесь (21) уже писал про плюсы использования.
А выбор за вами что использовать, вариантов много.
Я лишь предложил один из них.
(40) pumbaE, ну почему же нельзя. к документу СУБД можно прикрепить любую информацию (можно создать любое количество полей) например о пользователе создавшем документ или о группе пользователей. т.е. собственно контроль будет на стороне приложения клиента.
Хотя я с настройкой безопасности сильно и не разбирался, мне хватило типовых. Может там что нибудь и есть.
Неоднократно вставала проблема хранения документов сканов и прочего в базе, нужно попробовать
спасибо за статью
так, ту нарисовались апологеты теневого копирования… может кто-нибудь мне объяснит чем достигается целостность данных и НЕОСТАНОВ базы при теневом копировании когда копируемый файл пишется на диск — с ним активно работает база данных — в это же время выполянется теневое копирование…?
.
внятного ответа на вышеобозначенные вопросы — я не нашел…
Спасибо автору за классный вариант решения проблемы хранения файлов с удобным доступом из 1С. От постоянных добавлений «сканов» документов база пухнет чрезмерно. Давно подумывал над вариантами «исключения» не объектов 1С из основной базы. Хранить файлы в одном хранилище/базе намного удобнее, чем иметь десятки и сотни тысяч файлов, которые и бэкапить-то неудобно.
У MS SQL есть возможность хранить большие файлы в filestream. Рассматривалась эта возможность для хранения?
Сам столкнулся с необходимостью хранения больших файлов. Выбираю вариант хранения.
Предложенное автором решение интересно, поэтому хотелось бы рассмотреть его в сравнение с filestream.
(46) aspirator23, Нет такую возможность не рассматривал.
Я уже выше писал почему выбрал данную СУБД:
1. Надежность (ну по крайней мере по отзывам);
2. Скорость поиска и отдачи данных клиенту;
3. Доступ по http без использования драйверов;
4. Нет необходимости создавать в БД таблицы и при необходимости смогу к любому документу базы данных добавить любое количество полей;
5. Версионирование документов БД;
6. Удобное администрирование;
7. Денег платить не надо;
8. Ну и очень интересно было изучить что такое NoSQL.
Данный материал несомненно полезный, по крайне мере есть еще одно решение для хранения файлов и документов в ИБ.Есть решение конечно такое как Хранилище, но задачи бывают разные.Взято на заметку. Плюс автору.
Большое спасибо автору статьи! Было очень интересно ознакомиться с подобным решением, т.к. за NoSQL базы услышал впервые и раньше с ними не работал.
(44) CheBurator, а где тут обсуждалось про теневое копирование? В CouchDB отдельный процесс реплицирует данные на другой сервер. При этом ответственность за проверку окончания транзакции возложена на клиента, т.е. то что мы POST запросом отправили в базу документ(с файлом или без) и сервер ответил OK, не означает что транзакция завершилась успешно. Клиент должен дополнительно проверить, записался ли этот документ или нет…
Интересно, спасибо за статью.
(50) pumbaE, Я думаю т.к. http сервер встроен в СУБД, то он возвращает ответ уже после завершения транзакции (удачного или нет) и никаких доп проверок не надо. т.е. ответа сервера достаточно
(41)
тогда противоречит
т.к. в такой (объектная она, что ли?) СУБД априори будет больше занимать место (и требовать на свою обработку ресурсов) те же самые данные, которые «оптимизированы» по типу данных в реляционных СУБД — именно в силу того, что в вашей СУБД все типы данных — универсальные.
Прямо уж и любое?
Если даже ваша СУБД и использует «свою» FS, то на доступ к ней — нужны драйвера. 1С — это не ОС.
вот когда сделаете — поставлю плюс за полезность. А пока — чисто «игрушка» 🙂
(52)
1.Есть ограничение на размер базы данных? Размер одиночно загруженного файла?
2.Можно ли провести сравнение скорости загрузки очень больших файлов в базу?
Например: загрузить файл размером 1Гб в СУБД и просто скопировать этот же файл в каталог лежащий там где и СУБД. Это не с целью покритиковать, а с целью оценить скорость работы этого варианта для себя.
(44) CheBurator,
теневое копирование — вообще тормоза жуткие, по-крайней мере, в реализации Microsoft 🙂
В Линухе оно аналогичное как-то более человечно…
(45) realm,
Храните в ОС и давайте ссылки на файлы. Делов-то.
(47)
чудес не бывает. Если у вас автоматом добавляется «неограниченное» количество полей (в чем я тоже сомневаюсь — понятие «неограниченное» не относится к используемому в системах хранения данных), то редактировать/удалить — тоже без задействовования интерфейса администрирования?
(50) pumbaE,
это не про CouchDB, а ответ на посты (4) и (10), начатые
(4) babys,
А что, в SQL не так?
(52)
на скорость работы и качество контроля записи «встроенность» http-сервера не влияет — разве что только отсутствует необходимость «подвязки» стороннего http-сервера.
А так — это сродни тому, как если рассуждать «где быстрее команда выполнится — когда задать её через консоль или по красявому интерфейсу?»
(54) aspirator23,
Скорей всего, «стандартные» 2-4-10 Гб для бесплатных баз на xSQL.
hrip, верно? 🙂
Например: загрузить файл размером 1Гб в СУБД и просто скопировать …
aspirator23, разницы не будет ни в какой СУБД — FS сама по себе «оптимизированная СУБД» для хранения файлов, и в худшем для FS случае — разницы не будет никакой.
(60) поскольку aspirator23 спрашивал про CouсhDB, то неверно. это база данных с открытым исходным кодом и ограничений по использованию нет(на размер базы), разве что ограничения файловой системой. вообще она используется несколько для других целей, — основное её достоинство это достаточно прозрачный механизм синхронизации данных и поэтому её используют для хранения распределенных данных. на какой-то(не помню точно) конференции доклад делали по использованию её в системе сбора данных со счетчиков, которые разбросаны удаленно друг от друга.
я так не думаю, но спорить с вами не стану.
(61) djd.sf,
не путайте обработку данных и запись-чтение на хранение.
Или думаете, что доступ к «собственной» FS у какого-то CouсhDB будет быстрее и лучше, чем у коммерческих ОС? Своя FS введена туда единственно из-за удобства использования для себя «как хочу, так и верчу».
(53) AlexO, По поводу потребления ресурсов. Средняя загрузка ЦП при работе СУБД 0.5-4%, при добавлении файлов иногда подскакивает 10-30% на пару секунд (размер базы уже 8 Гб).
Вам хватит 100 полей в документе? На 102 устал добавлять. Мне хватает.
Для доступа к СУБД не нужны драйвера! использую «WinHttp.WinHttpRequest.5.1». Пробовал и стандартное для 1С HTTPСоединение — получилось всё кроме загрузки файла в СУБД.
Да версионирование из 1С не реализовано. Может быть попозже попробую сделать. но возможность восстановить удаленный файл всё равно есть через консоль администрирования.
Для вас может и игрушка, а я сделал и пользуюсь!
(63)
не мытьем, так катаньем 🙂 Все равно используется пусть и встроенный, но «драйвер» ОС.
Но через HTTP заносить данные — это же жутко долго.. считайте, вы все переводите в текст и передаете в базу…
(62) AlexO, Я согласен что от железа, ОС и ФС очень много зависит, надо сравнивать производительность СУБД на одинаковом оборудовании, сравнивать одинаковые операции
Но и задача под которую я предлагаю использовать СУБД не требует большого быстродействия.
(64) AlexO, Только что попробовал загрузить файл 30Мб
В CouchDB — 6 Сек.
В расшаренную папку — 4 сек
В хранилище доп информации УПП (крутиться на MS SQL) — 11 сек.
Хотя конечно это тоже всё относительно.
(66)
Ну, вы бы его еще сначала через Лос-Анджелес послали в MS SQL «ложиться» 🙂
1С — это ж полновестная и жесточайшая по хранению и обработке данных.
В расшаренную папку — 4 сек
да, тут я с вами полностью согласен:
(60) AlexO,
(54) aspirator23, Из клиента 1С грузятся файлы размером до 100 Мб. Если больше то ругается на нехватку памяти. А в саму СУБД грузил и по 500Мб через консоль.
Про сравнение скорости я только что написал в (66)
(68) AlexO, Стандартный механизм 1С для хранения файлов без изобретения всяких «велосипедов»
(69)
нет, я не про это — а про саму концепцию обработки данных в 1С.
Вот тут hogik описал подробно, плюс качественные комменты.
(70) AlexO, Обязательно почитаю.
А собственно из-за чего всё и затевалось то. У нас есть возможность использовать для хранения 2 варианта -это стандартный 1С и свои «костыли».
А костыли могут быть минимум 3-х видов:
1. Файлы на диске, а в базе пути к файлам;
2. SQL СУБД;
3. NoSQL СУБД.
Причины по которым я выбрал CouchDB я уже описывал.
Я нигде не пытался доказать, что это самое лучшее из всех решений и эта СУБД обладает самым максимальным быстродействием.
Данное решение позволяет довольно удобно работать с файлами, оно не очень сложно в реализации (самая большая сложность была — это написать парсер JSON)и скорость работы больше чем у стандартных механизмов 1С (указываю сразу, что я не делал контрольных примеров с хранением файлов напрямую на дисках или хранением в SQL СУБД и соответственно не замерял их производительность).
Ну а использовать данное решение или нет — это личное дело каждого.
Как минимум полезно знать что есть NoSQL СУБД, какими возможностями они обладают, и как с ними можно работать.
(66)
В CouchDB — 6 Сек.
В расшаренную папку — 4 сек
В хранилище доп информации УПП (крутиться на MS SQL) — 11 сек.
А кто нибудь сейчас помнит, что стоит за «расшаренная папка»? За ней крутится обычные серверные механизмы (просто встроенные в ядро), как и у http, ftp и т.д. серверов.
Скорость загрузки файлов в «расшаренная папка», http, ftp — должна практически совпадать, т.к. они все используют механизмы контроля доступа, логирования, а сами файлы пишут через бинарные потоки.
А скорость записи файла в NoSQL и SQL БД будут всегда выше, т.к. необходимо так же дополнительно рассчитывать экстенты служебных файлов на приращение данных. Т.е. в худшем случаи будет выделено «размер принимаемого файла <= размеру блока для его хранения». Это можно избежать создав сразу «супер гигантскую» пустую базу.
(64)
Но через HTTP заносить данные — это же жутко долго.. считайте, вы все переводите в текст и передаете в базу…
Там данные упаковываются и передаются отдельным потоком. Они не преобразуются в текст.
А если передавать файлы методом POST — то тогда будет преобразование в строку.
(72) EmpireSer, Я же написал что всё относительно т.к. шара на которую копировал, CouchDB и 1C сервер — это разные машины.
Ну я и вроде данный проект не предполагает использовать СУБД в режиме, когда будут совершаться десятки тысяч транзакций в секунду.
Файлы на сервер передаются методом PUT.
Кто-нибудь пробовал хранить данные в самой MS SQL базе?
Не там, где лежат данные баз 1С, а в отдельной таблице.
Ведь, если есть в конторе MS SQL то зачем еще использовать
какую-то другую СУБД.
Тем более, для простого хранения и вынимания файлов.
(74) OBEH,
а что пробовать, берите и храните.
(75) Хорошо. А пример этого самого хранения есть?
(76) OBEH,
примеры записи в SQL есть здесь на сайте.
(76) OBEH,
Выбирай какой больше нравиться…
Всё для MS SQL.
(78) KV1s, сбасибо!
Мда. Совсем забыл, что у меня база в postgreesql на Linux
(80) OBEH,
Под PostgreSQL ни один из вариантов у меня к сожелению не получилось запустить нормально 🙁
(80) OBEH,
крупно ошиблись… 🙂
Я не понимаю зачем использовать CouchDB для хранения файлов. Но если задачу можно свести к алгоритму Map-Reduce, то стоит заморочиться, давно планирую такое мероприятие, именно с CouchDB.
(83) alprk, Функция MAP там и так используется. А зачем использовать именно CoucDhB (по крайней мере я так считаю) я уже писал здесь (21) и здесь (47).
(84)
ждем основательных доработок «под ключ» 🙂
тогда и вопросов не возникнет — если будет удобное решение.
(71)
Это правда. НО! Всё время хочется, чтоб минимумом не ограничивались. Ну есть они, и с ними можно… А где обсуждение границ применимости? Где описание круга задач, в которых данный подход явно предпочтительнее, и наоборот, где он неуместно выглядит? В списке из (47) из восьми «причин выбора данной СУБД» семь на самом деле отвечают на вопрос «почему и эту СУБД тоже можно использовать в этой задаче»; и только пункт 8 — действительно причина для конкретного выбора…
(87) gaglo, А я по моему границы применимости и круг задач не пытался описать, я показал вариант применения данной СУБД для решения конкретной задачи.
Так же можно сказать и обо всех остальных СУБД. Их все тоже можно использовать для решения задачи хранения файлов.
А для вас что является критерием выбора СУБД (применительно к этой задаче)?
(88) …я чувствую непонимание меня собеседником… Попробую объясниться.
Я это заметил. Я считаю отсутствие этого — недостатком статьи.
Ну, не я взялся решать «эту» задачу. Кстати, сама задача явно недостаточно описана в статье. И это я считаю недостатком.
А вот моё непонимание упирается вот во что: в (71) вы как автор уже чётко расписали:
А костыли могут быть минимум 3-х видов…
Недостатки «Хранилища», оно же «стандартный 1С» — в статье выписаны и мне понятны. Решение перейти к костылям — понятно. Выбор вида костылей — непонятен. И неочевиден. И в статье не описан. А на вопрос, всплывший в (10) —
лично я ответа не заметил.
А без этого — статья выглядит безликой новостью, каких полно на всяких порталах. «Есть вот такая программа, она может вот что…». Безусловно похвально вложение личного опыта: «Я попробовал, она действительно может!» Не могу одобрять отсутствие аналитической части вида «Она может то-то и то-то, что у таких-то её конкурентов не получается или выходит хуже…»
И получается: минусовать статью не за что. А плюсовать неохота…
(24) EmpireSer,
вероятно, выжать 🙂
(90) andpal,
вероятно, выжать 🙂
Хоть я и русский, но мой русский до сих пор хромает 🙂 Нужно было слушаться маму и делать школьные домашние задания 🙂
По теме:
Из-за этой раздачи я полез в дебри NTFS и нашёл очень много полезного: есть механизмы мгновенного поиска без индексирования, отслеживание изменений, и возможность к папке/файлу добавить всё что душе угодно, и идентификаторы разделов и файлов/папок, и уникальные глобальные идентификаторы, и расширенные атрибуты файлов…
Т.е. используя этот «низкий уровень» можно натворить такое, что через проводник не увидишь и ни какая «нашлёпка» (Oracle, MS SQL, MySQL, CouchDB, mongoDB) уже не нужна будет.
(91) EmpireSer, мне близка ваша позиция, файловая система — база файлов.
Но тут явная «надстройка» над возможностями тех же серверных ОС. ОС всё равно нужна, так почему не выжАть из уже данных ею механизмов максимум?
Как и в 1С, кое-кто не освоив, не изучив логику и возможности конфигурации делают «велосипеды».
Но пусть будет много всяких решений, для кого-то они проще и эффективней, к тому же использовать
совсем не тривиально.
У вас есть рабочий пример?
(92) andpal,
совсем не тривиально.
У вас есть рабочий пример?
Всегда забываю: что значит «тривиально»?
И рабочий пример чего? Например ?
(89) gaglo, Я решал конкретную задачу и соответственно только ее и описал в статье, но в статье есть ссылки на источники где можно более подробно прочитать за данную СУБД.
Причина выбора «костылей» действительно в статье мало была описана, но в комментариях я по моему довольно подробно описал в (21) и (47). Если вы считаете, что их недостаточно для выбора, то хотел бы услышать все таки ваше мнение о том какими критериями надо руководствоваться при выборе СУБД.
на вопрос
я написал ответ в (21).
Не спорю, в статье маловато аналитики. Будет время постараюсь отредактировать статью и доработать демо базу, учитывая все услышанные пожелания.
(94) «…а мы упрямы…» Ну что ж, срублю ещё долю старбакса.
По-моему, это неконкретное описание конкретной задачи. Большое количество — это сколько? 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. Продолжать не буду…
(80) OBEH, (81) KV1s,
С PostgreSQL разобрался вот
(39) ну к примеру я пользую для этого 8.2z & Clarion 6. Пусть прочитают что-нибудь 🙂
(44) CheBurator, теневое копирование выполняется независимо от захвата файла другими приложениями, соответственно никакого транзакционного действа оно не проверяет. Я думал, что такие вещи нет необходимости Вам объяснять 🙂
При работе с конторами, типа Директор+Бухгалтер = ООО, конечно никакого скуля, никаких админов и т.п., поэтому теневое копирование, ночью когда все спят, это наше ФСЁ 😉
(6) К надежности стоит так же присовокупить наличие квалифицированного специалиста, который сможет в случае падения внешней базы с документами, ее реанимировать. Мой опыт показывает, что в крупных компаниях 1С хранится в MS SQL, наличествует более-менее грамотный спец по MS SQL и купленная лицензия. Установка же новой платформы, по которой найти спеца не так то просто, надежность скорее снизит. Безусловно NoSQL СУБД приспособлены для хранения не реляционных данных, но какие точно плюсы мы получим от подобного решения? Помните, как в дипломах и кандидатских? Научная новизна — дело хорошее, но где экономическое обоснование? 😉
(105) Silenser, Научная новизна — дело не просто хорошее, а очень хорошее т.к. позволяет не просто получать новые знания, но и применять их для решения новых задач. Например для меня это был первый проект с использованием rest интерфейса, а сейчас так или иначе приходится с ним работать в каждом втором проекте.
Экономическое обоснование для каждой задачи будет свое и оно актуально на момент решения задачи. На момент решения задачи и написания этой статьи (3 года назад) ресурсы сервера 1С были очень ограничены, поэтому и решено было хранение документов организовать таким образом. Сейчас же когда на сервере количество оперативной памяти подбирается к 100 Гб., а дисковую измеряем в терабайтах, то размещение и способ хранение данных уже не так критичны. Единственное, я против хранения файлов на диске (хотя в некоторых проектах и приходится так делать) и в самой базе данных (т.к. будет увеличиваться размер бекапов).
По поводу плюсов и минусов данного решения, в комментариях было очень много написано. Повторюсь что данная СУБД бесплатна, довольна проста в администрировании, настройка по инструкции тоже сложностей вызывать не должна, так что какой-то особый специалист здесь и не нужен.
А выбор конечно за Вами 🙂
Но по крайней мере Вы теперь точно знаете еще один способ работы с файлами из 1С.