Проектируется система, которая будет содержать платежные транзакции. Транзакций в теории может быть очень много, скажем миллион в час. Каждая запись должна содержать id этой транзакции, id карты с которой пришла, и другие параметры, например дату-время и кучу всего прочего.
Не хочется изобретать велосипед, таких систем наверняка вагоны и маленькая тележка. Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего. Каким образом делаются таблицы где требуется массированная вставка строк?

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

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

может и существует, для этого и спрашиваю)
Меньше полей конечно понятно, но их-же не сделаешь меньше чем требуется для работы. Поэтому может например id'шники для строк как-то отдельно генерируются в другой таблице, или вообще разбивается на несколько таблиц или еще что-нибудь в этом роде. Кроме того еще имеет место быть такие вещи как indexed views для хранения остатка по картам что-бы не делать такие запросы на "живой" таблице, все это в результате выполняется внутри транзакции и удлиняет ее, тоже непонятно нормальное решение или как-то таские вещи по-другому делаются

TaPaKвряд ли identity узкое место. Лог, индексы, сама генерация записи, ну и железо...
ну вот и интересует кто уже подобные велосипеды делал и проходил этапы определения что и как можно заоптимизировать

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 как-то эти проблемы-же решались?

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

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

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

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

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

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

много мелких коннектов, для каждой транзакции шлюз открывает отдельный tcp-ip коннект

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

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

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

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

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

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

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

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

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