Size: a a a

Архитектура ИТ-решений

2020 November 25

PD

Phil Delgyado in Архитектура ИТ-решений
pragus
Странный вопрос. Там же написано про dax и mmap.  Идея в том, чтобы выкинуть page cache и block layer из i/o path.
Я про другое - кто из БД умеет использовать эти вещи?
Т.е. если будет СУБД, оптимизированная под NPM - то прекрасно. Но пока еще таких нет.
источник

N

Nikolay in Архитектура ИТ-решений
Phil Delgyado
Ну, банковские системы даже 1K Payment-per-second тянут очень с трудом, а 10K - просто никак.
Ну и описание сложных платежей через конечный автомат - очень сложное и очень тяжело меняемое. Ну и с взаимодействием с пользователем там все грустно.
Я то как раз про платежи и говорю в основном, но не только про банк, а про произвольную платежку
все известные мне банковские системы работют или работали по этому принципу. Например почти все Форс, почти все Диасофт. 1K в секунду для банковсих систем это 86 400 000  платежей в день. в каком банке такое количество? Насколько я помню у визы всего 1.7К в секунду. Столько конечно на одном хосте трудно сделать т.к там трнзакции сами по себе занимают много времени без учета время на ожидания коммита
источник

D

Danil in Архитектура ИТ-решений
Phil Delgyado
Я про другое - кто из БД умеет использовать эти вещи?
Т.е. если будет СУБД, оптимизированная под NPM - то прекрасно. Но пока еще таких нет.
А им обязательно это уметь? Я вчера пока читал про NVDIMM, нашел статью майкрософта, который обещает большой прирост перформанса для MSSQL в случае перемещения transaction log на NVDIMM virtual storage
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Nikolay
все известные мне банковские системы работют или работали по этому принципу. Например почти все Форс, почти все Диасофт. 1K в секунду для банковсих систем это 86 400 000  платежей в день. в каком банке такое количество? Насколько я помню у визы всего 1.7К в секунду. Столько конечно на одном хосте трудно сделать т.к там трнзакции сами по себе занимают много времени без учета время на ожидания коммита
Ну, 1K в секунду в пике - это легко для средней платежке.
В черную пятницу 10K в пике для каких-нибудь Яндекс.Денег - реально.
У визы несколько лет назад зафиксировано 40K в секунду, про актуальные данные - не знаю. Но совсем не 1.7K
Ну и я не для нашего рынка работаю.
источник

N

Nikolay in Архитектура ИТ-решений
Phil Delgyado
Ну, реально, конечно, число соединений нужно как число воркеров, а их много не нужно, но зависит от транзакционности обработки сообщения и вообще времени обработки сообщения. На 10K воркеров и 10ms получим 1mln MPS
база не понятет 10Л соединений активных, каждое из которых будет держать лок. Ну или я не так вас понял.
источник

p

pragus in Архитектура ИТ-решений
Phil Delgyado
Я про другое - кто из БД умеет использовать эти вещи?
Т.е. если будет СУБД, оптимизированная под NPM - то прекрасно. Но пока еще таких нет.
А им особо не надо уметь, особенно если речь mmap.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Nikolay
база не понятет 10Л соединений активных, каждое из которых будет держать лок. Ну или я не так вас понял.
Хм, там же около сотни на ядро было на PG еще в девятке, а Oracle может быть и больше, насколько я помню.
100 ядер - уже не проблема )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
pragus
А им особо не надо уметь, особенно если речь mmap.
Хм. Увы, им нужно всю свою логику оптимизировать под такие задачи. А большинство рассчитано на шпиндельные диски, увы.
Как минимум при планировании запросов и работе с локами (да и дофига прочего).
источник

N

Nikolay in Архитектура ИТ-решений
Phil Delgyado
Хм, там же около сотни на ядро было на PG еще в девятке, а Oracle может быть и больше, насколько я помню.
100 ядер - уже не проблема )
это сказки, что 10К активных сессий оракле потянет. он может понянуть и 30К, но только если они будут неактивные.
источник

p

pragus in Архитектура ИТ-решений
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Nikolay
это сказки, что 10К активных сессий оракле потянет. он может понянуть и 30К, но только если они будут неактивные.
Ок, не видел тестов, так что может и сказки. Могу спросить у наших DBA, сколько они на кластерах выжимали.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Не надо читать про performance у производителя, там данные обычно не связаны с реальностью
источник

N

Nikolay in Архитектура ИТ-решений
вы только уточните, что они должны быть в статусе ACTIVE, когда будете спрашивать у DBA.
источник

N

Nikolay in Архитектура ИТ-решений
А тут разве активные коннекшены? на том же оракле можно создать тоже 100К, которые просто будет висеть в системе и ничего не делать.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Там пишут про query, а не про transactions. Разница большая
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Что там sysbench реально делает? Я не в курсе.
источник

p

pragus in Архитектура ИТ-решений
Phil Delgyado
Не надо читать про performance у производителя, там данные обычно не связаны с реальностью
ну они не производители, а скорее консалтинг. у них есть и свои варианты mongodb/mysql, но их бенчам вполне можно верить.
вот про pg: https://www.percona.com/blog/2020/07/28/evaluating-checkpointing-in-postgresql/
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Percona - производитель как раз )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Там же как раз про плагин перконы для thread pool )
источник

p

pragus in Архитектура ИТ-решений
Phil Delgyado
Там пишут про query, а не про transactions. Разница большая
источник