Здравствуйте, Sinclair, Вы писали:

V>>А сколько всего может быть вариантов плана у среднего запроса?
V>>Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
S>Это зависит от того, какую степень независимости клиента от сервера мы ожидаем.

Вот, кстате, первая разумная мысль.
Одобряю.


S>И там вариантов плана будут десятки и сотни.

От единиц до десятков, потому что "по нескольким физическим хранилищам и прочее" уже известно на момент компиляции, заведомо плохие ветки отсекаются так же, как они эффективно отсекаются в рантайм у современных SQL баз. С той лишь разницей, что предварительную оценку по заведомо плохим вариантам уже делать не надо в рантайм.

Т.е., поменял конфигурацию базы — всё перекомпиллировалось.
Как-то так.
Примерно как в 1C, я же приводил уже пример.
И да, для клиента АПИ мог не поменяться, т.е. некоторая изоляция "интерфейса" от "релизации" имеет место быть, как и в любой сложной системе.


S>Я не вижу связи между "во вполне конкретной конструкции join" и "суммой всех вариантов по всем запросам".

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


S>В самых простых учётных системах есть крайне популярная штука — star join.

Дело не в простоте учётной системе, а в требованиях некоей аналитики.

Потому что, когда речь идёт о движениях, то никаких "star" быть не может по причине ограничений целостности данных.
(кстате, частично эти ограничения целостности можно тоже отслеживать в compile-time)

А вот аналитика бывает произвольной — а давай-ка мы наложим даты дней рождения клиентов на их деловую активность? ))
И по моему личному опыту, строить аналитику из "сырых" данных — не лучшая идея.
Лучше перегонять это дело в "кубики" и вертеть ими уже как удобно.
И вот тут, действительно, SQL показывает свою мощь.
Как и любая "открытая" система, собсно.

V>>И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
S>А, ну это отличная идея. Не факт, правда, что работоспособная.

Крупные ERP-системы не в курсе, что не факт, что работоспособная.


S>Тем не менее, лично мои потребности эти прошитые запросы не удовлетворяют. Приходится писать скрипты, которые вытаскивают данные на клиента, и надругаются над ними уже локально.

А в той же 1С или Парусе или Axapta ты дорабатываешь саму "систему" и вот требуемый запрос для нового требуемого отчёта волшебным образом "возникает". Как и везде в этой области, собсно.


S>Тут ключ к успеху — не нагрузка, а то, что все виды запросов, действительно, зафиксированы раз и навсегда.

И что нагруженные сценарии оперируют ограниченным кол-вом таблиц, это тоже особенность таких сценариев.

Например, движения по счетам в бухгалтерии — это ровно одна основная таблица.
Движения товаров при средневзвешенном их учёте — тоже ровно одна "двигающаяся" таблица.
При партионном учёте — всего две "двигающихся" — партии и расход.

Остальные данные имеют характер справочных.

А "исходники" операций (накладные, счета, возвраты и т.д.) — это вообще лишь исходники. Их может быть много разных, их задача — сохранить некую прикладную подробность операции, по большей части избыточную для целей учёта, но требуемую для взаимодейдствия с клиентами и налоговой.

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


S>Тот же "банкинг" на самом деле устроен совсем не так, как во влажных мечтах С++ программистов. Там как раз SQL, адская Java, и прочие тормоза на ровном месте.

Банкинг устроен слишком по-разному.
Настолько слишком, что вряд ли ты в состоянии представить себе всю палитру используемых решений.
Фактически, учётная система каждого крупного банка — это его и ноу-хау и субъект конкуренции.
Я лишь упоминал случаи, когда некоторые крупные банки (типа дойчбанка) тоже используют подходы к опердню, как в биржах.
И я уверен, что в своё время они замечательно прошли все стадии "адской джавы и SQL".

В принципе, уже для данных вчерашнего дня джава + SQL смотрятся великолепно! ))
И её там для таких именно целей в избытке.
Для всех обслуживающих утилит — тоже.


S>А чего вы хотели, когда реал-тайм банкинг — это выполнение перевода в течение 4х часов минимум

4 часа происходит не сам перевод.
Это девочка оператор должна проверить твою виртуальную платёжку и дать ей ход.
Если это перевод м/у странами, то будет еще один клерк, который проверит операцию и даст ей ход дальше.
На приёмной стороне аналогично.
Совсем другое дело перевод внутри одной страны м/у банками, как это работало (просто я немного в курсе) для украинской платёжной системы.
Не успеет оператор отправить — уже приходит смс о получении.


S>Ну вот теперь мы говорим о чём-то предметном — о приложениях, где объём функционала — с гулькин хрен, а стоимость потери времени — высока. То есть — о биржах.

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


V>>"Это" становится известным в рантайм, а не компайл-тайм.
S>И слава байту. Иначе у нас первое же обновление сервера убьёт всех клиентов из-за несовместимости протокола.

А почему внешний-то протокол должен поменяться при каждом внутреннем изменении?
И почему даже в случае внешнего изменения должна нарушаться обратная совместимость?
Вот у меня в течении нескольких лет прошли перед глазами обновления одного из таких протоколов, дык, старым клиентам надо было обновляться только при желании задействовать некое новое АПИ.

V>>Я дал все ключевые слова по которым можно выйти прямо на спеки некоторых бирж и там в доке найти ответы на все вопросы.
S>Ага. А также ещё на 100500 мусора, который не имеет отношения к теме разговора.

Это тебе так кажется. "OMnet/OMX" — вполне себе URL при наличии доступа к гуглу.


S>Ну, то есть данных нет. Просто "ну, наверное там ребята разобрались". Можно было так и сказать, а не выделываться, намекая на какое-то сакральное знание, которым вы обладаете, а все остальные — неучи.

Ничего не понял — в чём сакральность, эй?
Я приводил вполне конкретные цифры roundtrip-а.
От аналогичных на SQL-серваке на той же машине они отличаются на порядок или больше.

По-сути, твой вопрос можно свести к следующей спекуляции: "а как ты вообще собрался вычленять из общего времени на выполнение запроса к SQL-серваку время, связанное исключительно с динамической природой SQL и всех операций вокруг этого?"

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

И я уверен, что ты прекрасно разбираешься в этих тонкостях, поэтому считаю грубой спекуляцией с твоей стороны требовать дать то, чего дать принципиально нельзя. Я могу лишь сравнить динамику со статикой. Большего я на себя не брал.


S>Что из чего вычитать? Ну, для "базы", которая на бирже крошечная и с примитивной структурой, данные есть. Правда, непонятно, каким образом биржа ухитряется выполнять коммит транзакции без записи на диск — там ведь никак не получатся ни единицы, ни десятки микросекунд.

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

Собсно, это верно даже для клиентской стороны — вот клиентский торговый "робот" формирует трафик сообщений в сторону биржи, но в сокет ни в коем случае нельзя писать по одному сообщению — ты банально не сможешь насытить сокет (там десятки байт на сообщение). Каждый раз закидывается пачка сообщений и опять по кругу. Пока вызывается ядерная ф-ия записи пачки байт в сокет (даже в неблокирующем режиме это может занять пару микросекунд), в очереди могут накопиться еще несколько сообщений. В режиме же, когда сокет насыщен по-масимуму, система реагирует на готовность сокета принять очередную пачку данных из очереди. Время реакции составляет порядка одной микросекунды. Вот такие тайминги. Для сравнения, на чиста дотнетных асинхронных сокетах (а там два конкурирующих асинхронных механизма) удаётся пропихнуть трафик примерно в 6-8 раз меньший, при том, что сообщения-то пихаются де-факто пачками, т.е. дополнительные затраты надо раскидывать на кучу сообщений, а не на каждое из них, т.е. ожидалась совсем другая разница. ))

Это насчёт уместности джавы или дотнета в таких делах.


S>для биржи не грех и кастомное решение навелосипедить,

А еще не грех взять движок от DB2, убрав из него всё, что касается обработки конкретно SQL, оставив только механику и надёжность. ))

"Унутре", т.е. в самом низу, современные БД весьма эффективны и нехило вылизаны с учётом особенностей операционок и дисков.
Т.е. не факт, что твой велосипед их перегонит-то при заданной надёжности.


S>внезапно оказывается, что предметом беседы стал не универсальный язык по доступу и манипуляции реляционными данными, а написание узкоспециализированных решений вроде бирж или телекоммуникаций

Не оказывается ни разу. ))

1. Эти области были приведены лишь как пример, где от SQL ПРИШЛОСЬ отказаться;
И такие области тоже надо уметь окучивать.
А "разрывы" в технологиях всегда болезненны и являются лишним источником ошибок.

2. Статика не отменяет динамику, а замечательно её дополняет.
Даже в С++ часто используют динамику в полный рост. Т.е. не dynamic_cast, а именно некие фреймворки, позволяющие оперировать динамическими данными. Как пример, хосподя, весь COM, OLE VARIANT и т.д.

Более того, часто неожиданно оказывается, что динамика хоть и нужна, но не так широко, как казалось из-за долголетней привычки её использовать.

Поэтому, все мои исходные тезисы в силе:
— убрать разрыв технологий;
— дать эффективный в рантайм инструмент;
— повысить контроль целостности и типизации данных еще на этапе разработки.