Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MS SQL Server > Хранение множества параметров приложения

Автор: lat 1.10.2013, 18:28

Доброго времени суток. Есть рабочая БД, досталась по наследству.  Упрощенная схема: Приложение  --->> Таблицы значений параметров Приложение  Id (int) Primary Key Description (Text) ... Таблица параметров_%type% Id (Int) Primary Key AppId (Int) Foreign Key Value (%type%) Всего таблиц 3, для каждого из типов, а именно:  Числовые, Строковые и Бинарные Значения. Почему так? – Могу лишь предположить, что такая структура уменьшит нагрузку на сервер, и файловую систему.  Как это работает?  Если просто,  есть приложение, все параметры приложения хранятся в таблицах Параметры, разбитые по типам.   Сейчас, количество параметров для одного приложения не превышает значения в 100 единиц. Это нормально, в таком режиме система работает худо-бедно. Проблема За этот месяц нужно подготовить решение для большой сети, в начальном состоянии состоящей из 50000 приложений, в каждом из которых будет по 2500 секций с параметрами.  Выполнив простую арифметику, 50000*(2500*n)= 125 000 000*n делаем прогноз, - «Господа, все ляжет! Support, запасайтесь терпением. Манагеры, готовьте скидки. » Причина моего скептицизма кроется в следующем:  - используется сервер MS-SQL 2005 разной сборки под разных клиентов, судя по тому, что я нашел в сети, есть ограничения на размер базы данных. Для Express это 4Гб, уже мимо. - как работать с таким объёмом данных?  Это мой первый опыт, и хочеться сделать все хорошо. Если нужно переделать все с нуля, бывалые-седоволосые-деды, пожалуйста, подскажите как или что почитать? Выход из ситуации вижу пока один,  выделить общие параметры для однотипных приложений и сделать их общими.  Примечание:  Решать за меня не нужно, и уж тем более проектировать. Хотя если есть время и желание размять мозги, от помощи не откажусь. Мне нужна лишь подсказка для зазуглить, только укажите направление куда копать. Желательно «не от сюда, и до обеда». Есть же решения под такие задачи, и думаю что придуманы они давно, мне бы только названия, имена, пароли и явки =)  UPD: Подготовив тестовый стенд, увидели следующую картину: Одно приложение = + 70 915 единичных параметров. 50 000 приложений = 3 545 750 000 параметров

Автор: Akina 1.10.2013, 20:31

Цитата(lat @  1.10.2013,  19:28 ) Всего таблиц 3, для каждого из типов, а именно:  Числовые, Строковые и Бинарные Значения. Почему так? – Могу лишь предположить, что такая структура уменьшит нагрузку на сервер, и файловую систему.  Я могу предположить, что программисту просто было тупо лень делатиь по-человечески. Цитата(lat @  1.10.2013,  19:28 ) Сейчас, количество параметров для одного приложения не превышает значения в 100 единиц. Это нормально, в таком режиме система работает худо-бедно. Я вообще не понимаю, о чём речь. Что за параметры хранятся в БД?  То, что параметры в моём понимании, даже если лежит где-то вдали, запроашивается один раз при старте. А далее либо только записываются изменения, либо могут перечитываться в многопользовательском режиме, если изменены кем-то другим - но и то, и другое не должно быть часто. Но у тебя явно не тот вариант. Цитата(lat @  1.10.2013,  19:28 ) 50000 приложений, в каждом из которых будет по 2500 параметров Это что ж за зверёк-то такой? причём уже существующий... А на чём он сейчас работает?  Хотя 125кк записей для MS SQL - не такой уж и страшный объём. Цитата(lat @  1.10.2013,  19:28 ) используется сервер MS-SQL 2005 разной сборки под разных клиентов Это как - один сервер, но разной сборки? Цитата(lat @  1.10.2013,  19:28 ) Для Express это Продакшен такого размера - на экспрессе? ты в своём уме? на аксессе ещё начни строить... а для нормального сервера размер БД ограничен только параметрами хранилова и файловой системы. Цитата(lat @  1.10.2013,  19:28 ) Выход из ситуации вижу пока один,  выделить общие параметры для однотипных приложений и сделать их общими Для осмысленного ответа мало сведений о системе. Но мне кажется, что надо выбросить мультитабличную бредятину и перейти на сериализацию параметров с хранением в единой таблице.

Автор: Magistrus 2.10.2013, 10:29

Не понимаю причину паники, в свое время разрабатывал приложение, где сервером хранения баз данных был SQL Server 2000. Примерно каждую минуту в базу сохранялась картинка с камеры, камер было больше 100. Когда я увольнялся, в базе было более 2,5 млн записей и все работало. Объем базы тоже был больше 4Гб.  Главное это правильная разработка архитектуры, запросов и индиксов. Да и лучше не включать автоматическую оптимизацию запросов, ляжет сервер точно ;)

Автор: lat 2.10.2013, 10:36

Цитата Я вообще не понимаю, о чём речь. Что за параметры хранятся в БД?  Приложение, структура   - параметр «Номер приложения» - параметр «Название приложения» - параметр «Секция настройки параметров коммуникации» - параметр «Секция настроек …» 2000 секций -- параметр «настройки Секции …» n параметров - параметр «Файлы» ПО представляет собой комплекс за основу которого взята Клиент-Серверная архитектура. Сервер используется лишь для хранения, вся обработка данных на Клиенте (Rich-клиент).  Клиент - многопользовательская система, работа которой заключается в редактировании параметров для приложений/сущностей/объектов. Какие именно параметры будут использоваться, система не знает. Для каждого из приложений может быть свой набор.  Цитата Это что ж за зверёк-то такой? причём уже существующий... А на чём он сейчас работает?  Клиент переходит на нашу систему, для обслуживания своей сети.  До этого использовался другой комплекс, тонкости его реализации мне не известны.   Цитата Это как - один сервер, но разной сборки? Мы предоставляем Клиент и Скрипт БД,  клиент сам решает на какой сервер установить Скрипт. Цитата Продакшен такого размера - на экспрессе? ты в своём уме? на аксессе ещё начни строить... а для нормального сервера размер БД ограничен только параметрами хранилова и файловой системы. Вечером ум был на месте, утром – ещё не проснулся =)  Диктовать клиенту в выборе Сервера не моя прерогатива, с нашей  стороны есть рекомендации описанные в документации.  Но как показывает практика, клиент начинает экономить и вместо требуемых, покупает, что по дешевле.   Цитата перейти на сериализацию параметров С этого места поподробнее.

Автор: lat 2.10.2013, 11:03

Цитата(Magistrus @ 2.10.2013,  09:29) Не понимаю причину паники Сам задумался,  а чего собственно? Сходил к тестироващикам, попинал: «И-за чего все началось?».  Проект миграции обсуждали давно, оказывается многое забыл. Свежая инфа, в шапке обновлю: Добавление 1 Приложения в базу увеличивает количество параметров STRING на 7029 штук INT на 63 808 штук BIN на 78 штук. Одно приложение = + 70 915 единичных параметров. 50 000 терминалов = 3 545 750 000 параметров?! --- Т.е. упустил момент, что  +2000 не параметров, а секций. В каждой из которой может быть n-е число параметров.

Автор: Zloxa 2.10.2013, 12:09

Цитата(lat @  1.10.2013,  19:28 )  Могу лишь предположить, что такая структура уменьшит нагрузку на сервер, и файловую систему.  Это, на сколько я понял, классическая структура определяемых пользователем аттрибутов. Обычно эту структуру используют, когда на этапе проектирования нет четкого понимания условий эксплуатации Цитата(lat @  1.10.2013,  19:28 ) Выполнив простую арифметику, 50000*2500= 125 000 000  делаем прогноз, - «Господа, все ляжет! Support, запасайтесь терпением. Манагеры, готовьте скидки. » Этой арифметики не достаточно для такого прогноза. Ничего из сказанного вами не говорит о том, что ваши опасения не беспочвенны, кроме упоминания эпитета "худо-бедно" по отношению к тому, что есть сейчас. Сайзинг и организация структуры хранения для хранения как такового, обычно проблемой являются лишь в случае интенсивного прироста данных, то, что данные вам нарастить удастся, я так понимаю, вы не сомневаетесь. Вы сомневаетесь, как я понимаю, что сможете их потом без особых потерь в производительности извлеакать. Для того чтобы  строить заключения на этот счет, нужно помимо сайзинга и структуры, понимать еще и как используются данные.

Автор: lat 2.10.2013, 13:00

Цитата Этой арифметики не достаточно для такого прогноза. Ничего из сказанного вами не говорит о том, что ваши опасения не беспочвенны, кроме упоминания эпитета "худо-бедно" по отношению к тому, что есть сейчас. Немного обновил данные, выходит что в самом начале эксплуатации в базе будет 3 545 750 000 записей в 3 таблицах. Мне как не большому знатоку  БД, в частности MS-SQL, интересно как такой объём повлияет на работу сервера? И сколько нужно дискового пространства + запас, для нормальной работы?    Цитата Вы сомневаетесь, как я понимаю, что сможете их потом без особых потерь в производительности извлеакать.   Именно, текущая реализация работает, если не вдаваться в подробности, очень медленно. На загрузку одного приложения Клиент тратит от 30с до 5м, в зависимости от количества параметров.   Как вы верно заметили прирост не проблема, а вот извлечение и обработка данных, это меня смущает. Пожалуй, эти детали можно опустить. Описать подробно процесс, схему работы и саму БД не могу, политика компании (большой Бро). Поэтому ограничиваюсь абстрактными понятиями.  В первую очередь интересно следующее:  - сможет ли сервер, а именно, MS-SQL 2005 справиться с таким наплывом информации? - best-practices при использовании большого, огромного, числа данных?

Автор: Zloxa 2.10.2013, 14:56

Цитата(lat @  2.10.2013,  14:00 ) Поэтому ограничиваюсь абстрактными понятиями.  Поэтому, увы, вам придется удовлетвориться абстрактными ответами.  Цитата(lat @  2.10.2013,  14:00 ) - сможет ли сервер, а именно, MS-SQL 2005 справиться с таким наплывом информации? да Цитата(lat @  2.10.2013,  14:00 ) - best-practices при использовании большого, огромного, числа данных?  осуществлять доступ к данным так, как это надо. использовать индексирование там, где это надо. использовать секционирование там, где это надо. использовать распределенные базы там, где это надо. Еще раз повторюсь - знаний о кличестве, размере данных и структуре их хранения не достаточно для того чтобы делать какие бы то не было заключения и вырабатывать какие бы то ни было рекомендации. При услвии, что у вас не хоронилище данных, где данные не хранятся, а хоронятся, надо знать еще как данные должны быть использованы.

Автор: Magistrus 3.10.2013, 18:13

Цитата(lat @  2.10.2013,  13:00 ) - сможет ли сервер, а именно, MS-SQL 2005 справиться с таким наплывом информации? да Цитата - best-practices при использовании большого, огромного, числа данных?  запросы должны быть простыми и оптимально использовать индексы. Выбирать лучше одним запросом, а не кучей мелких. Избегать агрегирования.  В первую очередь я бы посоветовал разобраться, почему медленно работает текущая реализация и постаратся ее оптимизировать, а потом уже расширять решение.  Какой средний размер blob полей в базе? Желательно чтобы такие столбцы не участвовали в SELECT в промежуточных выборках, если они есть.

Автор: Fortop 4.10.2013, 16:38

Цитата(Magistrus @  3.10.2013,  18:13 )  почему медленно работает текущая реализация Это очевидно же Цитата(lat @  1.10.2013,  18:28 ) Всего таблиц 3, для каждого из типов, а именно:  Числовые, Строковые и Бинарные Значения. Цитата(Zloxa @  2.10.2013,  12:09 ) Это, на сколько я понял, классическая структура определяемых пользователем аттрибутов. EAV всегда медленный. Перевести все в адекватные таблицы и скорость возрастет в десятки раз.

Автор: Akina 4.10.2013, 16:46

lat, мне не нравится то, что Вы рассказываете. Это очень нелогично. Такое впечатление, что Вы скрываете суть, а рассказываете аналогию.  Но аналогия - неудачна, описанный процесс не имеет смысла. В результате невозможно понять механизмов накопления и использования информации, степени её однородности, разрозненности и изменчивости, понять требуемый к обработке поток запросов с раскладкой по типам и оценить объём отдаваемой и изменяемой информации. Без всего этого можно давать лишь самые общие рекомендации. На системе Вашего объёма, да ещё на непонятной аппаратно-программной платформе, они почти бессмысленны.

Автор: Zloxa 4.10.2013, 17:04

Цитата(Fortop @  4.10.2013,  17:38 ) EAV всегда медленный. На сколько я понял, это не EAV, это просто AV, без E И медленней он не всегда на порядки. Есть частные случаи, когда вполне можно добиться приемлемой производительности и масштабируемости. Правда, да, эти случаи весьма не часты в виду своей ограниченности.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)