Опыт оптимизации и контроля производительности в БД с 3000 пользователей
Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года.
Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии".
Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность.
Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры.
**update от 04.03.2016 по вопросам из комментариев
Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии".
Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность.
Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры.
**update от 04.03.2016 по вопросам из комментариев
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(6)
Я работаю с базами на порядок меньше (сотни гигов), но уже там возникают проблемы, как то:
1) резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются
2) обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.
3) данные: вычистить мусор, пересчитать итоги (на базе в 600 гигов это занимало 10 часов на MSSQL и 12 на Постгресе), конфу поменять, индексы добавить
как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?
PS. кстати, не пробовали dt-шку выгрузить ? :-D
На текущий момент файл данных >4Тб
Я работаю с базами на порядок меньше (сотни гигов), но уже там возникают проблемы, как то:
1) резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются
2) обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.
3) данные: вычистить мусор, пересчитать итоги (на базе в 600 гигов это занимало 10 часов на MSSQL и 12 на Постгресе), конфу поменять, индексы добавить
как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?
PS. кстати, не пробовали dt-шку выгрузить ? :-D
(17) baton_pk,
Благодаря AlwaysOn и отчетной базе у нас всегда на готове 2 базы - копии. Но и ежедневное бекапирование делается, чуть дольше 3х часов идет.
Регламентные долго идут, за ночь не успевает. Пробовали несколько вариантов их организации, сейчас остановились на еже ночном обновлении статистик а переиндексация и дефрагментация в выходные.
Не скупимся на СХД ;) Жертвуем реструктуризацией.
Попробую расскажу)
резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются
Благодаря AlwaysOn и отчетной базе у нас всегда на готове 2 базы - копии. Но и ежедневное бекапирование делается, чуть дольше 3х часов идет.
обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.
Регламентные долго идут, за ночь не успевает. Пробовали несколько вариантов их организации, сейчас остановились на еже ночном обновлении статистик а переиндексация и дефрагментация в выходные.
как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?
Не скупимся на СХД ;) Жертвуем реструктуризацией.
PS. кстати, не пробовали dt-шку выгрузить ? :-D
Попробую расскажу)
У меня есть несколько вопросов по архитектуре описываемой высоконагруженной системы:
1. Какое разграничение прав доступа используется? Используется ли RLS? Какое количество в среднем различных ограничений видов доступа на одного пользователя?
2. Какая структура кластеров 1С? Используется ли масштабирование средствами 1С? Используется ли резервирование средствами 1С, каков параметр отказоустойчивости?
3. Используется ли виртуализация?
4. Конфигурация на обычных формах?
5. Какова средняя сложность запросов отчетов? Сколько таблиц участвуют в соединениях, есть ли виртуальные?
P.S. Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))
1. Какое разграничение прав доступа используется? Используется ли RLS? Какое количество в среднем различных ограничений видов доступа на одного пользователя?
2. Какая структура кластеров 1С? Используется ли масштабирование средствами 1С? Используется ли резервирование средствами 1С, каков параметр отказоустойчивости?
3. Используется ли виртуализация?
4. Конфигурация на обычных формах?
5. Какова средняя сложность запросов отчетов? Сколько таблиц участвуют в соединениях, есть ли виртуальные?
P.S. Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))
(2) ivanov660,
1. RLS не используется. Разграничиваем двумя этапами - роли (предварительное разграничение) и регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.
2. В кластере один центральный сервер и 3 дополнительных. Из "особенностей" только то, что у центрального сервера нет rphost'ов (APDEX у пользователей, работающих на процессах центрального сервера, стабильно хуже чем на других серверах). Резервирование кластера не используем, рассматривали возможность - пугает большое количество негативных отзывов, поэтому надо делать тестирование на 3500+ юзеров. Сейчас отказоустойчивость обеспечивается количеством доп серверов (если один выходит из строя - кластер будет способен это пережить) и отсутствием процессов на центральном сервере.
3. Виртуализация только на терминальных машинах. Добавляли в кластер виртуальный сервер 1С, идентичный по железу, APDEX на нем был на 1 - 2% ниже.
4. Формы обычные, клиенты толстые)
5. Сложные запросы. Архитектура изначально строилась по принципам "нет лишним таблицам" и "зачем нам регистр, если все есть в документе", поэтому все не просто.
3000 пользователей у нас работали еще на 8.1 и все было отлично. Перефразируя классика, "роль управляемых форм в производительности сильно преувеличена" ;)
1. RLS не используется. Разграничиваем двумя этапами - роли (предварительное разграничение) и регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.
2. В кластере один центральный сервер и 3 дополнительных. Из "особенностей" только то, что у центрального сервера нет rphost'ов (APDEX у пользователей, работающих на процессах центрального сервера, стабильно хуже чем на других серверах). Резервирование кластера не используем, рассматривали возможность - пугает большое количество негативных отзывов, поэтому надо делать тестирование на 3500+ юзеров. Сейчас отказоустойчивость обеспечивается количеством доп серверов (если один выходит из строя - кластер будет способен это пережить) и отсутствием процессов на центральном сервере.
3. Виртуализация только на терминальных машинах. Добавляли в кластер виртуальный сервер 1С, идентичный по железу, APDEX на нем был на 1 - 2% ниже.
4. Формы обычные, клиенты толстые)
5. Сложные запросы. Архитектура изначально строилась по принципам "нет лишним таблицам" и "зачем нам регистр, если все есть в документе", поэтому все не просто.
Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))
3000 пользователей у нас работали еще на 8.1 и все было отлично. Перефразируя классика, "роль управляемых форм в производительности сильно преувеличена" ;)
(111)
Если говорить про резервирование серверов (что и дает полноценную отказоустойчивость), то на 8.3.10 и ранее работает не очень хорошо (в последних релизах оно даже работает, но при включении заметна деградация в скорости работы), поэтому мы пока не используем. Тесты 8.3.11 показывают хорошие результаты, APDEX практически не отличается от режима без резервирования т.ч. надежда есть.
Если же говорить про отказоустойчивость в рамках стабильной работы (отсутствие без причинных вылетов, закрытия сеансов), то тут все хорошо, сейчас работаем на 8.3.10.
В 8.3 нет проблем с отказоустойчивостью?
Так понимаю вопрос касается следующего проекта, уже по переходу на 8.3. Давайте с определением для начала разберемся, а то под отказоустойчивостью можно понимать разные вещи.
Если говорить про резервирование серверов (что и дает полноценную отказоустойчивость), то на 8.3.10 и ранее работает не очень хорошо (в последних релизах оно даже работает, но при включении заметна деградация в скорости работы), поэтому мы пока не используем. Тесты 8.3.11 показывают хорошие результаты, APDEX практически не отличается от режима без резервирования т.ч. надежда есть.
Если же говорить про отказоустойчивость в рамках стабильной работы (отсутствие без причинных вылетов, закрытия сеансов), то тут все хорошо, сейчас работаем на 8.3.10.
(112) Спасибо за ответ. В терминологии могу быть неточен, сорри.
Про деградацию при использовании нескольких центральных серверов в теме. Если центральный один + несколько "вспомогательных" - то вопросов, как я понимаю, в части производительности не возникает?
Меня больше интересовала позиция 1с, раз уж у вас с ними очень тесный контакт )
Про деградацию при использовании нескольких центральных серверов в теме. Если центральный один + несколько "вспомогательных" - то вопросов, как я понимаю, в части производительности не возникает?
Меня больше интересовала позиция 1с, раз уж у вас с ними очень тесный контакт )
можно узнать подробности при переводе на 8.2? с какими трудностями столкнулись, что не учли помимо тестирования?
в чем он заключался, просто в конвертации? отказывались ли от совместимости?
в рамках проекта цктп какой франч участвовал ?
в чем он заключался, просто в конвертации? отказывались ли от совместимости?
в рамках проекта цктп какой франч участвовал ?
(7) kolya_tlt, Переход на 8.2.13, тот который делали своими силами, провалился из-за поведения кластера 1С - он отказывался балансировать сеансы. Все пользователи оказались на одном сервере - самом мощном по железу. Плюс кластер постоянно "тасовал" сеансы между процессами. Конфигурацию готовили без совместимости, все программные "нюансы" выловили при тестировании логики. Вот список замечаний, который мы в то время для себя составляли:
-Работа с NULL в запросах при использовании конструкций вида ЕСТЬNULL("("+Таблица.Поле+")") // старый комент, возможно исправлено в свежей версии
-Проверить наличие везде проверки на ОбменДанным.Загрузка // для репликации
-Заменить вызова ОткрытьФормуМодально()
-Убрать третий параметр из вызовов ПравоДоступа()
-В процедуру обработчик события «ОбработкаЗаполнения» передается структура, в которой может и не быть поля Ссылка.
-Исправить формат булево по умолчанию на Истина и Ложь.
-Не работает формат даты с использованием YYYY
-Функция ТипЗнч() - не возвращает "...Ссылка...", «Документ..» и т.п., соответственно не работает код вида Найти(ТипЗнч(СсылочноеЗначение), «Справочник»)
-При не использовании Наименования или Кода справочника необходимо отключить его проверку - открыть СтандартныеРеквизиты на закладке объекта Данные и в свойствах нужного
реквизиты указать Проверка - Не использовать.
-Ошибка при выполнении кода вида: ТабДок.Вывести(ТабДокКопия.Область());
-Не работают запросы с условием вида &Контрагент В (Таблица.Получатель, Таблица.Отправитель, Таблица.Объект) если какое то из полей Таблица.Получатель, Таблица.Отправитель, Таблица.Объект - составного типа // всегда возвращается ЛОЖЬ
-Не работают запросы с условием вида ГДЕ Документ.ТабличнаяЧасть.Ссылка ЕСТЬ НЕ NULL // всегда возвращается ИСТИНА
-Для протокола POP3 не корректно работает метод ИнтернетПочта.ПолучитьЗаголовки(); // все заголовки с одинаковым идентификатором сообщения
Показать
Привлечение ЦКТП изначально и обосновывалось необходимостью повысить стабильность работы платформы. Плюс мы решили вторую задачу - спрогнозировать поведение системы при двукратном увеличении количества пользователей (и производимой ими работы есессно).
Про франч - приводил ссылку на проект. Богачев Виктор (участвовавший эксперт) так же был на конференции и подробно рассказывал про это тестирование.
-Работа с NULL в запросах при использовании конструкций вида ЕСТЬNULL("("+Таблица.Поле+")") // старый комент, возможно исправлено в свежей версии
-Проверить наличие везде проверки на ОбменДанным.Загрузка // для репликации
-Заменить вызова ОткрытьФормуМодально()
-Убрать третий параметр из вызовов ПравоДоступа()
-В процедуру обработчик события «ОбработкаЗаполнения» передается структура, в которой может и не быть поля Ссылка.
-Исправить формат булево по умолчанию на Истина и Ложь.
-Не работает формат даты с использованием YYYY
-Функция ТипЗнч() - не возвращает "...Ссылка...", «Документ..» и т.п., соответственно не работает код вида Найти(ТипЗнч(СсылочноеЗначение), «Справочник»)
-При не использовании Наименования или Кода справочника необходимо отключить его проверку - открыть СтандартныеРеквизиты на закладке объекта Данные и в свойствах нужного
реквизиты указать Проверка - Не использовать.
-Ошибка при выполнении кода вида: ТабДок.Вывести(ТабДокКопия.Область());
-Не работают запросы с условием вида &Контрагент В (Таблица.Получатель, Таблица.Отправитель, Таблица.Объект) если какое то из полей Таблица.Получатель, Таблица.Отправитель, Таблица.Объект - составного типа // всегда возвращается ЛОЖЬ
-Не работают запросы с условием вида ГДЕ Документ.ТабличнаяЧасть.Ссылка ЕСТЬ НЕ NULL // всегда возвращается ИСТИНА
-Для протокола POP3 не корректно работает метод ИнтернетПочта.ПолучитьЗаголовки(); // все заголовки с одинаковым идентификатором сообщения
Привлечение ЦКТП изначально и обосновывалось необходимостью повысить стабильность работы платформы. Плюс мы решили вторую задачу - спрогнозировать поведение системы при двукратном увеличении количества пользователей (и производимой ими работы есессно).
Про франч - приводил ссылку на проект. Богачев Виктор (участвовавший эксперт) так же был на конференции и подробно рассказывал про это тестирование.
(18) kolya_tlt, Версия платформы - начиная с 8.2.19.83, сейчас обновились на 8.2.19.130
не актуальный комент, у нас в 8.1 была своя такая функция, поэтому пришлось переименовывать
В конфигураторе, Администрирование - Региональные установки, в 8.2 по умолчанию стоит Да и Нет - части пользователей не понравилось. Мы и цветовую схему настраивали максимально близко к 8.1
чем и зачем заменяли ОткрытьФормуМодально?
не актуальный комент, у нас в 8.1 была своя такая функция, поэтому пришлось переименовывать
что подразумевается под "Исправить формат булево по умолчанию"?
В конфигураторе, Администрирование - Региональные установки, в 8.2 по умолчанию стоит Да и Нет - части пользователей не понравилось. Мы и цветовую схему настраивали максимально близко к 8.1
(37) kolya_tlt, список актуальный, выкиньте пункт ОткрытьФормуМодально(), ну а формат булево по умолчанию - дело вкуса))
ОбменДанными.Загрузка нужна для корректной работы обменов. Ну и вообще наличие этой проверки в событиях ПередЗаписью, ПриЗаписи это уже стандарт.
Ни в 8.2 не в 8.3 не работает, попробуйте выполнить Формат(ТекущаяДата(), "ДФ=dd.MM.YYYY")
Искали просто - глобальным поиском строку YYYY с учетом регистра.
зачем нужна "Проверить наличие везде проверки на ОбменДанным.Загрузка" ?
ОбменДанными.Загрузка нужна для корректной работы обменов. Ну и вообще наличие этой проверки в событиях ПередЗаписью, ПриЗаписи это уже стандарт.
"Не работает формат даты с использованием YYYY" не работает где? и как вообще такое искали в коде?)
Ни в 8.2 не в 8.3 не работает, попробуйте выполнить Формат(ТекущаяДата(), "ДФ=dd.MM.YYYY")
Искали просто - глобальным поиском строку YYYY с учетом регистра.
Автору огромное спасибо! Очень востребованная тема. Столько боли прожито с производительностью. Почему-то в нашей стране считается, что оптимизация sql это вопрос программистов 1С, хотя 101% из них не обладают не то, что достаточными, но даже начальными знаниями в этом вопросе.
Отдельное спасибо за скульные запросы. Будем пробовать.
Отдельное спасибо за скульные запросы. Будем пробовать.
(0) Со всем уважением к автору и к его докладу!
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)
База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)
База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...
(19) Rustig, (26) Rustig, (31) Rustig,
Спасибо за вопросы. Видел методичку, как по задаваемым вопросам понять настроение человека и что его беспокоит, видимо много багов и косяков вас окружает ;) но это так, не много не в тему..
Слишком много внимания косякам, конечно есть и ошибки и просчеты, есть экстренные хотелки бизнеса, а ля "должно работать завтра". Не ошибается только тот, кто ничего не делает.
Но что бы половина обновления - исправление ошибок, серьезно? Частота обновления и количество программистов приведено для понимания скорости наращивания функционала. Постоянное развитие базы - это наша специфика.
Управляемые формы не использовались, на 8.2 мы перешли только в прошлом году, т.ч. основная разработка велась на 8.0 и 8.1
Формы списков - обычные, запросы которые вышли в топ - платформенные вызываемые, например, при скроллинге и выводе списка.
Построитель - да, "не красиво", но личное мнение, что для высоко нагруженных систем будущее за статичными формами поиска (интерфейс SAP это подтверждает). И красивые возможности типа таких без контроля по каким колонкам можно искать, по каким можно искать строго на равенство, по каким нельзя сортировать и т.п. - пугают потенциальным воздействием на систему.
Есть конечно. Это и рост самой компании и потребностей в части функционала.
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)
За тональность извините. :)
Спасибо за вопросы. Видел методичку, как по задаваемым вопросам понять настроение человека и что его беспокоит, видимо много багов и косяков вас окружает ;) но это так, не много не в тему..
База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
ЦФ-шник в студию - уверен, что косяков там достаточно....
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
ЦФ-шник в студию - уверен, что косяков там достаточно....
Слишком много внимания косякам, конечно есть и ошибки и просчеты, есть экстренные хотелки бизнеса, а ля "должно работать завтра". Не ошибается только тот, кто ничего не делает.
Но что бы половина обновления - исправление ошибок, серьезно? Частота обновления и количество программистов приведено для понимания скорости наращивания функционала. Постоянное развитие базы - это наша специфика.
Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...
Управляемые формы не использовались, на 8.2 мы перешли только в прошлом году, т.ч. основная разработка велась на 8.0 и 8.1
Формы списков - обычные, запросы которые вышли в топ - платформенные вызываемые, например, при скроллинге и выводе списка.
Построитель - да, "не красиво", но личное мнение, что для высоко нагруженных систем будущее за статичными формами поиска (интерфейс SAP это подтверждает). И красивые возможности типа таких без контроля по каким колонкам можно искать, по каким можно искать строго на равенство, по каким нельзя сортировать и т.п. - пугают потенциальным воздействием на систему.
в докладе нет анализа первопричины проблем
Есть конечно. Это и рост самой компании и потребностей в части функционала.
(38) Сергей, у вас много точек продаж, по факту они работают с "потоковым" клиентом. Очень напоминает розницу. Не думали представить всю вашу схему работы подразделений как сеть розничных точек продаж - на каждой точке своя небольшая база, вся информация собирается в центральной базе и т.д. и тому подобное?
(49) Rustig, первый совет, с которого начинается книга Фаулера о распределенных системах звучит так - "не распределяйте системы! ну а если это по каким-то очень веским причинам невозможно, то для вас следующие 600 страниц текста". примерно так...
(49) Rustig,
Думали, точнее не так, правильнее сказать, что изначально именно так и было :)
Повторю фразу, которую сказал на конференции: те, у кого одна большая база думают над её разделение, а те, у кого распределенная система, думают над её слиянием. Потому что не бывает идеальной системы, минусы есть и там и там.
"Распределенка" это как раз из рубрики двусторонних обменов, коллизий и не актуальности данных. Сейчас движение в сторону функционального разделения.
Не думали представить всю вашу схему работы подразделений как сеть розничных точек продаж - на каждой точке своя небольшая база
Думали, точнее не так, правильнее сказать, что изначально именно так и было :)
Повторю фразу, которую сказал на конференции: те, у кого одна большая база думают над её разделение, а те, у кого распределенная система, думают над её слиянием. Потому что не бывает идеальной системы, минусы есть и там и там.
"Распределенка" это как раз из рубрики двусторонних обменов, коллизий и не актуальности данных. Сейчас движение в сторону функционального разделения.
Конечно запросы из форм списков были не единственными, мы переписали достаточно много запросов, а где то и архитектуру. Эта работа дала результат. Раньше, например, нагрузка на систему в понедельник и пятницу могла быть настолько высока, что приходилось отпускать домой некоторые отделы (менеджеров, колл-центр). А в результате проведенной оптимизации получилось снизить нагрузку в пятницу – проблем больше не было. Да и в понедельник мы тоже, со скрипом, но работали.
Абзац по сути ни о чем. Если бы вы показали, какой кривой запрос был написан изначально, а какой стал в итоге, то это плюс тому кто в этом разобрался, и минус всей команде сразу, что допустили кривоту. Я за свою практику навидался так диких отчетов (запросов), что могу представить какие у вас были...
Штат разработчиков 20 человек. Сколько из них сертифицированы? Сколько из них с опытом свыше 3 лет программирования и консультирования? Вы извините , но 20 - ни о чем не говорит. А вот 20 профессионалов своего дела - уже впечатляет. :)
(20) Rustig, Статей и докладов на тему оптимизации запросов очень много. Не было смысла тратить время конференции, тем более сразу за мной на эту тему выступал Андрей Бурмистров.
Про команду - сильная команда, 7 экспертов (4 сертифицировались уже работая у нас). Но берем не за корочки вовсе, это не показатель.
Про команду - сильная команда, 7 экспертов (4 сертифицировались уже работая у нас). Но берем не за корочки вовсе, это не показатель.
обращайтесь в 1С, в рамках проектов ЦКТП достаточно оперативно устраняются и ошибки платформы и выявляются "узкие" места БД.
фирма 1с исправляет ошибки платформы исключительно для вас (в рамках договора цктп)? то есть вы остаетесь на том же релизе платформы, только с исправленными ошибками платформы? так что ли? при этом остальные компании исправления этих ошибок или получают с новыми релизами платформы, или не получают вовсе. правильно я вас понял?
(0) ЦУП появился до управляемых форм.... Управляемые формы покамест тормозят и требуют дорогого железа..... неужели такой супер ЦУП не может выявить проблемы управляемых форм?....
какую помощь оказывает цуп? только лишь такую, что начинает контролировать разработку кривых запросов программистов....теперь их можно уволить - есть доказательства их некомпетентности ....
какую помощь оказывает цуп? только лишь такую, что начинает контролировать разработку кривых запросов программистов....теперь их можно уволить - есть доказательства их некомпетентности ....
(30) Сергей, я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику - решение точечное - производительность увеличивается... в докладе нет анализа первопричины проблем, есть диагностический инструмент.... пусть мое мнение будет на ветке....
по поводу управляемых форм - это вопрос не к вам... это риторический вопрос ко всем кто работает с цупом и знаком с тормозами управляемых форм...
спасибо за доклад и статью, считаю ее полезным кейсом )) всего доброго
по поводу управляемых форм - это вопрос не к вам... это риторический вопрос ко всем кто работает с цупом и знаком с тормозами управляемых форм...
спасибо за доклад и статью, считаю ее полезным кейсом )) всего доброго
(31) Rustig, "я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику - решение точечное - производительность увеличивается..."
Придерживаюсь аналогичного мнения. С ЦУП приходится повозиться чтобы его запустить и постоянно натыкался на глюки ЦУП. Быстрее всего текущую картину можно получить по Монитору активности в MS SQL Server - самые длительные запросы.
Придерживаюсь аналогичного мнения. С ЦУП приходится повозиться чтобы его запустить и постоянно натыкался на глюки ЦУП. Быстрее всего текущую картину можно получить по Монитору активности в MS SQL Server - самые длительные запросы.
(76) ZLENKO, Монитор активности пользуется теми же динамическими представлениями (dm_exec_query_stats и dm_exec_requests) только более сложно агрегирует получаемые данные.
Можно посмотреть в хранимку tempdb.dbo.#am_get_querystats_...
Сталкивались с тем, что монитор активности сам создаёт нагрузку, особенно если интервал обновления маленький и он открыт у нескольких человек.
Можно посмотреть в хранимку tempdb.dbo.#am_get_querystats_...
Сталкивались с тем, что монитор активности сам создаёт нагрузку, особенно если интервал обновления маленький и он открыт у нескольких человек.
регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.
ужас... механизм не то чтобы "не гибкий", а спорный в использовании....
(0), (17) 4 Тб - тоже ни о чем!
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков? Деловые линии работают по всей России и м.б. за рубежом...
свертку давно делали?...
половину инфы можно удалить из рабочей базы - номенклатура которая сто лет не используется, контрагентов, которые давно не существуют, документы прошлых закрытых периодов например за 2000 год.... кому они нужны в текущей рабочей менеджерской базе?....
есть архив, если надо оттуда все достанете, есть дублирующая база, из нее можно вытащить любые документы.....
я уверен, что можно обойтись без цупа
ЦФ-шник в студию - уверен, что косяков там достаточно....
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков? Деловые линии работают по всей России и м.б. за рубежом...
свертку давно делали?...
половину инфы можно удалить из рабочей базы - номенклатура которая сто лет не используется, контрагентов, которые давно не существуют, документы прошлых закрытых периодов например за 2000 год.... кому они нужны в текущей рабочей менеджерской базе?....
есть архив, если надо оттуда все достанете, есть дублирующая база, из нее можно вытащить любые документы.....
я уверен, что можно обойтись без цупа
ЦФ-шник в студию - уверен, что косяков там достаточно....
(26) Rustig,
поверьте, это всё такая мелочь :)
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков?
номенклатура которая сто лет не используется, контрагентов, которые давно не существуют
классификатор адресов сколько съедает места?
классификатор банков?
номенклатура которая сто лет не используется, контрагентов, которые давно не существуют
поверьте, это всё такая мелочь :)
(33) я не уверен, что мелочи.
мы с вами на разных уровнях работаем. это не плохо, это очень хорошо, особенно если я что -то полезное черпаю из ваших знаний.
это все мелочи, пока у вас есть деньги на железо, на штат сисадминов, на серверные субд... мне в своей практике приходится сталкиваться с файловыми базами, у них ограничение на 4 Гб. и тут я начинаю выдумывать всякие финтиплюшки - картинки и пдф-счета, договора выношу в другие базы (число баз для хранения картинок, образов, сертификатов и т.д. неограничено и постоянно растет), свертка-свертка-и еще раз свертка....
сейчас я понимаю, что о некоторых аспектах никто не задумывается, пока есть деньги на железо, на сисадминов, на лицензии серверов, на цуп... если вы скачаете кладр с официального сайта, получите файлы около 320 Мб. если закачаете часть регионов кладра в базу БП 2.0 получите увеличение базы на 1Гб и выше. просто задумайтесь, что для кого-то это уже не мелочи...
я понимаю, что в пон-к вы продолжите заниматься своими текущими задачами с базами 300 Гб, и продолжите строить планы, как их реиндексировать, понимаю, что вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб....
мы с вами на разных уровнях работаем. это не плохо, это очень хорошо, особенно если я что -то полезное черпаю из ваших знаний.
это все мелочи, пока у вас есть деньги на железо, на штат сисадминов, на серверные субд... мне в своей практике приходится сталкиваться с файловыми базами, у них ограничение на 4 Гб. и тут я начинаю выдумывать всякие финтиплюшки - картинки и пдф-счета, договора выношу в другие базы (число баз для хранения картинок, образов, сертификатов и т.д. неограничено и постоянно растет), свертка-свертка-и еще раз свертка....
сейчас я понимаю, что о некоторых аспектах никто не задумывается, пока есть деньги на железо, на сисадминов, на лицензии серверов, на цуп... если вы скачаете кладр с официального сайта, получите файлы около 320 Мб. если закачаете часть регионов кладра в базу БП 2.0 получите увеличение базы на 1Гб и выше. просто задумайтесь, что для кого-то это уже не мелочи...
я понимаю, что в пон-к вы продолжите заниматься своими текущими задачами с базами 300 Гб, и продолжите строить планы, как их реиндексировать, понимаю, что вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб....
(46) Rustig,
Не в этом дело. Просто ваш ответ был в контексте 4ТБ, а для 4ТБ что гиг, что двадцать - мелочи.
70 магазинов с файловыми базами 2-4 ГБ, в каждом магазине по две: на складе и в магазине. Падают часто. Так что, да, мне тоже придётся скоро оптимизировать и их работу тоже :).
(49) Rustig,
нафигнафигнафигнафиг! если есть возможность работать напрямую, лучше работать напрямую. разбить одну база на две - это уже довольно эпохальное решение, а разбивать её на десяток - ошибка и тоже довольно-таки эпичная. в статье от Старых, ссылку на которую вы тут привели, описано, что не всегда параллельность даёт нужную отдачу. в случае с базами - это немалые накладные расходы на обмен.
мы с вами на разных уровнях работаем
Не в этом дело. Просто ваш ответ был в контексте 4ТБ, а для 4ТБ что гиг, что двадцать - мелочи.
вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб
70 магазинов с файловыми базами 2-4 ГБ, в каждом магазине по две: на складе и в магазине. Падают часто. Так что, да, мне тоже придётся скоро оптимизировать и их работу тоже :).
(49) Rustig,
на каждой точке своя небольшая база, вся информация собирается в центральной базе и т.д.
нафигнафигнафигнафиг! если есть возможность работать напрямую, лучше работать напрямую. разбить одну база на две - это уже довольно эпохальное решение, а разбивать её на десяток - ошибка и тоже довольно-таки эпичная. в статье от Старых, ссылку на которую вы тут привели, описано, что не всегда параллельность даёт нужную отдачу. в случае с базами - это немалые накладные расходы на обмен.
(26) Rustig, вы поймите, у оптимизации есть 2 пути:
1. отрезать лишние данные так как неоптимальный запрос их обрабатывает. отрезать можно тоже либо отказать от функциональной части, либо убрать старые данные
2. переписать неоптимальный запрос.
Думаю в проекты был выбран второй путь
ps косяки есть в любом цф-нике. вам зачем на них смотреть?
1. отрезать лишние данные так как неоптимальный запрос их обрабатывает. отрезать можно тоже либо отказать от функциональной части, либо убрать старые данные
2. переписать неоптимальный запрос.
Думаю в проекты был выбран второй путь
ps косяки есть в любом цф-нике. вам зачем на них смотреть?
(45) ответил в (46)
сталкивался с базой 150Гб будучи в команде разработчиков, за производительность не отвечал, вел разработку подсистем.
в дальнейшем во фрилансе работал с клиентами, разрабатывал подсистемы на файл-серверных базах размеров 40-70 Гб. Приходилось консультировать клиентов как ускорить работу 1С - в моих руках не было цупа, только голова, оптимизация запросов, оптимизация бизнес-процессов и архитектуры новых подсистем.
при работе с файловыми базами сталкивался с падением производительности при достижении базы критического порога допустимых размеров. принимал активное участие в ликвидации последствий.
Я не системный администратор, я программист. и смотрю на данный кейс как программист...
сталкивался с базой 150Гб будучи в команде разработчиков, за производительность не отвечал, вел разработку подсистем.
в дальнейшем во фрилансе работал с клиентами, разрабатывал подсистемы на файл-серверных базах размеров 40-70 Гб. Приходилось консультировать клиентов как ускорить работу 1С - в моих руках не было цупа, только голова, оптимизация запросов, оптимизация бизнес-процессов и архитектуры новых подсистем.
при работе с файловыми базами сталкивался с падением производительности при достижении базы критического порога допустимых размеров. принимал активное участие в ликвидации последствий.
Я не системный администратор, я программист. и смотрю на данный кейс как программист...
(26)
Беру свои слова обратно:4 Тб - тоже ни о чем!
Контекст изменился: 4 Тб это очень много, чтобы продолжать работать в том же духе и развивать систему. Кажется пора принимать серьезные меры по изменению ситуации. Проведу аналогию: для файловой базы критичен порог 4Гб, для файл-серверной пусть будет 4Тб... :))
4 Тб - тоже ни о чем!
Беру свои слова обратно:
Контекст изменился: 4 Тб это очень много, чтобы продолжать работать в том же духе и развивать систему. Кажется пора принимать серьезные меры по изменению ситуации. Проведу аналогию: для файловой базы критичен порог 4Гб, для файл-серверной пусть будет 4Тб... :))
(55) Rustig, аналогия в данном случае немного за уши притянута: для файловой базы ограничение в 4ГБ на одну внутреннюю таблицу - это ФИЗИЧЕСКОЕ ограничение, а 4ТБ для клиент-серверной - исключительно психологическое. База вполне может себе жить и пухнуть дальше до 40, 400, 4000. и если не заниматься доработками, связанными с реструктуризацией, то у платформы есть все возможности сделать так, чтобы пользователь не замечал разницы между большой базой и маленькой (речь, разумеется, не про типовые конфигурации :-D)
Два извечных вопроса интернета: Как? и Зачем ?
С периодичностью раз в полгода на различных евентах появляется человек с базой в десяток тысяч пользователей.
И что удивительно практически всегда там находится SoftPoint.
И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.
Кроме конечно желания генерального. Обычно он и говорит - хочу одну базу.
На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.
О чем и говорит уважаемый Rustig.
Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30.
С периодичностью раз в полгода на различных евентах появляется человек с базой в десяток тысяч пользователей.
И что удивительно практически всегда там находится SoftPoint.
И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.
Кроме конечно желания генерального. Обычно он и говорит - хочу одну базу.
На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.
О чем и говорит уважаемый Rustig.
Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30.
(54) capitan,
В чем удивительность, поделитесь? Почему вас не удивляет наличие у нас ЦУП, SQL, Windows, Perfomance Monitor, а именно инструменты этой компании?
повторюсь, основная причина - рост компании, открытие подразделений в городах.
Изначально каждое подразделение работало в своей базе. Решение о слиянии баз было принято из-за предъявляемых бизнес процессами требований. Ну а извечные вопросы Как? и Зачем? все равно будут, да же если доклад посвятить теме "Опыт оптимизации и контроля производительности в распределенной системе из 100 узлов".
Далеко от реальности. Когда у вас работоспособность БД на условном нуле затевать проект логической модификации БД это равносильно профессиональному самоубийству. Сначала дайте бизнесу рабочую базу, а дальше продумывайте новую архитектуру, её плюсы и минусы, считайте бюджет и выходите на защиту проекта.
а про бумагу то мы и забыли..)))
Если серьезно, то это набор общих фраз характеризующих некую идеальную среду мироздания. Когда мы рассматриваем реальную ситуацию, то появляются множество нюансов и так просто не получается. Например, сам пользователь актуальные данные не читает, но те изменения, которые он вносит - очень важны для остальных (бухгалтер, вносящий факт оплаты), либо окажется, что в небольшом филиале один сотрудник совмещает несколько должностей и после разделения он будет вынужден работать в 2х - 3х базах.
Пример по реалтаймности. Наш Call центр обзванивает клиентов для информирования, что груз прибыл и его можно забрать. При этом регламентное задание, актуализирующее номера телефонов в обзвонщике, работает раз в 5 минут. Так вот, за эти 5 минут информация успевает устаревать (клиент как раз забирал груз в это время; менеджер заблокировал выдачу из-за проблем с оплатой). Оператор Call центра в таких случаях просто извиняется и вешает трубку. В процентном отношении это не большие цифры, но в количественном это сотни напрасных звонков за сутки. Т.е. несколько сот клиентов могли бы раньше узнать о том, что груз уже приехал и его можно забрать. Естественно, что частота работы регламентного была увеличена. И сейчас, когда вся информация в одной базе, а если говорить про распределенку таких случаев будет неминуемо больше.
так их не станет 30, их в сумме все равно будет 3000, а вот число серверов 1С и баз, безопасность которых по идее и надо контролировать, значительно возрастет.
И что удивительно практически всегда там находится SoftPoint.
В чем удивительность, поделитесь? Почему вас не удивляет наличие у нас ЦУП, SQL, Windows, Perfomance Monitor, а именно инструменты этой компании?
И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.
повторюсь, основная причина - рост компании, открытие подразделений в городах.
Изначально каждое подразделение работало в своей базе. Решение о слиянии баз было принято из-за предъявляемых бизнес процессами требований. Ну а извечные вопросы Как? и Зачем? все равно будут, да же если доклад посвятить теме "Опыт оптимизации и контроля производительности в распределенной системе из 100 узлов".
На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.
Далеко от реальности. Когда у вас работоспособность БД на условном нуле затевать проект логической модификации БД это равносильно профессиональному самоубийству. Сначала дайте бизнесу рабочую базу, а дальше продумывайте новую архитектуру, её плюсы и минусы, считайте бюджет и выходите на защиту проекта.
Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
а про бумагу то мы и забыли..)))
Если серьезно, то это набор общих фраз характеризующих некую идеальную среду мироздания. Когда мы рассматриваем реальную ситуацию, то появляются множество нюансов и так просто не получается. Например, сам пользователь актуальные данные не читает, но те изменения, которые он вносит - очень важны для остальных (бухгалтер, вносящий факт оплаты), либо окажется, что в небольшом филиале один сотрудник совмещает несколько должностей и после разделения он будет вынужден работать в 2х - 3х базах.
Пример по реалтаймности. Наш Call центр обзванивает клиентов для информирования, что груз прибыл и его можно забрать. При этом регламентное задание, актуализирующее номера телефонов в обзвонщике, работает раз в 5 минут. Так вот, за эти 5 минут информация успевает устаревать (клиент как раз забирал груз в это время; менеджер заблокировал выдачу из-за проблем с оплатой). Оператор Call центра в таких случаях просто извиняется и вешает трубку. В процентном отношении это не большие цифры, но в количественном это сотни напрасных звонков за сутки. Т.е. несколько сот клиентов могли бы раньше узнать о том, что груз уже приехал и его можно забрать. Естественно, что частота работы регламентного была увеличена. И сейчас, когда вся информация в одной базе, а если говорить про распределенку таких случаев будет неминуемо больше.
И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30
так их не станет 30, их в сумме все равно будет 3000, а вот число серверов 1С и баз, безопасность которых по идее и надо контролировать, значительно возрастет.
(59) видел ответы ,некоторые улыбнули :) но не буду вдаваться в полемику, поберегу время.
Есть еще парочка вопросов:
1. Допустим сейчас вы полностью контролируете базу и всех 40 программистов, но предположим ваш сервер устал или что еще хуже - логический сбой БД.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?
Что в этот момент будут делать 3000 юзеров ?
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?
2. Есть такой закон - N 152-ФЗ. Пока вы работаете с юрлицами все неплохо, но как только в вашей базе появляется физ. лицо вам надо соответствовать.
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.
Есть еще парочка вопросов:
1. Допустим сейчас вы полностью контролируете базу и всех 40 программистов, но предположим ваш сервер устал или что еще хуже - логический сбой БД.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?
Что в этот момент будут делать 3000 юзеров ?
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?
2. Есть такой закон - N 152-ФЗ. Пока вы работаете с юрлицами все неплохо, но как только в вашей базе появляется физ. лицо вам надо соответствовать.
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.
(69) capitan,
Вопросы выводят в плоскость почему одна большая БД плохо (может показалось?). Абсолютно согласен с тем, что у этой архитектуры есть недостатки. И у распределенной системы они так же есть. Наша практика показала, что с точки зрения бизнес процессов иметь единую базу выгоднее. Этот опыт никому не навязывается, просто показываю, что это реально.
Если мы говорим про физическое разрушение БД, когда в базу принципиально нет возможности даже войти, то время восстановления работоспособности менее минуты - достаточно в свойствах базы 1С изменить базу СУБД на отчетную или базу-реплику (AlwaysOn). Все 3 базы на физически разных СХД и физически разных серверах.
В рамках ЦКТП тест был на 5000 пользователей. Что должно этому мешать?
У вас либо есть защитный механизм, либо его нет. Если защита есть, то ей должно быть по фиг 30 у вас пользователей или 3000.
Вообще всегда интересны различные идеи и концепты, они позволяют "расширять сознание", поэтому если у вас есть какое то видение, как разом "побороть" все вышеописанные проблемы, напишите, любопытно.
Вопросы выводят в плоскость почему одна большая БД плохо (может показалось?). Абсолютно согласен с тем, что у этой архитектуры есть недостатки. И у распределенной системы они так же есть. Наша практика показала, что с точки зрения бизнес процессов иметь единую базу выгоднее. Этот опыт никому не навязывается, просто показываю, что это реально.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?
Если мы говорим про физическое разрушение БД, когда в базу принципиально нет возможности даже войти, то время восстановления работоспособности менее минуты - достаточно в свойствах базы 1С изменить базу СУБД на отчетную или базу-реплику (AlwaysOn). Все 3 базы на физически разных СХД и физически разных серверах.
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?
В рамках ЦКТП тест был на 5000 пользователей. Что должно этому мешать?
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.
У вас либо есть защитный механизм, либо его нет. Если защита есть, то ей должно быть по фиг 30 у вас пользователей или 3000.
Вообще всегда интересны различные идеи и концепты, они позволяют "расширять сознание", поэтому если у вас есть какое то видение, как разом "побороть" все вышеописанные проблемы, напишите, любопытно.
(70) Капитан имеет в виду формальные проверки на соответствие (много мата пропущено) фз 152, к жизни не имеющего никакого практического отношения, но позволяющего за.. утомить, в общем - любого оператора персданных.
В подобных целях видел регламентную очистку исполненных и закрытых заказов, дабы не попасть по числу объектов под неудобный класс ИС.
А сам на проверке с уверенным видом расказывал, что "архивов у нас нет, всё отлажено и работает без сбоев, поэтому процедуры удаления ПДн после отзыва согласия на обработку не нужны и отсутствуют". Коллеги сдержались, проверяющие изумились, но отвязались.
В подобных целях видел регламентную очистку исполненных и закрытых заказов, дабы не попасть по числу объектов под неудобный класс ИС.
А сам на проверке с уверенным видом расказывал, что "архивов у нас нет, всё отлажено и работает без сбоев, поэтому процедуры удаления ПДн после отзыва согласия на обработку не нужны и отсутствуют". Коллеги сдержались, проверяющие изумились, но отвязались.
(70) самым великим мастером давать ответы далекие по смыслу от темы вопроса был конечно Михаил Сергеевич, долгой ему жизни. И задолго до него известна фраза Райкина - Хотите меня поставить в тупик своими вопросами - так я вас поставлю в тупик своими ответами.
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.
Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.
Что касается видения - ваша структура в точь точь похожа на любого крупного ретейлера, за той разницей - что на пунктах выдачи вы товар принимаете, а не продаете.
На самом деле, если ваша должность была сисадин или DBA, DBA кстати пишут фолианты об оптимизации серверов, вопросов бы не было. Я бы первый поставил +, написал бы здесь красавчеГ и откланялся.
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.
Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.
Что касается видения - ваша структура в точь точь похожа на любого крупного ретейлера, за той разницей - что на пунктах выдачи вы товар принимаете, а не продаете.
На самом деле, если ваша должность была сисадин или DBA, DBA кстати пишут фолианты об оптимизации серверов, вопросов бы не было. Я бы первый поставил +, написал бы здесь красавчеГ и откланялся.
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.
(74) capitan,
Извиняюсь, что не понял вопрос. Для нас тестирование - это именно функциональные тесты.
Реиндексация делается средствами СУБД. Пересчет итогов - делается в режиме предприятия. Реструктуризация всей базы - не делается, при необходимости делается для конкретного объекта. Проверки логической и ссылочной целостности сами по себе (на всякий случай) смысла не имеют, у нас много "битых" ссылок в силу особенности реализации отдельных подсистем.
По реструктуризации и проверкам целостности - не возможность использования именно ТиИ ни как не мешает, все возникающие задачи решались своими силами.
Нахождение справочника контрагентов в одной базе с остальными объектами конфигурации само по себе ничего не нарушает. Персональные данные это четко обозначенная информация о физ лице. Если эта информация храниться в базе, её можно шифровать, очищать, хранить эти данные в "другой БД" и т.д. и т.п. Но я искренне не понимаю при чем тут 3000 пользователей, если в БД их только 30, то на закон можно и подзабить? или эту проблему будет проще решить? Мне видится что закон касается любой системы, распределенной или нет - без разницы.
Груз и принимается и выдается. Это только часть основного бизнес процесса, вокруг него много вспомогательных (информирование клиентов, анализ ожидаемого грузопотока, планирование состава машины и её маршрута - только часть из них).
Не переходите на личности, вы ничего не знаете про мои знания. Касаемо сисадмина - да, сисадмин обычно не думает (и не должен) про то, что бы бизнес работодателя был более эффективен. Мне прекрасно известны все недостатки больших баз, но то, что вас смущает обоснование в виде удобства для бизнеса, говорит что вы далеки от руководящих позиций.
Про распределенку.
Если разговор зашел про недостатки больших баз, то всем (без сарказма - мне тоже) будет полезно увидеть как подобные проблемы решаются в распределенных системах и в чем их профит.
Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.
Извиняюсь, что не понял вопрос. Для нас тестирование - это именно функциональные тесты.
Реиндексация делается средствами СУБД. Пересчет итогов - делается в режиме предприятия. Реструктуризация всей базы - не делается, при необходимости делается для конкретного объекта. Проверки логической и ссылочной целостности сами по себе (на всякий случай) смысла не имеют, у нас много "битых" ссылок в силу особенности реализации отдельных подсистем.
По реструктуризации и проверкам целостности - не возможность использования именно ТиИ ни как не мешает, все возникающие задачи решались своими силами.
Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.
Нахождение справочника контрагентов в одной базе с остальными объектами конфигурации само по себе ничего не нарушает. Персональные данные это четко обозначенная информация о физ лице. Если эта информация храниться в базе, её можно шифровать, очищать, хранить эти данные в "другой БД" и т.д. и т.п. Но я искренне не понимаю при чем тут 3000 пользователей, если в БД их только 30, то на закон можно и подзабить? или эту проблему будет проще решить? Мне видится что закон касается любой системы, распределенной или нет - без разницы.
Что касается видения - ваша структура в точь точь похожа на любого крупного ретейлера, за той разницей - что на пунктах выдачи вы товар принимаете, а не продаете.
Груз и принимается и выдается. Это только часть основного бизнес процесса, вокруг него много вспомогательных (информирование клиентов, анализ ожидаемого грузопотока, планирование состава машины и её маршрута - только часть из них).
На самом деле, если ваша должность была сисадин или DBA,...
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.
Не переходите на личности, вы ничего не знаете про мои знания. Касаемо сисадмина - да, сисадмин обычно не думает (и не должен) про то, что бы бизнес работодателя был более эффективен. Мне прекрасно известны все недостатки больших баз, но то, что вас смущает обоснование в виде удобства для бизнеса, говорит что вы далеки от руководящих позиций.
Про распределенку.
Если разговор зашел про недостатки больших баз, то всем (без сарказма - мне тоже) будет полезно увидеть как подобные проблемы решаются в распределенных системах и в чем их профит.
Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
(75) "Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая."
Думаю аналогично.
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая."
Думаю аналогично.
(77) На самом деле, часть из этих проблем решаема, приведу пример как это решено у нас (продуктовая дистрибуция), несколько филиалов:
1.Двух сторонние обмены и как следствие конфликты изменений.
Организован РИБ, в каждом филиале подчиненный узел. Вся НСИ вводится только в центральной базе, различные виды документов могут быть отредактированы либо только в центральной базе, либо только на филиале. Аналогично организован обмен с бухгалтерской программой. Конфликты изменений практически исключены.
2.Процесс обновления более трудоемок за счет увеличения количества баз.
На самом деле, это критично если баз больше 10-15, на меньшем числе увеличение трудоемкости малозначительно, причем, при желании, это все можно еще и автоматизировать.
3.Все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
В центральную базу переносится не вся информация из филиалов, а только те данные, которые нужны для построения сводных отчетов по всей компании. В нашем случае, например, только информация о продажах.
4.Увеличение парка серверов и баз данных, требуется больше серверных лицензий - в общем, это не очень большие затраты, если "размазать" их на все время эксплуатации железа.
Очевидно, что этот подход также имеет свои минусы, но вполне себе имеет право на жизнь.
Автор конечно молодец, очень интересный кейс, но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор :) и бездумно брать этот пример и пытаться повторить не стоит...
1.Двух сторонние обмены и как следствие конфликты изменений.
Организован РИБ, в каждом филиале подчиненный узел. Вся НСИ вводится только в центральной базе, различные виды документов могут быть отредактированы либо только в центральной базе, либо только на филиале. Аналогично организован обмен с бухгалтерской программой. Конфликты изменений практически исключены.
2.Процесс обновления более трудоемок за счет увеличения количества баз.
На самом деле, это критично если баз больше 10-15, на меньшем числе увеличение трудоемкости малозначительно, причем, при желании, это все можно еще и автоматизировать.
3.Все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
В центральную базу переносится не вся информация из филиалов, а только те данные, которые нужны для построения сводных отчетов по всей компании. В нашем случае, например, только информация о продажах.
4.Увеличение парка серверов и баз данных, требуется больше серверных лицензий - в общем, это не очень большие затраты, если "размазать" их на все время эксплуатации железа.
Очевидно, что этот подход также имеет свои минусы, но вполне себе имеет право на жизнь.
Автор конечно молодец, очень интересный кейс, но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор :) и бездумно брать этот пример и пытаться повторить не стоит...
(79) genayo,
Спасибо за опыт. Все имеет право на жизнь, и у всего есть как минусы так и плюсы.
Если говорить о комфортных 100 пользователях в одной БД, получится 30 баз))
При текущем анализе возможности функционального разделения базы (не территориального, именно функционального) рассматривался вариант минимум из 10 баз.
Регистр с информацией о продажах у нас один из лидеров по размеру. Второй лидер, информация о движении груза, так же будет нужен в центральной БД для построения статистических отчетов. Мы оценивали какой бы мог быть профит и получается, что самые объемные таблицы все равно будут нужны в центральной БД. Как вариант - переписать всё, сделав разную конфигурацию под центр и под филиал. Продумав логику хранения данных можно будет что то сэкономить. Долго и дорого, но возможно.
Главное то, что кластер 1С справляется с этой задачей. У многих есть опасения именно это момента.
Спасибо за опыт. Все имеет право на жизнь, и у всего есть как минусы так и плюсы.
На самом деле, это критично если баз больше 10-15
Если говорить о комфортных 100 пользователях в одной БД, получится 30 баз))
При текущем анализе возможности функционального разделения базы (не территориального, именно функционального) рассматривался вариант минимум из 10 баз.
В центральную базу переносится не вся информация из филиалов, а только те данные, которые нужны для построения сводных отчетов по всей компании. В нашем случае, например, только информация о продажах.
Регистр с информацией о продажах у нас один из лидеров по размеру. Второй лидер, информация о движении груза, так же будет нужен в центральной БД для построения статистических отчетов. Мы оценивали какой бы мог быть профит и получается, что самые объемные таблицы все равно будут нужны в центральной БД. Как вариант - переписать всё, сделав разную конфигурацию под центр и под филиал. Продумав логику хранения данных можно будет что то сэкономить. Долго и дорого, но возможно.
но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор
Главное то, что кластер 1С справляется с этой задачей. У многих есть опасения именно это момента.
(79) genayo, не могу удержаться от off топа)
Бездумно - нет! Но пробовать и повторять - однозначно стоит! Сейчас для этого есть все инструменты и даже поддержка от 1С (ЦКТП). Чем больше будет подобный кейсов, тем лучше.
бездумно брать этот пример и пытаться повторить не стоит...
Бездумно - нет! Но пробовать и повторять - однозначно стоит! Сейчас для этого есть все инструменты и даже поддержка от 1С (ЦКТП). Чем больше будет подобный кейсов, тем лучше.
(81) У меня есть аргументы против такой точки зрения, но тема то конечно не про это, поэтому здесь их высказывать не буду. Позволю себе еще один вопрос вдогонку - вы хотя-бы гипотетически рассматриваете переход на 8.3, или вы считаете, что без новшеств, добавленных в 8.3 можно прожить (себе я тоже кстати этот вопрос задаю, однозначного ответа у меня пока нет...)?
(82) genayo,
Переход на 8.3 рассматривается. Интересны не столько программные "фишки", сколько оптимизация платформы и возможности кластера. Например в платформе изменена работа с временными таблицами (создается кластерный индекс и сам индекс не удаляется после выполнения запроса), наличие физических таблиц срезов. А в кластере привлекает возможность разделения функций по отдельным серверам.
Переход на 8.3 рассматривается. Интересны не столько программные "фишки", сколько оптимизация платформы и возможности кластера. Например в платформе изменена работа с временными таблицами (создается кластерный индекс и сам индекс не удаляется после выполнения запроса), наличие физических таблиц срезов. А в кластере привлекает возможность разделения функций по отдельным серверам.
(57) МихаилМ,
У нас ограничение от бизнеса - полное время обновления не должно превышать 2ч. За 2 часа, на хороших дисках, успевает реструктуризироваться почти любой объект метаданных. Есть и объекты, которые за это время не успевают, их мало и чаще всего это что то из базового бизнес-процесса, который редко меняется.
Если надо больше двух часов - разделяем обновление по объектно, если и это не помогает, то эти изменения откладываются до больших праздников.
автор, как решили проблему долгой реструктуризации ?
У нас ограничение от бизнеса - полное время обновления не должно превышать 2ч. За 2 часа, на хороших дисках, успевает реструктуризироваться почти любой объект метаданных. Есть и объекты, которые за это время не успевают, их мало и чаще всего это что то из базового бизнес-процесса, который редко меняется.
Если надо больше двух часов - разделяем обновление по объектно, если и это не помогает, то эти изменения откладываются до больших праздников.
(61) Painted,
Задач таких нет. Но раньше, в далекие времена 8.0 и когда веб сервисы плохо работали с большим количеством коннектов, то запросы сайта как раз и делали "прямые" запросы в базу-копию (раз в неделю разворачивали из бэкапа)
Прямыми запросами к MS SQL не баловались?
Задач таких нет. Но раньше, в далекие времена 8.0 и когда веб сервисы плохо работали с большим количеством коннектов, то запросы сайта как раз и делали "прямые" запросы в базу-копию (раз в неделю разворачивали из бэкапа)
(62) vec435,
Причин ровно две:
1. 1С справляется и при всех её недостатках она нам нравится.
2. Стоимость. Менять придется не только платформу, но и саму учетную систему, а это очень дорого и очень долго.
а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?
Причин ровно две:
1. 1С справляется и при всех её недостатках она нам нравится.
2. Стоимость. Менять придется не только платформу, но и саму учетную систему, а это очень дорого и очень долго.
(68) asved.ru,
Пользователи с базой работают терминально.
Показатели достаточно стабильны (исключение - время выполнения регламентных операций), в основном диапазон значений колеблется в нтервале 0,98 - 0,99.
Критичные отклонения - ниже 0,9. При 0,95 уже режим повышенного внимания. Но опять таки это наша специфика из-за большого количества пользователей. Грубо говоря APDEX 0,97 означает, что более 3% пользователей работают вне комфортной скорости. 3% это 90 пользователей, т.е. потенциально это 90 жалоб. Поэтому после внедрения APDEX'а была притирка - сопоставляли объем поступающих жалоб со значением показателя.
А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании.
Пользователи с базой работают терминально.
Насколько стабильны показатели APDEX? Какое отклонение вы считаете заслуживающим реакции?
Показатели достаточно стабильны (исключение - время выполнения регламентных операций), в основном диапазон значений колеблется в нтервале 0,98 - 0,99.
Критичные отклонения - ниже 0,9. При 0,95 уже режим повышенного внимания. Но опять таки это наша специфика из-за большого количества пользователей. Грубо говоря APDEX 0,97 означает, что более 3% пользователей работают вне комфортной скорости. 3% это 90 пользователей, т.е. потенциально это 90 жалоб. Поэтому после внедрения APDEX'а была притирка - сопоставляли объем поступающих жалоб со значением показателя.
Можно узнать подробнее про процесс разработки?
Какие проблемы возникают с таким большим количеством людей разработчиков в одной базе (у вас ведь одно хранилище или вы пользуетесь другими средствами совместной разработки)?
Как планируется время на выполнение задачи с учетом того, что (мое предположение) часто нужные объекты бывают захвачены другими разработчиками (а ведь еще есть тестирование)?
ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища. Наверное, есть то число, после которого уже увеличение количества разработчиков бессмысленно. Хотелось бы услышать Ваше мнение по этому поводу.
Какие проблемы возникают с таким большим количеством людей разработчиков в одной базе (у вас ведь одно хранилище или вы пользуетесь другими средствами совместной разработки)?
Как планируется время на выполнение задачи с учетом того, что (мое предположение) часто нужные объекты бывают захвачены другими разработчиками (а ведь еще есть тестирование)?
ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища. Наверное, есть то число, после которого уже увеличение количества разработчиков бессмысленно. Хотелось бы услышать Ваше мнение по этому поводу.
(84) Irwin, не все программисты работают на одну базу. У нас есть и типовые и несколько баз помельче. В этой базе, если не ошибаюсь, порядка 15 разработчиков.
Работаем через хранилище. Снижение конкуренции за объекты достигается разделением кода на логические блоки (функциональные подсистемы) и их выносом в отдельные модули. Для особо популярных объектов разделение вплоть до того, что каждая печатная форма в своем модуле. Плюс есть специализация разработчика, т.е. задачи в рамках одной подсистемы "придут" одному разработчику.
ИМХО, как и при работе пользователей, количество блокировок при разработке зависит от архитектуры конфигурации.
Работаем через хранилище. Снижение конкуренции за объекты достигается разделением кода на логические блоки (функциональные подсистемы) и их выносом в отдельные модули. Для особо популярных объектов разделение вплоть до того, что каждая печатная форма в своем модуле. Плюс есть специализация разработчика, т.е. задачи в рамках одной подсистемы "придут" одному разработчику.
ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища
ИМХО, как и при работе пользователей, количество блокировок при разработке зависит от архитектуры конфигурации.
Ничего удивительно ни в размере базы, ни в количестве пользователей нет. Наслышан об успешной оптимизации и рефакторинге кода от непосредственных исполнителей. На сегодняшний день очень много крупных компаний использующих 1С с объемами баз свыше 1 Тр и количеством пользователей от 500 (данные на одну базу). Есть компании в которых используются более 120 независимых баз между которыми осуществляется онлайн обмен. Реструктуризация больших таблиц средствами 1С - процедура долгая и утомительная. Даже при хорошем железе добавление нового реквизита в 1С с простым типом - несколько часов при объеме таблицы свыше 100 Гб и количестве записей от 80 млн. и более, естественно используются другие возможности. Это уже не говоря об удалении такого реквизита :), с проверкой логической и ссылочной целостностью базы. Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ? Используете data кластер от SoftPoin ? По заголовку запросов и происходит разделение (перенаправление) на различные сервера СУБД ? Как обошли отчеты в которых требуется создавать промежуточные временные таблицы ?
(86) Slon1c,
Удивительного нет, для того и доклад готовился, дабы меньше удивлялись. Чем больше примеров будет, тем лучше для сообщества.
Реструктуризацию используем только типовую, причин несколько, но основная - добавление колонки в существующую таблицу SQL возможно только с типом "содержит NULL", это может привести к построению плана запроса с избыточными операциями.
И так и нет) Изначально архитектура БД именно так и строилась - все данные в документах (это было сделано осознанно и на то были причины, но это тема отдельного холивара). Но уже несколько лет все новые проекты реализуются с ориентацией на регистры и это, в том числе, значительно увеличило ускорение роста объема данных..
Дата кластер действительно отличная штука, ей бы добавить признание от самой 1С и совместно создать мощный инструмент. На текущий момент оптимизация кода дала такой эффект, что мы можем работать и без отчетной базы и без дата кластера, но обе технологии повышают запас прочности и надежность системы в целом (плюс "горячий" бэкап), поэтому и остаются в строю.
Удивительного нет, для того и доклад готовился, дабы меньше удивлялись. Чем больше примеров будет, тем лучше для сообщества.
Реструктуризацию используем только типовую, причин несколько, но основная - добавление колонки в существующую таблицу SQL возможно только с типом "содержит NULL", это может привести к построению плана запроса с избыточными операциями.
Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ?
И так и нет) Изначально архитектура БД именно так и строилась - все данные в документах (это было сделано осознанно и на то были причины, но это тема отдельного холивара). Но уже несколько лет все новые проекты реализуются с ориентацией на регистры и это, в том числе, значительно увеличило ускорение роста объема данных..
Используете data кластер от SoftPoin ?
Дата кластер действительно отличная штука, ей бы добавить признание от самой 1С и совместно создать мощный инструмент. На текущий момент оптимизация кода дала такой эффект, что мы можем работать и без отчетной базы и без дата кластера, но обе технологии повышают запас прочности и надежность системы в целом (плюс "горячий" бэкап), поэтому и остаются в строю.
(87) по поводу новых колонок с реструктуризацией, то достаточно быстрый вариант такой: переименовывается исходная таблица, предварительно создается скрипит CREATE для таблицы. После переименовывания таблица создается, проводится реструктуризация, после чего через INSERT INTO SELECT FROM ...в старую уже отреструктуризированную таблицу вставляются записи из переименованной исходной таблицы. В итоге и поля "без нуллов", и данные вставлены куда быстрее, чем штатными механизмами, ибо штатный механизм читает записи, потом проверяет на типы данных, и если тип изменился и теперь не содержится в поле, то он очищает данное поле, после чего уже очищенный вариант пишет в таблицу. Это ну о-о-о-о-о-чень долго...
(101) starik-2005,
На сайте уже было одно из решений и мы уже общались на эту тему.
Там, кстати, вы другое решение озвучивали
после чего через INSERT INTO SELECT FROM ...в старую уже отреструктуризированную таблицу вставляются записи
не понял профит, именно эта операция самая длительная при типовой реструктуризации.
На сайте уже было одно из решений и мы уже общались на эту тему.
Там, кстати, вы другое решение озвучивали
Потом переименовываю старую таблицу обратно и АЛЬТЕР КООЛОНКА/АЛЬТЕР ИНДЕКС создаю соответствующие колонки и индексы.
и оно больше похоже на правду ;)
(102) да, я оба варианта использую. Но в последнее время из-за лени, видимо, чаще именно вариант с копированием применяю. Последний раз данную процедуру буквально на днях применял - у клиента есть регистр с 6кк записей. Достаточно большой. В него добавили ресурс текстовой - строка 10 символов. В итоге система на тестовом стенде реструктуризировалась очень долго - не дождались (думаю, примерно неделя бы ушла). При том вставка заняла всего 3 часа. Но это железки обычные - не ваши.
Есть у меня мнение, что большинство не понимает, как работает реструктуризация. Если бы она просто копировала данные из одной таблицы в другую за раз (ins ert in to tb1 sel ect * fr om tb2), то это было бы просто шикарно и скорость такой реструктуризации многих бы удивила. Но 1С все делает не так. Она читает порцию из таблицы 1, потом обрабатывает ее (проверяет соответствие типов полей с метаданными - как часть механизма), потом эту порцию записывает в таблицу с суффиксом NG. После того, как все объекты обновлены, 1С в транзакции удаляет старые таблицы и переименовывает таблицы NG. Основное время реструктуризации занимает обработка данных платформой, ну и порционность вставки вносят свою лепту, ибо одно дело - один запрос на сервере выполняется, совсем другое - куча запросов + данные, метаемые с сервера SQL на сервер приложений и обратно. Один сетевой трафик чего стоит.
Есть у меня мнение, что большинство не понимает, как работает реструктуризация. Если бы она просто копировала данные из одной таблицы в другую за раз (ins ert in to tb1 sel ect * fr om tb2), то это было бы просто шикарно и скорость такой реструктуризации многих бы удивила. Но 1С все делает не так. Она читает порцию из таблицы 1, потом обрабатывает ее (проверяет соответствие типов полей с метаданными - как часть механизма), потом эту порцию записывает в таблицу с суффиксом NG. После того, как все объекты обновлены, 1С в транзакции удаляет старые таблицы и переименовывает таблицы NG. Основное время реструктуризации занимает обработка данных платформой, ну и порционность вставки вносят свою лепту, ибо одно дело - один запрос на сервере выполняется, совсем другое - куча запросов + данные, метаемые с сервера SQL на сервер приложений и обратно. Один сетевой трафик чего стоит.
Сергей, подскажите пожалуйста, вы описывали, что у вас достаточно много запросов со стороны сайта к web сервисам 1с. Хотелось бы узнать поподробнее, что используется IIS, Apache?
Какое примерно к-во запросов в минуту/час ? С какими проблемами в этой связке столкнулись?
Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например ?
И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Какое примерно к-во запросов в минуту/час ? С какими проблемами в этой связке столкнулись?
Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например ?
И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
(88) dablack,
>Хотелось бы узнать поподробнее, что используется IIS, Apache?
Apache.
>Какое примерно к-во запросов в минуту/час ?
Запросов к веб серверам, со слов их админа, порядка 1500/минуту.
>С какими проблемами в этой связке столкнулись?
Работает достаточно надежно. Основное, с чем боролись - настройка таймингов. Суть проблемы (упрощенно) - если запрос выполняется дольше указанного в настройках веб сервера тайм аута, то число коннектов от веб сервера к базе увеличивается. Увеличиваться может до "бесконечности". Для объективно долго выполняющихся сервисов увеличивали тайминг + оптимизация кода и запросов.
>Хотелось бы узнать поподробнее, что используется IIS, Apache?
Apache.
>Какое примерно к-во запросов в минуту/час ?
Запросов к веб серверам, со слов их админа, порядка 1500/минуту.
>С какими проблемами в этой связке столкнулись?
Работает достаточно надежно. Основное, с чем боролись - настройка таймингов. Суть проблемы (упрощенно) - если запрос выполняется дольше указанного в настройках веб сервера тайм аута, то число коннектов от веб сервера к базе увеличивается. Увеличиваться может до "бесконечности". Для объективно долго выполняющихся сервисов увеличивали тайминг + оптимизация кода и запросов.
(88) dablack,
>Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например ?
Специально никто переписывать обычного клиента не будет - работа ради работы (да простят меня фанаты тонкого клиента и управляемых форм). Остальное будет рассматриваться в рамках запрашиваемой функциональности, если по условию задачи лучшим выходом будет metadata, то в эту сторону и будем смотреть.
>И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Тут все просто. Самописная dll для работы через API CISCO. 1с тут играет роли "выгрузить очередь для обзвона" и "найти клиента по номеру телефона и отобразить данные".
>Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например ?
Специально никто переписывать обычного клиента не будет - работа ради работы (да простят меня фанаты тонкого клиента и управляемых форм). Остальное будет рассматриваться в рамках запрашиваемой функциональности, если по условию задачи лучшим выходом будет metadata, то в эту сторону и будем смотреть.
>И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Тут все просто. Самописная dll для работы через API CISCO. 1с тут играет роли "выгрузить очередь для обзвона" и "найти клиента по номеру телефона и отобразить данные".
Сергей, Вы пишете:
Вопрос:
Уточните, пожалуйста, какие именно блокировки имелись ввиду? Какие транзакции ожидали освобождения этих блокировок? Конкретно каким образом удалось решить эту проблему? Неужели отказались от использования этого метода? А что использовали взамен?
Улучшили подсистему репликации и добились актуальности данных в 2 – 3 минуты, что значительно расширило список перенаправляемых отчетов. Доработки в основном были нужны потому, что стандартный метод "ВыбратьИзменения" планов обмена создает большое колличество блокировок.
Вопрос:
Уточните, пожалуйста, какие именно блокировки имелись ввиду? Какие транзакции ожидали освобождения этих блокировок? Конкретно каким образом удалось решить эту проблему? Неужели отказались от использования этого метода? А что использовали взамен?