Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Горизонтальное масштабирование: логика приложения (  [new]
Масштабный
Guest
Всем привет!

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

Дано. Нагруженная OLTP база, которая хранит счета и проводки со счета на счет. Табличка проводок - ключевая, на ней строится вся основная логика. И именно она быстро растет. Есть еще около 200 таблиц которые так или иначе хранят разные операции пользователей, имеющие ссылки на эти проводки (продажи, покупки, комиссии т.д.). Структура двух основных таблиц упрощенно выглядит так:
1) Таблица учетных записей
AccountId; Balance

2) Таблица проводок
EntryId; SrcAccountId; DstAccountId; Amount;

Логика всех верхне-уровневых операций написана на T-SQL и представлена в виде хранимок. Сервер приложений тупо их вызывает и заворачивает ответ в XML. Все абсолютно хранимки принимают параметр AccountId, то есть всегда есть контекст пользователя, по которому предполагается определять инстанс базы, куда нужно обратиться. Уперлись в то, как нам делить процедуру создания проводки. Она одна и вызывается из 500+ других процедур. Вызывающие процедуры могут создавать по несколько проводок в цикле, они же могут пытаться откатить все что наделали, если произошла ошибка. Вот тут и возникает основной вопрос - как не переписывая все вызывающие процедуры научиться создавать требуемые проводки на разных серверах, если один из счетов судя по карте хостится "удаленно"?

Принимаются любые предложения от сервис брокера до CLR хранимок. Может вообще смотреть в сторону DTC? У нас ведь как ни крути получается распределенная транзакция.

Поделитесь любым опытом, будет очень полезно. Может кто расскажет как банковские АБСки работают или они не масштабируются? Вроде задачи похожие.
29 май 13, 16:57    [14365886]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
londinium
Member

Откуда: Киев
Сообщений: 1197
автор
Может кто расскажет как банковские АБСки работают или они не масштабируются?

Ни разу не профессионал в АБСостроении. Так, наглый любитель. В банке есть понятие закрытия опер.периода - когда исторические проводки уезжают в архив. Зачем Вам сейчас бегать по проводкам 2010 года? Снесли их в архив и все
29 май 13, 17:03    [14365941]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Glory
Member

Откуда:
Сообщений: 104751
Масштабный
как не переписывая все вызывающие процедуры научиться создавать требуемые проводки на разных серверах, если один из счетов судя по карте хостится "удаленно"?

BOL - Creating Distributed Partitioned Views
29 май 13, 17:05    [14365965]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Масштабный
Guest
Glory,

Вьюшка объединяющая все данные как таковая не нужна. Этот вариант в первую очередь рассматривали, и в принципе он пока самый рабочий. Только без вью, а с выполнением удаленных процедур через linked сервера, дабы соблюсти транзакционность. Какие есть подводные камни?

Londinium,

Урезать не подходит. База прогибается именно от вставок, аналитика - отдельная история. Да и смотри требование бизнеса про удаленный хост со своими аккаунтами.
29 май 13, 18:35    [14366363]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
автор
Дано. Нагруженная OLTP база, которая хранит счета и проводки со счета на счет. Табличка проводок - ключевая, на ней строится вся основная логика. И именно она быстро растет. Есть еще около 200 таблиц которые так или иначе хранят разные операции пользователей, имеющие ссылки на эти проводки (продажи, покупки, комиссии т.д.).


Насколько нагруженная (тысяч транзакций в секунду)? Какой размер (число записей, размер) ключевой таблички? Общий размер базы? % роста в месяц, год?

автор
видим, что через годик одним сервером не справимся никак


"Видим" - это анализ каких счетчиков? Сервер "какой", СХД какая?

автор
научиться создавать требуемые проводки на разных серверах


А зачем?!
29 май 13, 20:04    [14366675]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Масштабный
Guest
pkarklin,

Я так понимаю в целом посыл такой - масштабировать не надо, справитесь на одном сервере?) Я тоже себя вдохновляют тем что, "вон, сбербанк как-то все карточки процессит на одной машине и ничего". Просто когда они упали и всем сталв известна их конфигурация, я был удивлен.

Собственно мой ответ на твои вопросы. Сейчас цифры не очень страшные, в пике доходит до 400 транзакий в секунду, но около года назад пики не превышали 60 транзакций. 5 кратный прирост за год. При этом сейчас мы должны запустить на этом же ядре еще пару проектов со сложно прогнозируемой нагрузкой.

База в RCSI объемом чуть больше 300Гб. Вся на SSD, таблица проводок вынесена на отдельный диск. Лог транзакций на отдельном, tempdb тоже. Причины почему "видим" - две, уже писал. Сейчас бизнесу даже более важно научиться выносить часть аккаунтов в ДЦ к заказчикам, спустя время - не менее важным станет вопрос производительности.
29 май 13, 20:36    [14366763]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Масштабный
Guest
Во я счетовод, получается не почти в семь раз выросло
29 май 13, 20:38    [14366769]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
автор
в целом посыл такой - масштабировать не надо, справитесь на одном сервере


В целом посыл такой - MS SQL горизонтально не масштабируется без геморроя.

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


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

автор
5 кратный прирост за год


За следующие 3 какие прогнозы прироста? Ибо с 60 до 400 - это одно, а с 400 до 1200 - это другое.

автор
Причины почему "видим" - две, уже писал.


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

автор
объемом чуть больше 300Гб


Это маленькая бд. Конфигурацию сервера так и не озвучили. Хотя без показаний счетчиков это мало интересно.

автор
Сейчас бизнесу даже более важно научиться выносить часть аккаунтов в ДЦ к заказчикам,


И это должна обязательно быть одна база распределенная база?
29 май 13, 20:51    [14366811]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Масштабный
Guest
Ну горизонтальное масштабирование по определению без геморроя не проходит, а нас так еще и вся логика на tsql да и терять данные никак нельзя, бабки считаются. Бизнес требует заложить минимум 10 кратный рост в течеие 2 лет. Такими темпами 1200 мы быстро догоним. По счетчикам честно признаюсь давно не ходил. Как поставили в феврале SSD все стало хорошо, все успокоились. А раньше упирались в осносном в диск, очередь на дисковые операции в пиках достигала 300мс. Если скажешь какие счетчики показать, с удовольствием посмотрю.

Что касается пазмера базы, безусловно ее сейчас хоть в оперативу загоняй, но время тикает)
Сервер dell не помню какой, но из свеэих, 16 физических ядер, 128 гб памяти. Диски твердотельные фирменные, все SLC, все в рейдах.
29 май 13, 21:48    [14367066]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Масштабный
Guest
pkarklin,

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


С айпада пищу, неудобно до задницы. Простите за опечатки
29 май 13, 21:52    [14367081]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
мимокрокодил
Guest
Масштабный,

шардинг таблички проводок по accountId, (например accountId % n, правда гемор при добавлении/удалении нод) не рассматриваете?
29 май 13, 22:08    [14367119]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Масштабный
Бизнес требует заложить минимум 10 кратный рост в течеие 2 лет.


Оптимистично. Т.е. получается 4 000 транзакций в секунду. Немного...


Масштабный
Если скажешь какие счетчики показать, с удовольствием посмотрю.


http://technet.microsoft.com/en-us/library/cc966540.aspx

автор
Сервер dell не помню какой, но из свеэих, 16 физических ядер, 128 гб памяти. Диски твердотельные фирменные, все SLC, все в рейдах.


Подавился печенькой... Сервер один? Диски внутренние? Бизнес только производительность интересует? Мдя...
29 май 13, 22:13    [14367136]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
мимокрокодил
шардинг таблички проводок по accountId, (например accountId % n, правда гемор при добавлении/удалении нод) не рассматриваете?


Здесь нечего шардить. Это задачи серверов начального уровня, например, DL380 Gen8 с какой-нить HP MCA2000 и парой полок. Гимор с шардингом в данном случае - стрельба из пушки по воробьям.
29 май 13, 22:16    [14367147]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
мимокрокодил
Guest
Масштабный
pkarklin,

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


С айпада пищу, неудобно до задницы. Простите за опечатки


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

и копии хранимок использующих эти данные.

выше приклад определяет номер шарда и вызывает хранимку на нем.
29 май 13, 22:18    [14367156]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
мимочебурашка
Guest
pkarklin,

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

да, предполагаю, что остальное автор все попробовал.
29 май 13, 22:22    [14367169]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
мимокрокодил
на каждой шарде можно вести таблицу accid, bal. в нем записи относящиеся только к данной шарде.

и копии хранимок использующих эти данные.

выше приклад определяет номер шарда и вызывает хранимку на нем.


Угу. Строим федерацию из 10ти серверов, размазывая эккаунты по последней цифре. Ставим еще 10ок рядом, дабы обеспечить отказоустойчивость...
29 май 13, 22:23    [14367173]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
мимочебурашка
да, предполагаю, что остальное автор все попробовал.


Автор даже не помнит, что у него за сервер и как он нагружен. Прогнать нагрузочное тестирование видимо тоже не пробовали.
29 май 13, 22:30    [14367201]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
МуМу
Member

Откуда:
Сообщений: 1134
http://www.microsoft.com/ru-ru/news/archive/2013/05/Microsoft_and_SoftPoint_confirm_efficiency_of_their_product_collaboration.aspx
Вот пример из последнего решения. Но честно говоря не понял конечной цели и оптимального решения из сумбурного объяснения.
30 май 13, 01:41    [14367644]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Кроме горизонтальной масштабируемости есть еще так называемые параллельные вычисления по которым есть тоже масса наработок. Готов бесплатно поделиться опытом если будет описание проблемы подробнее и конкретней. Насчет применения параллельных вычислений существует масса заблуждений. Я например на эту тему много споров выиграл. Последний пример восстановление последовательности документов для партионного учета(расчет себестоимости по фифо) в случае естественного уровня параллелизма значением один(например один и тот же товар в каждом документе) все равно можно распараллелить.
30 май 13, 01:48    [14367647]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
aleks2
Guest
Масштабный
Сейчас бизнесу даже более важно научиться выносить часть аккаунтов в ДЦ к заказчикам, спустя время - не менее важным станет вопрос производительности.


1. Вы ужо определитесь: чо вам надо то?
2. Если производительность - дык вам сказали, что ваш сервант ишо бодренько будет работать.
3. Если "выносить часть аккаунтов в ДЦ к заказчикам" - дык репликацию освойте, чтоле? Ибо иметь копию завсегда полезно.
30 май 13, 08:16    [14367826]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
SIMPLicity_
Member

Откуда: (((@)))
Сообщений: 8854
Уважаемый ТС, DTC, мне кажется, в Вашем случае - проигрышный вариант. Забудьте.
Репликация информации на сервера клиентов,- возможно да.

Я бы "нарезал" базу кусочками (по годам). Может быть, секционировал бы таблицу проводок на центральном сервере (заказчики пусть "трахаются" на своих локальных серверах как им заблагорассудится).
30 май 13, 09:15    [14368063]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Glory
Member

Откуда:
Сообщений: 104751
Масштабный
Вьюшка объединяющая все данные как таковая не нужна. Этот вариант в первую очередь рассматривали, и в принципе он пока самый рабочий. Только без вью, а с выполнением удаленных процедур через linked сервера, дабы соблюсти транзакционность. Какие есть подводные камни?

Вы же вроде поставили условие "не переписывая все вызывающие процедуры"
Правильно составленный Partitioned Views как раз и разрулит куда должны попасть данные при insert/update/delete
30 май 13, 09:20    [14368091]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Arm79
Member

Откуда: МО, Раменское
Сообщений: 3693
Еще экзотический вариант: рассмотрите свой вариант MapReduce. Раскидайте данные по нескольким серверам с одинаковой структурой БД. Можно с избыточностью, для сохранности данных. И сервером приложений одновременно один запрос на несколько серверов. а потом конкатенация результата.

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

PS Использование Linked серверов при частом дергании и транзакциях - это проблемы. Неправильно написанный селект с джойном удаленной таблицы легко и просто загрузит сеть сотнями мегабайтов информации. В общем, к ним нужно подходить с осторожностью.
30 май 13, 09:30    [14368133]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
Масштабный
Guest
Ого какой интерес, давайте по пунктам))

Map-Reduce нам не нужен, нужно разрулить именно вставку. С чтениями и аналитикой вопросов нет. Сервер приложений переписывать туго, очень много времени уйдет.
Репликацию мы освоили, есть еще и полный миррор, для отказоустойчивости. Теперь хотим еще и регистрировать счета и инициировать там же переводы с них и на них. В общем оцениваем возможности и степень геморройности.

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

Оставлю несколько общих вопросов:
1) Есть ли известные практики в масштабировании систем учета с двойной записью дебет-кредит, при условии синхронности выполнения операции на всех участвующих нодах?
2) Какие есть проблемы в подходе, когда мы будем добавлять все сервера друг другу как линкед и выполнять друг у друга хранимки?
3) Может вовсе какой-то варианты вообще пропустили? Задача сводится к транзакционному, синхронному вызову процедур на разных серверах. Мы рассматриваем в том числе варианты софтовой "транзакционности", когда откат делается допустим сторнированием.
30 май 13, 12:30    [14369346]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование: логика приложения (  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Обычно масштабирование происходит за счет распределения нагрузки на чтение. (даже если эта чтение в транзакции) Честно говоря не верится что у вас нагрузка исключительно создается операциями на запись. Впрочем если это так то увы. Можно масштабировать за счет дисковых контроллеров и увеличения дисковых мощностей, разумеется эффект будет если все правильно и оптимально настроить. Если и этого не хватит то смотрите в сторону PDW, судя по описаниям там есть необходимый функционал. (правда его так понимаю никто не щупал, да и для ярко выраженных биллинговых систем не факт что подойдет.)
30 май 13, 18:25    [14372100]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить