Хранение файлов в NoSQL СУБД CouchDB
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
"...а мы упрямы..."
несогласие с вашим мнением это есть упрямство?
Попробую подробно ответить на ваши вопросы.
Текущий размер используемой базы 8Гб, документов в СУБД 1700, Средний размер хранимого файла 1-10Мб. Сколько всего файлов в базе я не считал.
О том что проект невысоконагруженный я уже писал, т.е. частота обращений очень низкая и такими параметрами как частота обращений можно пренебречь (обычная база 1с - 100 пользователей, работа с файлами - это не основная работа).
Чем отличаются сканы от конструкторской и технологической документации? Ничем кроме расширений файлов! т.е. в УПП к элементам справочников "Номенклатура", "Спецификации номенклатуры", "Технологические карты производства" прикреплены описание тех. процессов , инструкции, паспорта, чертежи и т.д.
"скоро NoSQL захватит мир))"
это вообще чье то личное мнение в комментариях, которое никак не отражено ни в моей статье, ни в статье на которую я ссылаюсь.
В CouchDB действительно обновляется весь документ и это сказывается на размере базы и времени его обновления. Но в данном случае речь не идет о высокопроизводительном web сервере где совершаются тысячи или десятки тысяч транзакций в секунду.
Почему не хранить файлы просто на диске в файловой системе я писал уже.
Если хранить файлы в непосредственно в базе ("Хранилище дополнительной информации"), то начнет увеличиваться размер базы и бекапов. Об этом я тоже писал.
Про какую то альтернативную авторизацию я и не писал. я писал о том что СУБД поддерживает авторизацию по логину и паролю и для данной задачи этого вполне достаточно. И если кому то нужно устанавливать права на файлы, то я писал что в СУБД вместе с файлами можно сохранять любую доп. информацию, с которой потом как то будет можно работать (у меня это не реализовано в демо базе).
О том что СУБД быстрее файловой системы я вообще не писал! Где вы это взяли?
"для данной задачи надо обойтись без СУБД"
это ваше мнение. Я вас не заставляю использовать мое решение!
"Не должно множить сущее без необходимости" (с) Оккам.
Ну насчет надежности хранения файлов в СУБД вы наверное спорить не будете. Версионирование тоже штука полезная.
В данной СУБД не требуется проектировать структуру базы (таблицы, хранимые процедуры, триггеры) и для данной задачи очень подходит.
Для того чтобы внедрить и использовать мое решении требуется максимум минут 30: это установить саму СУБД, написать пару простеньких функций, объединить конфигурацию демо базы со своей и вывести на формы нужных объектов кнопки для открытия списка файлов.
Причем тут без разницы какую вы СУБД используете (MS SQL, PostgreSQL, Oracle), или вообще у вас файловая база - работать будет везде. Затрачиваться на покупку ПО тоже не надо.
Это в дополнение к тому что я уже писал о плюсах использования данной СУБД.
(96) ...вы обиделись? Напрасно!
На нашей фирме есть похожая задача. Фирма торгует электротехнической продукцией. Поставщики предоставляют нам сертификаты на свою продукцию, мы по требованию покупателей снабжаем их копиями сертификатов. Для этого сканы сертификатов привязаны к номенклатуре. Каждый сертификат накрывает много номенклатурных позиций, всего сканов около 400. Новый сертификат - явление редкое, скажем, раз в полгода. Обращения на чтение - несколько раз в неделю. Сканы хранятся просто в файловой системе, а в 1С - полные имена файлов.
Внедрение решения заняло когда-то минут 20, насчет надежности - ни один сертификат не пропадал и не повреждался неведомым врагом, бэкап делается пофайлово, затрат на покупку чего-нибудь вроде ПО не несли, всё и так работает. Версионированием в данном случае и не пахнет, так оно и не требовалось.
Заметив статью, сначала подумал, что в своё время мы что-то прощёлкали... Прочитав, и поучаствовав в обсуждении - больше так не думаю.
Слово "упрямы" я отношу не к несогласию с моим мнением, но к неумению - или нежеланию - отстаивать своё.
Вот возьмем чисто (96).
Простите, не понял. Как в этом случае документы соотносятся с файлами? Видимо, это не одно и то же, ибо одних 1700 - а других не счесть.
Не выдавать военной тайны! Раз в месяц или раз в столетие... (Видно, что подробный ответ может быть неконкретным...)
1С тоже поддерживает авторизацию "по логину и паролю". Я считаю её основной. Потому что 1С в данном случае - основная система. Если во внешней СУБД есть другой логин и другой пароль - это будет вторая авторизация. Альтернативная!
Смотрим в (21) "плюсы данного решения: ... 4. Скорость поиска данных в базе и их отдача у NoSQL СУБД очень высокая". Каюсь, домыслил. Потому что не представляю "плюсы решения вообще", а только плюсы "данного решения по сравнению с другими". А с какими другими? Наверное... Вы и сами знаете - я про костыль №1. Но иначе, извините, не понимаю.
Ну да. Но мог бы убедить. Но не смог. Или не захотел. Я вообще-то про себя думаю, что убедить меня можно. Но убедительными доводами. Хотя бы внешне убедительными.... Не сложилось.
В любом случае благодарю за потраченное на меня время.
На нашей фирме есть похожая задача. Фирма торгует электротехнической продукцией. Поставщики предоставляют нам сертификаты на свою продукцию, мы по требованию покупателей снабжаем их копиями сертификатов. Для этого сканы сертификатов привязаны к номенклатуре. Каждый сертификат накрывает много номенклатурных позиций, всего сканов около 400. Новый сертификат - явление редкое, скажем, раз в полгода. Обращения на чтение - несколько раз в неделю. Сканы хранятся просто в файловой системе, а в 1С - полные имена файлов.
Внедрение решения заняло когда-то минут 20, насчет надежности - ни один сертификат не пропадал и не повреждался неведомым врагом, бэкап делается пофайлово, затрат на покупку чего-нибудь вроде ПО не несли, всё и так работает. Версионированием в данном случае и не пахнет, так оно и не требовалось.
Заметив статью, сначала подумал, что в своё время мы что-то прощёлкали... Прочитав, и поучаствовав в обсуждении - больше так не думаю.
Слово "упрямы" я отношу не к несогласию с моим мнением, но к неумению - или нежеланию - отстаивать своё.
Вот возьмем чисто (96).
документов в СУБД 1700.... Сколько всего файлов в базе я не считал.
Простите, не понял. Как в этом случае документы соотносятся с файлами? Видимо, это не одно и то же, ибо одних 1700 - а других не счесть.
частота обращений очень низкая
Не выдавать военной тайны! Раз в месяц или раз в столетие... (Видно, что подробный ответ может быть неконкретным...)
Про какую то альтернативную авторизацию я и не писал. я писал о том что СУБД поддерживает авторизацию по логину и паролю
1С тоже поддерживает авторизацию "по логину и паролю". Я считаю её основной. Потому что 1С в данном случае - основная система. Если во внешней СУБД есть другой логин и другой пароль - это будет вторая авторизация. Альтернативная!
О том что СУБД быстрее файловой системы я вообще не писал! Где вы это взяли?
Смотрим в (21) "плюсы данного решения: ... 4. Скорость поиска данных в базе и их отдача у NoSQL СУБД очень высокая". Каюсь, домыслил. Потому что не представляю "плюсы решения вообще", а только плюсы "данного решения по сравнению с другими". А с какими другими? Наверное... Вы и сами знаете - я про костыль №1. Но иначе, извините, не понимаю.
Я вас не заставляю использовать мое решение!
Ну да. Но мог бы убедить. Но не смог. Или не захотел. Я вообще-то про себя думаю, что убедить меня можно. Но убедительными доводами. Хотя бы внешне убедительными.... Не сложилось.
В любом случае благодарю за потраченное на меня время.
(98) gaglo, Так я и не пытался убедить вас использовать именно это решение. Я вам о нем рассказал и привел доводы в его пользу. Вас они не устроили - не используйте. Вам например больше нравится файлы хранить на диске в ФС, а я считаю это решение в принципе неправильным. А то что у вас до сих пор все файлы целые - так это же замечательно.
Данная СУБД - документо-ориентированная (здесь нет таблиц) и то что в реляционной СУБД назвали бы строкой таблицы здесь называется документ. Документ может содержать какое-то(к слову какое-то не придираемся - не высчитывал максимальное количество полей и вложений одного документа) количество полей и вложений (файлов).
в предыдущем комментарии писал что таким параметром как частота обращений можно пренебречь. Если интересует конкретно, то к файлу могут и раз 20 (может и больше) в день обратиться, а могут и раз в месяц.
Это взято из общей информации по NoSQL - конкретно не замерял и соответственно цифру не назову.
Я считаю что для хранения файлов удобно использовать мое решение, кто-то считает что надо использовать те СУБД на которых уже крутятся базы 1С, вы считает что надо хранить в ФС. Так что каждый выберет то что считает правильным. По крайней мере вы уже знаете что есть еще один способ хранить файлы.
Как в этом случае документы соотносятся с файлами? Видимо, это не одно и то же, ибо одних 1700 - а других не счесть.
Данная СУБД - документо-ориентированная (здесь нет таблиц) и то что в реляционной СУБД назвали бы строкой таблицы здесь называется документ. Документ может содержать какое-то(к слову какое-то не придираемся - не высчитывал максимальное количество полей и вложений одного документа) количество полей и вложений (файлов).
Не выдавать военной тайны! Раз в месяц или раз в столетие... (Видно, что подробный ответ может быть неконкретным...)
в предыдущем комментарии писал что таким параметром как частота обращений можно пренебречь. Если интересует конкретно, то к файлу могут и раз 20 (может и больше) в день обратиться, а могут и раз в месяц.
Скорость поиска данных в базе и их отдача у NoSQL СУБД очень высокая
Это взято из общей информации по NoSQL - конкретно не замерял и соответственно цифру не назову.
Я считаю что для хранения файлов удобно использовать мое решение, кто-то считает что надо использовать те СУБД на которых уже крутятся базы 1С, вы считает что надо хранить в ФС. Так что каждый выберет то что считает правильным. По крайней мере вы уже знаете что есть еще один способ хранить файлы.
