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

06.08.12

Интеграция - Внешние источники данных

+86 –

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
Архивная копия базы данных 1С .dt 35,25Kb 75	75	Скачать (1 SM)	Купить за 1 850 руб.

Идея использования внешней базы данных появилась после того как столкнулся с необходимостью размещения большого количества файлов (Сканы документов, конструкторско-технологическая документация. Всего около 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).

+86 –

См. также

SALE! 15%

Экстрактор данных 1С в BI - выгрузка данных из 1С в BI-аналитику

Внешние источники данных Программист Бизнес-аналитик Пользователь Платформа 1С v8.3 Управляемые формы Анализ и прогнозирование Конфигурации 1cv8 Узбекистан Беларусь Кыргызстан Молдова Россия Казахстан Платные (руб)

Готовое решение для автоматической выгрузки данных из 1С 8.3 в базу данных ClickHouse, PostgreSQL или Microsoft SQL для работы с данными 1С в BI-системах. «Экстрактор данных 1С в BI» работает со всеми типовыми и нестандартными конфигурациями 1С 8.3 и упрощает работу бизнес-аналитиков. Благодаря этому решению, специалистам не требуется быть программистами, чтобы легко получать данные из 1С в вашей BI-системе.

28500 руб.

15.11.2022 20822 20 49

Интеграция 1С 8.3 с Power BI (Генератор представлений (View) в MS SQL/PostgreSQL по структуре базы данных 1С 8.3)

Поиск данных Внешние источники данных Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Если вам нужно автоматически генерировать представления (view) к вашей базе данных 1С (есть две версии - для СУБД MS SQL Server и для PostgreSQL) по структуре метаданных 1С, то вам необходима данная обработка. Наш "Генератор View", другими словами - это коннектор к данным 1С для Power BI - незаменимый помощник для бизнес-аналитиков, работающих с базами 1С из Yandex Datalens/Power BI и т.д. Работает для обычных и управляемых форм под 1С 8.3

230000 руб.

31.07.2020 13790 13 48

Перенос данных из Парус 7.хх в ЗГУ ред.3

Внешние источники данных Зарплата Бюджетный учет Программист Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 7.хх учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

48000 руб.

24.04.2017 51142 101 165

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022 10829 13 8

Перенос данных из Парус 8 в ЗГУ 3

Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020 25107 22 1

SALE! 10%

Интеграция 1С с Kit Vending/Kit Shop

Розничная торговля Внешние источники данных Программист Бухгалтер Платформа 1С v8.3 Бухгалтерский учет 1С:Розница 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Розничная и сетевая торговля (FMCG) Бухгалтерский учет Управленческий учет Платные (руб)

Загрузка данных продаж и инкассаций из сервиса Kit Vending в 1С. Реализовано в виде Расширения. Мониторинг состояний торговых автоматов.

~~9600~~ 8640 руб.

10.06.2019 28231 24 22

Базис-Мебельщик и 1С: Загрузка спецификаций в УНФ

Производство готовой продукции (работ, услуг) Внешние источники данных Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 Лесное и деревообрабатывающее хозяйство Россия Управленческий учет Платные (руб)

Обработка предназначена для загрузки файлов, выгруженных из системы Базис-мебельщик, в справочник 1С "Спецификации" для последующих процессов учета и диспетчирования полуфабрикатов и изделий.

10200 руб.

24.06.2021 20749 57 53

Перенос данных из Парус-Зарплата Бюджет 7.71 в ЗИКГУ 3.1

Внешние источники данных Зарплата Бюджетный учет Программист Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры бюджетного учреждения Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Перенос данных из Парус-Зарплата Бюджет 7.71 в ЗИКГУ 3.1.27 для начала работы системы. Загрузка информации по физическим лицам, сотрудникам, начальной штатной расстановки и данных для расчета среднего заработка.

19200 руб.

06.07.2012 164894 47 157

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. frai 06.08.12 20:32 Сейчас в теме

Планировал около полугода назад такое решение. тогда руки не дошли.
Хотелось бы узнать как организовал бекап для этой базы?

3. hrip 214 06.08.12 21:34 Сейчас в теме

(1) frai, для бекапа необходимо остановить службу сервера СУБД и скопировать файл ИмяБазыДанных.couch из папки "C:\Program Files\Apache Software Foundation\CouchDB\var\lib\couchdb"

21. hrip 214 07.08.12 12:36 Сейчас в теме

Хотелось бы, как я считаю, перечислить плюсы данного решения:
1. Хранение файлов просто на диске разложенных по папкам считаю неправильным т.к. можно любыми средствами ОС или программами их изменить или удалить. СУБД гарантирует доступ к данным только специальными средствами (здесь это обычные http запросы GET, PUT и DELETE).
2. СУБД поддерживает возможность авторизованного доступа к данным. Я не предлагал выкладывать СУБД в интернет (если кому то это будет необходимо, тогда придется серьезно разбираться с настройкой безопасности). У меня она используется в локальной сети.
3. Если надо будет устанавливать права на файлы для доступа из 1С, то это тоже возможно. т.к. документ СУБД может содержать любую информацию (например данные о пользователе его создавшем или о группе пользователя и т.д.).
4. Скорость поиска данных в базе и их отдача у NoSQL СУБД очень высокая (их поэтому и используют часто как хранилища).
5. Есть возможность делать бекап (писал здесь(3) ). Есть возможность получить доступ к удаленным файлам без манипуляций с восстановлением копии базы извлечением файла оттуда и помещением его в рабочую базу (версионирование).
6. Можно СУБД разместить при необходимости на другом физическом сервере.
7. При использовании такой связки 1С и CouchDB не увеличивается размер базы 1С и бекапов. Для CouchDB достаточно иметь всего один актуальный бекап (т.к. в нем будут содержаться все версии документов с их вложениями).

23. EmpireSer 07.08.12 13:01 Сейчас в теме

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

Очень жалко, что я сейчас не владею понятиями низкоуровневого хранения данных в этих БД. Весь мой опыт касался MS SQL и Oracle и у них именно хранение бинарных данных не оптимально. Я именно про хранение данных на носителе информации в служебных файлах БД.

26. hrip 214 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 и открывается соответствующим приложением
Ну я тоже как то не особо владею знаниями о низкоуровневом хранении данных :-)

28. EmpireSer 07.08.12 13:55 Сейчас в теме

(26) а как происходит добавление файла в хранилище? Сама БД, минуя сервер, сможет произвести PUT запрос при указании

http://localhost:5984/documents/0f64f1fb-ab0e-11e1-a055-080027004cb0/ИмяФайла.jpg

30. hrip 214 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

36. hrip 214 07.08.12 14:49 Сейчас в теме

Изменил в комментарии (30) имя файла на Картинка.jpg для того чтобы название библиотеки libcurl.dll никого в заблуждение не вводило. Это просто может быть любой файл

4. babys 90 07.08.12 01:04 Сейчас в теме

(1) frai, на win серверах есть теневое копирование, это бекап без освобождения файла.

7. hrip 214 07.08.12 07:57 Сейчас в теме

(4) babys, если честно даже не знал такую возможность, надо почитать будет.

10. EmpireSer 07.08.12 09:39 Сейчас в теме

А зачем вообще использовать любой вид БД для хранения файлов?
NTFS, FAT и т.д. - и есть форма NoSQL базы данных. Так зачем было создавать дополнительную оболочку одной БД над другой?
И конечно (4) babys правильно упомянул про "теневое копирование".
Конечно http доступ к данным в БД "как бы" хорошо, но это угроза безопасности. Из этого же разряда http и ftp в Oracle. Если данные в пределах 1С можно залогировать, проверить права доступа, то делать это уже и в БД - огромная проблема.

12. salexdv 2358 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 2358 07.08.12 10:30 Сейчас в теме

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

15. gaglo 07.08.12 11:01 Сейчас в теме

(14)

когда файлы хранятся просто на диске, а не в СУБД, и этих файлов очень много - обращение к диску занимает гораздо больше времени, чем чтение из БД

Ну когда 400-500 тысяч файлов в одной папке - верю. Но если сделать хоть относительно сбалансированное дерево каталогов - то с чего бы открытие файла по полному имени занимало больше времени, чем извлечение записи из БД, даже если она и антиSQL?
По безопасности я особых угроз не вижу. Разве что до файлов может добраться кто угодно любым проводником, а в БД залезть - надо иметь некое спецсредство. И преимуществ перед файловым хранением пока не вижу. Версионирование, быть может? Так в статье оно свелось к

файл даже после случайного удалению можно восстановить

- а это, кажется, должен обеспечить бэкап...

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 вообще интересна своей репликацией и возможнстью разрешения конфликтов. В теории можно поставить в настройках, что состояние документа будет "сохранен", только тогда, когда этот документ расползется на несколько серверов.

22. EmpireSer 07.08.12 12:44 Сейчас в теме

(19) pumbaE, спасибо. Этот вопрос я изучу подробнее (как будет время).
(20) mr zafod, к сожалению не видел... (убрано)

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

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

Но опять же, я тут размышляю именно из предположения: файлы меняются часто, клиент 1С может файлы добавить напрямую в БД, безопасность сети может быть уязвима.

25. hrip 214 07.08.12 13:09 Сейчас в теме

(22) EmpireSer, Возможно при очень большом количестве запросов к базе производительность как то и будет падать, но этот проект не высоконагруженный (я очень сомневаюсь что все мои 100 пользователей будут одновременно получать и сохранять файлы в базу, хотя может даже и это не вызовет снижение производительности).
Доступ к файлам осуществляется непосредственно из 1С (про безопасность доступа из 1С я написал здесь (21) ).
А если пользователь пытается добавить новый файл в базу, а версия документа СУБД уже изменилась, то ему будет выдан отказ и просьба обновить (заново получить с сервера) список файлов.
Ну и про безопасность. Если в моей локальной сети вдруг появится человек, который может положить CouchDB, то он сможет положить и всё остальное. Я думаю это вопрос уже немного из другой плоскости.

27. EmpireSer 07.08.12 13:49 Сейчас в теме

(25)

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

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

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

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

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

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

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

Если не считать, что 1С хранит "корпоративную тайну", то проблем нет.
А если считать - то многие из решений "просто, но со вкусом" могут стать "дыркой".

29. hrip 214 07.08.12 14:07 Сейчас в теме

(27) EmpireSer, База данных - это по любому файл на диске. Внутреннюю структуру этого файла я не знаю. Знаю что NoSQL СУБД оптимизированы для работы с большими объемами данных.
Контроль осуществляется на уровне приложения (клиента 1С). Когда получается список файлов, получается и версия документа СУБД и перед записью нового файла она сравнивается с текущей версией в СУБД.
1С тоже может запросто стать "дыркой". По моему в большинстве баз 1С пароли такие что их подобрать особого труда не составит (не во всех конечно). Я не рассматривал вопросы серьезной настройки безопасности т.к. она мне просто не требовалась и я соответственно эту тему не разбирал. Вот например самый простой вариант защиты файлов - поместить в архив под пароль или зашифровать каким нибудь ключом перед загрузкой на сервер. Вариантов защиты если она очень нужна можно придумать много.

31. EmpireSer 07.08.12 14:30 Сейчас в теме

(29) (30) простите, что я так привязался. Но я на месте сисадмина такой сети и указания директора "ни каких утечек данных" "таких" 1С-ков (т.е. таким образом организующих взаимодействие) "бил бы палкой".
Но я не сисадмин и сам 1С-ник :)))

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

где строка соединения равна например

http://localhost:5984/documents/b5a1b704-dd49-11e1-b509-e70be848db45/libcurl.dll?rev=5-9b34313f006c1c2edadf40ff8a0368c3

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

http://localhost:5984/documents/b5a1b704-dd49-11e1-b509-e70be848db45/libcurl.dll?rev=5-b5a1b704dd4911e1b509e70be848db45

Т.е. перезаписать саму библиотеку libcurl.dll

34. hrip 214 07.08.12 14:45 Сейчас в теме

(31) EmpireSer, Файл (например libcurl.dll) лежит на диске и чтобы его записать какими нибудь "левыми" средствами в базу надо как минимум знать id (b5a1b704-dd49-11e1-b509-e70be848db45), текущую версию (5-b5a1b704dd4911e1b509e70be848db45) документа СУБД ну и конечно же имя пользователя и пароль для доступа к базе (Транспорт.SetCredentials(ПараметрыСоединения.ИмяПользователя, ПараметрыСоединения.Пароль, 0); )
Если кто то всё это знает то надо бить уже админа за то что делает легкие пароли или пользователей которые не умеют их хранить.
У меня моя сеть защищена снаружи очень хорошо (тут я не волнуюсь). А внутри у меня, ну кроме тех кому положено знать, и не слышали таких слов как CouchDB, NoSQL, PUT или GET запросы и т.д.
Поэтому минимума защиты "от дурака" мне хватает.

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 с возможностью какой либо модификации данных)

39. hrip 214 07.08.12 15:33 Сейчас в теме

(37) EmpireSer, Ну что могу сказать, при наличии очень секретной информации и таких требований к безопасности вам наверное надо придумывать какие то другие средства для хранения файлов и доступа к ним. Может быть и подойдет данная СУБД после каких либо настроек. Увы я не специалист по безопасности чтобы вам квалифицированно ответить на все вопросы.
Ну если к вам в сеть вломиться специалист который может сделать всё что вы описали, то ему по моему будет пофиг что ломать CouchDB, MS SQL или файловую 1С

40. pumbaE 07.08.12 15:45 Сейчас в теме

(39) в couchdb вы можете настроить только доступ к базе. К отдельным документам к сожалению нет, соответственно для контроля надо делать трехзвенку...

42. hrip 214 07.08.12 16:00 Сейчас в теме

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

101. babys 90 23.08.12 17:00 Сейчас в теме

(39) ну к примеру я пользую для этого 8.2z & Clarion 6. Пусть прочитают что-нибудь :)

16. EmpireSer 07.08.12 11:05 Сейчас в теме

(14) salexdv, ну так Вам повезло, что Вы получили скорость обращения к файлам в БД быстрее, чем к диску.
Если серьёзно отнестись к системе хранения в файловом варианте, то можно получить потрясающие скорости. По сути это тоже самое, что оптимизация БД, т.к. если вдаться в дебри низкоуровневого хранения данных в БД, то мы напоримся на те же проблемы файлового доступа. Просто файлов меньше и они "жирнее", но сама БД хранит в них и бинарные данные файлов и свои журналы, метаинформацию и т.п., БД так же сталкиваются с фрагментацией, дают свои накладные расходы на организацию поиска.
Лично я для такой задачи оптимизировал бы сам сервер с файлами, отключил бы избыточность и т.п.

А про http - то я не зря спросил про сеть, т.к. я не понял как организуется получение файла из БД.
Тут файл на клиент передаёт сама БД по http или через сервер 1С?

20. mr zafod 23 07.08.12 11:31 Сейчас в теме

(16) EmpireSer, Вы видели в работе, например, связку nodeJS + mongoDB (или + CouchDB или +Redis)? Скорость отдачи статики просто колоссальна. NoSQL - идеальное хранилище для документов, музыки, видео и тд. Если же Вы хотите делать сложные агрегации или выборки с условиями и join'ми - то NoSQL проигрывает обычным реляционным SQL базам данных.

2. mkostya 30 06.08.12 20:52 Сейчас в теме

Это пять, как раз сегодня об этом думал... ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО, за то что выкладываете такие вещи это опыт и время... вообщем бегу пилить под себя)))

5. mr zafod 23 07.08.12 07:25 Сейчас в теме

Когда выбирали NoSQL хранилище, почему склонились именно к Couch? MongoDB не пробовали?

6. hrip 214 07.08.12 07:56 Сейчас в теме

(5) mr zafod, Читал про него, но не пробовал. В плане надежности они приблизительно одинаковые. Работать СУБД будет в режиме очень низкой нагрузки, поэтому производительность тут не критична. Мне понравилась идея с доступом по http протоколу, да и консоль администрирования удобная.

105. Silenser 612 04.02.16 10:57 Сейчас в теме

(6) К надежности стоит так же присовокупить наличие квалифицированного специалиста, который сможет в случае падения внешней базы с документами, ее реанимировать. Мой опыт показывает, что в крупных компаниях 1С хранится в MS SQL, наличествует более-менее грамотный спец по MS SQL и купленная лицензия. Установка же новой платформы, по которой найти спеца не так то просто, надежность скорее снизит. Безусловно NoSQL СУБД приспособлены для хранения не реляционных данных, но какие точно плюсы мы получим от подобного решения? Помните, как в дипломах и кандидатских? Научная новизна - дело хорошее, но где экономическое обоснование? ;)

106. hrip 214 08.02.16 14:19 Сейчас в теме

(105) Silenser, Научная новизна - дело не просто хорошее, а очень хорошее т.к. позволяет не просто получать новые знания, но и применять их для решения новых задач. Например для меня это был первый проект с использованием rest интерфейса, а сейчас так или иначе приходится с ним работать в каждом втором проекте.
Экономическое обоснование для каждой задачи будет свое и оно актуально на момент решения задачи. На момент решения задачи и написания этой статьи (3 года назад) ресурсы сервера 1С были очень ограничены, поэтому и решено было хранение документов организовать таким образом. Сейчас же когда на сервере количество оперативной памяти подбирается к 100 Гб., а дисковую измеряем в терабайтах, то размещение и способ хранение данных уже не так критичны. Единственное, я против хранения файлов на диске (хотя в некоторых проектах и приходится так делать) и в самой базе данных (т.к. будет увеличиваться размер бекапов).
По поводу плюсов и минусов данного решения, в комментариях было очень много написано. Повторюсь что данная СУБД бесплатна, довольна проста в администрировании, настройка по инструкции тоже сложностей вызывать не должна, так что какой-то особый специалист здесь и не нужен.
А выбор конечно за Вами :-)
Но по крайней мере Вы теперь точно знаете еще один способ работы с файлами из 1С.

8. salexdv 2358 07.08.12 09:11 Сейчас в теме

Зачетно! А как со скоростью работы такого рещения по сети? Притормаживает на клиентских машинах или нет? Какого размера пробовали передавать на клиентскую машину документы?

9. hrip 214 07.08.12 09:31 Сейчас в теме

(8) salexdv, Скорости хватает - приблизительно так же как и при копировании файлов по сети. Пробовал передавать файлы до 40 Мб. Средний размер файла у меня 1-10Мб. И передаются по сети (загружаются в СУБД или открываются) в среднем 1-5 сек. (зависит от размера файла, загруженности сервера).

11. pumbaE 07.08.12 09:44 Сейчас в теме

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

17. pumbaE 07.08.12 11:12 Сейчас в теме

Использую сервер ftp для таких случаев.

24. EmpireSer 07.08.12 13:07 Сейчас в теме

Вот если бы NoSQL базы могли работать как "чистая ОС" или создавали свою файловую архитектуру на жёстком диске (а не использовали ту, что уже размещена на диске), или внедряли свой низкоуровневый драйвер доступа к кластерам ЖД - то я бы даже "не пикнул".
Но тут явная "надстройка" над возможностями тех же серверных ОС. ОС всё равно нужна, так почему не выжить из уже данных ею механизмов максимум?

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,

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

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

И рабочий пример чего? Например этого?

32. EmpireSer 07.08.12 14:37 Сейчас в теме

Отредактировал предыдущий ответ.
Видно я ошибочно предположил, что сама библиотека "libcurl.dll" тоже может приехать к клиенту. А как понял, её использует "CouchDB" "внутри себя" что бы перезаписывать данные?

33. alprk 07.08.12 14:44 Сейчас в теме

Причем здесь libcurl.dll вообще?

35. hrip 214 07.08.12 14:46 Сейчас в теме

(33) alprk, вообще не причем. Это просто файл который попался мне для примера и я его положил в базу и привел для примера строку соединения. Вместо него можно просто вставить ИмяФайла.Расширение

38. AlexO 135 07.08.12 15:23 Сейчас в теме

1. Смысл хранить какие-то данные во внешней базе, если в 1С они не используются никак, кроме как "а вот набор картинок из другой базы"?
2. Смысл доступа к файлам из 1С к какой-то другой базе, если версионирование - все равно в той сторонней базе?
3. Смысл использовать какие-то NoSQL, когда можно организавать новую базу на существующем SQL (не думаете же вы, что все будут затевать с файловой 1С?) и хранить там все, что угодно.
hrip, дайте вразумительные ответы и приведите, пожалуйста, примеры использования такого хранения. Не теоретического.

41. hrip 214 07.08.12 15:53 Сейчас в теме

(38) AlexO, В принципе можно и не хранить данные таким образом. Вариантов много. Можно использовать стандартный механизм 1С (Хранилище доп. информации), можно хранить все файлы в папках, а в 1С хранить только путь к файлу, можно хранить в какой либо базе на SQL сервере.
В моей демо базе не реализована возможность получать версии документов (всегда получается последняя версия), хотя это можно сделать. Я использую такую базу для хранения файлов (подключаюсь к ней из УПП)и если кто то удалил файл случайно я могу его восстановить через консоль администрирования зная id документа в базе (т.е. GUID элемента в 1С). Может попозже дойдут руки и сделаю доступ к версиям из 1С.
За данную СУБД кстати денег платить не надо и она потребляет мало ресурсов (ну по крайней мере в таком режиме работы).
База данных не требует описания данных, как реляционные СУБД. Можно в любом документе СУБД создать любое количество полей и прикрепить любое количество вложений.
Для доступа к данным не нужны никакие драйвера.
Ну и вот здесь (21) уже писал про плюсы использования.
А выбор за вами что использовать, вариантов много.
Я лишь предложил один из них.

53. AlexO 135 08.08.12 10:38 Сейчас в теме

(41)

База данных не требует описания данных, как реляционная СУБД

тогда противоречит

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

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

Можно в любом документе СУБД создать любое количество полей

Прямо уж и любое?

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

Если даже ваша СУБД и использует "свою" FS, то на доступ к ней - нужны драйвера. 1С - это не ОС.

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

вот когда сделаете - поставлю плюс за полезность. А пока - чисто "игрушка" :)

63. hrip 214 08.08.12 11:11 Сейчас в теме

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

64. AlexO 135 08.08.12 11:20 Сейчас в теме

(63)

Для доступа к СУБД не нужны драйвера! использую "WinHttp.WinHttpRequest.5.1".

не мытьем, так катаньем :) Все равно используется пусть и встроенный, но "драйвер" ОС.
Но через HTTP заносить данные - это же жутко долго.. считайте, вы все переводите в текст и передаете в базу...

66. hrip 214 08.08.12 11:39 Сейчас в теме

(64) AlexO, Только что попробовал загрузить файл 30Мб
В CouchDB - 6 Сек.
В расшаренную папку - 4 сек
В хранилище доп информации УПП (крутиться на MS SQL) - 11 сек.
Хотя конечно это тоже всё относительно.

68. AlexO 135 08.08.12 11:50 Сейчас в теме

(66)

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

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

В CouchDB - 6 Сек.
В расшаренную папку - 4 сек

да, тут я с вами полностью согласен:
(60) AlexO,

разницы не будет ни в какой СУБД - FS сама по себе "оптимизированная СУБД" для хранения файлов, и в худшем для FS случае - разницы не будет никакой.

69. hrip 214 08.08.12 11:52 Сейчас в теме

(68) AlexO, Стандартный механизм 1С для хранения файлов без изобретения всяких "велосипедов"

70. AlexO 135 08.08.12 11:56 Сейчас в теме

(69)
нет, я не про это - а про саму концепцию обработки данных в 1С.
Вот тут Приложение к публикации: "Давайте забудем о свертке БД?" hogik описал подробно, плюс качественные комменты.

71. hrip 214 08.08.12 13:11 Сейчас в теме

(70) AlexO, Обязательно почитаю.
А собственно из-за чего всё и затевалось то. У нас есть возможность использовать для хранения 2 варианта -это стандартный 1С и свои "костыли".
А костыли могут быть минимум 3-х видов:
1. Файлы на диске, а в базе пути к файлам;
2. SQL СУБД;
3. NoSQL СУБД.
Причины по которым я выбрал CouchDB я уже описывал.
Я нигде не пытался доказать, что это самое лучшее из всех решений и эта СУБД обладает самым максимальным быстродействием.
Данное решение позволяет довольно удобно работать с файлами, оно не очень сложно в реализации (самая большая сложность была - это написать парсер JSON)и скорость работы больше чем у стандартных механизмов 1С (указываю сразу, что я не делал контрольных примеров с хранением файлов напрямую на дисках или хранением в SQL СУБД и соответственно не замерял их производительность).
Ну а использовать данное решение или нет - это личное дело каждого.
Как минимум полезно знать что есть NoSQL СУБД, какими возможностями они обладают, и как с ними можно работать.

87. gaglo 09.08.12 10:51 Сейчас в теме

(71)

Как минимум полезно знать что есть NoSQL СУБД, какими возможностями они обладают, и как с ними можно работать.

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

88. hrip 214 09.08.12 11:17 Сейчас в теме

(87) gaglo, А я по моему границы применимости и круг задач не пытался описать, я показал вариант применения данной СУБД для решения конкретной задачи.

"почему и эту СУБД тоже можно использовать в этой задаче"

Так же можно сказать и обо всех остальных СУБД. Их все тоже можно использовать для решения задачи хранения файлов.
А для вас что является критерием выбора СУБД (применительно к этой задаче)?

89. gaglo 10.08.12 08:48 Сейчас в теме

(88) ...я чувствую непонимание меня собеседником... Попробую объясниться.

А я по моему границы применимости и круг задач не пытался описать

Я это заметил. Я считаю отсутствие этого - недостатком статьи.

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

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

...есть возможность использовать для хранения 2 варианта - это стандартный 1С и свои "костыли".
А костыли могут быть минимум 3-х видов...

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

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

лично я ответа не заметил.
А без этого - статья выглядит безликой новостью, каких полно на всяких порталах. "Есть вот такая программа, она может вот что...". Безусловно похвально вложение личного опыта: "Я попробовал, она действительно может!" Не могу одобрять отсутствие аналитической части вида "Она может то-то и то-то, что у таких-то её конкурентов не получается или выходит хуже..."
И получается: минусовать статью не за что. А плюсовать неохота...

94. hrip 214 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. Продолжать не буду...

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 214 08.08.12 13:20 Сейчас в теме

(72) EmpireSer, Я же написал что всё относительно т.к. шара на которую копировал, CouchDB и 1C сервер - это разные машины.
Ну я и вроде данный проект не предполагает использовать СУБД в режиме, когда будут совершаться десятки тысяч транзакций в секунду.
Файлы на сервер передаются методом PUT.

43. LelikOFF 08.08.12 00:37 Сейчас в теме

Неоднократно вставала проблема хранения документов сканов и прочего в базе, нужно попробовать
спасибо за статью

44. CheBurator 2712 08.08.12 01:44 Сейчас в теме

так, ту нарисовались апологеты теневого копирования... может кто-нибудь мне объяснит чем достигается целостность данных и НЕОСТАНОВ базы при теневом копировании когда копируемый файл пишется на диск - с ним активно работает база данных - в это же время выполянется теневое копирование...?
.
внятного ответа на вышеобозначенные вопросы - я не нашел...

50. pumbaE 08.08.12 09:38 Сейчас в теме

(44) CheBurator, а где тут обсуждалось про теневое копирование? В CouchDB отдельный процесс реплицирует данные на другой сервер. При этом ответственность за проверку окончания транзакции возложена на клиента, т.е. то что мы POST запросом отправили в базу документ(с файлом или без) и сервер ответил OK, не означает что транзакция завершилась успешно. Клиент должен дополнительно проверить, записался ли этот документ или нет...

52. hrip 214 08.08.12 10:26 Сейчас в теме

(50) pumbaE, Я думаю т.к. http сервер встроен в СУБД, то он возвращает ответ уже после завершения транзакции (удачного или нет) и никаких доп проверок не надо. т.е. ответа сервера достаточно

54. aspirator23 339 08.08.12 10:39 Сейчас в теме

(52)
1.Есть ограничение на размер базы данных? Размер одиночно загруженного файла?
2.Можно ли провести сравнение скорости загрузки очень больших файлов в базу?
Например: загрузить файл размером 1Гб в СУБД и просто скопировать этот же файл в каталог лежащий там где и СУБД. Это не с целью покритиковать, а с целью оценить скорость работы этого варианта для себя.

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

я так не думаю, но спорить с вами не стану.

62. AlexO 135 08.08.12 11:08 Сейчас в теме

(61) djd.sf,

я так не думаю, но спорить с вами не стану.

не путайте обработку данных и запись-чтение на хранение.
Или думаете, что доступ к "собственной" FS у какого-то CouсhDB будет быстрее и лучше, чем у коммерческих ОС? Своя FS введена туда единственно из-за удобства использования для себя "как хочу, так и верчу".

65. hrip 214 08.08.12 11:32 Сейчас в теме

(62) AlexO, Я согласен что от железа, ОС и ФС очень много зависит, надо сравнивать производительность СУБД на одинаковом оборудовании, сравнивать одинаковые операции
Но и задача под которую я предлагаю использовать СУБД не требует большого быстродействия.

67. hrip 214 08.08.12 11:50 Сейчас в теме

(54) aspirator23, Из клиента 1С грузятся файлы размером до 100 Мб. Если больше то ругается на нехватку памяти. А в саму СУБД грузил и по 500Мб через консоль.
Про сравнение скорости я только что написал в (66)

59. AlexO 135 08.08.12 10:49 Сейчас в теме

(52)

http сервер встроен в СУБД

на скорость работы и качество контроля записи "встроенность" http-сервера не влияет - разве что только отсутствует необходимость "подвязки" стороннего http-сервера.
А так - это сродни тому, как если рассуждать "где быстрее команда выполнится - когда задать её через консоль или по красявому интерфейсу?"

58. AlexO 135 08.08.12 10:46 Сейчас в теме

(50) pumbaE,

а где тут обсуждалось про теневое копирование? В CouchDB...

это не про CouchDB, а ответ на посты (4) и (10), начатые
(4) babys,

на win серверах есть теневое копирование, это бекап без освобождения файла.

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

А что, в SQL не так?

55. AlexO 135 08.08.12 10:39 Сейчас в теме

(44) CheBurator,

и НЕОСТАНОВ базы при теневом копировании когда копируемый файл пишется на диск

теневое копирование - вообще тормоза жуткие, по-крайней мере, в реализации Microsoft :)
В Линухе оно аналогичное как-то более человечно...

102. babys 90 23.08.12 17:10 Сейчас в теме

(44) CheBurator, теневое копирование выполняется независимо от захвата файла другими приложениями, соответственно никакого транзакционного действа оно не проверяет. Я думал, что такие вещи нет необходимости Вам объяснять :)
При работе с конторами, типа Директор+Бухгалтер = ООО, конечно никакого скуля, никаких админов и т.п., поэтому теневое копирование, ночью когда все спят, это наше ФСЁ ;)

45. realm 08.08.12 03:00 Сейчас в теме

Спасибо автору за классный вариант решения проблемы хранения файлов с удобным доступом из 1С. От постоянных добавлений "сканов" документов база пухнет чрезмерно. Давно подумывал над вариантами "исключения" не объектов 1С из основной базы. Хранить файлы в одном хранилище/базе намного удобнее, чем иметь десятки и сотни тысяч файлов, которые и бэкапить-то неудобно.

56. AlexO 135 08.08.12 10:39 Сейчас в теме

(45) realm,

От постоянных добавлений "сканов" документов база пухнет чрезмерно.

Храните в ОС и давайте ссылки на файлы. Делов-то.

46. aspirator23 339 08.08.12 07:29 Сейчас в теме

У MS SQL есть возможность хранить большие файлы в filestream. Рассматривалась эта возможность для хранения?
Сам столкнулся с необходимостью хранения больших файлов. Выбираю вариант хранения.
Предложенное автором решение интересно, поэтому хотелось бы рассмотреть его в сравнение с filestream.

47. hrip 214 08.08.12 07:59 Сейчас в теме

(46) aspirator23, Нет такую возможность не рассматривал.
Я уже выше писал почему выбрал данную СУБД:
1. Надежность (ну по крайней мере по отзывам);
2. Скорость поиска и отдачи данных клиенту;
3. Доступ по http без использования драйверов;
4. Нет необходимости создавать в БД таблицы и при необходимости смогу к любому документу базы данных добавить любое количество полей;
5. Версионирование документов БД;
6. Удобное администрирование;
7. Денег платить не надо;
8. Ну и очень интересно было изучить что такое NoSQL.

57. AlexO 135 08.08.12 10:43 Сейчас в теме

(47)

4. Нет необходимости создавать в БД таблицы и при необходимости смогу к любому документу базы данных добавить любое количество полей;

чудес не бывает. Если у вас автоматом добавляется "неограниченное" количество полей (в чем я тоже сомневаюсь - понятие "неограниченное" не относится к используемому в системах хранения данных), то редактировать/удалить - тоже без задействовования интерфейса администрирования?

48. karakozov 08.08.12 08:47 Сейчас в теме

Данный материал несомненно полезный, по крайне мере есть еще одно решение для хранения файлов и документов в ИБ.Есть решение конечно такое как Хранилище, но задачи бывают разные.Взято на заметку. Плюс автору.

49. Gandalf Белый 08.08.12 08:57 Сейчас в теме

Большое спасибо автору статьи! Было очень интересно ознакомиться с подобным решением, т.к. за NoSQL базы услышал впервые и раньше с ними не работал.

51. mezzoforte 08.08.12 10:24 Сейчас в теме

Интересно, спасибо за статью.

74. OBEH 08.08.12 14:09 Сейчас в теме

Кто-нибудь пробовал хранить данные в самой MS SQL базе?
Не там, где лежат данные баз 1С, а в отдельной таблице.
Ведь, если есть в конторе MS SQL то зачем еще использовать
какую-то другую СУБД.
Тем более, для простого хранения и вынимания файлов.

75. AlexO 135 08.08.12 15:26 Сейчас в теме

(74) OBEH,
а что пробовать, берите и храните.

76. OBEH 08.08.12 16:52 Сейчас в теме

(75) Хорошо. А пример этого самого хранения есть?

77. AlexO 135 08.08.12 17:02 Сейчас в теме

(76) OBEH,
примеры записи в SQL есть здесь на сайте.

78. KroVladS 35 08.08.12 17:32 Сейчас в теме

(76) OBEH,
http://infostart.ru/public/74821/
http://infostart.ru/public/67205/
http://infostart.ru/public/77329/

Выбирай какой больше нравиться...
Всё для MS SQL.

79. OBEH 09.08.12 03:13 Сейчас в теме

(78) KV1s, сбасибо!

80. OBEH 09.08.12 03:49 Сейчас в теме

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

81. KroVladS 35 09.08.12 08:38 Сейчас в теме

(80) OBEH,
Под PostgreSQL ни один из вариантов у меня к сожелению не получилось запустить нормально :(

82. AlexO 135 09.08.12 09:34 Сейчас в теме

(80) OBEH,

Кто-нибудь пробовал хранить данные в самой MS SQL базе?

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

крупно ошиблись... :)

97. KroVladS 35 16.08.12 11:58 Сейчас в теме

(80) OBEH, (81) KV1s,
С PostgreSQL разобрался вот обсуждение

83. alprk 09.08.12 09:44 Сейчас в теме

Я не понимаю зачем использовать CouchDB для хранения файлов. Но если задачу можно свести к алгоритму Map-Reduce, то стоит заморочиться, давно планирую такое мероприятие, именно с CouchDB.

84. hrip 214 09.08.12 10:02 Сейчас в теме

(83) alprk, Функция MAP там и так используется. А зачем использовать именно CoucDhB (по крайней мере я так считаю) я уже писал здесь (21) и здесь (47).