Филиппов Олег | Руководитель Управления ИТ | WiseAdvice

«Как должна выглядеть правильная интеграция. Использование Mule ESB и RabbitMQ с 1С»

- Откуда берутся эти "сообщения"? Событийная интеграция вместо выгрузок по расписанию. - Зачем нужны Интеграционные шины, Middleware, очереди сообщений: - Почему нельзя "просто сделать http сервис в 1C и записывать данные при вызове"? - Почему не надо тратить время на регистры сведений вида "ОчередьСообщений, ИсторияСообщений"? - Правильная организация архитектуры (очередь, логирование, работа с ошибками). - Маленькие трюки. Использование ElasticSearch для логирования. - Инструментарий отладки http интеграций (Fiddler, Postman, SoapUI). - А как же 1С? EnterpriseData как шаг к событийной интеграции.

Опыт оптимизации и контроля производительности в БД с 3000 пользователей

0. Sergey.Noskov 890 14.07.15 12:20 Сейчас в теме
Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии".
Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность.
Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры.
**update от 04.03.2016 по вопросам из комментариев

Перейти к публикации

Комментарии
Сортировка: Древо
1. baton_pk 370 05.08.15 20:05 Сейчас в теме
А можно узнать размеры базы и параметры оборудования?
А из КИПа кроме ЦУПа чем-нибудь ещё пользовались? ЦКК, например, нагрузочное тестирование?
ivanov660; qwed557; +2 Ответить
6. Sergey.Noskov 890 06.08.15 10:32 Сейчас в теме
(1) baton_pk,
На текущий момент файл данных >4Тб
По железу можно посмотреть в проекте ЦКТП http://v8.1c.ru/expert/cts/cts-218-001.htm не один-в-один, но очень близко.
Из КИП еще пользовались стандартным нагрузочным тестом, под определенные задачи он подходит. ЦКК не использовали, присматриваемся.
17. baton_pk 370 06.08.15 19:01 Сейчас в теме
(6)
На текущий момент файл данных >4Тб

Я работаю с базами на порядок меньше (сотни гигов), но уже там возникают проблемы, как то:
1) резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются
2) обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.
3) данные: вычистить мусор, пересчитать итоги (на базе в 600 гигов это занимало 10 часов на MSSQL и 12 на Постгресе), конфу поменять, индексы добавить

как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?

PS. кстати, не пробовали dt-шку выгрузить ? :-D
34. Sergey.Noskov 890 07.08.15 10:53 Сейчас в теме
(17) baton_pk,
резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются

Благодаря AlwaysOn и отчетной базе у нас всегда на готове 2 базы - копии. Но и ежедневное бекапирование делается, чуть дольше 3х часов идет.

обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.

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

как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?

Не скупимся на СХД ;) Жертвуем реструктуризацией.

PS. кстати, не пробовали dt-шку выгрузить ? :-D

Попробую расскажу)
2. ivanov660 706 05.08.15 22:29 Сейчас в теме
У меня есть несколько вопросов по архитектуре описываемой высоконагруженной системы:
1. Какое разграничение прав доступа используется? Используется ли RLS? Какое количество в среднем различных ограничений видов доступа на одного пользователя?
2. Какая структура кластеров 1С? Используется ли масштабирование средствами 1С? Используется ли резервирование средствами 1С, каков параметр отказоустойчивости?
3. Используется ли виртуализация?
4. Конфигурация на обычных формах?
5. Какова средняя сложность запросов отчетов? Сколько таблиц участвуют в соединениях, есть ли виртуальные?

P.S. Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))
Kaval88; JohnyDeath; dj_serega; +3 Ответить
5. dj_serega 352 06.08.15 10:32 Сейчас в теме
(2) ivanov660, Присоединяюсь к вопросам.
10. Sergey.Noskov 890 06.08.15 11:40 Сейчас в теме
(2) ivanov660,
1. RLS не используется. Разграничиваем двумя этапами - роли (предварительное разграничение) и регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.
2. В кластере один центральный сервер и 3 дополнительных. Из "особенностей" только то, что у центрального сервера нет rphost'ов (APDEX у пользователей, работающих на процессах центрального сервера, стабильно хуже чем на других серверах). Резервирование кластера не используем, рассматривали возможность - пугает большое количество негативных отзывов, поэтому надо делать тестирование на 3500+ юзеров. Сейчас отказоустойчивость обеспечивается количеством доп серверов (если один выходит из строя - кластер будет способен это пережить) и отсутствием процессов на центральном сервере.
3. Виртуализация только на терминальных машинах. Добавляли в кластер виртуальный сервер 1С, идентичный по железу, APDEX на нем был на 1 - 2% ниже.
4. Формы обычные, клиенты толстые)
5. Сложные запросы. Архитектура изначально строилась по принципам "нет лишним таблицам" и "зачем нам регистр, если все есть в документе", поэтому все не просто.

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

3000 пользователей у нас работали еще на 8.1 и все было отлично. Перефразируя классика, "роль управляемых форм в производительности сильно преувеличена" ;)
корум; Atori-kun; adhocprog; artbear; Diego_Iv; vlad.frost; vasyak319; bforce; ivanov660; Bronislav; baton_pk; +11 Ответить
25. Rustig 973 06.08.15 23:12 Сейчас в теме
(10) спасибо за подробности! смелый шаг!
111. nvv1970 30.10.17 20:15 Сейчас в теме
(10) управляемые формы позволяют разгрузить терминальные сервера, а сервер 1с наоборот - загрузить.

1с запретила делать резервирование серверов на 8.2. В 8.3 нет проблем с отказоустойчивостью?
112. Sergey.Noskov 890 31.10.17 11:46 Сейчас в теме
(111)
В 8.3 нет проблем с отказоустойчивостью?
Так понимаю вопрос касается следующего проекта, уже по переходу на 8.3. Давайте с определением для начала разберемся, а то под отказоустойчивостью можно понимать разные вещи.
Если говорить про резервирование серверов (что и дает полноценную отказоустойчивость), то на 8.3.10 и ранее работает не очень хорошо (в последних релизах оно даже работает, но при включении заметна деградация в скорости работы), поэтому мы пока не используем. Тесты 8.3.11 показывают хорошие результаты, APDEX практически не отличается от режима без резервирования т.ч. надежда есть.
Если же говорить про отказоустойчивость в рамках стабильной работы (отсутствие без причинных вылетов, закрытия сеансов), то тут все хорошо, сейчас работаем на 8.3.10.
113. nvv1970 31.10.17 11:54 Сейчас в теме
(112) Спасибо за ответ. В терминологии могу быть неточен, сорри.
Про деградацию при использовании нескольких центральных серверов в теме. Если центральный один + несколько "вспомогательных" - то вопросов, как я понимаю, в части производительности не возникает?
Меня больше интересовала позиция 1с, раз уж у вас с ними очень тесный контакт )
114. Sergey.Noskov 890 31.10.17 12:42 Сейчас в теме
(113)
Если центральный один + несколько "вспомогательных" - то вопросов, как я понимаю, в части производительности не возникает?
тут все нормально, да.
За позицию 1С не скажу)) но в целом видно желание сделать все хорошо и красиво.
3. Red_Devil 165 06.08.15 10:03 Сейчас в теме
700 тысяч проведений в сутки??? Мы не знаем что со своими 100 пользователями в УПП делать а тут такое =0
4. baton_pk 370 06.08.15 10:15 Сейчас в теме
(3) Red_Devil, выкиньте УПП, заведите отдел разработки в 40+ человек, запилите самописку, пригласите ЦКТП.
KEV8383; корум; lustin; AlexeyFreeLife; ZLENKO; ojiojiowka; Rustig; siddy; +8 Ответить
8. Red_Devil 165 06.08.15 10:45 Сейчас в теме
(4) baton_pk, аа у них самописка, тогда конечно можно написать документ с 1 регистром =) Жаль в типовых такого не добьешься.
9. Sybr 226 06.08.15 10:56 Сейчас в теме
(8) Скорее всего в этой самописке регистров больше чем в типовой УПП.
KEV8383; корум; +2 Ответить
13. Lostar 06.08.15 14:46 Сейчас в теме
(3) Red_Devil, ну так УПП ж. Ужасающе неоптимизированный продукт по производительности. Даже 5 пользователе могут рождать deadlock`и.
7. kolya_tlt 11 06.08.15 10:41 Сейчас в теме
можно узнать подробности при переводе на 8.2? с какими трудностями столкнулись, что не учли помимо тестирования?
в чем он заключался, просто в конвертации? отказывались ли от совместимости?
в рамках проекта цктп какой франч участвовал ?
11. Sergey.Noskov 890 06.08.15 13:39 Сейчас в теме
(7) kolya_tlt, Переход на 8.2.13, тот который делали своими силами, провалился из-за поведения кластера 1С - он отказывался балансировать сеансы. Все пользователи оказались на одном сервере - самом мощном по железу. Плюс кластер постоянно "тасовал" сеансы между процессами. Конфигурацию готовили без совместимости, все программные "нюансы" выловили при тестировании логики. Вот список замечаний, который мы в то время для себя составляли:

-Работа с NULL в запросах при использовании конструкций вида ЕСТЬNULL("("+Таблица.Поле+")") // старый комент, возможно исправлено в свежей версии
-Проверить наличие везде проверки на ОбменДанным.Загрузка // для репликации
-Заменить вызова ОткрытьФормуМодально()
-Убрать третий параметр из вызовов ПравоДоступа()
-В процедуру обработчик события «ОбработкаЗаполнения» передается структура, в которой может и не быть поля Ссылка.
-Исправить формат булево по умолчанию на Истина и Ложь.
-Не работает формат даты с использованием YYYY
-Функция ТипЗнч() - не возвращает "...Ссылка...", «Документ..» и т.п., соответственно не работает код вида Найти(ТипЗнч(СсылочноеЗначение), «Справочник»)
-При не использовании Наименования или Кода справочника необходимо отключить его проверку - открыть СтандартныеРеквизиты на закладке объекта Данные и в свойствах нужного
реквизиты указать Проверка - Не использовать.
-Ошибка при выполнении кода вида: ТабДок.Вывести(ТабДокКопия.Область());
-Не работают запросы с условием вида &Контрагент В (Таблица.Получатель, Таблица.Отправитель, Таблица.Объект) если какое то из полей Таблица.Получатель, Таблица.Отправитель, Таблица.Объект - составного типа // всегда возвращается ЛОЖЬ
-Не работают запросы с условием вида ГДЕ Документ.ТабличнаяЧасть.Ссылка ЕСТЬ НЕ NULL // всегда возвращается ИСТИНА
-Для протокола POP3 не корректно работает метод ИнтернетПочта.ПолучитьЗаголовки(); // все заголовки с одинаковым идентификатором сообщения
Показать


Привлечение ЦКТП изначально и обосновывалось необходимостью повысить стабильность работы платформы. Плюс мы решили вторую задачу - спрогнозировать поведение системы при двукратном увеличении количества пользователей (и производимой ими работы есессно).
Про франч - приводил ссылку на проект. Богачев Виктор (участвовавший эксперт) так же был на конференции и подробно рассказывал про это тестирование.
CratosX; Rustig; kolya_tlt; +3 Ответить
18. kolya_tlt 11 06.08.15 20:39 Сейчас в теме
(11) 1. в итоге какая версия платформы вела себя достаточно стабильно для текущей работы?
2. чем и зачем заменяли ОткрытьФормуМодально?
3. что подразумевается под "Исправить формат булево по умолчанию"?
35. Sergey.Noskov 890 07.08.15 11:02 Сейчас в теме
(18) kolya_tlt, Версия платформы - начиная с 8.2.19.83, сейчас обновились на 8.2.19.130

чем и зачем заменяли ОткрытьФормуМодально?

не актуальный комент, у нас в 8.1 была своя такая функция, поэтому пришлось переименовывать

что подразумевается под "Исправить формат булево по умолчанию"?

В конфигураторе, Администрирование - Региональные установки, в 8.2 по умолчанию стоит Да и Нет - части пользователей не понравилось. Мы и цветовую схему настраивали максимально близко к 8.1
37. kolya_tlt 11 07.08.15 11:08 Сейчас в теме
(35) а может быть актуализируете список ? :) по возможности конечно.
1. зачем нужна "Проверить наличие везде проверки на ОбменДанным.Загрузка" ?
2. "Не работает формат даты с использованием YYYY" не работает где? и как вообще такое искали в коде?)
39. Sergey.Noskov 890 07.08.15 12:26 Сейчас в теме
(37) kolya_tlt, список актуальный, выкиньте пункт ОткрытьФормуМодально(), ну а формат булево по умолчанию - дело вкуса))
зачем нужна "Проверить наличие везде проверки на ОбменДанным.Загрузка" ?

ОбменДанными.Загрузка нужна для корректной работы обменов. Ну и вообще наличие этой проверки в событиях ПередЗаписью, ПриЗаписи это уже стандарт.

"Не работает формат даты с использованием YYYY" не работает где? и как вообще такое искали в коде?)

Ни в 8.2 не в 8.3 не работает, попробуйте выполнить Формат(ТекущаяДата(), "ДФ=dd.MM.YYYY")
Искали просто - глобальным поиском строку YYYY с учетом регистра.
12. DoctorRoza 06.08.15 14:44 Сейчас в теме
А вот мне стало интересно, ну что же это за контора то такая с такой базой? Энергетики или нефтяники что ли?
15. Bronislav 06.08.15 15:00 Сейчас в теме
(12) DoctorRoza, "Деловые линии" - транспортная компания.
16. Sergey.Noskov 890 06.08.15 15:08 Сейчас в теме
(15) Bronislav, раскрыл интригу)) приятно было быть нефтяником ;)
14. Lostar 06.08.15 14:53 Сейчас в теме
Автору огромное спасибо! Очень востребованная тема. Столько боли прожито с производительностью. Почему-то в нашей стране считается, что оптимизация sql это вопрос программистов 1С, хотя 101% из них не обладают не то, что достаточными, но даже начальными знаниями в этом вопросе.

Отдельное спасибо за скульные запросы. Будем пробовать.
19. Rustig 973 06.08.15 22:36 Сейчас в теме
(0) Со всем уважением к автору и к его докладу!
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)
База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...
38. Sergey.Noskov 890 07.08.15 12:13 Сейчас в теме
(19) Rustig, (26) Rustig, (31) Rustig,
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)

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

База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
ЦФ-шник в студию - уверен, что косяков там достаточно....

Слишком много внимания косякам, конечно есть и ошибки и просчеты, есть экстренные хотелки бизнеса, а ля "должно работать завтра". Не ошибается только тот, кто ничего не делает.
Но что бы половина обновления - исправление ошибок, серьезно? Частота обновления и количество программистов приведено для понимания скорости наращивания функционала. Постоянное развитие базы - это наша специфика.

Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...

Управляемые формы не использовались, на 8.2 мы перешли только в прошлом году, т.ч. основная разработка велась на 8.0 и 8.1
Формы списков - обычные, запросы которые вышли в топ - платформенные вызываемые, например, при скроллинге и выводе списка.
Построитель - да, "не красиво", но личное мнение, что для высоко нагруженных систем будущее за статичными формами поиска (интерфейс SAP это подтверждает). И красивые возможности типа таких http://v8.1c.ru/o7/201401ls/index.htm без контроля по каким колонкам можно искать, по каким можно искать строго на равенство, по каким нельзя сортировать и т.п. - пугают потенциальным воздействием на систему.

в докладе нет анализа первопричины проблем

Есть конечно. Это и рост самой компании и потребностей в части функционала.
47. Rustig 973 08.08.15 20:32 Сейчас в теме
(38) Вы точно уловили мое настроение! +
49. Rustig 973 08.08.15 20:46 Сейчас в теме
(38) Сергей, у вас много точек продаж, по факту они работают с "потоковым" клиентом. Очень напоминает розницу. Не думали представить всю вашу схему работы подразделений как сеть розничных точек продаж - на каждой точке своя небольшая база, вся информация собирается в центральной базе и т.д. и тому подобное?
52. a_titeev 5 08.08.15 22:24 Сейчас в теме
(49) Rustig, первый совет, с которого начинается книга Фаулера о распределенных системах звучит так - "не распределяйте системы! ну а если это по каким-то очень веским причинам невозможно, то для вас следующие 600 страниц текста". примерно так...
корум; Dach; dddxddd; Mi4man; sorb; Rustig; +6 Ответить
53. Sergey.Noskov 890 10.08.15 10:04 Сейчас в теме
(49) Rustig,
Не думали представить всю вашу схему работы подразделений как сеть розничных точек продаж - на каждой точке своя небольшая база

Думали, точнее не так, правильнее сказать, что изначально именно так и было :)
Повторю фразу, которую сказал на конференции: те, у кого одна большая база думают над её разделение, а те, у кого распределенная система, думают над её слиянием. Потому что не бывает идеальной системы, минусы есть и там и там.
"Распределенка" это как раз из рубрики двусторонних обменов, коллизий и не актуальности данных. Сейчас движение в сторону функционального разделения.
DimaP; Sybr; Rustig; +3 Ответить
20. Rustig 973 06.08.15 22:44 Сейчас в теме
Конечно запросы из форм списков были не единственными, мы переписали достаточно много запросов, а где то и архитектуру. Эта работа дала результат. Раньше, например, нагрузка на систему в понедельник и пятницу могла быть настолько высока, что приходилось отпускать домой некоторые отделы (менеджеров, колл-центр). А в результате проведенной оптимизации получилось снизить нагрузку в пятницу – проблем больше не было. Да и в понедельник мы тоже, со скрипом, но работали.


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

Штат разработчиков 20 человек. Сколько из них сертифицированы? Сколько из них с опытом свыше 3 лет программирования и консультирования? Вы извините , но 20 - ни о чем не говорит. А вот 20 профессионалов своего дела - уже впечатляет. :)
29. Sergey.Noskov 890 07.08.15 07:56 Сейчас в теме
(20) Rustig, Статей и докладов на тему оптимизации запросов очень много. Не было смысла тратить время конференции, тем более сразу за мной на эту тему выступал Андрей Бурмистров.

Про команду - сильная команда, 7 экспертов (4 сертифицировались уже работая у нас). Но берем не за корочки вовсе, это не показатель.
корум; +1 Ответить
21. Rustig 973 06.08.15 22:50 Сейчас в теме
(0) глава "Разделяй и властвуй" - очень поучительна!
22. Rustig 973 06.08.15 22:57 Сейчас в теме
обращайтесь в 1С, в рамках проектов ЦКТП достаточно оперативно устраняются и ошибки платформы и выявляются "узкие" места БД.


фирма 1с исправляет ошибки платформы исключительно для вас (в рамках договора цктп)? то есть вы остаетесь на том же релизе платформы, только с исправленными ошибками платформы? так что ли? при этом остальные компании исправления этих ошибок или получают с новыми релизами платформы, или не получают вовсе. правильно я вас понял?
28. Sergey.Noskov 890 07.08.15 07:37 Сейчас в теме
(22) Rustig, Нет, выходит официальный релиз, никаких исключений.
23. Rustig 973 06.08.15 23:06 Сейчас в теме
(0) ЦУП появился до управляемых форм.... Управляемые формы покамест тормозят и требуют дорогого железа..... неужели такой супер ЦУП не может выявить проблемы управляемых форм?....
какую помощь оказывает цуп? только лишь такую, что начинает контролировать разработку кривых запросов программистов....теперь их можно уволить - есть доказательства их некомпетентности ....
30. Sergey.Noskov 890 07.08.15 07:58 Сейчас в теме
(23) Rustig, Где управляемые формы? И при чем тут ЦУП...
31. Rustig 973 07.08.15 09:50 Сейчас в теме
(30) Сергей, я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику - решение точечное - производительность увеличивается... в докладе нет анализа первопричины проблем, есть диагностический инструмент.... пусть мое мнение будет на ветке....
по поводу управляемых форм - это вопрос не к вам... это риторический вопрос ко всем кто работает с цупом и знаком с тормозами управляемых форм...
спасибо за доклад и статью, считаю ее полезным кейсом )) всего доброго
76. ZLENKO 376 14.08.15 13:28 Сейчас в теме
(31) Rustig, "я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику - решение точечное - производительность увеличивается..."

Придерживаюсь аналогичного мнения. С ЦУП приходится повозиться чтобы его запустить и постоянно натыкался на глюки ЦУП. Быстрее всего текущую картину можно получить по Монитору активности в MS SQL Server - самые длительные запросы.
78. Sergey.Noskov 890 14.08.15 14:15 Сейчас в теме
(76) ZLENKO, Монитор активности пользуется теми же динамическими представлениями (dm_exec_query_stats и dm_exec_requests) только более сложно агрегирует получаемые данные.
Можно посмотреть в хранимку tempdb.dbo.#am_get_querystats_...
Сталкивались с тем, что монитор активности сам создаёт нагрузку, особенно если интервал обновления маленький и он открыт у нескольких человек.
24. Rustig 973 06.08.15 23:11 Сейчас в теме
регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.


ужас... механизм не то чтобы "не гибкий", а спорный в использовании....
32. kolya_tlt 11 07.08.15 09:56 Сейчас в теме
(24) Rustig, прошу аргументировать и предложить вариант
26. Rustig 973 07.08.15 00:45 Сейчас в теме
(0), (17) 4 Тб - тоже ни о чем!
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков? Деловые линии работают по всей России и м.б. за рубежом...
свертку давно делали?...
половину инфы можно удалить из рабочей базы - номенклатура которая сто лет не используется, контрагентов, которые давно не существуют, документы прошлых закрытых периодов например за 2000 год.... кому они нужны в текущей рабочей менеджерской базе?....
есть архив, если надо оттуда все достанете, есть дублирующая база, из нее можно вытащить любые документы.....
я уверен, что можно обойтись без цупа
ЦФ-шник в студию - уверен, что косяков там достаточно....
27. Fox-trot 54 07.08.15 07:34 Сейчас в теме
(26) Rustig,
ЦФ-шник в студию - уверен, что ....

мальчик, может тебе ключи от дома дать, где деньги лежат? (с) не_моё
wowik; Artem-B; корум; Sibars; dgolovanov; +5 Ответить
33. baton_pk 370 07.08.15 10:14 Сейчас в теме
(26) Rustig,
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков?
номенклатура которая сто лет не используется, контрагентов, которые давно не существуют


поверьте, это всё такая мелочь :)
корум; asved.ru; JohnyDeath; a_titeev; dgolovanov; +5 Ответить
46. Rustig 973 08.08.15 20:30 Сейчас в теме
(33) я не уверен, что мелочи.
мы с вами на разных уровнях работаем. это не плохо, это очень хорошо, особенно если я что -то полезное черпаю из ваших знаний.
это все мелочи, пока у вас есть деньги на железо, на штат сисадминов, на серверные субд... мне в своей практике приходится сталкиваться с файловыми базами, у них ограничение на 4 Гб. и тут я начинаю выдумывать всякие финтиплюшки - картинки и пдф-счета, договора выношу в другие базы (число баз для хранения картинок, образов, сертификатов и т.д. неограничено и постоянно растет), свертка-свертка-и еще раз свертка....
сейчас я понимаю, что о некоторых аспектах никто не задумывается, пока есть деньги на железо, на сисадминов, на лицензии серверов, на цуп... если вы скачаете кладр с официального сайта, получите файлы около 320 Мб. если закачаете часть регионов кладра в базу БП 2.0 получите увеличение базы на 1Гб и выше. просто задумайтесь, что для кого-то это уже не мелочи...
я понимаю, что в пон-к вы продолжите заниматься своими текущими задачами с базами 300 Гб, и продолжите строить планы, как их реиндексировать, понимаю, что вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб....

51. baton_pk 370 08.08.15 21:18 Сейчас в теме
(46) Rustig,
мы с вами на разных уровнях работаем

Не в этом дело. Просто ваш ответ был в контексте 4ТБ, а для 4ТБ что гиг, что двадцать - мелочи.

вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб

70 магазинов с файловыми базами 2-4 ГБ, в каждом магазине по две: на складе и в магазине. Падают часто. Так что, да, мне тоже придётся скоро оптимизировать и их работу тоже :).

(49) Rustig,
на каждой точке своя небольшая база, вся информация собирается в центральной базе и т.д.

нафигнафигнафигнафиг! если есть возможность работать напрямую, лучше работать напрямую. разбить одну база на две - это уже довольно эпохальное решение, а разбивать её на десяток - ошибка и тоже довольно-таки эпичная. в статье от Старых, ссылку на которую вы тут привели, описано, что не всегда параллельность даёт нужную отдачу. в случае с базами - это немалые накладные расходы на обмен.
36. kolya_tlt 11 07.08.15 11:04 Сейчас в теме
(26) Rustig, вы поймите, у оптимизации есть 2 пути:
1. отрезать лишние данные так как неоптимальный запрос их обрабатывает. отрезать можно тоже либо отказать от функциональной части, либо убрать старые данные
2. переписать неоптимальный запрос.
Думаю в проекты был выбран второй путь

ps косяки есть в любом цф-нике. вам зачем на них смотреть?
45. a_titeev 5 08.08.15 17:48 Сейчас в теме
(26) Rustig,

классификатор адресов сколько съедает места?
классификатор банков?
Вы точно сталкивались с большими базами?
(6) замечательно. Отличный опыт. Спасибо что поделились. Пожалуй перейму пару идей :)
48. Rustig 973 08.08.15 20:42 Сейчас в теме
(45) ответил в (46)
сталкивался с базой 150Гб будучи в команде разработчиков, за производительность не отвечал, вел разработку подсистем.
в дальнейшем во фрилансе работал с клиентами, разрабатывал подсистемы на файл-серверных базах размеров 40-70 Гб. Приходилось консультировать клиентов как ускорить работу 1С - в моих руках не было цупа, только голова, оптимизация запросов, оптимизация бизнес-процессов и архитектуры новых подсистем.
при работе с файловыми базами сталкивался с падением производительности при достижении базы критического порога допустимых размеров. принимал активное участие в ликвидации последствий.
Я не системный администратор, я программист. и смотрю на данный кейс как программист...
55. Rustig 973 11.08.15 13:18 Сейчас в теме
(26)
4 Тб - тоже ни о чем!

Беру свои слова обратно: 4 Тб - тоже ни о чем!
Контекст изменился: 4 Тб это очень много, чтобы продолжать работать в том же духе и развивать систему. Кажется пора принимать серьезные меры по изменению ситуации. Проведу аналогию: для файловой базы критичен порог 4Гб, для файл-серверной пусть будет 4Тб... :))
58. baton_pk 370 11.08.15 18:00 Сейчас в теме
(55) Rustig, аналогия в данном случае немного за уши притянута: для файловой базы ограничение в 4ГБ на одну внутреннюю таблицу - это ФИЗИЧЕСКОЕ ограничение, а 4ТБ для клиент-серверной - исключительно психологическое. База вполне может себе жить и пухнуть дальше до 40, 400, 4000. и если не заниматься доработками, связанными с реструктуризацией, то у платформы есть все возможности сделать так, чтобы пользователь не замечал разницы между большой базой и маленькой (речь, разумеется, не про типовые конфигурации :-D)
40. molodoi1sneg 15 07.08.15 14:20 Сейчас в теме
А бух. учет где ведется? Обмен?
41. Sergey.Noskov 890 07.08.15 15:22 Сейчас в теме
(40) molodoi1sneg, Бух учет ведется в типовой, первичка грузится через обмен.
42. baton_pk 370 07.08.15 16:09 Сейчас в теме
(41)
ооо! а вот тут-то самая вкусняшка начинается!
двусторонний обмен? коллизии? блокировки при обменах? размеры пакетов?
43. Sergey.Noskov 890 07.08.15 16:25 Сейчас в теме
(42) baton_pk, неа, не начинается)) Обмен односторонний + закрытие периода, поэтому блокировок и коллизий нет.
44. genayo 07.08.15 20:43 Сейчас в теме
(41) А вот тут интересно, для типовых конфигураций применяли такие-же методики анализа проблем?
50. Rustig 973 08.08.15 20:58 Сейчас в теме
(0) свяжу ваш кейс со статьей http://infostart.ru/public/387232/
так сказать на будущее
54. capitan 619 11.08.15 10:39 Сейчас в теме
Два извечных вопроса интернета: Как? и Зачем ?
С периодичностью раз в полгода на различных евентах появляется человек с базой в десяток тысяч пользователей.
И что удивительно практически всегда там находится SoftPoint.
И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.
Кроме конечно желания генерального. Обычно он и говорит - хочу одну базу.
На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.
О чем и говорит уважаемый Rustig.
Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30.
59. Sergey.Noskov 890 11.08.15 18:11 Сейчас в теме
(54) capitan,
И что удивительно практически всегда там находится SoftPoint.

В чем удивительность, поделитесь? Почему вас не удивляет наличие у нас ЦУП, SQL, Windows, Perfomance Monitor, а именно инструменты этой компании?

И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.

повторюсь, основная причина - рост компании, открытие подразделений в городах.
Изначально каждое подразделение работало в своей базе. Решение о слиянии баз было принято из-за предъявляемых бизнес процессами требований. Ну а извечные вопросы Как? и Зачем? все равно будут, да же если доклад посвятить теме "Опыт оптимизации и контроля производительности в распределенной системе из 100 узлов".

На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.

Далеко от реальности. Когда у вас работоспособность БД на условном нуле затевать проект логической модификации БД это равносильно профессиональному самоубийству. Сначала дайте бизнесу рабочую базу, а дальше продумывайте новую архитектуру, её плюсы и минусы, считайте бюджет и выходите на защиту проекта.

Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.

а про бумагу то мы и забыли..)))
Если серьезно, то это набор общих фраз характеризующих некую идеальную среду мироздания. Когда мы рассматриваем реальную ситуацию, то появляются множество нюансов и так просто не получается. Например, сам пользователь актуальные данные не читает, но те изменения, которые он вносит - очень важны для остальных (бухгалтер, вносящий факт оплаты), либо окажется, что в небольшом филиале один сотрудник совмещает несколько должностей и после разделения он будет вынужден работать в 2х - 3х базах.
Пример по реалтаймности. Наш Call центр обзванивает клиентов для информирования, что груз прибыл и его можно забрать. При этом регламентное задание, актуализирующее номера телефонов в обзвонщике, работает раз в 5 минут. Так вот, за эти 5 минут информация успевает устаревать (клиент как раз забирал груз в это время; менеджер заблокировал выдачу из-за проблем с оплатой). Оператор Call центра в таких случаях просто извиняется и вешает трубку. В процентном отношении это не большие цифры, но в количественном это сотни напрасных звонков за сутки. Т.е. несколько сот клиентов могли бы раньше узнать о том, что груз уже приехал и его можно забрать. Естественно, что частота работы регламентного была увеличена. И сейчас, когда вся информация в одной базе, а если говорить про распределенку таких случаев будет неминуемо больше.

И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30

так их не станет 30, их в сумме все равно будет 3000, а вот число серверов 1С и баз, безопасность которых по идее и надо контролировать, значительно возрастет.
корум; DimaP; adhocprog; starik-2005; AKnyazkov; artbear; gallam99; altu71; Bronislav; baton_pk; +10 Ответить
69. capitan 619 12.08.15 22:09 Сейчас в теме
(59) видел ответы ,некоторые улыбнули :) но не буду вдаваться в полемику, поберегу время.
Есть еще парочка вопросов:
1. Допустим сейчас вы полностью контролируете базу и всех 40 программистов, но предположим ваш сервер устал или что еще хуже - логический сбой БД.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?
Что в этот момент будут делать 3000 юзеров ?
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?
2. Есть такой закон - N 152-ФЗ. Пока вы работаете с юрлицами все неплохо, но как только в вашей базе появляется физ. лицо вам надо соответствовать.
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.
70. Sergey.Noskov 890 13.08.15 12:37 Сейчас в теме
(69) capitan,
Вопросы выводят в плоскость почему одна большая БД плохо (может показалось?). Абсолютно согласен с тем, что у этой архитектуры есть недостатки. И у распределенной системы они так же есть. Наша практика показала, что с точки зрения бизнес процессов иметь единую базу выгоднее. Этот опыт никому не навязывается, просто показываю, что это реально.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?

Если мы говорим про физическое разрушение БД, когда в базу принципиально нет возможности даже войти, то время восстановления работоспособности менее минуты - достаточно в свойствах базы 1С изменить базу СУБД на отчетную или базу-реплику (AlwaysOn). Все 3 базы на физически разных СХД и физически разных серверах.
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?

В рамках ЦКТП тест был на 5000 пользователей. Что должно этому мешать?
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.

У вас либо есть защитный механизм, либо его нет. Если защита есть, то ей должно быть по фиг 30 у вас пользователей или 3000.

Вообще всегда интересны различные идеи и концепты, они позволяют "расширять сознание", поэтому если у вас есть какое то видение, как разом "побороть" все вышеописанные проблемы, напишите, любопытно.
71. Зеленоград 13.08.15 13:00 Сейчас в теме
(70) Капитан имеет в виду формальные проверки на соответствие (много мата пропущено) фз 152, к жизни не имеющего никакого практического отношения, но позволяющего за.. утомить, в общем - любого оператора персданных.

В подобных целях видел регламентную очистку исполненных и закрытых заказов, дабы не попасть по числу объектов под неудобный класс ИС.


А сам на проверке с уверенным видом расказывал, что "архивов у нас нет, всё отлажено и работает без сбоев, поэтому процедуры удаления ПДн после отзыва согласия на обработку не нужны и отсутствуют". Коллеги сдержались, проверяющие изумились, но отвязались.
72. Sergey.Noskov 890 13.08.15 14:34 Сейчас в теме
(71) Зеленоград, Это я понял, я не понял при чем тут 3000 пользователей. Видимо надо уволить 2970 сотрудников компании, ведь с 30 пользователями все намного легче)
74. capitan 619 14.08.15 11:40 Сейчас в теме
(70) самым великим мастером давать ответы далекие по смыслу от темы вопроса был конечно Михаил Сергеевич, долгой ему жизни. И задолго до него известна фраза Райкина - Хотите меня поставить в тупик своими вопросами - так я вас поставлю в тупик своими ответами.
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.
Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.
Что касается видения - ваша структура в точь точь похожа на любого крупного ретейлера, за той разницей - что на пунктах выдачи вы товар принимаете, а не продаете.
На самом деле, если ваша должность была сисадин или DBA, DBA кстати пишут фолианты об оптимизации серверов, вопросов бы не было. Я бы первый поставил +, написал бы здесь красавчеГ и откланялся.
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.
75. Sergey.Noskov 890 14.08.15 13:23 Сейчас в теме
(74) capitan,
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.

Извиняюсь, что не понял вопрос. Для нас тестирование - это именно функциональные тесты.
Реиндексация делается средствами СУБД. Пересчет итогов - делается в режиме предприятия. Реструктуризация всей базы - не делается, при необходимости делается для конкретного объекта. Проверки логической и ссылочной целостности сами по себе (на всякий случай) смысла не имеют, у нас много "битых" ссылок в силу особенности реализации отдельных подсистем.
По реструктуризации и проверкам целостности - не возможность использования именно ТиИ ни как не мешает, все возникающие задачи решались своими силами.
Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.

Нахождение справочника контрагентов в одной базе с остальными объектами конфигурации само по себе ничего не нарушает. Персональные данные это четко обозначенная информация о физ лице. Если эта информация храниться в базе, её можно шифровать, очищать, хранить эти данные в "другой БД" и т.д. и т.п. Но я искренне не понимаю при чем тут 3000 пользователей, если в БД их только 30, то на закон можно и подзабить? или эту проблему будет проще решить? Мне видится что закон касается любой системы, распределенной или нет - без разницы.
Что касается видения - ваша структура в точь точь похожа на любого крупного ретейлера, за той разницей - что на пунктах выдачи вы товар принимаете, а не продаете.

Груз и принимается и выдается. Это только часть основного бизнес процесса, вокруг него много вспомогательных (информирование клиентов, анализ ожидаемого грузопотока, планирование состава машины и её маршрута - только часть из них).
На самом деле, если ваша должность была сисадин или DBA,...
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.

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

Про распределенку.
Если разговор зашел про недостатки больших баз, то всем (без сарказма - мне тоже) будет полезно увидеть как подобные проблемы решаются в распределенных системах и в чем их профит.
Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
77. ZLENKO 376 14.08.15 13:30 Сейчас в теме
(75) "Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая."

Думаю аналогично.
79. genayo 14.08.15 15:59 Сейчас в теме
(77) На самом деле, часть из этих проблем решаема, приведу пример как это решено у нас (продуктовая дистрибуция), несколько филиалов:

1.Двух сторонние обмены и как следствие конфликты изменений.
Организован РИБ, в каждом филиале подчиненный узел. Вся НСИ вводится только в центральной базе, различные виды документов могут быть отредактированы либо только в центральной базе, либо только на филиале. Аналогично организован обмен с бухгалтерской программой. Конфликты изменений практически исключены.
2.Процесс обновления более трудоемок за счет увеличения количества баз.
На самом деле, это критично если баз больше 10-15, на меньшем числе увеличение трудоемкости малозначительно, причем, при желании, это все можно еще и автоматизировать.
3.Все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
В центральную базу переносится не вся информация из филиалов, а только те данные, которые нужны для построения сводных отчетов по всей компании. В нашем случае, например, только информация о продажах.
4.Увеличение парка серверов и баз данных, требуется больше серверных лицензий - в общем, это не очень большие затраты, если "размазать" их на все время эксплуатации железа.

Очевидно, что этот подход также имеет свои минусы, но вполне себе имеет право на жизнь.

Автор конечно молодец, очень интересный кейс, но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор :) и бездумно брать этот пример и пытаться повторить не стоит...
80. Sergey.Noskov 890 14.08.15 16:52 Сейчас в теме
(79) genayo,
Спасибо за опыт. Все имеет право на жизнь, и у всего есть как минусы так и плюсы.

На самом деле, это критично если баз больше 10-15

Если говорить о комфортных 100 пользователях в одной БД, получится 30 баз))
При текущем анализе возможности функционального разделения базы (не территориального, именно функционального) рассматривался вариант минимум из 10 баз.

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

Регистр с информацией о продажах у нас один из лидеров по размеру. Второй лидер, информация о движении груза, так же будет нужен в центральной БД для построения статистических отчетов. Мы оценивали какой бы мог быть профит и получается, что самые объемные таблицы все равно будут нужны в центральной БД. Как вариант - переписать всё, сделав разную конфигурацию под центр и под филиал. Продумав логику хранения данных можно будет что то сэкономить. Долго и дорого, но возможно.

но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор

Главное то, что кластер 1С справляется с этой задачей. У многих есть опасения именно это момента.
81. Sergey.Noskov 890 14.08.15 17:18 Сейчас в теме
(79) genayo, не могу удержаться от off топа)
бездумно брать этот пример и пытаться повторить не стоит...

Бездумно - нет! Но пробовать и повторять - однозначно стоит! Сейчас для этого есть все инструменты и даже поддержка от 1С (ЦКТП). Чем больше будет подобный кейсов, тем лучше.
82. genayo 14.08.15 21:21 Сейчас в теме
(81) У меня есть аргументы против такой точки зрения, но тема то конечно не про это, поэтому здесь их высказывать не буду. Позволю себе еще один вопрос вдогонку - вы хотя-бы гипотетически рассматриваете переход на 8.3, или вы считаете, что без новшеств, добавленных в 8.3 можно прожить (себе я тоже кстати этот вопрос задаю, однозначного ответа у меня пока нет...)?
83. Sergey.Noskov 890 17.08.15 10:32 Сейчас в теме
(82) genayo,
Переход на 8.3 рассматривается. Интересны не столько программные "фишки", сколько оптимизация платформы и возможности кластера. Например в платформе изменена работа с временными таблицами (создается кластерный индекс и сам индекс не удаляется после выполнения запроса), наличие физических таблиц срезов. А в кластере привлекает возможность разделения функций по отдельным серверам.
56. Xershi 375 11.08.15 13:37 Сейчас в теме
Прошу поправить
на одину
.
60. Sergey.Noskov 890 11.08.15 18:14 Сейчас в теме
57. МихаилМ 11.08.15 13:41 Сейчас в теме
автор, как решили проблему долгой реструктуризации ? и удаления доп.индексов после реструктуризации
63. Sergey.Noskov 890 12.08.15 12:16 Сейчас в теме
(57) МихаилМ,
автор, как решили проблему долгой реструктуризации ?

У нас ограничение от бизнеса - полное время обновления не должно превышать 2ч. За 2 часа, на хороших дисках, успевает реструктуризироваться почти любой объект метаданных. Есть и объекты, которые за это время не успевают, их мало и чаще всего это что то из базового бизнес-процесса, который редко меняется.
Если надо больше двух часов - разделяем обновление по объектно, если и это не помогает, то эти изменения откладываются до больших праздников.
61. Painted 20 12.08.15 10:49 Сейчас в теме
Прямыми запросами к MS SQL не баловались? Или близость к 1С не позволяет? Или баловались, но вслух об этом не говорят?
64. Sergey.Noskov 890 12.08.15 13:53 Сейчас в теме
(61) Painted,
Прямыми запросами к MS SQL не баловались?

Задач таких нет. Но раньше, в далекие времена 8.0 и когда веб сервисы плохо работали с большим количеством коннектов, то запросы сайта как раз и делали "прямые" запросы в базу-копию (раз в неделю разворачивали из бэкапа)
62. vec435 15 12.08.15 10:52 Сейчас в теме
а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?
65. Sergey.Noskov 890 12.08.15 14:06 Сейчас в теме
(62) vec435,
а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?

Причин ровно две:
1. 1С справляется и при всех её недостатках она нам нравится.
2. Стоимость. Менять придется не только платформу, но и саму учетную систему, а это очень дорого и очень долго.
baton_pk; +1 Ответить
66. genayo 12.08.15 16:39 Сейчас в теме
(65) Если не секрет, сколько у вас серверных ключей и сколько клиентских и каких, программных или аппаратных?
67. Sergey.Noskov 890 12.08.15 17:46 Сейчас в теме
(66) genayo, Ключи программные. 4 серверных и 3500 пользовательских.
68. asved.ru 33 12.08.15 18:05 Сейчас в теме
А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании. RDS?
Насколько стабильны показатели APDEX? Какое отклонение вы считаете заслуживающим реакции?
Спасибо.

73. Sergey.Noskov 890 13.08.15 15:41 Сейчас в теме
(68) asved.ru,
А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании.

Пользователи с базой работают терминально.
Насколько стабильны показатели APDEX? Какое отклонение вы считаете заслуживающим реакции?

Показатели достаточно стабильны (исключение - время выполнения регламентных операций), в основном диапазон значений колеблется в нтервале 0,98 - 0,99.
Критичные отклонения - ниже 0,9. При 0,95 уже режим повышенного внимания. Но опять таки это наша специфика из-за большого количества пользователей. Грубо говоря APDEX 0,97 означает, что более 3% пользователей работают вне комфортной скорости. 3% это 90 пользователей, т.е. потенциально это 90 жалоб. Поэтому после внедрения APDEX'а была притирка - сопоставляли объем поступающих жалоб со значением показателя.
84. Irwin 285 17.08.15 11:18 Сейчас в теме
Можно узнать подробнее про процесс разработки?
Какие проблемы возникают с таким большим количеством людей разработчиков в одной базе (у вас ведь одно хранилище или вы пользуетесь другими средствами совместной разработки)?
Как планируется время на выполнение задачи с учетом того, что (мое предположение) часто нужные объекты бывают захвачены другими разработчиками (а ведь еще есть тестирование)?

ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища. Наверное, есть то число, после которого уже увеличение количества разработчиков бессмысленно. Хотелось бы услышать Ваше мнение по этому поводу.
artbear; baton_pk; +2 Ответить
85. Sergey.Noskov 890 17.08.15 14:48 Сейчас в теме
(84) Irwin, не все программисты работают на одну базу. У нас есть и типовые и несколько баз помельче. В этой базе, если не ошибаюсь, порядка 15 разработчиков.
Работаем через хранилище. Снижение конкуренции за объекты достигается разделением кода на логические блоки (функциональные подсистемы) и их выносом в отдельные модули. Для особо популярных объектов разделение вплоть до того, что каждая печатная форма в своем модуле. Плюс есть специализация разработчика, т.е. задачи в рамках одной подсистемы "придут" одному разработчику.

ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища

ИМХО, как и при работе пользователей, количество блокировок при разработке зависит от архитектуры конфигурации.
86. Slon1c 03.09.15 14:22 Сейчас в теме
Ничего удивительно ни в размере базы, ни в количестве пользователей нет. Наслышан об успешной оптимизации и рефакторинге кода от непосредственных исполнителей. На сегодняшний день очень много крупных компаний использующих 1С с объемами баз свыше 1 Тр и количеством пользователей от 500 (данные на одну базу). Есть компании в которых используются более 120 независимых баз между которыми осуществляется онлайн обмен. Реструктуризация больших таблиц средствами 1С - процедура долгая и утомительная. Даже при хорошем железе добавление нового реквизита в 1С с простым типом - несколько часов при объеме таблицы свыше 100 Гб и количестве записей от 80 млн. и более, естественно используются другие возможности. Это уже не говоря об удалении такого реквизита :), с проверкой логической и ссылочной целостностью базы. Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ? Используете data кластер от SoftPoin ? По заголовку запросов и происходит разделение (перенаправление) на различные сервера СУБД ? Как обошли отчеты в которых требуется создавать промежуточные временные таблицы ?
87. Sergey.Noskov 890 05.09.15 17:41 Сейчас в теме
(86) Slon1c,
Удивительного нет, для того и доклад готовился, дабы меньше удивлялись. Чем больше примеров будет, тем лучше для сообщества.
Реструктуризацию используем только типовую, причин несколько, но основная - добавление колонки в существующую таблицу SQL возможно только с типом "содержит NULL", это может привести к построению плана запроса с избыточными операциями.
Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ?

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

Дата кластер действительно отличная штука, ей бы добавить признание от самой 1С и совместно создать мощный инструмент. На текущий момент оптимизация кода дала такой эффект, что мы можем работать и без отчетной базы и без дата кластера, но обе технологии повышают запас прочности и надежность системы в целом (плюс "горячий" бэкап), поэтому и остаются в строю.
101. starik-2005 1386 08.11.16 12:33 Сейчас в теме
(87) по поводу новых колонок с реструктуризацией, то достаточно быстрый вариант такой: переименовывается исходная таблица, предварительно создается скрипит CREATE для таблицы. После переименовывания таблица создается, проводится реструктуризация, после чего через INSERT INTO SELECT FROM ...в старую уже отреструктуризированную таблицу вставляются записи из переименованной исходной таблицы. В итоге и поля "без нуллов", и данные вставлены куда быстрее, чем штатными механизмами, ибо штатный механизм читает записи, потом проверяет на типы данных, и если тип изменился и теперь не содержится в поле, то он очищает данное поле, после чего уже очищенный вариант пишет в таблицу. Это ну о-о-о-о-о-чень долго...
102. Sergey.Noskov 890 08.11.16 12:51 Сейчас в теме
(101) starik-2005,
после чего через INSERT INTO SELECT FROM ...в старую уже отреструктуризированную таблицу вставляются записи
не понял профит, именно эта операция самая длительная при типовой реструктуризации.
На сайте уже было одно из решений http://infostart.ru/public/536650/ и мы уже общались на эту тему.
Там, кстати, вы другое решение озвучивали
Потом переименовываю старую таблицу обратно и АЛЬТЕР КООЛОНКА/АЛЬТЕР ИНДЕКС создаю соответствующие колонки и индексы.
и оно больше похоже на правду ;)
103. starik-2005 1386 08.11.16 13:36 Сейчас в теме
(102) да, я оба варианта использую. Но в последнее время из-за лени, видимо, чаще именно вариант с копированием применяю. Последний раз данную процедуру буквально на днях применял - у клиента есть регистр с 6кк записей. Достаточно большой. В него добавили ресурс текстовой - строка 10 символов. В итоге система на тестовом стенде реструктуризировалась очень долго - не дождались (думаю, примерно неделя бы ушла). При том вставка заняла всего 3 часа. Но это железки обычные - не ваши.

Есть у меня мнение, что большинство не понимает, как работает реструктуризация. Если бы она просто копировала данные из одной таблицы в другую за раз (ins ert in to tb1 sel ect * fr om tb2), то это было бы просто шикарно и скорость такой реструктуризации многих бы удивила. Но 1С все делает не так. Она читает порцию из таблицы 1, потом обрабатывает ее (проверяет соответствие типов полей с метаданными - как часть механизма), потом эту порцию записывает в таблицу с суффиксом NG. После того, как все объекты обновлены, 1С в транзакции удаляет старые таблицы и переименовывает таблицы NG. Основное время реструктуризации занимает обработка данных платформой, ну и порционность вставки вносят свою лепту, ибо одно дело - один запрос на сервере выполняется, совсем другое - куча запросов + данные, метаемые с сервера SQL на сервер приложений и обратно. Один сетевой трафик чего стоит.
88. dablack 16.12.15 09:30 Сейчас в теме
Сергей, подскажите пожалуйста, вы описывали, что у вас достаточно много запросов со стороны сайта к web сервисам 1с. Хотелось бы узнать поподробнее, что используется IIS, Apache?
Какое примерно к-во запросов в минуту/час ? С какими проблемами в этой связке столкнулись?
Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например http://www.oknosoft.ru/metadata/ ?
И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
89. Sergey.Noskov 890 25.12.15 13:18 Сейчас в теме
(88) dablack,
>Хотелось бы узнать поподробнее, что используется IIS, Apache?
Apache.
>Какое примерно к-во запросов в минуту/час ?
Запросов к веб серверам, со слов их админа, порядка 1500/минуту.
>С какими проблемами в этой связке столкнулись?
Работает достаточно надежно. Основное, с чем боролись - настройка таймингов. Суть проблемы (упрощенно) - если запрос выполняется дольше указанного в настройках веб сервера тайм аута, то число коннектов от веб сервера к базе увеличивается. Увеличиваться может до "бесконечности". Для объективно долго выполняющихся сервисов увеличивали тайминг + оптимизация кода и запросов.
90. Sergey.Noskov 890 25.12.15 18:32 Сейчас в теме
(88) dablack,
>Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например http://www.oknosoft.ru/metadata/ ?
Специально никто переписывать обычного клиента не будет - работа ради работы (да простят меня фанаты тонкого клиента и управляемых форм). Остальное будет рассматриваться в рамках запрашиваемой функциональности, если по условию задачи лучшим выходом будет metadata, то в эту сторону и будем смотреть.

>И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Тут все просто. Самописная dll для работы через API CISCO. 1с тут играет роли "выгрузить очередь для обзвона" и "найти клиента по номеру телефона и отобразить данные".
91. goodron 29.12.15 21:55 Сейчас в теме
Про это:
Виктор Богачев, Проект по нагрузочному тестированию 1С 8 для 5000 пользователей в одной ИБ
http://www.youtube.com/watch?v=0KN5DdkbS2g
mickey.1cx; Sergey.Noskov; +2 Ответить
92. zhichkin 249 17.01.16 23:46 Сейчас в теме
Сергей, Вы пишете:
Улучшили подсистему репликации и добились актуальности данных в 2 – 3 минуты, что значительно расширило список перенаправляемых отчетов. Доработки в основном были нужны потому, что стандартный метод "ВыбратьИзменения" планов обмена создает большое колличество блокировок.

Вопрос:
Уточните, пожалуйста, какие именно блокировки имелись ввиду? Какие транзакции ожидали освобождения этих блокировок? Конкретно каким образом удалось решить эту проблему? Неужели отказались от использования этого метода? А что использовали взамен?
Оставьте свое сообщение

Вакансии

Удаленный ИТ-журналист
Санкт-Петербург
По совместительству

Программист 1С
Санкт-Петербург
зарплата от 80 000 руб. до 150 000 руб.
Полный день

Консультант-аналитик 1С
Москва
зарплата до 160 000 руб.
Полный день

Удаленный бизнес-аналитик 1С
Санкт-Петербург
Временный (на проект)

Разработчик (эксперт) по направлению 1С:ЗУП 3
Санкт-Петербург
зарплата от 130 000 руб.
Полный день