Группа: Основатель
Сообщений: 13982
Из: Киев
Спасибо сказали: 4549 раз
Рейтинг: 3678.1
У нас сейчас договора хранятся в специальном каталоге на сервере, не в базе данных. Делалось давно, не нашей командой. Почему так сделано, могу только предположить. Полагаю, чтобы не увеличивать размер базы. На данный момент этот каталог занимает 35 Гб. Я лично не считаю, что это очень много и что это как-то будет влиять на производительность системы. Если ещё сделать по уму - то тем более. А вот минус этого дела таков, что случались жалобы от пользователя, мол раньше был скан договора у клиента, а сейчас нету. Смотрим, файла на сервере нету. Был он там или нет - фиг знает. И если, например, база куда-то переезжает, то надо не забывать таскать за собой этот каталог.
Группа: Местный
Сообщений: 2908
Из: Київ, Україна
Спасибо сказали: 1159 раз
Рейтинг: 1244.5
Из-за уменьшения производительности сервера базы данных, производительности программы (надо и помещать, и извлекать), понижения показателей целостности и сохранности (в случае сбоя, например), ухудшения мобильности, повышения сложности администрирования...
Допрацьовую: - "Бухгалтерія для України 2.1"; - "Альфа-Авто: Автосалон+Автосервіс+Автозапчастини, українська версія".
А вот минус этого дела таков, что случались жалобы от пользователя, мол раньше был скан договора у клиента, а сейчас нету. Смотрим, файла на сервере нету. Был он там или нет - фиг знает.
в правах на папку убрать галку "Удаление", и проблема решена.
Встречалась мне база на 18 гб файловая, в неё загружались скан копии сертификатов продукции, на каждую партию. Летала на ура, даже не притормаживала. Я бы хранил вне базы, объяснить затрудняюсь, но что-то мне стрёмно такой объем лить в базу. Кстати, старые сертификаты в базе можно и удалить, а старые договора вряд ли...
Группа: Местный
Сообщений: 630
Спасибо сказали: 168 раз
Рейтинг: 133.4
Acid @ Сегодня, 14:01 , Та же проблема стоит, только с чертежами и дизайн-макетами. Склоняюсь к внешнему хранению, а в базе только линки (импорт в каталог через рубрикатор с преобразованием имени файла.). Почему?
Цитата(Егор Динин @ 17.03.16, 15:38)
объяснить затрудняюсь, но что-то мне стрёмно такой объем лить в базу
#define private public enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day
Группа: Основатель
Сообщений: 13982
Из: Киев
Спасибо сказали: 4549 раз
Рейтинг: 3678.1
Цитата(Petre @ 17.03.16, 14:41)
Из-за уменьшения производительности сервера базы данных
За счет чего?
Цитата(Petre @ 17.03.16, 14:41)
производительности программы (надо и помещать, и извлекать)
А помещать с сервера на клиент и извлекать обратно, в случае с файловым каталогом, не надо что ли?
Цитата(Petre @ 17.03.16, 14:41)
понижения показателей целостности и сохранности (в случае сбоя, например)
Опять таки, не обижайтесь, но как по мне, это аргумент высосан из пальца. То же самое можно сказать про файловую систему. Кстати, про то, что надо делать регулярные бэкапы базы - про это многие знают. В случае с файловым хранилищем нужно дополнительно организовать и мониторить и его бэкапы.
Цитата(Petre @ 17.03.16, 14:41)
ухудшения мобильности
За счет чего? Дольше файлик куда-то копироваться будет? Ну так каталог тоже, если что, перемещать нужно.
Цитата(Petre @ 17.03.16, 14:41)
повышения сложности администрирования
За счет чего? Как по мне, то повышение сложности администрирования относится к минусам отдельного файлового каталога.
Короче говоря, я лично, не могу принять не одного из аргументов выше.
Цитата(Acid @ 17.03.16, 15:12)
в правах на папку убрать галку "Удаление", и проблема решена.
Группа: Местный
Сообщений: 630
Спасибо сказали: 168 раз
Рейтинг: 133.4
Цитата(Vofka @ 17.03.16, 16:41)
А помещать с сервера на клиент и извлекать обратно, в случае с файловым каталогом, не надо что ли? ... За счет чего? Дольше файлик куда-то копироваться будет? Ну так каталог тоже, если что, перемещать нужно.
Ссылки ведь на единое файловое хранилище, значит меньше надо восстанавливать данных по объёму. Копии базы надо делать часто, для разработки или поддержки франчем.
#define private public enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day
Если линковать, то такой каталог в конечном итоге станет файло-помойкой. хрен там что найдешь. Строить структуру каталогов, другое дело. Это будут и Сертификаты, и Договора, и прочие сопутствующие документы. Объем получится не слабый. Хранить в базе меня останавливает следующий момент - если база "сбойнет", то фиг восстановишь. Потому что хранится в сжатом виде и в двоичных данных. В обоих методах по плюсам/минусам практически паритет. Чешу репу...
Страховиков никто не обслуживает? как там реализовано?
Цитата(Vofka @ 17.03.16, 16:42)
Удалять тоже надо иметь возможность, если что
Историю надо хранить. Переместить в папку "Устаревшие", например.
Группа: Основатель
Сообщений: 13982
Из: Киев
Спасибо сказали: 4549 раз
Рейтинг: 3678.1
andr_andrey, возможно. Но это в теории так. То есть на практике, на самом деле, если целенаправленно замерять, то копирование/разворачивание базы будет происходить дольше из-за её объёма. Спору нет. Но на практике, вероятно, это вообще не проблема. Ну то есть я принимаю тот плюс, что база будет меньше (со всеми вытекающими), но в реальной жизни это, как по мне, не шибко большой плюс при сегодняшнем железе.
Цитата(Acid @ 17.03.16, 16:54)
Хранить в базе меня останавливает следующий момент - если база "сбойнет", то фиг восстановишь.
А то, что кроме сканов договоров будет ещё и куча другой информации потеряно - это не проблема?
Цитата(Acid @ 17.03.16, 16:54)
Историю надо хранить. Переместить в папку "Устаревшие", например.
Наверное. Но это все организовывать как-то надо. Мы, 1С-ники, хотим просто заходить в журнал регистрации и смотреть кто что менял.
Группа: Местный
Сообщений: 2908
Из: Київ, Україна
Спасибо сказали: 1159 раз
Рейтинг: 1244.5
Цитата(Vofka @ 17.03.16, 16:42)
За счет чего?
За счет манипулирования избыточными данными. Ведь, по-сути, нам не нужны ни итоги, ни статистика, ни индексация. Это просто двоичные данные, которые в момент их использования все равно превращаются в файлы.
Цитата(Vofka @ 17.03.16, 16:42)
А помещать с сервера на клиент и извлекать обратно, в случае с файловым каталогом, не надо что ли?
В случае хранения в ИБ - надо в любом случае. В случае хранения как файлы - не всегда (зависит от варианта использования). Т.е. "хуже не будет, но может быть лучше")))
Цитата(Vofka @ 17.03.16, 16:42)
Опять таки, не обижайтесь, но как по мне, это аргумент высосан из пальца. То же самое можно сказать про файловую систему. Кстати, про то, что надо делать регулярные бэкапы базы - про это многие знают. В случае с файловым хранилищем нужно дополнительно организовать и мониторить и его бэкапы.
Согласитесь, когда к файловым операциям (которые тоже не стабильны) добавляются преобразования туда-обратно средствами 1с и сам способ хранения, то простым арифметическим перемножением условных коэффициентов нестабильности получаем меньший итоговый коэффициент, чем в варианте файлового хранения.
Цитата(Vofka @ 17.03.16, 16:42)
За счет чего? Дольше файлик куда-то копироваться будет? Ну так каталог тоже, если что, перемещать нужно.
В данном случае у нас, например, организовано так: отдельный сервер БД, отдельный файловый сервер. Именно это и имел ввиду.
Цитата(Vofka @ 17.03.16, 16:42)
За счет чего? Как по мне, то повышение сложности администрирования относится к минусам отдельного файлового каталога.
Например, перенос базы по любой причине (переезд, копирование для тестирования, резервирование, хранение резервных копий ...). Проще и быстрее работать с 10 гиг, чем с 100.
Если работать над недостатками файлового варианта, то, по моему мнению, стоит уделить внимание хорошему программному менеджеру работы с файлами.
Допрацьовую: - "Бухгалтерія для України 2.1"; - "Альфа-Авто: Автосалон+Автосервіс+Автозапчастини, українська версія".
Группа: Основатель
Сообщений: 13982
Из: Киев
Спасибо сказали: 4549 раз
Рейтинг: 3678.1
Цитата(Petre @ 17.03.16, 17:24)
За счет манипулирования избыточными данными. Ведь, по-сути, нам не нужны ни итоги, ни статистика, ни индексация. Это просто двоичные данные, которые в момент их использования все равно превращаются в файлы.
За счет какого манипулирования? Можете привести конкретный пример о чем речь, потому что не понимаю.
Цитата(Petre @ 17.03.16, 17:24)
В случае хранения в ИБ - надо в любом случае. В случае хранения как файлы - не всегда (зависит от варианта использования)
Опять таки, не понятно. Приведите пример варианта использования, когда будет лучше.
Цитата(Petre @ 17.03.16, 17:24)
Согласитесь, когда к файловым операциям (которые тоже не стабильны) добавляются преобразования туда-обратно средствами 1с и сам способ хранения, то простым арифметическим перемножением условных коэффициентов нестабильности получаем меньший итоговый коэффициент, чем в варианте файлового хранения.
В теории так, согласен. Но давайте смотреть на вещи реально, а не с точки зрения "теоретиков". Вы или кто-то из круга ваших знакомых программистов, когда-нибудь сталкивались с проблемой, когда были бы заметны проявления этой теории?
Цитата(Petre @ 17.03.16, 17:24)
Например, перенос базы по любой причине (переезд, копирование для тестирования, резервирование, хранение резервных копий ...). Проще и быстрее работать с 10 гиг, чем с 100.
С этим я согласен. Но. Вряд-ли соотношение сканов к остальной информации базе будет 90% на 10%. То есть, если база большая, то скорее всего сканы это не основной её объем. А посему будет ли реально какой-то действительный профит от копирования 100 Гб по сравнению пусть с 70 Гб? Как по мне, то профита особо никакого.
Группа: Местный
Сообщений: 2908
Из: Київ, Україна
Спасибо сказали: 1159 раз
Рейтинг: 1244.5
Цитата(Vofka @ 17.03.16, 17:42)
Вряд-ли соотношение сканов к остальной информации базе будет 90% на 10%.
Если говорить о сжатых данных (резервное копирование средствами СУБД или выгрузка средствами 1с), то чаще всего это будет даже больше 90%.
Цитата(Vofka @ 17.03.16, 17:42)
Но давайте смотреть на вещи реально, а не с точки зрения "теоретиков". Вы или кто-то из круга ваших знакомых программистов, когда-нибудь сталкивались с проблемой, когда были бы заметны проявления этой теории?
Честно говоря, на практике чаще всего проблемы производительности решаются не применением знаний по оптимизации и толкового администрирования, а решением "в лоб" - покупкой дополнительного железа и установкой (почти всегда без лицензий) дополнительного софта. И это печально. Хотя стоит признать, это - тоже вариант решения проблемы.
Цитата(Vofka @ 17.03.16, 17:42)
Приведите пример варианта использования, когда будет лучше.
Изящный пример сейчас не придумаю. Но хорошо уже то, что не требуются операции ни помещения, ни извлечения из хранилища при прочих равных условиях.
Цитата(Vofka @ 17.03.16, 17:42)
За счет какого манипулирования? Можете привести конкретный пример о чем речь, потому что не понимаю.
Здесь я говорю о том, что "цена" хранения единицы данных в СУБД выше "цены" хранения на диске за счет различных операций: перестроение индекса, проверка целостности бд, резервное копирование, сжатие бд... Но опять таки, это все в теории...
Сообщение отредактировал Petre - 17.03.16, 18:10
Допрацьовую: - "Бухгалтерія для України 2.1"; - "Альфа-Авто: Автосалон+Автосервіс+Автозапчастини, українська версія".
Группа: Местный
Сообщений: 630
Спасибо сказали: 168 раз
Рейтинг: 133.4
Цитата(Vofka @ 17.03.16, 17:42)
С этим я согласен. Но. Вряд-ли соотношение сканов к остальной информации базе будет 90% на 10%. То есть, если база большая, то скорее всего сканы это не основной её объем. А посему будет ли реально какой-то действительный профит от копирования 100 Гб по сравнению пусть с 70 Гб? Как по мне, то профита особо никакого.
Это можно посчитать, взять количество заключённых договоров за год с "додатками" и "протоколами розбіжностей" и умножить на среднюю длину договора в страницах А4 и умножить на размер скана страницы в 1,2Мб (jpg среднего качества). Узнаете рост базы в год, и умножите на количество лет сопровождения базы без сворачивания в архив. По нашим расчётам, средний договор без больших дизайн-макетов - 25Мб. Но у нас есть проблема дорогого рейда из SAS 15k, который не хочется использовать для "мёртвых" данных в 17% от общего размера базы (ведь договоры нужны редко для просмотра и печати, а ещё надо умножить на 3, так как есть две копии базы для разработчиков внутренних и франча). Я всё больше склоняюсь к внешнему хранению.
#define private public enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day
Группа: Основатель
Сообщений: 13982
Из: Киев
Спасибо сказали: 4549 раз
Рейтинг: 3678.1
andr_andrey, с такой вводной, как у вас - возможно. Но справедливости ради стоит отметить, что можно секционировать базу на уровне SQLя и вынести соответствующую таблицу на отдельный носитель.
Группа: Основатель
Сообщений: 13982
Из: Киев
Спасибо сказали: 4549 раз
Рейтинг: 3678.1
Petre, ваше вчерашнее сообщение только сейчас заметил, поэтому отвечаю с опозданием, так сказать .
Цитата(Petre @ 17.03.16, 18:09)
Если говорить о сжатых данных (резервное копирование средствами СУБД или выгрузка средствами 1с), то чаще всего это будет даже больше 90%.
Если по условиям задачи, сканы договоров - это данные, которые не страшно утратить безследно и особо они никому не нужны, то в этом случае я соглашусь, что лучше хратить их где-то отдельно от базы данных. Но если же это важные данные, то вам, на ряду с базой данных, прийдется обеспечить резервное копирование этого каталога. А это, как минимум, дополнительная головная боль. А во вторых, вы уверены, что бэкап каталога будет проходить быстрее той части бэкапа базы, которая будет бэкапить таблицу с этимим данными?
Цитата(Petre @ 17.03.16, 18:09)
Изящный пример сейчас не придумаю. Но хорошо уже то, что не требуются операции ни помещения, ни извлечения из хранилища при прочих равных условиях.
Тогда я приведу 2 примера: 1) 1 секунда и 100 секунд 2) 0.00001 секунда и 0.0000001 В обоих примерах разница между временем составляет 2 порядка. 2 порядка - это относительно много? Конечно. А абсолютно? А если абсолютно, то в первом случае это много, а во втором - это ерунда. Хотя, еще раз, и там и там разница в 2 порядка. Так вот, то о чем вы говорите про извлечение и помещение в хранилище, на мой взгляд, это больше приближено ко второму случаю, чем к первому.
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!