Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4      [все]
 Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
Проектируется система, которая будет содержать платежные транзакции. Транзакций в теории может быть очень много, скажем миллион в час. Каждая запись должна содержать id этой транзакции, id карты с которой пришла, и другие параметры, например дату-время и кучу всего прочего.
Не хочется изобретать велосипед, таких систем наверняка вагоны и маленькая тележка. Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего. Каким образом делаются таблицы где требуется массированная вставка строк?
24 май 17, 09:16    [20506438]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
stenford
Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего. Каким образом делаются таблицы где требуется массированная вставка строк?
Думаете существует какое-то заклинание по созданию волшебно-быстрой таблицы ? :)

По возможности меньше полей и индексов. Поля желательно минимальной длины.
Некоторые советуют использовать char вместо varchar и краткую дату, если не важны секунды и следующее столетие.
24 май 17, 09:22    [20506457]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
stenford,

вряд ли identity узкое место. Лог, индексы, сама генерация записи, ну и железо...
24 май 17, 09:32    [20506485]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
LSV
Думаете существует какое-то заклинание по созданию волшебно-быстрой таблицы ? :)

По возможности меньше полей и индексов. Поля желательно минимальной длины.
Некоторые советуют использовать char вместо varchar и краткую дату, если не важны секунды и следующее столетие.


может и существует, для этого и спрашиваю)
Меньше полей конечно понятно, но их-же не сделаешь меньше чем требуется для работы. Поэтому может например id'шники для строк как-то отдельно генерируются в другой таблице, или вообще разбивается на несколько таблиц или еще что-нибудь в этом роде. Кроме того еще имеет место быть такие вещи как indexed views для хранения остатка по картам что-бы не делать такие запросы на "живой" таблице, все это в результате выполняется внутри транзакции и удлиняет ее, тоже непонятно нормальное решение или как-то таские вещи по-другому делаются
24 май 17, 09:37    [20506509]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
TaPaK
вряд ли identity узкое место. Лог, индексы, сама генерация записи, ну и железо...

ну вот и интересует кто уже подобные велосипеды делал и проходил этапы определения что и как можно заоптимизировать
24 май 17, 09:39    [20506518]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
aleksrov
Member

Откуда:
Сообщений: 948
stenford,

А если In memory поробывать? Не идеал конечно, но если нагрузка и впрямь столь серьезная может и подойдет.
Хотя если честно с банками дело не имел и не знаю как должно быть в этой сфере :)
24 май 17, 09:58    [20506610]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
aleks2
Guest
aleksrov
stenford,

А если In memory поробывать? Не идеал конечно, но если нагрузка и впрямь столь серьезная может и подойдет.
Хотя если честно с банками дело не имел и не знаю как должно быть в этой сфере :)


Казачок то заслатый!

ЗЫ. Тредстартер - чудак.
Не верит, что "простая таблица" будет работать быстро, но верит, что кучка простых таблиц со сложносочинеными связями будет работать "быстро".

Чудесны дела твои, осподи!
24 май 17, 10:14    [20506674]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
aleksrov
Member

Откуда:
Сообщений: 948
aleks2,

Ага, пишу прямиком из Редмонда.
Тут уже была тема что таблицы типа 2012, 2013, 2014, 2015 и т.д. самый быстрый способ :)
24 май 17, 10:39    [20506790]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
aleksrov
aleks2,

Ага, пишу прямиком из Редмонда.
Тут уже была тема что таблицы типа 2012, 2013, 2014, 2015 и т.д. самый быстрый способ :)
это быстрый способ управления, а не работы
24 май 17, 10:41    [20506798]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
invm
Member

Откуда: Москва
Сообщений: 9772
stenford
Транзакций в теории может быть очень много, скажем миллион в час
Это не нагрузка даже для простого домашнего компьютера.
stenford
Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего.
Наймите для проектирования системы специалиста у которого есть знания, а не подозрения. Иначе рискуете очень долго быть объектом граблетерапии.
24 май 17, 11:31    [20507076]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
Задача непонятна. Сколько вешать в граммах то?
Сколько записей вы будете писать, каким способом?
По записи? Пакетно? Bulk insert?
Какая нужна производительность записей?
1000 записей в секунду? 10 000? 100 000? 1 000 000?
Если ограничения - порядка 10 - 20 тысяч записей в секунду, пишете по одной записи, короткими транзакциями, в 1 таблицу - никакой дополнительной оптимизации не надо.
Сгодится совершенно ординарный сервер в ценовом диапазоне до 500 тыс. Дисковую подсистему только продумайте, и, возможно, сеть.

Если вам нужно до 100 000 в секунду, то тоже никакой оптимизации особой не надо.
Нужно много памяти, много ядер (но можно - относительно низкой частоты, не 1С чай), SSD диски (причем под логи - обязательно).
Можно таблицу на секции порезать и по разным дискам, висящим на разных каналах контроллера разнести.
И железяка потребуется несколько суровее.

А вот если речь идет примерно о миллионе в секунду и больше - вот тут уже всё сурово.
Тут уже нужно думать о специализированных решениях (например - Parallel Data Warehouse), и биться с разнесением таблицы по разным серверам и т.д.

А из рекомендаций к архитектуре - всё просто и стандартно.
Одна таблица. Можно широкую, но одну. Если для этого потребуется денормализовать схему данных - денормализуйте.
Короткие типы данных. Где можно использовать фиксированные типы - лучше использовать их. Используйте datetime2 вместо datetime. Там где это возможно, избегайте NULLable полей.
В качестве синтетического ключа - identity (но по нему совершенно необязательно строить кластерный индекс).
Никаких триггеров.
Никаких внешних ключей. Точнее - констрейнтов связанных с ними.
Минимум индексов.
Самый минимум индексов.
Никаких индексированных представлений, особенно сложных.

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

Как то так, ИМХО...
24 май 17, 11:37    [20507113]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
uaggster,

в общем всё так, только column store убьют вставку
24 май 17, 11:40    [20507124]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
it17
Member

Откуда:
Сообщений: 108
stenford
Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего. Каким образом делаются таблицы где требуется массированная вставка строк?

Вероятно вопрос касается только 1 поля: какого типа должен быть ключ.
Если сделать ключ по guid и генерить его на клиенте, то вставки будут работать быстрее, чем на Identity при условии что данные валятся от разных коннектов (например клиентбанк)
Если данные массово переливать из одной тарелки в другую под одним коннектом, оставить identity
24 май 17, 12:04    [20507230]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
TaPaK
uaggster,

в общем всё так, только column store убьют вставку

В 2016SP1 они ж кричат, что всё, наконец, заработало быстро и правильно?
Это ж главная фича 2016!
Может кто пробовал уже?
Действительно плохо?
24 май 17, 12:36    [20507436]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
uaggster
TaPaK
uaggster,

в общем всё так, только column store убьют вставку

В 2016SP1 они ж кричат, что всё, наконец, заработало быстро и правильно?
Это ж главная фича 2016!
Может кто пробовал уже?
Действительно плохо?
Оно же не для OLTP
24 май 17, 13:31    [20507750]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
uaggster
Задача непонятна. Сколько вешать в граммах то?
Сколько записей вы будете писать, каким способом?
По записи? Пакетно? Bulk insert?
Какая нужна производительность записей?
1000 записей в секунду? 10 000? 100 000? 1 000 000?
Если ограничения - порядка 10 - 20 тысяч записей в секунду, пишете по одной записи, короткими транзакциями, в 1 таблицу - никакой дополнительной оптимизации не надо.
Сгодится совершенно ординарный сервер в ценовом диапазоне до 500 тыс. Дисковую подсистему только продумайте, и, возможно, сеть.

Если вам нужно до 100 000 в секунду, то тоже никакой оптимизации особой не надо.
Нужно много памяти, много ядер (но можно - относительно низкой частоты, не 1С чай), SSD диски (причем под логи - обязательно).
Можно таблицу на секции порезать и по разным дискам, висящим на разных каналах контроллера разнести.
И железяка потребуется несколько суровее.

А вот если речь идет примерно о миллионе в секунду и больше - вот тут уже всё сурово.
Тут уже нужно думать о специализированных решениях (например - Parallel Data Warehouse), и биться с разнесением таблицы по разным серверам и т.д.

А из рекомендаций к архитектуре - всё просто и стандартно.
Одна таблица. Можно широкую, но одну. Если для этого потребуется денормализовать схему данных - денормализуйте.
Короткие типы данных. Где можно использовать фиксированные типы - лучше использовать их. Используйте datetime2 вместо datetime. Там где это возможно, избегайте NULLable полей.
В качестве синтетического ключа - identity (но по нему совершенно необязательно строить кластерный индекс).
Никаких триггеров.
Никаких внешних ключей. Точнее - констрейнтов связанных с ними.
Минимум индексов.
Самый минимум индексов.
Никаких индексированных представлений, особенно сложных.

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

Как то так, ИМХО...


спасибо, полезная информация.
Предположим убрали внешние ключи, индексы и таблицу оставили кучей. Однако с информацией в таблице-то все равно надо как-то работать, надо по запросу показать к примеру все транзакции определенной карты, как минимум индекс по id карты получается должен быть, посчитать баланс карты - тут index view'шки нужны, не высчитывать-же его на боевой таблице на каждый чих. Причем не получится его как-то постфактум слить в другую таблицу и посчитать там - баланс должен быть актуален немедленно что-бы карта в минус не ушла пока аналитика где-то там пересчитывается. Как все эти проблемы решаются? Точное число транзакций неизвестно, это зависит от обьема бизнеса, сегодня может быть небольшой, те-же несколько тысяч в секунду, но через пару лет могут до сотен тысяч вырасти - не перекраивать-же систему из-за этого, архитектурно надо сразу правильно сделать с прицелом на большие обьемы
Про колоночные индексы почитаю, но до 2016 как-то эти проблемы-же решались?
24 май 17, 13:31    [20507755]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
stenford
Предположим убрали внешние ключи, индексы и таблицу оставили кучей. Однако с информацией в таблице-то все равно надо как-то работать, надо по запросу показать к примеру все транзакции определенной карты, как минимум индекс по id карты получается должен быть
Не надо без индексов. Просто минимизируйте их количество.
stenford
посчитать баланс карты - тут index view'шки нужны, не высчитывать-же его на боевой таблице на каждый чих
Можно хранить баланс в другой таблице, в картах.
stenford
через пару лет могут до сотен тысяч вырасти - не перекраивать-же систему из-за этого, архитектурно надо сразу правильно сделать с прицелом на большие обьемы
Можно делать распределённую систему, однако нужно всё таки точнее прогнозировать потребности.
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?
Собственно, 100 тысяч траназкций в секунду - это 3000 миллиардов транзакций в год, мне кажется, столько на нашей планете пока нет.
24 май 17, 14:36    [20508085]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
человек_ниоткуда
Guest
alexeyvg
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

дА!

uaggster
Как то так, ИМХО...

Да! Собственно вопрос к топикастеру кто и как туде будет данные всувать? Много клиентов, или один/два сервиса платежей - пачками. Пачками вероятно быстрее.

И Да. Но...
А почему денормализовать? Разьве не лучше что там были только ключи и данне (сумма платежа т.е.). Тогда вставщих сможет себе закешировать наборы ключей классификаторов и формировать готовую запись на своей стороне.

А почему секции? Ну вернее, как вариант для тестирования, я б попробовал сделать "горячую" секцию в виде таблицы без индексов вообще, на отдельной файловой группе; и "рабочую" секцию в виде таблицы с кластерником и минимумом нужных индексов.
Вставка транзакций велась бы в горячую секцию, а в рабочую производился бы периодический перенос данных. Далее горячую секцию на N-файлов раскидать (т.е. файлгруппа из N-файлов), чтоб уменьшить вероятность зависонов из-за LACH блокировок на GAM, SGAM и т.п.
24 май 17, 15:14    [20508251]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
человек_ниоткуда
alexeyvg
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

дА!

uaggster
Как то так, ИМХО...

...
А почему денормализовать? Разьве не лучше что там были только ключи и данне (сумма платежа т.е.). Тогда вставщих сможет себе закешировать наборы ключей классификаторов и формировать готовую запись на своей стороне.

Имелось ввиду, чтобы не осуществлялась вставка в структуру Master-Detail (т.е. заголовочные данные - в одной таблице, расшифровка по позициям - во второй и т.д.)
То, что можно использовать коды справочников - это понятно.
Вот только в высоконагруженных системах нежелательно привязывать эти справочники с помощью декларативной ссылочной целостности.
Оно, конечно, потенциальная дыра в консистентности информации, но поддержание этих связей уж очень больно по производительности вставок/удалений/изменений бьёт.

человек_ниоткуда
А почему секции? Ну вернее, как вариант для тестирования, я б попробовал сделать "горячую" секцию в виде таблицы без индексов вообще, на отдельной файловой группе; и "рабочую" секцию в виде таблицы с кластерником и минимумом нужных индексов.
Вставка транзакций велась бы в горячую секцию, а в рабочую производился бы периодический перенос данных. Далее горячую секцию на N-файлов раскидать (т.е. файлгруппа из N-файлов), чтоб уменьшить вероятность зависонов из-за LACH блокировок на GAM, SGAM и т.п.

Да нет же, всё проще.
Если поток данных - очень интенсивный, то можно пропорционально снизить нагрузку на дисковую подсистему просто порезав файл с данными на части, и разместив эти части на разных каналах контроллера. Т.е. канал на диск станет ... ну... в N раз шире, где N - число частей.
Разумеется, это можно сделать просто поместив таблицу в файловую группу из нескольких файлов.
Но тогда сервер будет делить данные так, как ему хочется. А порезав таблицу на секции - мы этот процесс контролируем, и можем какие то еще дополнительные преимущества получить.

Кстати, по Вашей схеме можно просто 2 таблицы соорудить: горячую (за текущий день, час и т.д.) и холодную неизменяемую, с кучей индексов, колоночных в т.ч.
24 май 17, 15:55    [20508433]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
alexeyvg
Собственно, 100 тысяч траназкций в секунду - это 3000 миллиардов транзакций в год, мне кажется, столько на нашей планете пока нет.

Вот тут не согласен.
100 тысяч траназкций в секунду может быть 10 минут в сутки :)
24 май 17, 16:03    [20508477]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
uaggster
alexeyvg
Собственно, 100 тысяч траназкций в секунду - это 3000 миллиардов транзакций в год, мне кажется, столько на нашей планете пока нет.

Вот тут не согласен.
100 тысяч траназкций в секунду может быть 10 минут в сутки :)
Ну, собственно, это вопрос о функциях самой системы.
Это аналитическая система?
Или ОЛТП - платёжная система?

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

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

Во втором случае нужно делать распределённую систему, и для надёжности, и для скорости. Если там действительно большие нагрузки (национальная платёжная система?)
24 май 17, 17:11    [20508804]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
человек_ниоткуда
Guest
uaggster
Имелось ввиду, чтобы не осуществлялась вставка в структуру Master-Detail (т.е. заголовочные данные - в одной таблице, расшифровка по позициям - во второй и т.д.)

Ну если в этом смысле, то вопросов нет.

uaggster
Разумеется, это можно сделать просто поместив таблицу в файловую группу из нескольких файлов.
Но тогда сервер будет делить данные так, как ему хочется. А порезав таблицу на секции - мы этот процесс контролируем, и можем какие то еще дополнительные преимущества получить.

Я имелл ввиду секционирование не декларативными инструментами SQL (partiton scheme и т.д.), а именно две таблицы сделать. Маленькую в которую будет вставка новых данных вестись, и большую в которую будет периодическая выгрузка из маленькой делаться.
Резать на секции я считаю надо уже после того как система будет работать в с продуктивной нагрузкой. Т.к. обычно угадать с этим очень трудно. На моём опыте только не очень удачные попытки, когда получалось что в одну секцию 90% потока идёт.

uaggster
Кстати, по Вашей схеме можно просто 2 таблицы соорудить: горячую (за текущий день, час и т.д.) и холодную неизменяемую, с кучей индексов, колоночных в т.ч.

Ну так я и предложил, вы прямо эту цитату вырезали. Просто дополнительно таблицу с "горячей" секцией на многофайловую файлгруппу положить.
Опять же - можно и 2 горячих таблицы сделать, и на два канала SAN (я ведь правильно понял что имеется ввиду контроллер SAN) их повесить.
24 май 17, 19:24    [20509202]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
alexeyvg
Можно хранить баланс в другой таблице, в картах.

так делать не хочется, во-первых расчет может оказаться просто неверным из-за какого-нибудь трудноуловимого бага при массированной вставке, во-вторых update тоже не бесплатный и идет в той-же транзакции, и еще не факт что он будет много быстрее чем индексированная вьюшка производимая самим сервером (правда надо еще проветилировать производительность этих вьюшек на больших обьемах)

alexeyvg
Можно делать распределённую систему, однако нужно всё таки точнее прогнозировать потребности.
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

сразу делать к примеру то-же секционирование не стоит, согласен, на секции можно пилить и потом, когда обьемы вырастут. Проектирование-же структур таблиц сразу надо делать оптимальным, какой смысл ее делать неверно а затем переделывать?

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

как тут уже написали, может быть спайк активности в короткий промежуток времени, условно в 12 часов все пошли на обед и платят картами. А шлюзы платежных систем (мастеркард к примеру) отслеживает проседание в отклике и при определенном проценте выхода из требуемого времени отклика на компанию-провайдера накладываются нехилые штрафы (сотни тысяч долларов)
25 май 17, 02:25    [20509819]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
человек_ниоткуда
Да! Собственно вопрос к топикастеру кто и как туде будет данные всувать? Много клиентов, или один/два сервиса платежей - пачками. Пачками вероятно быстрее.

много мелких коннектов, для каждой транзакции шлюз открывает отдельный tcp-ip коннект
25 май 17, 02:28    [20509820]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
stenford
alexeyvg
Можно делать распределённую систему, однако нужно всё таки точнее прогнозировать потребности.
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

сразу делать к примеру то-же секционирование не стоит, согласен, на секции можно пилить и потом, когда обьемы вырастут. Проектирование-же структур таблиц сразу надо делать оптимальным, какой смысл ее делать неверно а затем переделывать?
Так вот, я утверждаю, что оптимальность структуры заключается в её устойчивости к сбоям, полноте и однозначности передачи бизнес-логики данных, декларативном обеспечении целостности, и т.д. А не в "скорости вставки".
stenford
ак тут уже написали, может быть спайк активности в короткий промежуток времени, условно в 12 часов все пошли на обед и платят картами
Да это понятно, что могут быть пики.
Я просто призываю стараться максимально корректно рассчитывать реальную нагрузку, в т.ч. пиковую.

Что бы нагрузка составила 100 тыщ транзакций в секунду, нужно, что бы в обед 10 миллионов человек подошли к миллиону терминалов и совершили операции.

Вы будете бслуживать миллион терминалов на старте? Тогда ок, ваши расчёты правильные.
stenford
alexeyvg
Можно хранить баланс в другой таблице, в картах.

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

Я так сразу не могу сказать, что эффективнее, но на мой взгляд эффективнее хранить баланс, особенно при удлинении истории хранения.

Насчёт баги - ну, писать надо правильно.
Это ведь очень простая логика, её вполне реально надёжно, это ведь один оператор апдэйта в триггере.
25 май 17, 09:00    [20510029]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
Как то тестировал я подобное: одновременный перевод денег по зарплатной программе.
Так вот на моём домашнем компе, где я развернул и базу и приложение я дошёл до сотни запросов в секунду на обычных таблицах с IDENTITY.

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

ИМХО в первую очередь затык будет на стороне приложения, а не БД.
25 май 17, 09:40    [20510204]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
stenford, на чём кстати клиента БД писать будете?
25 май 17, 09:40    [20510207]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
alexeyvg
Да это понятно, что могут быть пики.
Я просто призываю стараться максимально корректно рассчитывать реальную нагрузку, в т.ч. пиковую.

Что бы нагрузка составила 100 тыщ транзакций в секунду, нужно, что бы в обед 10 миллионов человек подошли к миллиону терминалов и совершили операции.

Вы будете бслуживать миллион терминалов на старте? Тогда ок, ваши расчёты правильные.


что-бы нагрузка составила 100 тысяч в секунду, надо что-бы 100 тысяч человек произвели ее в эту самую секунду. В результате половина из них получит отклик не в 2 секунды, а в 10.

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

Я так сразу не могу сказать, что эффективнее, но на мой взгляд эффективнее хранить баланс, особенно при удлинении истории хранения.

Насчёт баги - ну, писать надо правильно.
Это ведь очень простая логика, её вполне реально надёжно, это ведь один оператор апдэйта в триггере.

нет, в триггере точно никакой логики не будет. Правильно код без багов конечно очень хорошая цель, но недостижимая, поэтому первым делом надо сводить к минимуму саму возможность его допустить, а не декларировать такие цели и потом искать и наказывать виновных. Соответственно что способен сделать сам сервер - он сам и должен делать. Далеко не факт что вьюшка пересчитывает весь обьем строк, она вполне может оптимизированна для таких случаев, а даже если сейчас нет - то может в будущем.
25 май 17, 09:49    [20510248]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
stenford,
автор
что-бы нагрузка составила 100 тысяч в секунду, надо что-бы 100 тысяч человек произвели ее в эту самую секунду. В результате половина из них получит отклик не в 2 секунды, а в 10.

вы бухгалтер?
25 май 17, 09:52    [20510270]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
skyANA
stenford, на чём кстати клиента БД писать будете?

клиент либо будет типа вебсервиса вызываемого самим банком, либо какой-то сервис будет который слушает tcp-ip соединения шлюза. Это еще не решено
25 май 17, 09:53    [20510278]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
stenford
что-бы нагрузка составила 100 тысяч в секунду, надо что-бы 100 тысяч человек произвели ее в эту самую секунду. В результате половина из них получит отклик не в 2 секунды, а в 10.

А Вы уже подумали о том, что до базы дело в этом случае и не дойдёт, очередь образуется на веб-сервере или последний вообще приляжет :)
25 май 17, 09:54    [20510284]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
stenford
skyANA
stenford, на чём кстати клиента БД писать будете?

клиент либо будет типа вебсервиса вызываемого самим банком, либо какой-то сервис будет который слушает tcp-ip соединения шлюза. Это еще не решено

Вот надо бы решить, коль Вы собрались обеспечивать 100 тыс. запросов в секунду.
25 май 17, 09:55    [20510292]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
skyANA
А Вы уже подумали о том, что до базы дело в этом случае и не дойдёт, очередь образуется на веб-сервере или последний вообще приляжет :)

это отдельный вопрос, не относящийся к таблицам базы данных) Решатся тоже будет отдельно какой-нибудь вебфермой
25 май 17, 09:57    [20510298]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
stenford
skyANA
А Вы уже подумали о том, что до базы дело в этом случае и не дойдёт, очередь образуется на веб-сервере или последний вообще приляжет :)

это отдельный вопрос, не относящийся к таблицам базы данных) Решатся тоже будет отдельно какой-нибудь вебфермой

Я намекаю Вам на то, что Вы не на то тратите время. C вашими 278 вставок в секунду БД легко справится на обычных таблицах с IDENTITY.
25 май 17, 10:05    [20510333]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
alexeyvg
Вот именно, нужно сравнить.
Вьюшка пересчитывает при апдэйте всю историю для данных значений полей группировки (то есть по номеру карты), а триггер на вставку будет апдэйтить только одну запись.

Ненене!
"Вот так у нас все олени и кончились!"(С)
Это убьет всю производительность на корню, и при некоторой удаче можно еще натрахаться с локами-дедлоками по самое небалуйся.

Наверное, всё же схема "Горячая таблица" без индексов (ну, в разумном понимании слова "без") - "Холодная таблица" со всевозможными индексами и предрассчитанными агрегатами, пополняемая из горячей таблицы в периоды минимальной активности потребителей - наше всё.

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

С другой стороны, если, например, количество транзакций за день - небольшое, ну миллион - 10 миллионов, то, наверное, можно и не париться.
Порезать холодную таблицу по количеству опердней, ну, пусть 365, а в оперативной - держать две секции: До/После времени закрытия опердня.
И по процедуре закрытия опердня формировать из секции "До" горячей таблицы данные для секции, соответствующей конкретному опердню холодной таблицы, уже со всеми индексами, индексированными вью, таблицами предрассчитанных агрегатов, свистелками и перделками.
Понятно, что в отдельную табличку/таблички, рядом с холодной.
А потом одномоментно выносить переключением метаданных секцию "ДО" из горячей таблицы и включать подготовленные данные в холодную.
Причем холодную таблицу - можно и на соседнем сервере держать, проблем то...
Ну, понятно, еще сверххолодная таблица понадобиться, из одних агрегатов за передыдущие годы...

Т.е. это классическая схема "хранилище - оперативные данные", только отказ в обслуживании на момент пополнения хранилища недопустим, а так - никаких чудес.

Всё ИМХО, разумеется.
25 май 17, 10:13    [20510373]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
uaggster,

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

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

2-30млн в сутки вообще не требуют никаких особых приседаний. Годовые таблицы, для спихивания подальше. это то что вижу, а так да можно придумывать сколько угодно.
25 май 17, 10:25    [20510426]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
stenford
alexeyvg
Да это понятно, что могут быть пики.
Я просто призываю стараться максимально корректно рассчитывать реальную нагрузку, в т.ч. пиковую.

Что бы нагрузка составила 100 тыщ транзакций в секунду, нужно, что бы в обед 10 миллионов человек подошли к миллиону терминалов и совершили операции.

Вы будете обслуживать миллион терминалов на старте? Тогда ок, ваши расчёты правильные.

что-бы нагрузка составила 100 тысяч в секунду, надо что-бы 100 тысяч человек произвели ее в эту самую секунду. В результате половина из них получит отклик не в 2 секунды, а в 10.
Не, такого точно не будет.
Всё распределяется равномерно, жизнь не дискретна. От миллиона терминалов транзакции будут распределяться очень, очень равномерно.

Неравномерность возможна только в том случае, если кто то буферизирует этот миллион транзакций, накопит их за 10 секунд, а потом плюнет в вас.
Но тогда латентность создаёте не вы, и вся система в целом нормально работать не будет.
25 май 17, 11:14    [20510597]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8690
"Для скорости" существуют нереляционные/нетранзакционые СУБД.
25 май 17, 11:16    [20510602]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
uaggster
alexeyvg
Вот именно, нужно сравнить.
Вьюшка пересчитывает при апдэйте всю историю для данных значений полей группировки (то есть по номеру карты), а триггер на вставку будет апдэйтить только одну запись.

Ненене!
"Вот так у нас все олени и кончились!"(С)
Это убьет всю производительность на корню, и при некоторой удаче можно еще натрахаться с локами-дедлоками по самое небалуйся.
Почему убьёт? Данных же будет читаться меньше, а писаться столько же, по сравнению с мат-вьюхой.
Дедлоками придётся управлять, да.
Впрочем, можно, конечно, и без триггеров, и соответственно не апдэйтить итог в той же транзакции, но это очень сильно поднимает требования к качеству кода и архитектуре.
uaggster
С другой стороны, если, например, количество транзакций за день - небольшое, ну миллион - 10 миллионов, то, наверное, можно и не париться.
Порезать холодную таблицу по количеству опердней, ну, пусть 365, а в оперативной - держать две секции:
С миллионом непонятно зачем вообще париться с секциями, "порезать" и т.д.?
Но ТС говорит про стотыщ в секунду, то есть 8 миллиардов 640 миллионов в сутки.
25 май 17, 11:22    [20510626]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
Владислав Колосов
"Для скорости" существуют нереляционные/нетранзакционые СУБД.
Да, отличный выбор для финансовой системы :-)
25 май 17, 11:23    [20510627]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8690
alexeyvg
Владислав Колосов
"Для скорости" существуют нереляционные/нетранзакционые СУБД.
Да, отличный выбор для финансовой системы :-)


Так выбор зависит от контекста задачи, который автор тщательно скрывает :) Ему шашечки или ехать?
25 май 17, 11:30    [20510652]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
stenford
нет, в триггере точно никакой логики не будет. Правильно код без багов конечно очень хорошая цель, но недостижимая, поэтому первым делом надо сводить к минимуму саму возможность его допустить, а не декларировать такие цели и потом искать и наказывать виновных. Соответственно что способен сделать сам сервер - он сам и должен делать. Далеко не факт что вьюшка пересчитывает весь обьем строк, она вполне может оптимизированна для таких случаев, а даже если сейчас нет - то может в будущем.
И вообще, непонятна концентрация на "таблице транзакций".

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

Поэтому повторю своё ИМХО - решение проблем масштабирования нужно закладывать архитектурно в виде распределения компонентов системы. Что, конечно, не исключает оптимального написания кода и оптимальной модели данных внутри узла.
25 май 17, 11:31    [20510655]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8690
Для меня его способ решения приема платежей вовсе не очевиден, например.
25 май 17, 11:32    [20510656]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
cossack5
Member

Откуда:
Сообщений: 496
Тут уже предлагали In Memory. Не вижу причин, почему нельзя.
25 май 17, 12:01    [20510766]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8690
Подозреваю, что автор хочет обеспечить логическую транзакционнность с внешними системами.
25 май 17, 12:04    [20510778]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
invm
Member

Откуда: Москва
Сообщений: 9772
alexeyvg
Вьюшка пересчитывает при апдэйте всю историю для данных значений полей группировки (то есть по номеру карты), а триггер на вставку будет апдэйтить только одну запись.
Не всю. Пересчитывается дельтами только по затронутым строкам. Именно поэтому в индексированных представлениях недопустимы max, min и т.п.
25 май 17, 12:26    [20510886]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
invm
alexeyvg
Вьюшка пересчитывает при апдэйте всю историю для данных значений полей группировки (то есть по номеру карты), а триггер на вставку будет апдэйтить только одну запись.
Не всю. Пересчитывается дельтами только по затронутым строкам. Именно поэтому в индексированных представлениях недопустимы max, min и т.п.
Дельтами? Не знал, спасибо.

Кстати, странно, что max, min недопустимы. Они ведь тоже дельтой вычисляются - добавленное (изменённое) значение больше чем было текущее (для поля группировки, т.е. для ключа view), значит, это новый max
25 май 17, 12:51    [20511024]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
cossack5
Тут уже предлагали In Memory. Не вижу причин, почему нельзя.
Выключается питание, и в базе нет уже подтверждённых платежей.
25 май 17, 12:52    [20511032]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
defragmentator
Member

Откуда:
Сообщений: 20504
stenford
Причем не получится его как-то постфактум слить в другую таблицу и посчитать там - баланс должен быть актуален немедленно что-бы карта в минус не ушла пока аналитика где-то там пересчитывается. Как все эти проблемы решаются? Точное число транзакций неизвестно, это зависит от обьема бизнеса, сегодня может быть небольшой, те-же несколько тысяч в секунду, но через пару лет могут до сотен тысяч вырасти - не перекраивать-же систему из-за этого, архитектурно надо сразу правильно сделать с прицелом на большие обьемы


Ну совсем онлайн не получится, конечно.
Если вставка будет не справляться, можно делать только пакетную запись, скажем 1 раз в секунду.
Например, накапливать транзакции в промежуточных таблицах.
25 май 17, 13:14    [20511124]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
aleks2
Guest
Владислав Колосов
"Для скорости" существуют нереляционные/нетранзакционые СУБД.

Наивняк.

"Для скорости" - существует текстовый файл с записью "в конец".
25 май 17, 14:18    [20511468]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
alexeyvg
Владислав Колосов
"Для скорости" существуют нереляционные/нетранзакционые СУБД.
Да, отличный выбор для финансовой системы :-)

А что не так?

Волею судеб выплачиваю кредит и меня не парит то, что мои платежи будут обработаны на следующий банковский день.
То есть они пихаются в некую очередь, что по всей видимости выгребается каким-то количеством нод-подписчиков.
25 май 17, 14:27    [20511511]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
skyANA
alexeyvg
пропущено...
Да, отличный выбор для финансовой системы :-)

А что не так?

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

нет. В большинстве своём это либо форвардится руками операторов которые разбирают что ж за фигню ты шлёшь или не попали в опердень. ниболее
25 май 17, 14:30    [20511525]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
Да и крупные банковские системы - это давно уже eventual consistency.
Поехал я колесить по Европе и операции через банкоматы, в ресторанах и магазинах долетают до менеджера моего банка далеко не моментально и не в одной транзакции.
25 май 17, 14:30    [20511528]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
TaPaK
skyANA
пропущено...

А что не так?

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

нет. В большинстве своём это либо форвардится руками операторов которые разбирают что ж за фигню ты шлёшь или не попали в опердень. ниболее

Ну окей, подписчик аналоговый. Что это меняет? :)
25 май 17, 14:32    [20511539]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
skyANA
TaPaK
пропущено...

нет. В большинстве своём это либо форвардится руками операторов которые разбирают что ж за фигню ты шлёшь или не попали в опердень. ниболее

Ну окей, подписчик аналоговый. Что это меняет? :)

то что твоя транзакция просто меняет состояние, а ниоткуда не вытаскивается и перетаскивается из ноды в ноду, от скуки
25 май 17, 14:35    [20511551]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
TaPaK
uaggster,

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

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

2-30млн в сутки вообще не требуют никаких особых приседаний. Годовые таблицы, для спихивания подальше. это то что вижу, а так да можно придумывать сколько угодно.

Гм... Ну, сколько по времени займет удаление 10, к примеру, миллионов записей из 12ти миллионной таблицы?
И сколько клиентов будет ждать, пока таблица освободится?
25 май 17, 16:18    [20512037]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
uaggster
TaPaK
uaggster,

пропущено...

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

2-30млн в сутки вообще не требуют никаких особых приседаний. Годовые таблицы, для спихивания подальше. это то что вижу, а так да можно придумывать сколько угодно.

Гм... Ну, сколько по времени займет удаление 10, к примеру, миллионов записей из 12ти миллионной таблицы?
И сколько клиентов будет ждать, пока таблица освободится?

я думаю все клиенты придут лично если начнут удалять транзакции
25 май 17, 16:20    [20512042]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
alexeyvg
С миллионом непонятно зачем вообще париться с секциями, "порезать" и т.д.?
Но ТС говорит про стотыщ в секунду, то есть 8 миллиардов 640 миллионов в сутки.

Миллион - два в день - вполне себе "примерно миллиард" в год.
Вполне себе вменяемые объемы, в отношении которых уже придётся как-то заморачиваться по поводу производительности.
И опять же, 100 000 в секунду != 8 миллиардов в сутки.
Потому что таких секунд может быть всего несколько десятков.
(и словить отказ в обслуживании из за того, что система захлебнулась, можно и тогда, когда в сутки она прокачивает не так уж и много данных).
25 май 17, 16:27    [20512061]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 1030
TaPaK
uaggster
пропущено...

Гм... Ну, сколько по времени займет удаление 10, к примеру, миллионов записей из 12ти миллионной таблицы?
И сколько клиентов будет ждать, пока таблица освободится?

я думаю все клиенты придут лично если начнут удалять транзакции

Я имею ввиду - переносить из горячей таблицы в холодную :-)
25 май 17, 16:28    [20512064]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
invm
Member

Откуда: Москва
Сообщений: 9772
alexeyvg
Кстати, странно, что max, min недопустимы. Они ведь тоже дельтой вычисляются - добавленное (изменённое) значение больше чем было текущее (для поля группировки, т.е. для ключа view), значит, это новый max
При удалении не получится.
25 май 17, 17:00    [20512191]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
invm
alexeyvg
Кстати, странно, что max, min недопустимы. Они ведь тоже дельтой вычисляются - добавленное (изменённое) значение больше чем было текущее (для поля группировки, т.е. для ключа view), значит, это новый max
При удалении не получится.
Да, при удалении или уменьшении значения, которое было "MAX" не получится...
25 май 17, 18:37    [20512597]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
uaggster
Порезать холодную таблицу по количеству опердней, ну, пусть 365, а в оперативной - держать две секции: До/После времени закрытия опердня.
И по процедуре закрытия опердня формировать из секции "До" горячей таблицы данные для секции, соответствующей конкретному опердню холодной таблицы, уже со всеми индексами, индексированными вью, таблицами предрассчитанных агрегатов, свистелками и перделками.

непонятно каким все-же образом вы предлагаете держать баланс актуальным если вьюшка с ним в холодной таблице лежит и обновляется в конце дня?
26 май 17, 02:14    [20513312]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
invm
Не всю. Пересчитывается дельтами только по затронутым строкам. Именно поэтому в индексированных представлениях недопустимы max, min и т.п.

круто, это значит от обьемов производительность не должна зависеть и такая вьюшка должна спрaвляться со своей задачей даже на горячей таблице в тысячами записей на данной карте
26 май 17, 02:17    [20513313]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
alexeyvg
И вообще, непонятна концентрация на "таблице транзакций".

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


не будет там десятков записей в десятках таблиц по крайней мере внутри транзакции, все вещи типа логирования и каких-то обсчетов или сторонний сервисов типа проверки транзакций на AML или на фрод будут в отдельном месте обрабатываться и не задерживать основную транзакцию т.к. ее отклик критичен по времени
26 май 17, 02:22    [20513314]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2850
skyANA
Да и крупные банковские системы - это давно уже eventual consistency.
Поехал я колесить по Европе и операции через банкоматы, в ресторанах и магазинах долетают до менеджера моего банка далеко не моментально и не в одной транзакции.

ты путаешь settlement у всех этих транзакций и саму авторизацию, я в данном топике про авторизацию говорю, когда ты покупаешь себе кофе в европах авторизация производится немедленно (за парой исключений) т.е. провайдер платежей продавца кофе коннектится к твоему банку и спрашивает кто ты и разрешено-ли тебе потратить эти деньги, в этот момент банк проверяет твой баланс, записывает себе эту транзакцию и отвечает провайдеру что да, давай аппрувь его запрос, после чего провайдер высвечивает approve на платежном аппарате и тебе дают кофе, а твой доступный баланс уменьшается на эту сумму. А "официальная" транзакция вообще придет в банк через неделю и появится у тебя в онлайн-банкинге когда туда поступит и будет обработан текстовый файл со списком всех транзакций
26 май 17, 02:33    [20513317]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Таблица для транзакций  [new]
EV.P
Member

Откуда:
Сообщений: 134
stenford,

Господа, подскажите, как правильно организовать хранение данных в таком случае.
Будет одна таблица, в которую будет каждую секунду сыпаться платёжная информация о сделках. Примерно по 10-30 записей в секунду. Объём таблицы предполагается в десятки миллионов записей. Да, таблицу нужно будет сегментировать.
Над этой же таблицей будет строиться отчётность OLAP в режиме, близком к real-time. Будет ли отображаться в OLAP свежепоступившая информация? Или нужно будет давать время кубу для пересчёта? Правилен ли такой подход или же нужно делать отдельную базу для OLAP и как-то быстро синхронизировать её с основной OLTP? Объём самой базы данных предполагается в 50-100 Гб. Всего таблиц будет немного, около 25-30. Вся бизнес-логика будет вынесена в микросервисы (на C#, с использованием Entity Framework). Правилен ли такой подход?
Предполагается использование MS SQL Server 2017 Standard Edition. Точно ли в Standard Edition есть OLAP, близкий к реал-тайму? Или это только есть в Enterprise Edition?
Нашёл достаточно много ограничений для Standard Edition в части быстроты работы с OLAP и быстроты работы в целом:
https://docs.microsoft.com/ru-ru/sql/sql-server/editions-and-components-of-sql-server-2017?view=sql-server-2017
17 янв 19, 10:45    [21787577]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
EV.P
Member

Откуда:
Сообщений: 134
uaggster
Задача непонятна. Сколько вешать в граммах то?
Сколько записей вы будете писать, каким способом?
По записи? Пакетно? Bulk insert?
Какая нужна производительность записей?
1000 записей в секунду? 10 000? 100 000? 1 000 000?
Если ограничения - порядка 10 - 20 тысяч записей в секунду, пишете по одной записи, короткими транзакциями, в 1 таблицу - никакой дополнительной оптимизации не надо.
Сгодится совершенно ординарный сервер в ценовом диапазоне до 500 тыс. Дисковую подсистему только продумайте, и, возможно, сеть.

Если вам нужно до 100 000 в секунду, то тоже никакой оптимизации особой не надо.
Нужно много памяти, много ядер (но можно - относительно низкой частоты, не 1С чай), SSD диски (причем под логи - обязательно).
Можно таблицу на секции порезать и по разным дискам, висящим на разных каналах контроллера разнести.
И железяка потребуется несколько суровее.

А вот если речь идет примерно о миллионе в секунду и больше - вот тут уже всё сурово.
Тут уже нужно думать о специализированных решениях (например - Parallel Data Warehouse), и биться с разнесением таблицы по разным серверам и т.д.

А из рекомендаций к архитектуре - всё просто и стандартно.
Одна таблица. Можно широкую, но одну. Если для этого потребуется денормализовать схему данных - денормализуйте.
Короткие типы данных. Где можно использовать фиксированные типы - лучше использовать их. Используйте datetime2 вместо datetime. Там где это возможно, избегайте NULLable полей.
В качестве синтетического ключа - identity (но по нему совершенно необязательно строить кластерный индекс).
Никаких триггеров.
Никаких внешних ключей. Точнее - констрейнтов связанных с ними.
Минимум индексов.
Самый минимум индексов.
Никаких индексированных представлений, особенно сложных.

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

Как то так, ИМХО...


Правильно ли я Вас понимаю, что для OLAP с количеством транзакций в секунду от 1000 нужна одна широкая таблица? А реляционный OLTP вынести в отдельную базу?
Искал решения на базе PostgreSQL, чтобы прикрутиьь к нему нормальный более-менее быстрый OLAP, но так и не нашёл. Какие-то OLAP-решения под PostgreSQL может и существуют, но вряд ли они будут дешёвыми и быстрыми. В нашем случае запаздывание OLAP более чем на 3 секунды недопустимо (при более чем 100 транзакциях в секунду).
17 янв 19, 11:07    [21787596]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
EV.P
Member

Откуда:
Сообщений: 134
Также, как я понимаю, нужно будет использовать memory optimized таблицы для быстрых OLAP и OLTP?
17 янв 19, 11:13    [21787602]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31905
EV.P
Господа, подскажите, как правильно организовать хранение данных в таком случае.
Будет одна таблица, в которую будет каждую секунду сыпаться платёжная информация о сделках. Примерно по 10-30 записей в секунду. Объём таблицы предполагается в десятки миллионов записей. Да, таблицу нужно будет сегментировать.
Над этой же таблицей будет строиться отчётность OLAP в режиме, близком к real-time. Будет ли отображаться в OLAP свежепоступившая информация? Или нужно будет давать время кубу для пересчёта? Правилен ли такой подход или же нужно делать отдельную базу для OLAP и как-то быстро синхронизировать её с основной OLTP?
OLAP используют для того, что бы аналитики могли крутить данные, что бы понять, какие же есть между ними зависимости, то есть для аналитиков неважно, старые данные или новые, для определения тенденций свежесть не нужна.

А оперативные отчёты, если нужно условно реальное время, лучше делать на свежих данных (или на их рид-онли копии)

Т.о. нужно 3 уровня - OLTP для транзакций, копия OLTP для оперативных отчётов, и OLAP для не-опреативной аналитики.
Это идеальный вариант.

Но если начальство тупое, и непременно "хочет OLAP", можно делать источником данных OLAP базу OLTP, то есть использовать ROLAP , но про букву "R" им не говорить.
17 янв 19, 13:52    [21787853]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
EV.P
Member

Откуда:
Сообщений: 134
alexeyvg
EV.P
Господа, подскажите, как правильно организовать хранение данных в таком случае.
Будет одна таблица, в которую будет каждую секунду сыпаться платёжная информация о сделках. Примерно по 10-30 записей в секунду. Объём таблицы предполагается в десятки миллионов записей. Да, таблицу нужно будет сегментировать.
Над этой же таблицей будет строиться отчётность OLAP в режиме, близком к real-time. Будет ли отображаться в OLAP свежепоступившая информация? Или нужно будет давать время кубу для пересчёта? Правилен ли такой подход или же нужно делать отдельную базу для OLAP и как-то быстро синхронизировать её с основной OLTP?
OLAP используют для того, что бы аналитики могли крутить данные, что бы понять, какие же есть между ними зависимости, то есть для аналитиков неважно, старые данные или новые, для определения тенденций свежесть не нужна.

А оперативные отчёты, если нужно условно реальное время, лучше делать на свежих данных (или на их рид-онли копии)

Т.о. нужно 3 уровня - OLTP для транзакций, копия OLTP для оперативных отчётов, и OLAP для не-опреативной аналитики.
Это идеальный вариант.

Но если начальство тупое, и непременно "хочет OLAP", можно делать источником данных OLAP базу OLTP, то есть использовать ROLAP , но про букву "R" им не говорить.


Отлично. Спасибо за подробный и понятный совет.
По Вашему опыту есть ли какие-либо другие быстрые OLAP-решения и не такие дорогие, как MS Standard/Enterprise (так как у MS Standard стоит ~3000 долларов за одно ядро процессора, а Enterprise и вовсе 15k$ за ядро)? Причём для работы с такими хранилищами должны быть стандартные коннекторы для .Net.
17 янв 19, 14:01    [21787863]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
.Евгений
Member

Откуда:
Сообщений: 684
EV.P,

Вы хотите организовать BI для отражения биржевой торговли, этим и вызваны немыслимые требования по максимальной задержке актуальности данных, верно?

Если так, то, во-первых, на три секунды не прогибайтесь, начинайте торговаться от часа. Во-вторых, сначала постройте ХД и попытайтесь именно им удовлетворить потребности бизнеса.

P.S. Год опыта работы со связкой Calypso+RabbitMQ+ХД на MS SQL 2016.
17 янв 19, 15:01    [21787957]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
EV.P
Member

Откуда:
Сообщений: 134
.Евгений,

Нам RabbitMQ не понравился - постоянный жор памяти неизвестно по каким причинам. Из-за этого стабильная работа в режиме 24х7 невозможна (постоянно приходилось перезагружать сервер). Режим работы RabbitMQ был автоматическим (автоматическое подтверждение получения сообщения, автоудаление данных при отключении клиента):
Вот код:

ConnectionFactory factory = new ConnectionFactory() { HostName = "localhost" };
IConnection positionConn = factory.CreateConnection();
IModel  channel = positionConn.CreateModel();
channel.ExchangeDeclare("companyName", ExchangeType.Direct, false, true);
channel.QueueDeclare(queue: "positionUpdate",  durable: false, exclusive: false, autoDelete: true);
channel.QueueBind("positionUpdate", "companyName", "positionUpdateKey", null);


Получается, что жор памяти недетерминированный. В очереди не накапливалось более 10-15 сообщений.
18 янв 19, 10:07    [21788485]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2414
EV.P
Правилен ли такой подход или же нужно делать отдельную базу для OLAP и как-то быстро синхронизировать её с основной OLTP?


неправилен
отдельной, синхронить ETL или репликацию
куб(ы) в режим ROLAp если нужна оперативное отражение изменений
18 янв 19, 11:06    [21788548]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
.Евгений
Member

Откуда:
Сообщений: 684
EV.P
.Евгений,

Нам RabbitMQ не понравился - постоянный жор памяти неизвестно по каким причинам. Из-за этого стабильная работа в режиме 24х7 невозможна (постоянно приходилось перезагружать сервер).

У вас невозможна, у многих других - возможна.
EV.P
Режим работы RabbitMQ был автоматическим (автоматическое подтверждение получения сообщения, автоудаление данных при отключении клиента)...

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

Моя загрузка данных изначально обеспечивала гарантированную доставку (подтверждение отправляется только после записи сообщения в БД), возможности просмотра и перезагрузки выбранных сообщений в ХД. Плюс prefetch и пакетная обработка, позволяющие на скромной виртуалке обрабатывать (принимать, записывать, парсить и снова записывать) поток 600 сообщений в секунду и более.
18 янв 19, 11:16    [21788565]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
EV.P
Member

Откуда:
Сообщений: 134
.Евгений,

Да, всё правильно. При сбое нам уже не важны данные.
RabbitMQ нужен был только для организации правильной очередности и сохранения этой очередности при записи в БД. Если произошёл сбой, то как и куда сохранять данные и как потом их оттуда поднимать когда сервис стартует после перезагрузки сервера - так и не смог найти ответа.
Также удалось исследовать, что RabbitMQ на платформе Erlang/OTP катастрофически замусоривает память и жор памяти приводит к сокрушительному сбою в работе уже через пару-тройку часов. В общем, какая-то ересь этот RabbitMQ.
24 янв 19, 10:29    [21792983]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
EV.P
Member

Откуда:
Сообщений: 134
.Евгений
EV.P
.Евгений,

Нам RabbitMQ не понравился - постоянный жор памяти неизвестно по каким причинам. Из-за этого стабильная работа в режиме 24х7 невозможна (постоянно приходилось перезагружать сервер).

У вас невозможна, у многих других - возможна.
EV.P
Режим работы RabbitMQ был автоматическим (автоматическое подтверждение получения сообщения, автоудаление данных при отключении клиента)...

Моя загрузка данных изначально обеспечивала гарантированную доставку (подтверждение отправляется только после записи сообщения в БД), возможности просмотра и перезагрузки выбранных сообщений в ХД. Плюс prefetch и пакетная обработка, позволяющие на скромной виртуалке обрабатывать (принимать, записывать, парсить и снова записывать) поток 600 сообщений в секунду и более.


Если можно, поделитесь информацией как и что настроить, чтобы сервис не падал, не жрал память и какой примерно код нужно написать. Очень нужно.
24 янв 19, 10:31    [21792988]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4      [все]
Все форумы / Microsoft SQL Server Ответить