v7: Базу 1С 7.7 (8.х) SQL распределяем по разным дискам, используя файловые группы. #640936

Функционал SQL-сервера в части поддержки файловых групп, и схем секционирования применительно к 1С, мало кто использует. Сложно сказать почему. Возможно из-за недостаточной информированности 1С-программистов, возможно из-за того, что базы 1С никогда не вырастают до больших размеров. Ведь базы 1С редко когда содержат данные за период более чем 5 лет. Возможно, потому, что многие пользователи (как и программисты) видят в “свертке” (обрезке) базы 1С панацею от всех бед и ошибок прошлого периода. Возможно потому, что 1C, как платформа, не способна поддерживать непротиворечивый и актуальный массив информации за длительный период (5-10 и более лет). Посему больших баз 1С попросту не бывает. Но между тем, файловые группы как раз и предназначены для использования в больших базах (больших по меркам SQL-сервера, а не 1С, естественно) Распределив самые часто использующиеся, и самые большие таблицы по разным файловым группам (соответственно, жестким дискам), мы распределим нагрузку по дисковой подсистеме более оптимальным образом, нежели при хранении всей базы данных на одном жестком диске. Интуитивно мы можем предположить, что скорость операций считываниязаписи дисковой подсистемы возрастет. Причем тем больше возрастет, чем больший размер имеет база данных. Подробная статья тут

10RAID и голова не болит...

> Возможно потому, что 1C, как платформа, не способна поддерживать непротиворечивый и актуальный массив информации за длительный период (5-10 и более лет). - это кто вам сказал? - оцените "массив информации" - это скольо в граммах? . в одной из компаний, которые обслуживаю раз в меясц а то и реже - бухбаза с 2006г. - это нормальный "массив" информации..? (база маленькая! . в свое время мерялись пиписками здесь еще по размеру баз на 7.7 - были вполне приличные (и на бухия, где достаточно правдоподобных цифр), а управленческие/торговые - где все намного строже .. вроде так? не соврал?

5-10 лет - большое количество фирм столько времени даже не живет... ;-)

а практически ?

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

про секционирование на исэвенте затрагивали

в статье приводится разделение на файловых группы для 1с 7.7. но у 1с77 достаточно много  технологических прощетов - "узких мест" производительности, устранените которых более кординально повлияет на производительность. так же не указаны рекамендации ms по поводу использования фг. не понятно, для кого (чего) написана статья? Недо программистам (админам) это не нужно. А кто разбирается, те уже сделали сответствующие настройки. похоже для рекламу автора.

Думаю вы осознаете что любое предположение имеет границы применения. И вы хорошо понимаете что своим предположением наверняка вышли за те границы которые я неявно предполагал. --- Но все же попробую ответить. Во первых хочу заметить что в вашем суждении не хватает одного ньюанса. Для того чтобы обслуживать нашу бесконечно большую базу (расположенную на бесконечно большом числе жестких дисков) нужно бесконечно большое число процессоров сервера. Тогда ваше суждение будет выглядеть так "для базы бесконечно большого размера обслуживаемой сервером с бесконечно большим количеством процессоров получаем бесконечно малое время отклика". --- И тогда я вам отвечу - нет, не бесконечно малое. Как вы заметили в условиях задачи фигурируют две бесконечно большие величины (размер базы и количество процессоров). Посему время отклика будет являться неопределенной величиной

смею заметить, что для задачи распределения базы по файловым группам - без разницы 1С это версии 7.7 или 8. Посему материал применим к обоим версиям 1С. --- целью статьи не было описание всех узких мест 1С, посему этот критический выпад не могу принять.

а не надо неявно предполагать, а то у разных - разные "границы применимости".

я неявно предположил, что база обслуживается на 4 процессорах. вы в критке моего утверждения вышли за те границы, которые я предполагал...

ну знаете ли, моё неявное предположение о том что база не является бесконечно большой по моему не требуется подчеркивать и делать явным)

понятно, пошли гнилые отмазки.. ;-)

да уж так всегда)) чистая правда выглядит невероятной ложью)) лучше приврать так правдоподобней)

Кому надо - проблемы решают. А статья фигня. Автор видимо только что узнал, что есть такая клёвая штука, и решил поделиться. Вот пусть он поделится, что будет когда 1С захочет _1SJourn перезаполнить (реквизит в шапку дока добавили, или недайбоже длину/тип номера поменяли).

Большие базы "по меркам SQL-сервера" и по меркам 1С 7.7 - это две очень большие разницы. Подозреваю, когда база 7.7 доходит до больших размеров по меркам MSSQL, 1Сник уже не первых год роет в инете различную информацию о методах ускорения связки 7.7+MSSQL. "база данных, использованная в этом примере, имеет размер ~15 гигабайт" Это, по вашему, похоже на большую "по меркам SQL-сервера" базу? :-)

не понимаю практического применения для 1с из минусов сабжа 1. уменьшается отказоустойчивость системы в целом 2. требует более квалифицированых спецов 3. более сложное взаимодействие с ОС (например если будут дисковые квоты или верчионирование файлов) ни одного ПРАКТИЧЕСКОГО плюса я не вижу зы правда я с большими базами не работал (более 100 гиг)

+  совершенно прав. как-то забыли, что 1с 7.7,8.* ПЕРЕСОЗДАЕТ таблицы так что про секционирование можете не начинать писать статью. без дополнительного шаманства для 1с фг и секционирование - вред.

одно время обсуждали разделение на файловые группы но там речь шла про размещение персональных данных на шифрованном диске --- Вложения в оперативку дают больший прирост производительности