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

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

А что не так?

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

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

А что не так?

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

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

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

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

А что не так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Откуда:
Сообщений: 127
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

Откуда:
Сообщений: 127
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

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

Откуда: Moscow
Сообщений: 31356
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

Откуда:
Сообщений: 127
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

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

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

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

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

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

Нам 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

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


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

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

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

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

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

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

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

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