Доброго времени суток.

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

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

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

Приложение 
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 параметров


Это сообщение отредактировал(а) lat - 2.10.2013, 11:09

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


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


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


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


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


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

Не понимаю причину паники, в свое время разрабатывал приложение, где сервером хранения баз данных был SQL Server 2000.

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

Главное это правильная разработка архитектуры, запросов и индиксов. Да и лучше не включать автоматическую оптимизацию запросов, ляжет сервер точно ;)

Это сообщение отредактировал(а) Magistrus - 2.10.2013, 10:30

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

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



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



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



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

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



С этого места поподробнее.  


Это сообщение отредактировал(а) lat - 2.10.2013, 11:19

Сам задумался,  а чего собственно?

Сходил к тестироващикам, попинал: «И-за чего все началось?». 
Проект миграции обсуждали давно, оказывается многое забыл.

Свежая инфа, в шапке обновлю:

Добавление 1 Приложения в базу увеличивает количество параметров
STRING на 7029 штук
INT на 63 808 штук
BIN на 78 штук.

Одно приложение = + 70 915 единичных параметров.
50 000 терминалов = 3 545 750 000 параметров?!

---
Т.е. упустил момент, что  +2000 не параметров, а секций. В каждой из которой может быть n-е число параметров.


Это сообщение отредактировал(а) lat - 2.10.2013, 11:10

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

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


Это сообщение отредактировал(а) Zloxa - 2.10.2013, 12:18

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

 

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

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

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


да

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


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

Это сообщение отредактировал(а) Zloxa - 2.10.2013, 14:59

да

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

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

Какой средний размер blob полей в базе? Желательно чтобы такие столбцы не участвовали в SELECT в промежуточных выборках, если они есть.

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




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

Перевести все в адекватные таблицы и скорость возрастет в десятки раз.

lat, мне не нравится то, что Вы рассказываете. Это очень нелогично. Такое впечатление, что Вы скрываете суть, а рассказываете аналогию. 

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

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

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



Это сообщение отредактировал(а) Zloxa - 4.10.2013, 17:05