Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9468
Molochnik
Никакого, я просто объяснил почему несмотря на критическую секцию здесь используются две транзакции а не одна


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

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

ну да. А то что это влияет на ширину резалтсета для сортировки конечно не думаем. Да и тащить по сети лишнее это конечно круто, она же жирная выдержит.

> в WHERE поля без уточнения, согласен, но это косметика.

Во-первых это потенциальные грабли, на которые со временем наступишь. А во-вторых вот смотрю я сейчас на твой запрос и не понимаю можно ли его улучшить или нет, потому что не понятно что именно фильтруется.

> Условий фильтрации много, ну и что? Все нужны.

Его наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации.
18 фев 19, 09:48    [21812556]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

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

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

Симонов Денис
ну да. А то что это влияет на ширину резалтсета для сортировки конечно не думаем. Да и тащить по сети лишнее это конечно круто, она же жирная выдержит.

Для FB используется ROWS 1, для MS SQL - TOP 1. Увеличивать и так гигантский текст SQL перечислением нескольких десятков полей особо желания не было. Этот так важно?
Симонов Денис
Во-первых это потенциальные грабли, на которые со временем наступишь.

Это понятно
Симонов Денис
Его наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации.

Сомнительно. Все условия разнородные, скорее всего упростить можно только уменьшив количество возможностей, чего не хотелось бы.
18 фев 19, 10:08    [21812568]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Vlad F
Member

Откуда:
Сообщений: 774
Molochnik
Vlad F
Molochnik,
Это очень даже не странно, это стандарт.

Странно что в микрософте об этом знали :)

Да это, поди, сделали еще те, у кого майкрософт это дело скупила.))
18 фев 19, 10:12    [21812572]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9468
Molochnik
Если и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения?


а почему это она должна быть долгой? В твоём SELECT выбирается одна жалкая запись. Если это делается долго, то нужно запрос оптимизировать.

> Этот так важно?

пока не увидел план сказать не могу, но почему-то у меня подозрения что сортировка не планом ORDER идет, а через SORT и тогда это действительно важно

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

я уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр
18 фев 19, 10:21    [21812577]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27938
Molochnik,

про потоки.
- в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно.
В других серверах точно так же. 1 поток - 1 коннект.
- если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код?
18 фев 19, 10:56    [21812637]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1551
Molochnik
Смысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись.

сделайте один поток, ответственный за распределение заданий из очереди

зы
поговаривают зубы можно per rectum удалять, но зачем
18 фев 19, 11:00    [21812644]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Симонов Денис
Molochnik
Если и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения?

а почему это она должна быть долгой? В твоём SELECT выбирается одна жалкая запись. Если это делается долго, то нужно запрос оптимизировать.

В реальности две таблицы большие остальные очень маленькие. С увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит. Как я уже говорил таблицы, поля и индексы обеих баз одинаковы и тексты запросов тоже.
Симонов Денис
пока не увидел план сказать не могу, но почему-то у меня подозрения что сортировка не планом ORDER идет, а через SORT и тогда это действительно важно

Посмотрел в ibexpert там действительно вначале идет PLAN SORT...
Симонов Денис
я уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр

Да было бы неплохо

kdv
Molochnik,
про потоки.
- в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно.
В других серверах точно так же. 1 поток - 1 коннект.

так и устроено один поток - один коннект.
kdv
Molochnik,
- если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код?

Работа с базой не является основной целью программы, а полезная деятельность отлично распараллеливается. Критическая секция используется только для выборки данных.
Дегтярев Евгений
сделайте один поток, ответственный за распределение заданий из очереди

Так делать не хочу поскольку в данном случае считаю это излишним усложнением. И зачем тогда вообще сервер баз данных использовать? Сделал всю работу с бд через один поток и радуйся. Работа с файловыми таблицами парадокса быстрее любого SQL сервера на порядок. Там где не используется бд, этот механизм (один поток для обработки информации) я использую часто, но с базой желания нет. Тем более как я уже сказал MS SQL работает как и надо.
18 фев 19, 11:30    [21812707]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 10267
Molochnik
С увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит.
Ну так там и кеш не 16МБ, не так ли ?
18 фев 19, 11:37    [21812721]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
o_v_a
Member

Откуда: Тула
Сообщений: 1049
Ну и уж истины ради только...
Увидим мы статистику выполнения реального запроса, который "тормозит в сравнении с таким же на MS SQL) или нет? А также конфиг сервера firebird SQL и заголовок статистики базы ?
18 фев 19, 12:09    [21812767]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1551
Molochnik
Тем более как я уже сказал MS SQL работает как и надо.

но это не значит что сделано все как надо

Если инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам
18 фев 19, 12:13    [21812780]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Файл конфига FB 3 приложен. Для FB2.5 настроек специальных никогда не делалось.

К сообщению приложен файл (firebird.conf - 2Kb) cкачать
18 фев 19, 12:46    [21812842]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Вот лог с тестированием одного селекта при 50 тыс записей для FB И MS SQL, работает только один поток.
Первые записи - идет выборка с FB, последние - с MS

К сообщению приложен файл (database.2019.02.log - 4Kb) cкачать
18 фев 19, 12:48    [21812847]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9468
Molochnik
#hqbird traceapi plugin should be in plugins folder!
TracePlugin = fbtrace2db


так у тебя HQBird? Или просто скопировал бездумно?
18 фев 19, 12:55    [21812868]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1551
400-500ms на получение задачи из очереди это "как и надо"?
18 фев 19, 12:56    [21812871]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9468
Дегтярев Евгений,

у него фильтрация записи мутная. Т.е. если сам SELECT запрос медленный, то там чего не делай с прикладой всё равно работать будет отвратительно
18 фев 19, 13:04    [21812895]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Дегтярев Евгений
Если инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам

По мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно.
18 фев 19, 13:11    [21812914]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27938
Molochnik
Критическая секция используется только для выборки данных.

к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся.
18 фев 19, 13:13    [21812920]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Симонов Денис
так у тебя HQBird? Или просто скопировал бездумно?

да тупо скопировал оптимизированный конфиг для суперсервера. Для классик и суперклассик параметры в файле меняю на рекомендуемые оптимизированные с того же сайта.
Дегтярев Евгений
400-500ms на получение задачи из очереди это "как и надо"?

ну, скажем так приемлемо. Сама обработка записи может десяток секунд идти
kdv
Molochnik
Критическая секция используется только для выборки данных.

к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся.

Да, ни к чему конечно, к работе с БД это не относится. Ошибся и заметил это после отправки вопроса
18 фев 19, 13:17    [21812931]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47376

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

Она логична, но при её реализации ты допустил две ошибки:
1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками,
что на корню рушит логику.
2) Подавленное исключение не позволяет заметить ошибку обновления и пропустить уже
захваченную другим потоком запись.

Проще говоря, твоя система обработки не работает от слова "совсем" на сервере где нет
грязного чтения. MS SQL - твоё всё и альтернатив нет.

Posted via ActualForum NNTP Server 1.5

18 фев 19, 13:21    [21812941]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Dimitry Sibiryakov
Она логична, но при её реализации ты допустил две ошибки:
1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками,
что на корню рушит логику.

У меня же читающая транзакция read_commited. Если параллельный поток закоммитил данные, неужели читающая другого этого не увидит? Как же у меня она вообще работает тогда? А она работает, причем без исключений
18 фев 19, 13:25    [21812951]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1551
Molochnik
По мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно.

- не вижу ничего логичного
- не вижу усложнения
- поделите записи на группы и отдавайте обработчику нужную
- время обработки тут вообще причем?
18 фев 19, 13:28    [21812953]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47376

Molochnik
Как же у меня она вообще работает тогда?

Это в народе называется "дуракам везёт".

Molochnik
А она работает, причем без исключений

Это естественно, потому что ты глушишь их секцией except.

Posted via ActualForum NNTP Server 1.5

18 фев 19, 13:28    [21812954]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Дегтярев Евгений
- поделите записи на группы и отдавайте обработчику нужную
/quot]
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry Sibiryakov
Это в народе называется "дуракам везёт".

Все время же везти не может
Molochnik
А она работает, причем без исключений

Это естественно, потому что ты глушишь их секцией except.

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.
18 фев 19, 13:41    [21812970]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 122
Дегтярев Евгений
- поделите записи на группы и отдавайте обработчику нужную
- время обработки тут вообще причем?

Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry Sibiryakov
Это в народе называется "дуракам везёт".

Все время же везти не может
Dimitry Sibiryakov
Это естественно, потому что ты глушишь их секцией except.

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.
18 фев 19, 13:43    [21812971]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1551
Molochnik
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.

оставим тему про дублирование, я понял что для вас значит усложнение...

вернемся к скорости
в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет
но сначала оптимизируйте запрос/структуру (которых мы так и не увидели)
в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много
18 фев 19, 13:56    [21812984]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить