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

Меня как 1С ника интересует такой тест использования хранимых процедур на Net.
Часто в модулях проведения приходится использовать рекурсивные алгоритмы, и разветвленные алгоритмы, где иногда нужно добираться доатрибута через 4-5 точку, где каждый новый шаг зависит от предыдущего. (10 тысяц строчек кода не предел).
Такие вещи перекрасно проходят для локальных баз (файловый кэш прекрасно работает со всеми процессами напримерв терминалах, но ужасно долго в SQL).
Вот можно какой нибудь тест на проход по таблице с доступом по ссылочным полям по 2 3 из исходной таблцы с джойнами с иерархией в хотя бы в 3 таблицы.
Интерес насколько тормозит межпроцессное взаимодействие.

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

V>Как может XML быть тоньше того же ASN.1, например?
А ему не надо быть тоньше, он и так достаточно тонок. По факту, межпроцессное взаимодействие с помощю WCF проигрывает DCOM-у на пренебрежимо малую для подавляющего большинства реальных приложений величину.

V>Я может, скажу громко, но использование СУБД настолько широко сейчас, что ко многим сценариям обобщённое требование звучит как "реалтайм". Дык, надо от туда и брать наработки.
Зачем, если и так не плохо все работает. Ну не самое это узкое место.

V>Нет, конечно, тут нужен комплекс мер. Просто реализация "бизнес-логики" в виде sored procecure решает сразу два пункта из этого комплекса: убирает 2 лишние сериализации (заметь — самые неэффективные из всей цепочки), а так же лишний слой межпроцессного взаимодействия (который на современных ОС не эффективен по фундаментальным причинам).
Проблема только в одном, эти две неэффективные сериализации и прочие взаимодействия — отнюдь не самые узкие места во всей цепочке. И вынесение всего барахла на сиквел, только прибавит проблем с поддержкой и разработкой, а вот скорости практически не увеличит.

V>Согласись, что СУБД изначально стали выносить за пределы приложений с целью обеспечения безопасности данных путём такого изолирования.
Не безопасности, а масштабирования. СУБД, как персистенс хранилище не масштабируется вообще, стейтлес же логику можно размазать по произвольному количеству серверов, получая практически линейную масштабируемость.
А вот безопасность как раз проще держать в БД.

V>Управляемые среды с валидируемым кодом, ИМХО, решают эту проблему. Сейчас связь с этими stored proc на .Net не самая эффективная, на основе "того что было" (System.Data), если народ будет этим повсеместно пользоваться, то возникнет требование более легковесного и типизированного решения, которое вполне может быть реализовано MS.
Я вполне доволен тем, что из себя представляет System.Data сейчас, и не вижу никаких причин помещать логику в БД. Никаких практических проблем это не решит, а лишней возни здорово прибавит.

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

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

V>>Как может XML быть тоньше того же ASN.1, например?
IB>А ему не надо быть тоньше, он и так достаточно тонок. По факту, межпроцессное взаимодействие с помощю WCF проигрывает DCOM-у на пренебрежимо малую для подавляющего большинства реальных приложений величину.

Это от того, что тяжеловесная XML сериализация занимает не самое большую долю тиков в межпроцессном взаимодействии, ЧТД.

V>>Я может, скажу громко, но использование СУБД настолько широко сейчас, что ко многим сценариям обобщённое требование звучит как "реалтайм". Дык, надо от туда и брать наработки.
IB>Зачем, если и так не плохо все работает. Ну не самое это узкое место.

А какое же место тогда узкое?

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

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

V>Это от того, что тяжеловесная XML сериализация занимает не самое большую долю тиков в межпроцессном взаимодействии, ЧТД.
С чего бы ей быть тяжеловесной-то?

V>А какое же место тогда узкое?
БД запросы и взаимодействие с удаленным клиентом.

V> В разогретом состоянии такая база отвечает действительно "мгновенно", не являясь узким местом.
Это "мгновенно", все равно больше, чем сериализация/десериализация и межпроцессное взаимодействие.

V> И все эти пляски апп-серверов вокруг базы, да еще на столь расточительных технологиях, добавляют задержку, сопоставимую с полезной или даже большую.
V>Сей факт неприятен сам по себе, не находишь?
Не нахожу.. Я не нахожу, что технологии расточительные, я не нахожу, что они добавляют сопоставимую задержку (в тех случаях где имеет смысл сопоставлять) и, как следствие, я не нахожу в этом неприятных фактов.
Но дело даже не в этом, а в том, что даже если это и проблема, то решаться она должна уж ни как не внесением стейтлес логики в базу.

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

IB>СУБД, как персистенс хранилище не масштабируется вообще, стейтлес же логику можно размазать по произвольному количеству серверов, получая практически линейную масштабируемость.
Позвольте, это как же персистенс хранилище не масштабируется? Вот к примеру:
Scale up:
— Больше винчестеров
— RAID
— Меняем физ. интерфейс к HDD, например используем RAM
Scale out:
— DB cluster
— Distributed File System (та же MogileFS к примеру)

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

_>Позвольте, это как же персистенс хранилище не масштабируется?
А вот так. Речь о том, что производительность стейтлес решений можно поднять просто поставив больше железок вокруг (горизонтально), масштабировать же стейтфул толком можно лишь увеличивая мощность одной железки, что сильно снижает перспективы такого масштабирования.

_>Вот к примеру:
_>Scale up:
_>- Больше винчестеров
_>- RAID
...
_>- Distributed File System (та же MogileFS к примеру)
Количество доступного дискового пространства на производительность влияет мало.

_>- Меняем физ. интерфейс к HDD, например используем RAM
Про ACID забудь в этом случае и это все опять про одну железку.

_>Scale out:
_>- DB cluster
Посмотри на tpc.org — там очень наглядно показано, как одна мощная железка рвет на тряпки любой кластер, перекрывая его в производительности в несколько раз. В последнее время там помоему вообще забили на попытки собрать производительный OLTP кластер.

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

_>>- Больше винчестеров
_>>- RAID
IB>...
_>>- Distributed File System (та же MogileFS к примеру)
IB>Количество доступного дискового пространства на производительность влияет мало.
В производительности можно выйграть, если, к примеру, поместить разные БД на разные физические диски.
Не все RAID одинаково полезны. Для перфоманса есть к примеру RAID0, RAID3.
По поводу distributed FS тоже зря — нагрузка так же распределяется. Узким местом становится сетевое взаимодествие, но и это решается применением того же оптоволокна.

_>>- Меняем физ. интерфейс к HDD, например используем RAM
IB>Про ACID забудь в этом случае и это все опять про одну железку.
Конечно — это же scale up.

_>>Scale out:
_>>- DB cluster
IB>Посмотри на tpc.org — там очень наглядно показано, как одна мощная железка рвет на тряпки любой кластер, перекрывая его в производительности в несколько раз. В последнее время там помоему вообще забили на попытки собрать производительный OLTP кластер.
Ну тут конечно трудно спорить. Проблемма в том, что у железки есть чёткий потолок, а кластер можно наращивать постепенно, что-то оптимизируя "по ходу пьесы". В итоге — большая гибкость. Пройдёт 2 года и ваша железка морально устареет, в то время как ваш конкурент будет неспеша апгрейдить кластер.

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

_>Пройдёт 2 года и ваша железка морально устареет, в то время как ваш конкурент будет неспеша апгрейдить кластер.

Так это решение совсем другой проблемы, проблемы неспешного апгрейда.

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

_>>>- Больше винчестеров
_>>>- RAID
IB>>...
_>>>- Distributed File System (та же MogileFS к примеру)
IB>>Количество доступного дискового пространства на производительность влияет мало.
_>В производительности можно выйграть, если, к примеру, поместить разные БД на разные физические диски.
_>Не все RAID одинаково полезны. Для перфоманса есть к примеру RAID0, RAID3.
_>По поводу distributed FS тоже зря — нагрузка так же распределяется. Узким местом становится сетевое взаимодествие, но и это решается применением того же оптоволокна.

_>>>- Меняем физ. интерфейс к HDD, например используем RAM
IB>>Про ACID забудь в этом случае и это все опять про одну железку.
_>Конечно — это же scale up.

_>>>Scale out:
_>>>- DB cluster
IB>>Посмотри на tpc.org — там очень наглядно показано, как одна мощная железка рвет на тряпки любой кластер, перекрывая его в производительности в несколько раз. В последнее время там помоему вообще забили на попытки собрать производительный OLTP кластер.
_>Ну тут конечно трудно спорить. Проблемма в том, что у железки есть чёткий потолок, а кластер можно наращивать постепенно, что-то оптимизируя "по ходу пьесы". В итоге — большая гибкость. Пройдёт 2 года и ваша железка морально устареет, в то время как ваш конкурент будет неспеша апгрейдить кластер.
Класный пример кстати — ЖЖ. Видели их презенташку? Вместо того, что бы купить "крутую железку", поставить на неё базу и радоваться пока не упрёшься в потолок, они крутили кластер. Причём в разных вариациях, каждый раз анализируя распределение нагрузки и узкие места. В итоге пришли решению где одна база разбита на кучу маленьких — благо логика приложения позволяла. Очень поучительно имхо.

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

_>Класный пример кстати — ЖЖ. Видели их презенташку? Вместо того, что бы купить "крутую железку", поставить на неё базу и радоваться пока не упрёшься в потолок, они крутили кластер. Причём в разных вариациях, каждый раз анализируя распределение нагрузки и узкие места. В итоге пришли решению где одна база разбита на кучу маленьких — благо логика приложения позволяла. Очень поучительно имхо.

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

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

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

_>>Класный пример кстати — ЖЖ. Видели их презенташку? Вместо того, что бы купить "крутую железку", поставить на неё базу и радоваться пока не упрёшься в потолок, они крутили кластер. Причём в разных вариациях, каждый раз анализируя распределение нагрузки и узкие места. В итоге пришли решению где одна база разбита на кучу маленьких — благо логика приложения позволяла. Очень поучительно имхо.

IT>Поучительно здесь прежде всего то, что логика приложения позволяет разбить базу на кучу маленьких. Случай мягко говоря редкий в ентерпрайзах. Чаще получается разбивать базу на логически независимые блоки, немного пожертвовав целостностью.

К тому и веду — persistence вполне себе масштабируется, просто нужно знать как готовить. Хоть и не без гемороя.

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

_>В производительности можно выйграть, если, к примеру, поместить разные БД на разные физические диски.
Это все не про то, это по прежнему одна железка и далеко не все базы позволяют размазать нагрузку по дискам.

_>Конечно — это же scale up.
Те кто могут себе такое позволить — ставять MySQL и не парятся.

_>Ну тут конечно трудно спорить.
Об чем и речь.

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

_>Класный пример кстати — ЖЖ. Видели их презенташку?
ЖЖ, кстати пример не очень классный, но речь не о нем...

_>Вместо того, что бы купить "крутую железку", поставить на неё базу и радоваться пока не упрёшься в потолок, они крутили кластер. Причём в разных вариациях, каждый раз анализируя распределение нагрузки и узкие места. В итоге пришли решению где одна база разбита на кучу маленьких — благо логика приложения позволяла. Очень поучительно имхо.
Вот и я о том же. Далеко не все приложения можно таким образом размазать по нескольким узлам. И выходом тут является вынесение на эти узлы стейтлес логики, причем этот способ относительно универсальный, который работает везде, где есть эта стейтлес логика. Ровно по этой причине мне и не нравится запихивание этой стейтлес логики в БД, что убъет идею вынесения ее на другие узлы.

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

_>К тому и веду — persistence вполне себе масштабируется, просто нужно знать как готовить. Хоть и не без гемороя.
Как бы так тебе объяснить.. =) Здесь, в принципе, все примерно представляют, включая интимные подробности, как именно масштабируется БД и какими ритуальными приседаниями это делается. Речь о том, что горизонтально отмасштабировать стейтлес напорядок легче. И по сравнению с этим БД таки нефига не масштабируется (хотя мы все прекрасно знаем как это делается).

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

IT>>Поучительно здесь прежде всего то, что логика приложения позволяет разбить базу на кучу маленьких. Случай мягко говоря редкий в ентерпрайзах. Чаще получается разбивать базу на логически независимые блоки, немного пожертвовав целостностью.

_>К тому и веду — persistence вполне себе масштабируется, просто нужно знать как готовить. Хоть и не без гемороя.

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