Distinct с вложеным позапросом.

Совместимость InterBase, Firebird, Yaffil между собой и по версиям

Модераторы: kdv, Alexey Kovyazin

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 июл 2005, 10:33

Видно работа 150(в среднем 50 активных) пользователей и баз в 7 гигов это видно так демо версия.
не верю я в это. это сервер приложений с FB Embedded? могу поверить (еле-еле), если только запросы совсем примитивные, и выполняются не более 0.1-0.2 секунды. Иначе - трупик. Embedded никогда не предполагался как сервер приложений по очень простым причинам:

это dll, то есть любое приложение, его подключающее, превращается в сервер. Следовательно
а) если оно упадет, упадет и "сервер", и есть риск повредить базу
б) при этих условиях может быть организован только 1 exe в виде сервера приложений. два запустить нельзя. Значит надо организовывать пул коннектов (тредовый).
в) embedded не работает с тредами, ибо коннект локальный. Ну может быть Yaffil Personal (ибо там xnet), но все равно это стремно.

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

_so_
Сообщения: 144
Зарегистрирован: 04 ноя 2004, 22:17

Сообщение _so_ » 27 июл 2005, 12:27

б) при этих условиях может быть организован только 1 exe в виде сервера приложений. два запустить нельзя.
С этим никто не спорит
в) embedded не работает с тредами, ибо коннект локальный.
Так про это пишу, чтобы этого хотелось.
По надежности не согласен.

Если падает IB то автоматичеки падают и подключенные конекты к сервере приложению.
могу поверить (еле-еле), если только запросы совсем примитивные, и выполняются не более 0.1-0.2 секунды.
Что-то это слишком долгие запросы. У нас много запросов которые выполняются в интервале 0,010-0,1 c.

Надежность работы с базой по-моему не зависит от того где реализован сервак в виде exe или dll.
Может тогда IB или FB вообще не использует dll. Полная чушь.

Обращение к серваку замедляет не только время выполнения запроса,но и его prepare и прокачку записей и взятие блобов, так как это обращение по сетке причем между различными процесами с разным адресным пространством и разными менеджерами памяти и т. д.
Для пимера прокачивался запрос пару тысячей записей с блобами. На embeded серваке этот запрос с прокачкой всех записей т блобов выполняется в 2 раза быстрей. 2с и 1с соответсвенно. Конешно такие запросы редкость, но все равно.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 27 июл 2005, 12:50

В обчим, трэба щоб либо Камаз разгонялся до 250 за 5 сек, либо Ламборжини вёз 20 тонн компоста, иначе оба - ацтой :-D

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 июл 2005, 14:11

Надежность работы с базой по-моему не зависит от того где реализован сервак в виде exe или dll.
Может тогда IB или FB вообще не использует dll. Полная чушь.
так. давай посмотрим на чушь. ЕЩЕ РАЗ. Embedded - это dll. Твое приложение (exe) + Embedded (dll) - это ОДИН ПРОЦЕСС. То есть СЕРВЕР.
Если твое приложение (exe), использующее embedded (dll) упало, то это эквивалентно ПАДЕНИЮ СЕРВЕРА. Если же падает твое приложение, которое соединяется к ОБЫЧНОМУ, ОТДЕЛЬНОМУ СЕРВЕРУ (ibserver.exe/fbserver.exe), то сервер ПРОДОЛЖАЕТ РАБОТАТЬ.

Теперь ты разницу ощущаешь, между падением клиента + сервера и клиента со ВСТРОЕННЫМ сервером?
Что-то это слишком долгие запросы. У нас много запросов которые выполняются в интервале 0,010-0,1 c.
я и говорю, примитивные запросы. Соответственно, при сериализуемом доступе (через embedded) сама проблема ПООЧЕРЕДНОГО выполнения запросов не заметна. Как только появятся запросы, выполняющиеся 1-5 секунд, то все сразу станет заметно. Напомню, что речь про использование Embedded + сервер приложений.
Обращение к серваку замедляет не только время выполнения запроса,но и его prepare и прокачку записей и взятие блобов, так как это обращение по сетке причем между различными процесами с разным адресным пространством и разными менеджерами памяти и т. д
вот это - чушь. особенно при том, что в Embedded запросы сериализуются. Как раз при взятии блобов и т.п. и будет разница, даже если сервер приложений и сервер БД соединены сеткой 100Мбит.
Для пимера прокачивался запрос пару тысячей записей с блобами. На embeded серваке этот запрос с прокачкой всех записей т блобов выполняется в 2 раза быстрей. 2с и 1с соответсвенно. Конешно такие запросы редкость, но все равно.
ну так вот. Если к Embedded пойдут 3 таких запроса одновременно, то он сможет их обслужить только ПОСЛЕДОВАТЕЛЬНО. А обычный сервер БД - параллельно.

_so_
Сообщения: 144
Зарегистрирован: 04 ноя 2004, 22:17

Сообщение _so_ » 27 июл 2005, 15:53

ну так вот. Если к Embedded пойдут 3 таких запроса одновременно, то он сможет их обслужить только ПОСЛЕДОВАТЕЛЬНО. А обычный сервер БД - параллельно.
Уважаемый KDV вы читаете через строчку (и это уже замечено не раз). Вообще-то я писал требования к такому embeded сервер:
Конечно требования к такому серверу каждый коннект в отдельном потоке, потокозащищенность поддержка SMP и т.д.
И я не говорил, что можно использовать текущий embeded сервер FB для многопользовательской работы да и SS FB тоже не оптимально.
вот это - чушь. особенно при том, что в Embedded запросы сериализуются. Как раз при взятии блобов и т.п. и будет разница, даже если сервер приложений и сервер БД соединены сеткой 100Мбит.
этого я не понял.
Вы еще писали
если только запросы совсем примитивные, и выполняются не более 0.1-0.2 секунды.
Хорошо еще select, а например insert. Не знаю как Вам, а мне очень сложно написать insert выполняющейся более 0.2. А если таких инсертов тысячи.
Теперь ты разницу ощущаешь, между падением клиента + сервера и клиента со ВСТРОЕННЫМ сервером?
Опять не читаем текст.
Я писал: "Если падает IB то автоматически падают и подключенные коннекты к сервере приложению"
И по-моему мы друг друга не понимаем. Я говорю про версию Embedded сервера которую хотел бы видеть, а вы мне все про текущую, про которую и так все известно.
Я вообще сомневаюсь что для FB будет когда-нибудь нормальным SS (параллельно выполнять запросы на нескольких процах), а Borland вряд ли будет делать Embedded.
На самом деле я увидел минусы Embedded сервера, которые реально не позволят его использовать(даже если будет удовлетворять многим требованиям). Главный из них невозможность использования других утилит для работы с базой во время работы сервера приложения (так как он выступает сервером). Например даже BACKUP базы. Писать свой не очень правильно. А у нас например на одном из клиентов работа идет круглосуточно. Вот про это я действительно забыл.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 июл 2005, 16:24

И по-моему мы друг друга не понимаем. Я говорю про версию Embedded сервера которую хотел бы видеть, а вы мне все про текущую, про которую и так все известно.
правильно. потому что другого embedded быть не может. я потому и объяснял про dll, падения и непараллельность, чтобы было понятно, что даже если сделать "параллельность" то это не спасет от exe+dll.
Я писал: "Если падает IB то автоматически падают и подключенные коннекты к сервере приложению"
а я писал, что если падает сервер приложений, то падает и Embedded, если именно он используется как сервер БД. Чтобы было понятно, чего ждать от embedded, любого.
На самом деле я увидел минусы Embedded сервера, которые реально не позволят его использовать(даже если будет удовлетворять многим требованиям)
вот и хорошо.
а Borland вряд ли будет делать Embedded.
вот это еще неизвестно.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 27 июл 2005, 16:30

_so_ писал(а):Я вообще сомневаюсь что для FB будет когда-нибудь нормальным SS (параллельно выполнять запросы на нескольких процах), а Borland вряд ли будет делать Embedded.
Сомневаться - священное право (лево) каждого.
За борланд не скажу, а вот про вулкан почитать посоветую. Конечно - слияние не завтра, но...
_so_ писал(а):На самом деле я увидел минусы Embedded сервера, которые реально не позволят его использовать(даже если будет удовлетворять многим требованиям). Главный из них невозможность использования других утилит для работы с базой во время работы сервера приложения (так как он выступает сервером). Например даже BACKUP базы. Писать свой не очень правильно. А у нас например на одном из клиентов работа идет круглосуточно. Вот про это я действительно забыл.
Именно таким образом работает классик на линуксе - там нет локального пртокола, но сам движок выполнен в виде .so (где-то я видел эти 2 буквы ? ;) и грузится каждым клиентским процессом, AFAIU

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 июл 2005, 16:45

а вот про вулкан почитать посоветую
вопрос - "посоветую" кому? :)

читать конечно можно, но вот толку от этого на самом деле мало. Ибо этот самый документ про вулкан изобилует превосходными степенями при совершенно ином реальном положении дел. Увы.
Именно таким образом работает классик на линуксе - там нет локального пртокола, но сам движок выполнен в виде .so (где-то я видел эти 2 буквы ? Wink и грузится каждым клиентским процессом, AFAIU
но он использует менеджер блокировок, как и остальные "клиентские" процессы классика. В Embedded это делать бессмысленно, так как сервер станет представлять собой отдельный exe и пользовательский exe+dll. То есть, смысл теряется, когда можно с тем же успехом запустить суперсервер или классик как таковые.

_so_
Сообщения: 144
Зарегистрирован: 04 ноя 2004, 22:17

Сообщение _so_ » 27 июл 2005, 16:52

правильно. потому что другого embedded быть не может. я потому и объяснял про dll, падения и непараллельность, чтобы было понятно, что даже если сделать "параллельность" то это не спасет от exe+dll.
А вот это спорно. Почему то мне удается писать такие прложения.
Если есть многопотоковое приложение почему оно не может вызывать функции или процедуры из dll, которые работали паралельно. Я не знаю может уважаемый kdv не знаком с такими понятиями как потоки, кртические, секции, мьютексы и т. д. Не понимаю я до конца. Чем отличается реализация кода в dll или exe. Например exe вобще занимать 10 кб, а остальной может быть размещен в *.dll,*.bpl,*.ocx и т.д.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 27 июл 2005, 17:26

kdv писал(а):
а вот про вулкан почитать посоветую
вопрос - "посоветую" кому? :)
Да уж не тебе :wink:
kdv писал(а):читать конечно можно, но вот толку от этого на самом деле мало. Ибо этот самый документ про вулкан изобилует превосходными степенями при совершенно ином реальном положении дел. Увы.
Чел сомневается в будущем FB SS. Фактически говорит - вот борланд сделал, а вы - пацаны ышшо.
Что ему ещё сказать ? Так, чтобы вежливо :)

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 июл 2005, 17:43

Почему то мне удается писать такие прложения.
которые вообще без багов и никогда не падают?
Если есть многопотоковое приложение почему оно не может вызывать функции или процедуры из dll, которые работали паралельно.
опять двадцать пять.... локальный коннект gds32.dll НЕ ПОДДЕРЖИВАЕТ ПАРАЛЛЕЛЬНУЮ РАБОТУ. он сериализуется.
Я не знаю может уважаемый kdv не знаком с такими понятиями как потоки, кртические, секции, мьютексы и т. д.
спасибо, я Рихтера читал лет 8 назад. а пул коннектов для IB, тредовый, написал в 1997 году. В виде компонент.
Не понимаю я до конца. Чем отличается реализация кода в dll или exe.
мы про что? про падения или локальный коннект?
Например exe вобще занимать 10 кб, а остальной может быть размещен в *.dll,*.bpl,*.ocx и т.д.
или еще про что?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 июл 2005, 18:18

я наверное, попробую закрыть этот вопрос окончательно.
Итак, излагаю:

1. gds32.dll поддерживает параллельную (из разных тредов) обработку только на уровне отдельных коннектов

2. локальный коннект в gds32.dll не работает параллельно (если только это не xnet)

3. FB Embedded - это fbserver.exe (суперсервер) в виде клиентской gds32.dll (или если угодно - fbclient.dll). То есть, сервер экспортируется в виде функций.

4. приложение (exe), использующее Embedded (dll) превращается в сервер, т.к. dll "сервера" исполняется в адресном пространстве приложения (exe).

5. если в отдельном сервере superserver запросы из разных коннектов обрабатываются в разных threads, то в embedded это может быть сделано только на уровне приложения (тем не менее шедулер потоков работает внутри dll Embedded, тут я был неправ, признаю).

теперь, из этих фактов можно сделать следующие выводы относительно приложения (или сервера приложений), работающего с Embedded:

а) поскольку приложение являет собой "сервер", то только оно одно может работать с конкретной БД. Соответственно, для серверов приложений, использующих Embedded, невозможна модель Multi-Instance.

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

в) любая ошибка в приложении, ведущая к порче сегмента данных или падению приложения, может привести к разрушению БД (см. пункт 4).

Наверное, все. Если претензий нет, внесу в FAQ.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 27 июл 2005, 19:48

hvlad писал(а): Что ему ещё сказать ? Так, чтобы вежливо :)
Вот я решил помалкивать. Чел ни хрена не может понять, что embedded - это экземпляр сервера, слитый со своим _собственным и единственным клиентом_ в один флакон, но усиленно гнёт пальцы и учит отцов ибаста, а также лучше всех знает что будет и чего не будет в FB и насколько правильно в IB решён вопрос с нитями. Имхо нехай дальше рассуждает с умным человеком, то бишь, с самим собой, а я, дурак, помолчу.

_so_
Сообщения: 144
Зарегистрирован: 04 ноя 2004, 22:17

Сообщение _so_ » 28 июл 2005, 10:43

По моему пальцы здесь гну не я. Я не спорю с вами про текущий вариант FB embedded.
Насчет багов они во всех приложениях есть. Ошибок не совершают те только кто ничего не делает и не расуждает.
Насчет много поточного приложения. Я не понимаю почему если падает одна нитка должен упасть весь сервак. Это пять же баг, который нужно исправлять. Понятно если упадет главная нитка. И никто не спорит "gds32.dll поддерживает параллельную (из разных тредов) обработку только на уровне отдельных коннектов" по моему это известно давно.
По моему мы говорим о разных вещах. Вы давите, что такие крутые все мы знаем про текущие версии, с этим я тоже не спорю. Но все знать нельзя. А я вам о говорю о возможной реализации, которую мо моему мнению вполне можно сделать (вопрос на сколько это только реально из-за различных ресурсов).

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 28 июл 2005, 12:17

Я не спорю с вами про текущий вариант FB embedded.
дык и на тему "будущих" вариантов Embedded тоже спорить не надо. я вообще не понимаю, о чем здесь спорить, и какие-такие догадки по поводу будущего Embedded можно строить. Есть два варианта сервера - exe и dll. Третьего не дано. Про оба известно, как они функционируют. Они не могут функционировать иначе (за исключением распараллеливаемости суперсервера, это отдельный вопрос).

Если есть какие-то идеи - давай, высказывай.
насчет много поточного приложения. Я не понимаю почему если падает одна нитка должен упасть весь сервак.
да не должен, конечно, если обработка ошибок грамотно написана. но в случае embedded вопрос не про его надежность, а про надежность приложения. Я не пойму, почему надежность клиент+сервер ставится вровень с приложение+embedded? Вообще это личное дело каждого, можно вместо embedded даже BDE для доступа к DBF использовать.

_so_
Сообщения: 144
Зарегистрирован: 04 ноя 2004, 22:17

Сообщение _so_ » 02 авг 2005, 10:41

Если есть какие-то идеи - давай, высказывай.
Не знаю какие предложения. По моему они очевидны. В одной из ниток (может быть главной) создается менеджер коннектов (Общий кэш, управление транзакциями и т. д.). И в уже отдельных нитках создаются подключения. Это один из вариантов. Второй может быть другой. Делается подключение одно. Но в каждой отдельной нитки создаются несколько транзакций. Так как здесь нет сокетов, то тоеритические параллельную работу запросов и транзакций реализовать можно. Но мне советовать сложно так как я не лазил никогда в код сервера, плюс я никогда не писал под linux. А FB и IB проектируется как многоплатформенный, и я слышал проектирование многопоточности по linux были проблемы (по крайней мере, раньше). Поэтому писать сервак который сильно будет завязан под винду не всем понравится. Но это так рассуждения. Сейчас бы больше хотелось чтобы IB и FB, лучше строил планы. От этого наверное производительность наверное выиграла больше. Просто в нашей системе большинство запросов строится динамически и подстраивать каждый ну очень долго и не всегда реально. Приходится делать настройки под отключению индексов на различные поля во время выполнения определенного классов запросов и т. д. Использую IB уже лет 8 и жду когда же они это наконец это сделают. Причем иногда вообще смешно, почему не используется статистика которая есть в самой базе. Просто некоторые люди которые работали например c MS SQL, говорят что про эту пробле5му вообще никогда не слышали(но другие все же были). Ладно буду надеется на лучшее. По крайней мере, параллелизм в суперсервере IB сделали.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 02 авг 2005, 12:26

_so_ писал(а):Сейчас бы больше хотелось чтобы IB и FB, лучше строил планы. От этого наверное производительность наверное выиграла больше
Попробуй FB2, просто для сравнения
_so_ писал(а):Использую IB уже лет 8 и жду когда же они это наконец это сделают.
А что - кто-то обещал ? :lol: :lol: :lol:
_so_ писал(а):Причем иногда вообще смешно, почему не используется статистика которая есть в самой базе. Просто некоторые люди которые работали например c MS SQL, говорят что про эту пробле5му вообще никогда не слышали(но другие все же были)
Если не слышали - не значит что её нет. Я работаю с MSSQL (тсс), так что кое-что знаю и о нём
_so_ писал(а): Ладно буду надеется на лучшее. По крайней мере, параллелизм в суперсервере IB сделали.
Я промолчу на это :oops:

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 02 авг 2005, 13:11

В одной из ниток (может быть главной) создается менеджер коннектов (Общий кэш, управление транзакциями и т. д.). И в уже отдельных нитках создаются подключения.
это для Embedded? извини, но я не стал пока дальше читать. если для супера вообще - тогда посмотрю, но в принципе раз ты читал про Вулкан, то должен быть в курсе планируемых изменений.

_so_
Сообщения: 144
Зарегистрирован: 04 ноя 2004, 22:17

Сообщение _so_ » 03 авг 2005, 16:58

hvlad писал(а):Попробуй FB2, просто для сравнения
Попробовал на на одном для из меня последнем проблемном запросе. Действительно лучше.
Описываю пример. На одной из таблиц есть есколько индексов по одиночным полям. Используются для различных запросов.
Но в одном изь запросов есть ограничение по нескольким полям.
При этом IB7.1 и IB7.5 использует для ограничения все индексы.
FB2.0 использует толька два (c наилучшей статистикой).
Соответсвенно без оптимизации запроса FB 2.0 работает быстрее.
Но все равно ввторой индекс использовать здесь тоже не рекомендуется т.к. с оптимизацией черер обрамление через udf поля запрос работает еще быстрее. И самое главное по статистике очевидно первый индекс почти уникальный. Для второго индекса намного больше.
На даном этапе вижу Fb сработал лучше. После окончательной тестировки IB 7.5.1 попробую тестировать локально FB 2.0.

_so_
Сообщения: 144
Зарегистрирован: 04 ноя 2004, 22:17

Сообщение _so_ » 03 авг 2005, 18:16

Забыл добавить. FB в отличие от IB показал выдал полность плал запроса (IB только план вложеных подзапросов). Если уважаемый kdv и Merlin будут меня чем-то закидывать, то при выполнеии запросв использовался IBExpert.

Ответить