Хранение множества параметров приложения

 
0
 
MS SQL Server
ava
lat | 01.10.2013, 19:28
Доброго времени суток.

Есть рабочая БД, досталась по наследству.

Упрощенная схема:

Приложение  --->> Таблицы значений параметров

Приложение 
Id (int) Primary Key
Description (Text)
...

Таблица параметров_%type%
Id (Int) Primary Key
AppId (Int) Foreign Key
Value (%type%)

Всего таблиц 3, для каждого из типов, а именно:
Числовые, Строковые и Бинарные Значения.
Почему так? – Могу лишь предположить, что такая структура уменьшит нагрузку на сервер, и файловую систему.

Как это работает? 
Если просто,
есть приложение, все параметры приложения хранятся в таблицах Параметры, разбитые по типам.  
Сейчас, количество параметров для одного приложения не превышает значения в 100 единиц. Это нормально, в таком режиме система работает худо-бедно.

Проблема
За этот месяц нужно подготовить решение для большой сети, в начальном состоянии состоящей из 50000 приложений, в каждом из которых будет по 2500 параметров.
Выполнив простую арифметику, 50000*2500= 125 000 000 делаем прогноз,
- «Господа, все ляжет! Support, запасайтесь терпением. Манагеры, готовьте скидки. »

Причина моего скептицизма кроется в следующем: 
- используется сервер MS-SQL 2005 разной сборки под разных клиентов, судя по тому, что я нашел в сети, есть ограничения на размер базы данных. Для Express это 4Гб, уже мимо.
- как работать с таким объёмом данных?  Это мой первый опыт, и хочеться сделать все хорошо. Если нужно переделать все с нуля, бывалые-седоволосые-деды, пожалуйста, подскажите как или что почитать?


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

Примечание:
Решать за меня не нужно, и уж тем более проектировать. Хотя если есть время и желания, от помощи не откажусь.
Мне нужна лишь подсказка для зазуглить, только укажите направление куда копать. Желательно «не от сюда, и до обеда».
Есть же решения под такие задачи, и думаю что придуманы они давно, мне бы только названия, имена, пароли и явки =)
Comments (11)
ava
Akina | 01.10.2013, 20:31 #
Цитата (lat @  1.10.2013,  19:28 findReferencedText)
Всего таблиц 3, для каждого из типов, а именно: 

Числовые, Строковые и Бинарные Значения.

Почему так? – Могу лишь предположить, что такая структура уменьшит нагрузку на сервер, и файловую систему. 

Я могу предположить, что программисту просто было тупо лень делатиь по-человечески.

Цитата (lat @  1.10.2013,  19:28 findReferencedText)
Сейчас, количество параметров для одного приложения не превышает значения в 100 единиц. Это нормально, в таком режиме система работает худо-бедно.

Я вообще не понимаю, о чём речь. Что за параметры хранятся в БД?
То, что параметры в моём понимании, даже если лежит где-то вдали, запроашивается один раз при старте. А далее либо только записываются изменения, либо могут перечитываться в многопользовательском режиме, если изменены кем-то другим - но и то, и другое не должно быть часто. Но у тебя явно не тот вариант.

Цитата (lat @  1.10.2013,  19:28 findReferencedText)
50000 приложений, в каждом из которых будет по 2500 параметров

Это что ж за зверёк-то такой? причём уже существующий... А на чём он сейчас работает?
Хотя 125кк записей для MS SQL - не такой уж и страшный объём.

Цитата (lat @  1.10.2013,  19:28 findReferencedText)
используется сервер MS-SQL 2005 разной сборки под разных клиентов

Это как - один сервер, но разной сборки?

Цитата (lat @  1.10.2013,  19:28 findReferencedText)
Для Express это

Продакшен такого размера - на экспрессе? ты в своём уме? на аксессе ещё начни строить... а для нормального сервера размер БД ограничен только параметрами хранилова и файловой системы.

Цитата (lat @  1.10.2013,  19:28 findReferencedText)
Выход из ситуации вижу пока один, 

выделить общие параметры для однотипных приложений и сделать их общими

Для осмысленного ответа мало сведений о системе. Но мне кажется, что надо выбросить мультитабличную бредятину и перейти на сериализацию параметров с хранением в единой таблице.
ava
Magistrus | 02.10.2013, 10:29 #
Не понимаю причину паники, в свое время разрабатывал приложение, где сервером хранения баз данных был SQL Server 2000.

Примерно каждую минуту в базу сохранялась картинка с камеры, камер было больше 100. Когда я увольнялся, в базе было более 2,5 млн записей и все работало. Объем базы тоже был больше 4Гб. 
ava
lat | 02.10.2013, 10:36 #
Цитата


Я вообще не понимаю, о чём речь. Что за параметры хранятся в БД? 


Приложение, структура  
- параметр «Номер приложения»
- параметр «Название приложения»
- параметр «Секция настройки параметров коммуникации»
- параметр «Секция настроек …» 2000 записей
- параметр «Файлы»

ПО представляет собой комплекс за основу которого взята Клиент-Серверная архитектура.
Сервер используется лишь для хранения, вся обработка данных на Клиенте (Rich-клиент).
Клиент - многопользовательская система, работа которой заключается в редактировании параметров для приложений/сущностей/объектов. Какие именно параметры будут использоваться, система не знает. Для каждого из приложений может быть свой набор.

Цитата


Это что ж за зверёк-то такой? причём уже существующий... А на чём он сейчас работает? 



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

Цитата


Это как - один сервер, но разной сборки?



Мы предоставляем Клиент и Скрипт БД,
клиент сам решает на какой сервер установить Скрипт.

Цитата


Продакшен такого размера - на экспрессе? ты в своём уме? на аксессе ещё начни строить... а для нормального сервера размер БД ограничен только параметрами хранилова и файловой системы.



Вечером ум был на месте, утром – ещё не проснулся =)

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

Цитата


перейти на сериализацию параметров с хранением в единой таблице. 



С этого места поподробнее.  
ava
lat | 02.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-е число параметров.
ava
Zloxa | 02.10.2013, 12:09 #
Цитата (lat @  1.10.2013,  19:28 findReferencedText)
 Могу лишь предположить, что такая структура уменьшит нагрузку на сервер, и файловую систему. 

Это, на сколько я понял, классическая структура определяемых пользователем аттрибутов.
Обычно эту структуру используют, когда на этапе проектирования нет четкого понимания условий эксплуатации
Цитата (lat @  1.10.2013,  19:28 findReferencedText)
Выполнив простую арифметику, 50000*2500= 125 000 000 

делаем прогноз, - «Господа, все ляжет! Support, запасайтесь терпением. Манагеры, готовьте скидки. »

Этой арифметики не достаточно для такого прогноза. Ничего из сказанного вами не говорит о том, что ваши опасения не беспочвенны, кроме упоминания эпитета "худо-бедно" по отношению к тому, что есть сейчас.
ava
lat | 02.10.2013, 13:00 #
Цитата


Этой арифметики не достаточно для такого прогноза. Ничего из сказанного вами не говорит о том, что ваши опасения не беспочвенны, кроме упоминания эпитета "худо-бедно" по отношению к тому, что есть сейчас.



Немного обновил данные, выходит что в самом начале эксплуатации в базе будет 3 545 750 000 записей в 3 таблицах. Мне как не большому знатоку  БД, в частности MS-SQL, интересно как такой объём повлияет на работу сервера? И сколько нужно дискового пространства + запас, для нормальной работы?   

Цитата


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



Именно, текущая реализация работает, если не вдаваться в подробности, очень медленно.
На загрузку одного приложения Клиент тратит от 30с до 5м, в зависимости от количества параметров.  
Как вы верно заметили прирост не проблема, а вот извлечение и обработка данных, это меня смущает.
Пожалуй, эти детали можно опустить. Описать подробно процесс, схему работы и саму БД не могу, политика компании (большой Бро). Поэтому ограничиваюсь абстрактными понятиями.

В первую очередь интересно следующее:
- сможет ли сервер, а именно, MS-SQL 2005 справиться с таким наплывом информации?
- best-practices при использовании большого, огромного, числа данных?

ava
Zloxa | 02.10.2013, 14:56 #
Цитата (lat @  2.10.2013,  14:00 findReferencedText)
Поэтому ограничиваюсь абстрактными понятиями. 

Поэтому, увы, вам придется удовлетвориться абстрактными ответами. :unknw

Цитата (lat @  2.10.2013,  14:00 findReferencedText)
- сможет ли сервер, а именно, MS-SQL 2005 справиться с таким наплывом информации?

да
Цитата (lat @  2.10.2013,  14:00 findReferencedText)
- best-practices при использовании большого, огромного, числа данных? 

использовать секционироание там, где это надо.
использовать индексирование там, где это надо.
использовать распределенные базы там, где это надо.
осуществлять доступ к данным так, как это надо.


Еще раз повторюсь - знаний о кличестве, размере данных и структуре их хранения не достаточно для того чтобы делать какие бы то не было заключения и вырабатывать какие бы то ни было рекомендации. При услвии, что у вас не обычное хоронилище данных, надо знать еще как данные должны быть использованы.
ava
Magistrus | 03.10.2013, 18:13 #
Цитата (lat @  2.10.2013,  13:00 findReferencedText)
- сможет ли сервер, а именно, MS-SQL 2005 справиться с таким наплывом информации?

да
Цитата
- best-practices при использовании большого, огромного, числа данных? 

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

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

Какой средний размер blob полей в базе? Желательно чтобы такие столбцы не участвовали в SELECT в промежуточных выборках, если они есть.
ava
Fortop | 04.10.2013, 16:38 #
Цитата (Magistrus @  3.10.2013,  18:13 findReferencedText)
 почему медленно работает текущая реализация

Это очевидно же

Цитата (lat @  1.10.2013,  18:28 findReferencedText)
Всего таблиц 3, для каждого из типов, а именно: 

Числовые, Строковые и Бинарные Значения.

Цитата (Zloxa @  2.10.2013,  12:09 findReferencedText)
Это, на сколько я понял, классическая структура определяемых пользователем аттрибутов.


EAV всегда медленный.

Перевести все в адекватные таблицы и скорость возрастет в десятки раз.
ava
Akina | 04.10.2013, 16:46 #
lat, мне не нравится то, что Вы рассказываете. Это очень нелогично. Такое впечатление, что Вы скрываете суть, а рассказываете аналогию.

Но аналогия - неудачна, описанный процесс не имеет смысла. В результате невозможно понять механизмов накопления и использования информации, степени её однородности, разрозненности и изменчивости, понять требуемый к обработке поток запросов с раскладкой по типам и оценить объём отдаваемой и изменяемой информации. Без всего этого можно давать лишь самые общие рекомендации. На системе Вашего объёма, да ещё на непонятной аппаратно-программной платформе, они почти бессмысленны.
ava
Zloxa | 04.10.2013, 17:04 #
Цитата (Fortop @  4.10.2013,  17:38 findReferencedText)
EAV всегда медленный.

На сколько я понял, это не EAV, это просто AV, без E

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

Please register or login to write.
Firm of day
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
Contributors
  Akina   Magistrus ava  Fortop   lat ava  Zloxa
advanced
Submit