Оптимизируй это! Или MS SQL и Экспертный подход творят чудеса!

0. Роман Царенко (R.Tsarenko) 196 16.06.17 12:11 Сейчас в теме
В статье речь пойдет про взаимодействие сервера 1С с MS SQL.
Мы очень часто слышим, как важно оптимизировать все критические участки системы заблаговременно, в плановом режиме, как надо, «от и до» во всех деталях. Но в реальной жизни бывает по-другому. Очень часто клиенты обращаются к нам, когда система уже не дает работать: «спасите, помогите, болит очень сильно, надо решать». Об одном из таких случаев я и хотел бы вам сегодня рассказать.

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

Комментарии
1. Ildar Gabdrakhmanov (spezc) 301 11.07.17 10:20 Сейчас в теме
Интересная подача материала)))) слог и картинки заслуживают звезду
VladC#; DrAku1a; EliasShy; sansys; Gang031; inf012; METAL; gortol; rovenko.n; kare; +10 2 Ответить
2. Геннадий Николаев (genayo) 11.07.17 11:05 Сейчас в теме
Кейс интересный, показывает, к каким последствиям может привести изначально неправильный выбор архитектуры приложения.
VladC#; EliasShy; sansys; amoarok; Gang031; Nelli_A86; delete; inf012; gortol; echo77; Waanneek; +11 1 Ответить 2
3. rjhev korum (корум) 310 11.07.17 11:51 Сейчас в теме
(2) Случай интересный.

кейс из крокодиловой кожи :)
the1; 4rtehouse; Dmitri93; +3 Ответить 1
4. Иван Немчинов (Waanneek) 74 11.07.17 12:00 Сейчас в теме
(2) Плюсанул! В начале статьи уже было понятно что надо архитектуру пересматривать. Либо распределенную базу делать, либо разносить проблемный регистр на несколько, чтобы данные на тек. момент и на будущий период брались из разных мест как вариант. Статистики и итоги до поры до времени будут спасать, но со временем база наберет критический объем и эти меры уже не помогут (не будут давать приемлемую скорость работы).

Думал речь пойдет о разделении на несколько баз с синхронизацией, те кто оперативно работают будут в основной базе, те у кого дикая нагрузка, но не оперативно - в отдельную базу с задержкой получения информации на Xч/мин. Это позволило бы реально снизить нагрузку на оперативную базу.
5. Геннадий Николаев (genayo) 11.07.17 12:02 Сейчас в теме
(3) Чемодан из крокодиловой кожи тогда уж.
6. Brr (brr) 178 11.07.17 12:39 Сейчас в теме
7. Владимир Безфамильный (Vovan1975) 14 11.07.17 12:51 Сейчас в теме
А можно по подробнее рассказать почему решили отключить текущие итоги?
8. Антон Стеклов (asved.ru) 33 11.07.17 13:12 Сейчас в теме
(7) Они не нужны, т.к. точка актуальности в далеком будущем и остатки берутся почти всегда задним числом.
9. Антон Стеклов (asved.ru) 33 11.07.17 13:25 Сейчас в теме
На счет "MS SQL не имеет гибких интерфейсных настроек для обновления статистики" - чушь полная, бред сивого DBA.
В целом статья технологически инфантильная, даже объяснение природы проблемы на уровне планировщика - детский сад, штаны на лямках. Ничего он там не ищет, а принимает решение о выборе того или иного оператора плана, основываясь на неверных данных. Например, считает, что в одной из сторон джойна строк мало, и ставит nested loops, который действительно выгоден в таких условиях, но очень печален, когда число строк растет.

Единственная зрелая мысль во всей статье - порядок использования итогов. Однако даже это решение неверно, т.к. с дальнейшим ростом объемов данных работать перестанет.
Здесь необходима переработка архитектуры хранения данных в целом.
ZOMI; aKomper; zarucheisky; Dem1urg; Dach; gortol; FarhadIlyazov; GreenDragon; +8 Ответить
10. rjhev korum (корум) 310 11.07.17 15:04 Сейчас в теме
(8) "как быстро починить чтобы пореже падало".

Надёжней исключить работу будущей датой, и держать точку актуальности текущим днём.

Кто мешал сделать нормальный регистр планирования с датой в измерении?...
11. Андрей Антипенко (Kopman) 15 12.07.17 04:54 Сейчас в теме
Статья в 4 словах:
Мы настроили регламент MSSQL.
ZOMI; manlak; Dem1urg; корум; rovenko.n; +5 Ответить 1
12. Alexey (AlexeyFreeLife) 12.07.17 07:41 Сейчас в теме
вопрос не по теме: зачем столько картинок ? после пролистывания статьи не читая текст уже подустал.
ZOMI; alexkmbk; perpleks; +3 Ответить 1
13. Александр Крынецкий (echo77) 740 12.07.17 07:58 Сейчас в теме
(11) Не только, здесь и очистка таблицы текущих итогов и расчет итогов по месяцам и наведение порядка во внешних отчетах
14. Александр Крынецкий (echo77) 740 12.07.17 08:06 Сейчас в теме
(0) Опечатку на слайде поправьте http://infostart.ru/upload/iblock/09b/09b70ceaa97acb6f38273c481f638e72.jpg
Маленькие замечания:
максимальная дата в 1С - 3999 год
неплохо бы сразу в статье сказать, что регистр накопления остатков
на сколько оправдано разделение итогов в этом регистре?
странно, что "профессиональные каскадеры" не вспомнили про то, что текущие итоги и обычные ежемесячные итоги – это одна и та же таблица.
15. Александр Крынецкий (echo77) 740 12.07.17 08:08 Сейчас в теме
(12) Не соглашусь, картинки разбавляют текст, его становится легче читать. То что листать приходится дольше - это да :-)
Gang031; Artem-B; inf012; 4rtehouse; gortol; rovenko.n; +6 Ответить
16. Alexander . (manlak) 77 12.07.17 10:13 Сейчас в теме
За статью плюс, понравилось!
Только небольшое замечание, а нельзя было вместо "скриншотов" обновления статистики и текста тех.журнала, код выставлять по человечески, который можно было б скопировать в буфер обмена? )
Gang031; mytg; 4rtehouse; 1Concept; perpleks; +5 Ответить 1
17. Sergey Andreev (starik-2005) 1040 12.07.17 11:18 Сейчас в теме
(16)
код выставлять по человечески, который можно было б скопировать в буфер обмена
ИМХО, код вставлять без понимания его сути - это зло абсолютно неэкспертное. Любой копипаст - это риск, что:
1. То, что кописастишь - полная хрень (как в данном случае);
2. То, что копипастишь, сложно изменить;
3. То, что копипастишь, сложно понять.
18. aKomper (aKomper) 12.07.17 15:57 Сейчас в теме
19. Herby 12.07.17 16:15 Сейчас в теме
статья про типичную русскую проблему - сначала делаем, а потом думаем.

весь ваш огромный двухгодичный опыт в области оптимизации тратится на борьбу со следствием. бесполезное это дело.

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

отчеты для вашей третьей группы пользователей перенести в BI.
отчеты для второй группы перенести в копию базы, размещенной на другом сервере (на дворе 21 век и решений по репликации БД достаточно много).

в итоге нагрузка упадет в сотни раз.

иначе так и будете упираться в пробки.
20. Sergey Andreev (starik-2005) 1040 12.07.17 17:05 Сейчас в теме
(19)
отчеты для второй группы перенести в копию базы, размещенной на другом сервере...
в итоге нагрузка упадет

Даже если на одном сервере - и то упадет.
21. Александр Ярошенко (teller) 13.07.17 06:46 Сейчас в теме
статья о том как администраторы субд решали проблемы проектировщиков :)
вот так и оттачивается мастерство
22. vasek (iliabvf) 13.07.17 09:25 Сейчас в теме
Гениальная подача материала! Дизайн заказывали у школьников?
23. Андрей Sh. (ansh15) 13.07.17 10:24 Сейчас в теме
Даже на мегамощностях заказчика на это ушло бы 13 часов

Можно про "мегамощности" более детально рассказать, если не секрет?
stroganov_ru; +1 Ответить
24. Роман Озеряный (rozer) 189 13.07.17 11:35 Сейчас в теме
(22) когда вышел фильм этот с Киану Ривзом вы были школьником а может и в д/с ходили еще ) норм статья но это оч частный случай про откл итогов - лучше архитектуру пересмотреть, да
25. Сергей Носков (Sergey.Noskov) 716 13.07.17 15:44 Сейчас в теме
(4)
Статистики и итоги до поры до времени будут спасать, но со временем база наберет критический объем и эти меры уже не помогут
почему?
Особых проблем не вижу, итоги рассчитываются, запрос всегда строится к таблице итогов за месяц и union по таблице движений (максимум за месяц).
26. Яков Коган (Yashazz) 2103 14.07.17 12:04 Сейчас в теме
Один конкретный кейс, один из множества способов решения. Зато много картинок и потому много плюсов.

статья о том как администраторы субд решали проблемы проектировщиков :)

Воистину.

...надо мне в следующий раз полуголых женщин в публикацию напихать, авось модераторы пропустят. Тогда точно статья выйдет в топ)))
27. Александр Хомяк (logarifm) 975 14.07.17 15:28 Сейчас в теме
поистину есть еще понятия кривых итогов - это некорректное закрытие регистров. Провисшие записи. Вот что точно паразит!!!

Надо сверять учет насколько велика вероятность записей

Товар Заполненая аналитика Движение приход
Товар пустая аналитика Движение расход

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

Статья зачетная. И нет придела совершенству в поисках производительности и самое главное нет одного эликсира или панацеи ... (ИМХО)
28. Дмитрий Фатов (Fatov_DI) 20.07.17 10:31 Сейчас в теме
Спасибо за статью! Мне оформление понравилось, по крайней мере читается легко....

В результате, мы приняли решение просто снести таблицу итогов и напрямую сделали truncate table из MS SQL.


Т.е. Вы грохнули таблицу итогов, потом запустили пересчет итогов? Сколько он длился по времени?
29. Вячеслав Гилёв (Gilev.Vyacheslav) 1739 23.07.17 11:46 Сейчас в теме
всего то надо было не хранить миллиард строк в одной таблице, а не бороться с последствиями хранения
ZOMI; Silenser; +2 Ответить
30. Владимир Поздняков (Red_Devil) 163 10.08.17 10:31 Сейчас в теме
Все проблемы как всегда из-за коллекторов!!!
31. Александр Потапов (tiniji) 145 10.08.17 14:28 Сейчас в теме
Хороший способ объяснить заказчику куда ушли его деньги. На написание презентации )

P.S. Думаю проф. уже эта информация известна давно. Ну а новички не поймут, что такое статистика и с чем его едят.
32. Олег Николаев (o.nikolaev) 192 12.08.17 22:51 Сейчас в теме
Для тех кто сотрудничает с "микрофинансовыми" организациями, в аду отдельная сковородка. Каждый день +1000% от предыдущей температуры.
Оставьте свое сообщение