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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Откуда: Moscow
Сообщений: 30751
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить