Они опять там внесли непоправимые улучшения в свой софт, что он стал еще более тормозной? Любой средней руки программист без проблем напишет на с++ код, который за несколько секунд даже на слабо компе обсчитает несколько миллионов сделок, которые были за торговую сессию. Что там можно считать так долго и где они понабрали настолько некомпетентных прогеров?
Jame Bonds, ну да, по 10 минуту — это единичный случай… сегодня в опцах разнос был с утра, видать подстраховались, увеличили время на обработку данных.
Любой средней руки программист без проблем напишет на с++ код, который за несколько секунд даже на слабо компе обсчитает несколько миллионов сделок
Сложные распределённые системы работают по иным законам. Несколько миллионов SQL-инсертов/апдейтов за несколько секунд? Это шутка недели, однозначно.
И пока есть люди, которые думают подобным образом, у меня на столе есть кусок хлеба с икрой пармезан с гран-резервой. Подниму вечером бокал за ваше здоровье!
однорукий экономист, redis и mongodb что ли? Так для любых операций, где в одном месте убыло, а в другом прибыло нужна поддержка транзакций. Т.е. база должна быть ACID - https://ru.wikipedia.org/wiki/ACID Ни одна из «нормальных быстрых баз» не удовлетворяет этим требованиям полностью (частично — да).
Lev, это не отменяет кривость программистов. Все данные можно зарание подготовить, до начала клиринга. Да и нормально спроектированные базы с грамотно расставленными индексами выгрузят миллион сделок за несколько секунд.
однорукий экономист, как это «заранее подготовить»? Последняя транзакция была в 13:59:59
Миллионные базы с правильными индексами у меня под рукой (вот в буквальном смысле, в соседней консоли). Но не удаётся выгружать «за несколько секунд». То в диски упирается, то в CPU, то в сеть. Прямо беда-беда.
Кроме непосредственной выгрузки надо ещё и пометить, что в одном месте убыло, в другом прибыло и закоммитить эту транзакцию. Это довольно дорогостоящая операция, никакими «за несколько секунд» там и не пахнет.
Lev, это последняя, никто не мешает зарание начать выгружать предыдущие.
А что комитить то собрался в базу и почему это минутами должно делаться?
И кстати современные диски, кпу, и память имеют очень высокую производительность, миллион сделок прочитать займет меньше секунды(при условии что руки программиста растут из правильного места, а не оттуда откуда у разработчиков мосбиржи).
однорукий экономист, транзакция в субд это атомарная операция, внутри которой может быть куча разных операций, и когда она успешно выполняется, то результат записывается на диск
и нужно не просто миллион сделок прочитать, а вычислить все пары кто кому должен и т.д. чтобы потом проверить задолженности и заявленное ГО клиентом
однорукий экономист, тем не менее основная цель это посчитать все задолженности и ГО клиентов, если это делать 1 раз в день, то нужно увеличить ГО по всем инструментам, логично? :)
meat, вообще-то все задолжности и ГО итак на протяжении всех торгов расчитываются в реалтаме ;) Так чтоже они там считают 10мин, если все уже было посчитано до этого, причем очень быстро(при выставлении каждой заявки).
однорукий экономист, http://nationalclearingcentre.ru/viewCatalog.do?menuKey=244
посмотри тут в правилах, там pdf документ, возможно найдешь причину почему так долго
никто не мешает зарание начать выгружать предыдущие
Куда и что выгружать? Что за ересь вы несёте? Вы хоть понимаете, как это работает и что такое консистентность данных? Пока не завершилась последняя транзакция — ничего делать нельзя.
От дальнейшей дискуссии с вами я воздержусь, слишком разный уровень компетенции.
Успехов в торговле!
Против этого есть только один метод — кирпича. Не докупать пока нет — 50% и более, не продавать пока нет 3х минимум от своих средних, понимая, что они на акциях отбивать будут ключевую ставку за пару ...
покупателя нет, объемы нулевые вообще.
посмотрите прошлую отсечку, там гэп был меньше дивов, те кто купил накануне просто в плюсе остались за сутки и потом все откупили тоже быстро.
а сейчас что? ...
Sloikin, Смутные сомнения у меня. А что ник аглицкими буквами прописан? И ты лично знаешь этих кошек, которые не едят? Или ты с довольствием всу перепутал?
Ну прально, за чем?..
Как минимум не всегда.
Так что ничего я не ошибаюсь.
Сложные распределённые системы работают по иным законам. Несколько миллионов SQL-инсертов/апдейтов за несколько секунд? Это шутка недели, однозначно.
И пока есть люди, которые думают подобным образом, у меня на столе есть кусок хлеба с икрой пармезан с гран-резервой. Подниму вечером бокал за ваше здоровье!
Легко и быстро можно посчитать на памяти параллельно на нескольких серверах.
А вот это — сохранение посчитанного в сторэйдж, тоже делается параллельно и легко закидывается в фоновый процесс.
Нечего делать всякие перерывы на ровном месте и там где они не нужны.
Это малина для всякого рожа манипуляций.
Основная задержка возникает при подъеме необходимых для расчета данных на Память из сиквельных баз или других бд.
Затем считаться должно все на памяти параллельно на нескольких серверах — это делается быстро.
Результаты, которые посчитались, могут сохраняться на СиквелСерверах уже при работающей торговой системе в фоновом режиме хоть до утра.
однорукий экономист, redis и mongodb что ли? Так для любых операций, где в одном месте убыло, а в другом прибыло нужна поддержка транзакций. Т.е. база должна быть ACID - https://ru.wikipedia.org/wiki/ACID
Ни одна из «нормальных быстрых баз» не удовлетворяет этим требованиям полностью (частично — да).
С другой стороны, посмотрим на вакансии на МосБирже (вкладка IT) - https://www.moex.com/ru/career/vacancies/
Ни на что не намекает?
Миллионные базы с правильными индексами у меня под рукой (вот в буквальном смысле, в соседней консоли). Но не удаётся выгружать «за несколько секунд». То в диски упирается, то в CPU, то в сеть. Прямо беда-беда.
Кроме непосредственной выгрузки надо ещё и пометить, что в одном месте убыло, в другом прибыло и закоммитить эту транзакцию. Это довольно дорогостоящая операция, никакими «за несколько секунд» там и не пахнет.
А что комитить то собрался в базу и почему это минутами должно делаться?
И кстати современные диски, кпу, и память имеют очень высокую производительность, миллион сделок прочитать займет меньше секунды(при условии что руки программиста растут из правильного места, а не оттуда откуда у разработчиков мосбиржи).
и нужно не просто миллион сделок прочитать, а вычислить все пары кто кому должен и т.д. чтобы потом проверить задолженности и заявленное ГО клиентом
посмотри тут в правилах, там pdf документ, возможно найдешь причину почему так долго
однорукий экономист, похоже, что вы имеете очень слабое представление о механизме транзакций в реляционных БД и какое это имеет значение для финансовой сферы
https://www.tutorialspoint.com/sql/sql-transactions.htm
Куда и что выгружать? Что за ересь вы несёте? Вы хоть понимаете, как это работает и что такое консистентность данных? Пока не завершилась последняя транзакция — ничего делать нельзя.
От дальнейшей дискуссии с вами я воздержусь, слишком разный уровень компетенции.
Успехов в торговле!
gans-spb.livejournal.com/33248.html
читай ганса_спб, может у тебя будет шанс стать человеком.