|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Имеется многопотоковое дельфийское приложение, у каждого потока свое соединение к общей базе. Через Unidac может работать с Firebird и MS SQL. Каждый поток выполняет (регулярно и часто) одинаковый для всех сложный SELECT, и затем одинаковый для всех простой UPDATE, со своим набором параметров. При тестировании обнаружил, что с MS SQL программа работает быстро и реально многопотоково, а с Firebird выглядит так как будто каждый поток ждет когда до него дойдет очередь выполнять запрос, в итоге получается а разы медленнее чем с MS SQL. Тестировал на FB2.5 и FB3.0 со всеми архитектурами, ситуация примерно одинакова. В какую сторону смотреть? Не может же быть, что Firebird в разы хуже MS SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 23:50 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, давай сюда тест, повторимый. Иначе о чем. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:09 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Поменять сообщение видимо нельзя, поэтому добавлю, что все запросы делаются через критическую секцию, т.е. фактически эти запросы к базе выполняются потоками по очереди, но это не мешает MS SQL обрабатывать их очень быстро в отличии от FB. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:11 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, набросать тест? А ты, не имея его исходников, начнешь угадывать, насколько он соответствует твоим задачам. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:20 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Фэйтл ЭраMolochnik, давай сюда тест, повторимый. Иначе о чем. Сильно много усилий придется потратить такой тест сделать, фактически надо с нуля тестовое приложение написать. Если без этого никак проще оставить как есть и не париться. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:23 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnikпроще оставить как есть и не париться Если допустимо не оптимизировать - не оптимизируй. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:25 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Фэйтл ЭраMolochnikпроще оставить как есть и не париться Если допустимо не оптимизировать - не оптимизируй. Наверное так и оставлю, в принципе работает, посмотрел как запрос выполняется в IBExpert, все вроде корректно, в плане куча джойнов и индексов, "natural" только один, в таблице где обычно 1-2 записи. Чтобы оптимизировать вероятно нужно будет сильно потрудиться. Не стоит игра свеч наверно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:33 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikПри тестировании обнаружил, что с MS SQL программа работает быстро и реально многопотоково Molochnikвсе запросы делаются через критическую секцию, т.е. фактически эти запросы к базе выполняются потоками по очередиТы определись - "реально многопотоково" или таки "по очереди" ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:45 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikКаждый поток выполняет (регулярно и часто) одинаковый для всех сложный SELECT, и затем одинаковый для всех простой UPDATE, со своим набором параметровА коммит - где ? В MSSQL - автокоммит небось, а у FB нужно явно делать. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 00:47 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
hvladТы определись - "реально многопотоково" или таки "по очереди" Да, ошибся поправить вопрос уже было нельзя. с базой приложение работают фактически однопотоково. Просто визуально MS SQL работал намного быстрее и выглядело так, будто потоки выполняют запросы одновременно. hvladА коммит - где ? В MSSQL - автокоммит небось, а у FB нужно явно делать. Нет все явно, для каждого потока две формальных транзакции, первый (SELECT) SQL выполняется в читающей, второй (UPDATE) - в пишущей. Для FB у читающей 'Params=read;wait;read_committed;rec_version', у пишущей 'Params=write;wait;read_committed;rec_version', читающая постоянная, пишущая - открывается, закрывается. Для MS SQl формально выглядит так же, транзакции без параметров. Зачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 06:29 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Код в каждом потоке выглядит примерно так Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
SQL селект очень большой, упрощенно (уменьшено раза в 3, но суть ту же) выглядит так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
SQL апдейт очень простой: Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 07:54 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikИмеется многопотоковое дельфийское приложение, у каждого потока свое соединение к общей базе <..>. Милый друг, ну а зачем же ты тогда критические секции в них запихал? И что будет, если обращение к ним (секциям) просто закомментировать? И если уж на то пошло, то мерить/сравнивать тебе надо, для начала, простое последовательное выполнение тех запросов в цикле. Слелай циклы на тысячу итераций к каждому серверу (вот тебе саамый простой тест), засеки время и озвучь результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:28 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, за такой SELECT надо руки отрывать, без относительно того на каком сервере это выполняется ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:32 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Vlad FМилый друг, ну а зачем же ты тогда критические секции в них запихал? Смысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись. Vlad FИ если уж на то пошло, то мерить/сравнивать тебе надо, для начала, простое последовательное выполнение тех запросов в цикле. Слелай циклы на тысячу итераций к каждому серверу (вот тебе саамый простой тест), засеки время и озвучь результат. да, сделаю ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:34 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов ДенисMolochnik, за такой SELECT надо руки отрывать, без относительно того на каком сервере это выполняется И в чем кривость? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:35 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikЗачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует. Это вообще феерический бред. Каким образом боком здесь вообще другое приложение работающее с теми же таблицаим? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:42 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, во всём, начиная от table.*, поля в where без уточнений к какой таблице относятся, 100500 условий фильтрации ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:46 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов ДенисMolochnikЗачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует. Это вообще феерический бред. Каким образом боком здесь вообще другое приложение работающее с теми же таблицаим? Никакого, я просто объяснил почему несмотря на критическую секцию здесь используются две транзакции а не одна ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:47 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов ДенисMolochnik, во всём, начиная от table.*, поля в where без уточнений к какой таблице относятся, 100500 условий фильтрации Поля используются практически все, их очень много, чтобы по отдельности выписывать. в WHERE поля без уточнения, согласен, но это косметика. Условий фильтрации много, ну и что? Все нужны. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 08:49 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikСмысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись. Select for update, с с оответствующей обработкой результатов возможного отлупа в потоках, с тем чтобы они в подобной ситуации повторяли попытку поиска неиспользуемой записи? Подумай над этим. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:03 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Vlad FSelect for update, с с оответствующей обработкой результатов возможного отлупа в потоках, с тем чтобы они в подобной ситуации повторяли попытку поиска неиспользуемой записи? Подумай над этим. Этой конструкции нет в MS SQL поэтому я стараюсь такие не использовать. Также например не использую функцию IIF, потому что вплоть до 2008 года в MS SQL ее не было. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:18 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, Но case то был?? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:30 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Vlad FMolochnik, Но case то был?? Да, как ни странно, case был. У меня сейчас совместимость вплоть до MS SQL 2000 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:37 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, Это очень даже не странно, это стандарт. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:43 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Vlad FMolochnik, Это очень даже не странно, это стандарт. Странно что в микрософте об этом знали :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:45 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikНикакого, я просто объяснил почему несмотря на критическую секцию здесь используются две транзакции а не одна это как раз и есть чушь. Паттерн с использованием двух транзакций происходит от нежелания закрывать недофетченный курсор, при завершении единственной транзакции которая обновила запись. От наличия нескольких приложений работающих с теми же таблицами это никак не зависит. > Поля используются практически все, их очень много, чтобы по отдельности выписывать. ну да. А то что это влияет на ширину резалтсета для сортировки конечно не думаем. Да и тащить по сети лишнее это конечно круто, она же жирная выдержит. > в WHERE поля без уточнения, согласен, но это косметика. Во-первых это потенциальные грабли, на которые со временем наступишь. А во-вторых вот смотрю я сейчас на твой запрос и не понимаю можно ли его улучшить или нет, потому что не понятно что именно фильтруется. > Условий фильтрации много, ну и что? Все нужны. Его наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:48 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов Денисэто как раз и есть чушь. Паттерн с использованием двух транзакций происходит от нежелания закрывать недофетченный курсор, при завершении единственной транзакции которая обновила запись. От наличия нескольких приложений работающих с теми же таблицами это никак не зависит. Всегда все пишут, что пишущая транзакция должна быть короткой при многопользовательском доступе. Если и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения? Особенно учитывая что запросы фактически непрерывно. Симонов Денисну да. А то что это влияет на ширину резалтсета для сортировки конечно не думаем. Да и тащить по сети лишнее это конечно круто, она же жирная выдержит. Для FB используется ROWS 1, для MS SQL - TOP 1. Увеличивать и так гигантский текст SQL перечислением нескольких десятков полей особо желания не было. Этот так важно? Симонов ДенисВо-первых это потенциальные грабли, на которые со временем наступишь. Это понятно Симонов ДенисЕго наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации. Сомнительно. Все условия разнородные, скорее всего упростить можно только уменьшив количество возможностей, чего не хотелось бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 10:08 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikVlad FMolochnik, Это очень даже не странно, это стандарт. Странно что в микрософте об этом знали :) Да это, поди, сделали еще те, у кого майкрософт это дело скупила.)) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 10:12 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikЕсли и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения? а почему это она должна быть долгой? В твоём SELECT выбирается одна жалкая запись. Если это делается долго, то нужно запрос оптимизировать. > Этот так важно? пока не увидел план сказать не могу, но почему-то у меня подозрения что сортировка не планом ORDER идет, а через SORT и тогда это действительно важно > Сомнительно. Все условия разнородные, скорее всего упростить можно только уменьшив количество возможностей, чего не хотелось бы. я уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 10:21 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, про потоки. - в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно. В других серверах точно так же. 1 поток - 1 коннект. - если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 10:56 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikСмысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись. сделайте один поток, ответственный за распределение заданий из очереди зы поговаривают зубы можно per rectum удалять, но зачем ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 11:00 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов ДенисMolochnikЕсли и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения? а почему это она должна быть долгой? В твоём SELECT выбирается одна жалкая запись. Если это делается долго, то нужно запрос оптимизировать. В реальности две таблицы большие остальные очень маленькие. С увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит. Как я уже говорил таблицы, поля и индексы обеих баз одинаковы и тексты запросов тоже. Симонов Дениспока не увидел план сказать не могу, но почему-то у меня подозрения что сортировка не планом ORDER идет, а через SORT и тогда это действительно важно Посмотрел в ibexpert там действительно вначале идет PLAN SORT... Симонов Денися уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр Да было бы неплохо kdvMolochnik, про потоки. - в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно. В других серверах точно так же. 1 поток - 1 коннект. так и устроено один поток - один коннект. kdvMolochnik, - если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код? Работа с базой не является основной целью программы, а полезная деятельность отлично распараллеливается. Критическая секция используется только для выборки данных. Дегтярев Евгенийсделайте один поток, ответственный за распределение заданий из очереди Так делать не хочу поскольку в данном случае считаю это излишним усложнением. И зачем тогда вообще сервер баз данных использовать? Сделал всю работу с бд через один поток и радуйся. Работа с файловыми таблицами парадокса быстрее любого SQL сервера на порядок. Там где не используется бд, этот механизм (один поток для обработки информации) я использую часто, но с базой желания нет. Тем более как я уже сказал MS SQL работает как и надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 11:30 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikС увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит.Ну так там и кеш не 16МБ, не так ли ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 11:37 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Ну и уж истины ради только... Увидим мы статистику выполнения реального запроса, который "тормозит в сравнении с таким же на MS SQL) или нет? А также конфиг сервера firebird SQL и заголовок статистики базы ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 12:09 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikТем более как я уже сказал MS SQL работает как и надо. но это не значит что сделано все как надо Если инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 12:13 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Файл конфига FB 3 приложен. Для FB2.5 настроек специальных никогда не делалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 12:46 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Вот лог с тестированием одного селекта при 50 тыс записей для FB И MS SQL, работает только один поток. Первые записи - идет выборка с FB, последние - с MS ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 12:48 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik#hqbird traceapi plugin should be in plugins folder! TracePlugin = fbtrace2db так у тебя HQBird? Или просто скопировал бездумно? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 12:55 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
400-500ms на получение задачи из очереди это "как и надо"? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 12:56 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев Евгений, у него фильтрация записи мутная. Т.е. если сам SELECT запрос медленный, то там чего не делай с прикладой всё равно работать будет отвратительно ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:04 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев ЕвгенийЕсли инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам По мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:11 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikКритическая секция используется только для выборки данных. к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:13 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов Денистак у тебя HQBird? Или просто скопировал бездумно? да тупо скопировал оптимизированный конфиг для суперсервера. Для классик и суперклассик параметры в файле меняю на рекомендуемые оптимизированные с того же сайта. Дегтярев Евгений400-500ms на получение задачи из очереди это "как и надо"? ну, скажем так приемлемо. Сама обработка записи может десяток секунд идти kdvMolochnikКритическая секция используется только для выборки данных. к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся. Да, ни к чему конечно, к работе с БД это не относится. Ошибся и заметил это после отправки вопроса ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:17 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikПо мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Она логична, но при её реализации ты допустил две ошибки: 1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками, что на корню рушит логику. 2) Подавленное исключение не позволяет заметить ошибку обновления и пропустить уже захваченную другим потоком запись. Проще говоря, твоя система обработки не работает от слова "совсем" на сервере где нет грязного чтения. MS SQL - твоё всё и альтернатив нет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:21 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovОна логична, но при её реализации ты допустил две ошибки: 1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками, что на корню рушит логику. У меня же читающая транзакция read_commited. Если параллельный поток закоммитил данные, неужели читающая другого этого не увидит? Как же у меня она вообще работает тогда? А она работает, причем без исключений ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:25 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikПо мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно. - не вижу ничего логичного - не вижу усложнения - поделите записи на группы и отдавайте обработчику нужную - время обработки тут вообще причем? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:28 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikКак же у меня она вообще работает тогда? Это в народе называется "дуракам везёт". MolochnikА она работает, причем без исключений Это естественно, потому что ты глушишь их секцией except. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:28 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев Евгений- поделите записи на группы и отдавайте обработчику нужную /quot] Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось. Dimitry SibiryakovЭто в народе называется "дуракам везёт". Все время же везти не может MolochnikА она работает, причем без исключений Это естественно, потому что ты глушишь их секцией except. Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:41 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев Евгений- поделите записи на группы и отдавайте обработчику нужную - время обработки тут вообще причем? Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось. Dimitry SibiryakovЭто в народе называется "дуракам везёт". Все время же везти не может Dimitry SibiryakovЭто естественно, потому что ты глушишь их секцией except. Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:43 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikЭто фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось. оставим тему про дублирование, я понял что для вас значит усложнение... вернемся к скорости в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет но сначала оптимизируйте запрос/структуру (которых мы так и не увидели) в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 13:56 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
а физически не на одну ли тачку взгромоздили Firebird SQL и MS SQL? Потому как если это так, то можно пеплом присыпать себе всё... Метра на два. Firebird будет на правах падчерицы по ресурсам в этой ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 14:09 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikВсе время же везти не может Может. MolochnikЯ глушу там просто на всякий случай, по инерции, по логике хуже не будет. Ну да. Подумаешь: незамеченный конфликт. Это всего лишь означает, что одна и та же запись будет обработана несколько раз разными потоками. Ничего страшного, просто из-за долгого времени обработки одной записи обработка всех записей будет в несколько раз дольше. Стоп! Уж не на это ли ты жаловался?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 14:44 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев ЕвгенийMolochnikЭто фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось. оставим тему про дублирование, я понял что для вас значит усложнение... вернемся к скорости в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет но сначала оптимизируйте запрос/структуру (которых мы так и не увидели) в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много Да, решил разобраться с самим запросом. Отключая разные куски запроса оказалось что проблема в скорости связана с ORDER BY: Код: sql 1.
tbl1.Priority у всех записей одинаковый, в tbl1 запись одна tbl2.Priority у всех записей одинаковый, и их в tbl2 50 тыс штук При объединении таблиц получаются 50 тыс записей у которых tbl1.Priority=0 и tbl2.Priority=0 и по этим полям идет сортировка, которая напрягает оба серверы, но FB особенно. Правда как дальше быть не знаю, поскольку сортировка по приоритету должна быть, он все таки может быть разным. Индексы на оба поля делал но толку нет, значения то одинаковые. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 15:59 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, я же тебе сразу сказал, что твои * играют злую шутку, потому что план там SORT ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 16:16 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
... а статистику выполнения реального запроса и gstat -h базы мы, похоже, что так и не дождёмся ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 16:21 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikПри объединении таблиц получаются 50 тыс записей у которых tbl1.Priority=0 и tbl2.Priority=0 и по этим полям идет сортировка, которая напрягает оба серверы, но FB особенно. Правда как дальше быть не знаю, поскольку сортировка по приоритету должна быть, он все таки может быть разным. Индексы на оба поля делал но толку нет, значения то одинаковые. и все эти 50т требуют обработки? если нет, то сначала отобрать те которые требуют - после и сортировать до посинения и еще вопрос почему задачи не сортируются по одной таблице? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 18:02 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
o_v_a... а статистику выполнения реального запроса и gstat -h базы мы, похоже, что так и не дождёмся просто не знал как это делается. Понял сделаю. Дегтярев Евгенийи все эти 50т требуют обработки? если нет, то сначала отобрать те которые требуют - после и сортировать до посинения да нужно именно все записи обработать, может сложиться ситуация когда 49999 записей имеют приоритет 0, а последняя 1, нужно чтобы сначала была обработана последняя запись. Наверное можно сначала выбрать всевозможные приоритеты первой таблицы, затем всевозможные приоритеты второй, потом организовать вложенные циклы c запросом в котором уже не будет ORDER BY по приоритетам. Неужели так и надо делать? Выглядит ужасно криво. Дегтярев Евгенийи еще вопрос почему задачи не сортируются по одной таблице? Не совсем понял вопрос, имеется ввиду почему "сортировка по полям разных таблиц а не по одной"? Две разные сущности и каждая имеет приоритет. Симонов ДенисMolochnik, я же тебе сразу сказал, что твои * играют злую шутку, потому что план там SORT Я просто не мог предположить что поле с постоянным значением оказывает такое тяжелое воздействие. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 18:34 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, авторда нужно именно все записи обработать, может сложиться ситуация когда 49999 записей имеют приоритет 0, а последняя 1, нужно чтобы сначала была обработана последняя запись это решается соответствующим индексом, но для этого данные должны быть в одной таблице ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 18:58 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, топик, непонятно чего ты хочешь? на халяву получить производительность коммерческой дорогой СУБД? ....... ФБ - простая легковесная штука. отсюда ее плюсы и минусы. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 22:56 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев ЕвгенийMolochnik, это решается соответствующим индексом, но для этого данные должны быть в одной таблице Может представление сделать? Будет фактически одна виртуальная таблица, но индекс же на ней не построишь, не вариант. Тогда может просто дублировать поля Priority в одну таблицу? И при любом изменении исходных (это случается крайне редко) просто обновлять результирующую по которой и идет запрос? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 07:58 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
SiemarglMolochnik, топик, непонятно чего ты хочешь? на халяву получить производительность коммерческой дорогой СУБД? ....... ФБ - простая легковесная штука. отсюда ее плюсы и минусы. У меня претензий к нему нет, MS SQL тоже же медленно работает, а проблема оказалась в запросе который писал я сам. Если убрать поля приоритетов из сортировки, запрос выполняется обоими серверами мгновенно (5-10 мс) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 08:01 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik Код: sql 1.
....а вот в планировщике процессов в windows ввели такое понятие как dynamic priority boost, иначе на сильно загруженной системе некоторые процессы вообще переставали выполнятьcя, могли часами висеть в состоянии "жду своего шанса" ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 15:40 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikSiemarglMolochnik, топик, непонятно чего ты хочешь? на халяву получить производительность коммерческой дорогой СУБД? ....... ФБ - простая легковесная штука. отсюда ее плюсы и минусы. У меня претензий к нему нет, MS SQL тоже же медленно работает, а проблема оказалась в запросе который писал я сам. Если убрать поля приоритетов из сортировки, запрос выполняется обоими серверами мгновенно (5-10 мс) Во-первых, чем какое-то штуко универсальнее, тем оно хуже в каждом конкретном применении, это аксиома. Это насчёт проектирования единого приложения под любую СУБД. Во вторых, убрать это поле из сортировки как два пальца об асфальт, и не надо городить никаких процедур-вьюх. Делаем в приложении примерно так. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Если приоритетных действительно заметно меньше, есть смысл сотворить индекс по Priority и добиться его использования в QPriority , вплоть до создания композита Priority,ID. И обеспечить его неиспользование в QCommon через +0. Это, правда, может повлечь за собой аналогичную подрихтовку других запросов с условием на Priority. Касательно в два запроса выглядит криво. Таки нам шашечки или ехать? Ходы кривые роет подземный умный крот, нормальные герои всегда идут в обход проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 17:00 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаЕсли приоритетных действительно заметно меньше, есть смысл сотворить индекс по Priority и добиться его использования в QPriority , вплоть до создания композита Priority,ID. И обеспечить его неиспользование в QCommon через +0. Это, правда, может повлечь за собой аналогичную подрихтовку других запросов с условием на Priority. Касательно в два запроса выглядит криво. Таки нам шашечки или ехать? Ходы кривые роет подземный умный крот, нормальные герои всегда идут в обход проблем. Выглядит круто, но мне непонятно без примера. Это обработка одного потока, желающего получить одну запись? Тогда почему Priority=1? Потоку же нужен не конкретный приоритет а просто самый высокий. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 21:24 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
На текущий момент сделал в основной таблице поле Priority в дополнение к полю NextDateTimeText. Значение в него пишется синтетическое, вычисляемое на основе tbl1.Priority и tbl2.Priority и всегда обновляемое при изменении либо tbl1 либо tbl2. Сделал индекс на основе Priority, NextDateTimeText. Сейчас первая запись, если подходит, ищется около 10 мс на FB. Если дополнительный фильтр по времени запрещает все записи, т.е. худший случай, когда шерстятся все 50 тыс. записей и ничего не находится, запрос длится около 1 сек. Т.е. даже в худшем случае запрос открывается существенно быстрее чем раньше в лучшем случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 21:38 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, Т.е. все-таки можешь, когда захочешь?)) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 21:47 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Vlad FMolochnik, Т.е. все-таки можешь, когда захочешь?)) Так криво же! Лишнее поле, лишние запросы. :) Тут вопрос как дальше оптимизировать чтобы убрать эту 1 секунду на поиск несуществующей записи, видимо циклов с вложенным запросами не избежать. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 22:09 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, не обязательно. 1. Можно кое что покумекать с CTE для отделения фильтрации и получения первой записи от присоединения дополнительных данных 2. Условия фильтрации можно упростить, да и вообще всякие LIKE нормально не оптмизируются ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 22:34 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов ДенисMolochnik, 1. Можно кое что покумекать с CTE для отделения фильтрации и получения первой записи от присоединения дополнительных данных Думаете, возможно оптимизировать? Вот я попроще оформил эту проблему: Table1 Id | TaskId | Info| -------------------- 1 | 1 | ' ' | 2 | 1 | ' ' | 3 | 1 | ' ' | 4 | 1 | ' ' | ...| ...| ...| Table2 TaskId | Condition | -------------------- 1 | 0 | Код: sql 1. 2.
Симонов ДенисMolochnik, 1. Условия фильтрации можно упростить, да и вообще всякие LIKE нормально не оптмизируются Я уже немного поправил часть с LIKE: Код: sql 1.
заменил Код: sql 1.
иначе без CAST ошибка при непустом :AllowedTexts вылезала. Вообще этот параметр используется очень редко, поэтому LIKE там обычно не срабатывает (т.е. условие всегда True). А вот условие по времени и дате срабатывает часто. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 00:17 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikЭто обработка одного потока, желающего получить одну запись? Будем считать, что я неправильно понял, что извлечение данных из базы и отметка того, что запись принята к рассмотрнию, сведены в критической секции, а потоки растекаются мыслью по древу с полученными из неё, секции, данными, каждый со своей возвращаемой этой секцией строкой резалтсета. На что наводит такая штучка как ROWS 1 в тексте запроса. Кстати, такой синтаксис мне незнаком, но я подумал, что либо я не в курсе последних веяний, либо автор привёл запрос MS SQL. MolochnikТогда почему Priority=1? Потоку же нужен не конкретный приоритет а просто самый высокий. Это я тоже неправильно понял из Molochniktbl1.Priority у всех записей одинаковый, в tbl1 запись одна tbl2.Priority у всех записей одинаковый, и их в tbl2 50 тыс штук что 1 - приоритетные строки, 0 - нет. Если есть иерархия приоритетов и основная масса всё-таки с нулевым, отсекаем её в первом запросе по where priority>0 и сортировку оставляем, на небольшом количестве записей она мешать не будет. Во втором уже ни условия на priority, ни сортировки по нему нет - ненулевые поймает первый, до второго дело дойдёт только если он пустой. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 02:29 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка Будем считать, что я неправильно понял, что извлечение данных из базы и отметка того, что запись принята к рассмотрнию, сведены в критической секции, а потоки растекаются мыслью по древу с полученными из неё, секции, данными, каждый со своей возвращаемой этой секцией строкой резалтсета. да, все так оно и есть Старый плюшевый мишкаНа что наводит такая штучка как ROWS 1 в тексте запроса. Кстати, такой синтаксис мне незнаком, но я подумал, что либо я не в курсе последних веяний, либо автор привёл запрос MS SQL. Все придумывают кто на что горазд: TOP, ROWS, FIRST. Стандарта видимо нет. Старый плюшевый мишкаЭто я тоже неправильно понял из что 1 - приоритетные строки, 0 - нет. Если есть иерархия приоритетов и основная масса всё-таки с нулевым, отсекаем её в первом запросе по where priority>0 и сортировку оставляем, на небольшом количестве записей она мешать не будет. Во втором уже ни условия на priority, ни сортировки по нему нет - ненулевые поймает первый, до второго дело дойдёт только если он пустой. Понял вашу логику. Приоритет меняется от 1 до 5 в двух используемых таблицах, думаю больше никому не потребуется, по умолчанию - 3. Обычно да, приоритет не меняют, но если все-таки поменяют, он сразу будет другим во многих записях. Т.е если сделать ускорение только для обычного приоритета, клиент будет недоумевать почему при обычном приоритете система работает быстро, а при критическом тормозит :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 08:22 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikВсе придумывают кто на что горазд: TOP, ROWS, FIRST. Стандарта видимо нет. ROWS - стандарт. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 09:11 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
WildSeryROWS - стандарт. Хорошо бы микрософту об этом сказать ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 09:20 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
WildSeryROWS - стандарт. Нет. По стандарту только в 3.0 сделано Код: plaintext 1.
гы. Теперь в Firebird аж 3 способа сделать одно и то же ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 09:35 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов Денис, Я имел в виду ISO SQL 2008, а не Firebird. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 10:03 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
WildSery, вот как раз там и есть тот синтаксис что я привёл. Его кстати почти во всех последних версиях SQL серверов прикрутили в том числе и в Oracle, MS SQL Server ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 10:13 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikТ.е если сделать ускорение только для обычного приоритета почему для обычного, делай для всех MolochnikПриоритет меняется от 1 до 5 в двух используемых таблицах можно вообще сделать таблицу Максимальный_Приоритет с одной единственнйо строкой и заполнять её на триггерах. или тупо в клиенте сделать цикл по приоритетам, как только нашлась первая запись, цикл прерывать и поскольку тебе все равно никогда больше одоной строки не надо, то вместо "ORDER BY tbl1.Priority DESC" написать "WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) )" Но IMHO зря это. Лучше реально считывать пачками хотя бы пару десятков задач, а потом уже на клиенте их разбирать по потокам. Впрочем, если обработка задачи по 10 секунд... (интересно, почему так долго) SQL апдейт очень простой: UPDATE tbl1 SET TextMarked=1 WHERE TextId=:TextId Вот это мне тоже не нравится. Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами). Соответственно, при ошибке в обработчике можно задачу возвращать в пул "неназначенных". При Успешной обработке - просто удалять из таблицы. У тебя же похоже что во-первых идёт модификация "широкой" таблицы по одному столбцу. Во вторых получается таблица, где TextMarked=0 выполняется только у очень немногих записей. Кажется считается, что индексы по таким столбцам неэффективны. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 20:08 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Ariochили тупо в клиенте сделать цикл по приоритетам, как только нашлась первая запись, цикл прерывать Да, вариант рабочий, я просто хотел обойтись одним запросом Ariochи поскольку тебе все равно никогда больше одоной строки не надо, то вместо "ORDER BY tbl1.Priority DESC" написать "WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) )" Это не прокатит, может быть так, что запись с максимальным приоритетом не удовлетворяет другим условиям, например по времени, а записи с меньшим - удовлетворяют. В итоге, при наличии реальных записей система будет стоять. AriochНо IMHO зря это. Лучше реально считывать пачками хотя бы пару десятков задач, а потом уже на клиенте их разбирать по потокам. Да уже предлагали этот вариант ( Дегтярев Евгений ) - один поток, обработчик базы, раскидывает данные по потокам. Я предположил что это чересчур сложно, имея сервер БД, который в общем то должен сам решать эту задачу AriochВпрочем, если обработка задачи по 10 секунд... (интересно, почему так долго) Пользователь долго думает. AriochВот это мне тоже не нравится. Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами). Соответственно, при ошибке в обработчике можно задачу возвращать в пул "неназначенных". При Успешной обработке - просто удалять из таблицы. В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета AriochУ тебя же похоже что во-первых идёт модификация "широкой" таблицы по одному столбцу. Во вторых получается таблица, где TextMarked=0 выполняется только у очень немногих записей. 50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей. Очень немного записей (обычно 0) получается когда не выполняется условие, подобное для всех, например время. Тут сразу получается очень долго. Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку: Код: sql 1.
и затем цикл по всем полученнным TaskId: Код: sql 1. 2.
Как сделать такой же эффективный один запрос я не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 09:38 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikОчевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку: Код: sql 1.
и затем цикл по всем полученнным TaskId: Код: sql 1. 2.
Как сделать такой же эффективный один запрос я не знаю. Встряну в середину разговора Если уже получил нужные TaskID из Table2 в первом запросе то зачем JOIN да еще и LEFT во втором Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 09:59 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikОчевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку: Код: sql 1.
и затем цикл по всем полученнным TaskId: Код: sql 1. 2.
Как сделать такой же эффективный один запрос я не знаю. Встряну в середину разговора Если уже получил нужные TaskID из Table2 в первом запросе то зачем JOIN да еще и LEFT во втором Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 09:59 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, > > Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами). > В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета примерно да не так не первый раз говорят - сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей, постройте индексы покрывающие ваши кейсы и крутите ее как угодно, разделите захват таска и получение данных по нему зы и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 10:22 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
m7mВстряну в середину разговора Если уже получил нужные TaskID из Table2 в первом запросе то зачем JOIN да еще и LEFT во втором Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем Код: sql 1. 2.
Пример просто был вырожденный чересчур, реально в Table2 имеются еще полезные поля которые нужно извлечь с помощью JOIN. Да действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия Дегтярев Евгенийне первый раз говорят - сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей, постройте индексы покрывающие ваши кейсы и крутите ее как угодно, разделите захват таска и получение данных по нему зы и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс так почти все поля и нужны (процентов 70), если все вносить в одну таблицу, то постоянно придется отслеживать все изменения в исходных, коих различных 6 штук, но вариант конечно рабочий ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 12:46 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikДа действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия А нет, все от данных зависит, сейчас тестировал на 200 тыс идентичных записях в обоих серверах. Составил табличку 1)Если нет ни одной удовлетворяющей записи, FB INNER JOIN - 1.6 сек LEFT JOIN - 5.5 сек MS INNER JOIN - 0.6 сек, LEFT JOIN - 0.6 сек 2) Если из 200 тыс доступны по условию все, то при получении одной записи FB INNER JOIN - 20 сек, LEFT JOIN - 0.8 секунды MS INNER JOIN - 0.01 сек LEFT JOIN - 0.01 сек Последние результаты для FB просто удручающие ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 14:56 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, я тебе уже советовал отделять условия фильтрации от остальных данных? делай так Код: sql 1. 2. 3.
если этот запрос будет быстро работать, то и остальное заработает. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:08 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikЭто не прокатит, может быть так, что запись с максимальным приоритетом не удовлетворяет другим условиям, например по времени, а записи с меньшим - удовлетворяют. Хммм... Ну тогда вот именно в этом случае, относительно редком, и "сыграешь на понижение", сделаешь второй запрос Arioch"WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) ) - :StepDown " StepDown = 0, 1, 2, 3.... Molochnikимея сервер БД, который в общем то должен сам решать эту задачу количество действий на вытаскивание одного задания, в процентах на непосредственно получения задания, и на обрамление для многопоточности есть вообще такие заморочки, как "безблокировочные структуры данных", которые весьма сложные и баго-опасные, но ими занимаются. потому что чем дольше у тебя процессор занимается действием "получить следующий элемент" - тем боьлше вероятность, что два таких действия с разных процессоров пересекутся. Тем, соотв., больше вероятность - что процессор будет работать "на мусорное ведро". Даже вот тупо так: процессор 1 начал получать задание процессор 2 начал получать задание процессор 1 получил задание №1 процессор 2 получил задание №1 процессор 1 начал обрабатывать задание №1 процессор 2 начал обрабатывать задание №1 процессор 1 кончил обрабатывать задание №1 процессор 2 кончил обрабатывать задание №1 процессор 1 положил в БД задание №1 процессор 2 попытался положить в БД задание №1 - и обломался (а то, не дай бог, и положил, дубль) процессор 1 начал получать задание процессор 2 начал получать задание процессор 1 получил задание №2 процессор 2 получил задание №2 .... если задания примерно равнозначные по сложности - то такая цепочка может дооолго идти. а если процессоров >2 - то ещё дольше. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:15 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikВ общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета ну сиииииильно примерно, учитывая что вместо одной таблицы у тебя джойн полудесятка и учитывая, что отработанные записи вместо простого удаления из таблицы помечаются отдельным столбцом TextMarked - который вообще нафиг не нужен. Просто удаляй отработанную запись из таблицы. Molochnik50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей. это сегодня. завтра у тебя 50К с 0 и 50К с 1 послезавтра - 50К с 0 и 100К с 1 через месяц - 50К с 0 и 3М с 1 и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:20 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев Евгенийне первый раз говорят - сделайте отдельную узкую таблицу для очереди туда ещё и генератор можно будет прицепить, ради dirty read, ради того, чтобы "захват таска" выполнялся вообще ВНЕ ТРАНЗАКЦИЙ и таким образом два разных клиента просто В ПРИНЦИПЕ не могли схватить один и тот же таск да, надо будет отрабатывать ошибочные ситуации типа "клиент схватил таск и умер, а уборщица украла сетевой кабель" - вбрасывать задание обратно с новым ID > generator-value но захват пачки заданий становится максимально быстрым и вообще без возможных пересечений с конкурентами ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:24 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikПоследние результаты для FB просто удручающие а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:27 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, 20 сек - это, конечно, сильно. Может анализ производительности в Эксперте посмотрим? План? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:42 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
AriochMolochnikПоследние результаты для FB просто удручающие а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ? Да сделал так, еще дополнительно провел бэкап рестор базы, результаты получше стали 1)Если нет ни одной удовлетворяющей записи, FB INNER JOIN - 1.2 сек LEFT JOIN - 4.1 сек 2) Если из 200 тыс доступны по условию все, то при получении одной записи FB INNER JOIN - 17 сек, LEFT JOIN - 0.015 сек То есть в идеальном случае, когда любая запись подходит FB работает почти как MS, что не может не радовать. Но INNER JOIN просто смерть какая-то. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 16:10 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik Но INNER JOIN просто смерть какая-то. Вот тут ты не прав нельзя просто так заменить LEFT JOIN на INNER JOIN ибо это совершенно разные запросы и совершенно разные результаты выполнения зы. не видя ни структур таблиц, ни планов, ни запросов мы тебе тут много чего насоветуем ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 16:45 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikAriochпропущено... а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ? Да сделал так, еще дополнительно провел бэкап рестор базы, результаты получше стали 1)Если нет ни одной удовлетворяющей записи, FB INNER JOIN - 1.2 сек LEFT JOIN - 4.1 сек 2) Если из 200 тыс доступны по условию все, то при получении одной записи FB INNER JOIN - 17 сек, LEFT JOIN - 0.015 сек То есть в идеальном случае, когда любая запись подходит FB работает почти как MS, что не может не радовать. Но INNER JOIN просто смерть какая-то. Да план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 19:03 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов ДенисMolochnik, я тебе уже советовал отделять условия фильтрации от остальных данных? делай так Код: sql 1. 2. 3.
если этот запрос будет быстро работать, то и остальное заработает. Потестировал ваш вариант, оставил одно поле Код: sql 1.
и убрал Код: sql 1.
иначе выдавал ошибку. Результаты следующие: 1)Если нет ни одной удовлетворяющей записи (Count =0) FB INNER JOIN - 1.3 сек LEFT JOIN - 3.8 сек MS INNER JOIN - 0.005 сек, LEFT JOIN - 0.005 сек 2) Если из 200 тыс доступны по условию все ( Count =200000) FB INNER JOIN - 4.2 сек, LEFT JOIN - 4.2 сек MS INNER JOIN - 0.7 сек LEFT JOIN - 0.7 сек m7mВот тут ты не прав нельзя просто так заменить LEFT JOIN на INNER JOIN ибо это совершенно разные запросы и совершенно разные результаты выполнения В общем случае согласен, но в моем варианте и варианте тестового примера, когда возвращается одна строка результат по логике должен быть примерно одинаковым, что результаты MS в общем то доказывают. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 19:09 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
m7mне видя ни структур таблиц, ни планов, ни запросов мы тебе тут много чего насоветуем ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе Реально там нет ничего интересного, ну вообще ничего, 6 таблиц джойнятся с разными несложными разумными условиями, никаких нестед таблиц или сложных конструкций, две таблицы большие да, по 200 тыс записей, джойнятся один к одному по полю, которое в одной таблице уникально, остальные таблицы по 1-3 записи. Основная проблема судя по всему - очень много одинаковых значений по полям, которые используется при сортировке и фильтре. Старый плюшевый мишкаДа план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без. Это пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 19:24 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnikесли у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" Ты просто пока не сталкивался. Например, выполни поиск слова "хинт" в форуме https://www.sql.ru/forum/microsoft-sql-server. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 19:35 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik, упрости запрос по максимуму на которых проявляются тормоза. Приведи его здесь, статистику выполнения и explain план запроса. Кстати в MS SQL ном варианте тоже хотелось бы на план взглянуть ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 19:47 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikЭто пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :) IBExpert внизу, вместе со временем выполнения, показывает пресловутый план. Перечень использованных индексов. Причём они перечисляются в порядке перебора таблиц, на которых они созданы. То есть, индексы таблицы, от которой начинается перебор, идут первыми (если она вообще не идёт натуралом), первого уровня подчинённости - вторыми и так далее. Скажем, условие "on t1.id=t2.id" в иннер может быть выполнено как перебором t1 с подтягиванием записей из t2 по индексу на t2, так и наоборот. Посмотри на план и прикинь как ТЫ бы это делал сам, ручками, чтобы не за... за... устать, в общем. И если оптимизатор сделал наоборот, то имеем то, что имеем, и надо вправлять ему мозги подзатыльником. Типа "on t1.id+0=t2.id". Тогда t1 точно будет ведущей, а t2 подтягиваться по индексу. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 20:13 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов Денис Старый плюшевый мишка Да все сделаю, посмотрю и проверю ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 20:28 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаIBExpert внизу, вместе со временем выполнения, показывает пресловутый план там ещё статистика чтений показываетсЯ, сколько с диска и сколько с кэша в памяти особенно еслди сравнить один и тот же запрос по холодному и по горячему вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 14:18 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев Евгенийсделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей ....а если таски настолько разные, что полей надо мноооого и узко не получается, то вероятно можно сделать несколько разных таблиц-очередей едва ли критерии распределения тасков по разным типов воркеров менются часто ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 14:21 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
AriochСтарый плюшевый мишкаIBExpert внизу, вместе со временем выполнения, показывает пресловутый план там ещё статистика чтений показываетсЯ, сколько с диска и сколько с кэша в памяти особенно еслди сравнить один и тот же запрос по холодному и по горячему вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше MSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например. А вы тут к каждому индексу цепляетесь.... =) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 14:41 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
SiemarglAriochпропущено... там ещё статистика чтений показываетсЯ, сколько с диска и сколько с кэша в памяти особенно еслди сравнить один и тот же запрос по холодному и по горячему вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше MSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например. А вы тут к каждому индексу цепляетесь.... =) В некоторых случаях развертывание всего комплекса, и полгода работы занимают меньше времени, чем развертывание MSSQL со всеми нетями, апдетями и пр. фигней. Для по-настоящему больших задач все равно динозавры-оракулы. Наша ниша - маленькие теплокровные млекопитающие(ся). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 15:19 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
SiemarglMSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например. А вы тут к каждому индексу цепляетесь.... =) К сожалению, там те же проблемы. Оптимизатор конкретной СУБД (MS SQL, DB2, PostgrSQL), используемой совместно с 1С, тоже строит планы по схожим принципам. Просто разработчики 1С более тщательно, чем Вы, подходят к вопросу генерации запросов. И все равно, иногда приходится работать ручками, об этом много написано, например: http://www.gilev.ru/optimquery/ http://www.gilev.ru/index/ Чудо-СУБД не существует. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 16:22 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
AriochДегтярев Евгенийсделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей ....а если таски настолько разные, что полей надо мноооого и узко не получается хрень если так, очень даже хрень на до даже в этом случае есть решение зы сорри за резкость, в сибири пятница празднуется во всю ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 17:58 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев ЕвгенийMolochnikСмысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись. сделайте один поток, ответственный за распределение заданий из очереди Дегтярев ЕвгенийMolochnikПо мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно. - не вижу ничего логичного - не вижу усложнения - поделите записи на группы и отдавайте обработчику нужную - время обработки тут вообще причем?Дегтярев ЕвгенийMolochnikЭто фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось. оставим тему про дублирование, я понял что для вас значит усложнение... Опять вернулся к этой задаче и к вашему методу решения. Интересно что у меня примерно так раньше (лет 10 назад) так и работало, когда один поток лазил в базу и создавал очередь заданий в памяти (кэш), к которой уже обращались потоки обработчики, не лазящие в базу. Потом я бросил этот способ, поскольку: 1) кэш иногда переполнялся, если ни одному потоку не нужна была запись долгое время (а может и не вовсе не пригодилась бы), 2) приходилось отслеживать его актуальность, если таблица менялась сторонней программой, 3) иногда нужной записи не было в кэше и поток простаивал. Все это конечно решалось, но выглядело сложно и уродливо, и я бросил этот способ в пользу теперешней схемы. Если рассматривать вариант без кэша, когда данные берутся из таблицы только когда они реально нужны (онлайн), то в чем тогда преимущество одного потока перед несколькими потоками, работающими через критическую секцию? В оверхеде работы критической секции? Это разве не "ловля блох"? Хотя потоков может быть и штук двести. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 00:18 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik3) иногда нужной записи не было в кэше и поток простаивал он так и так будет простаивать, только в вашем случае он будет постоянно долбить БД тяжелым запросом, который ничего не возвращает. MolochnikЕсли рассматривать вариант без кэша, когда данные берутся из таблицы только когда они реально нужны (онлайн), то в чем тогда преимущество одного потока перед несколькими потоками, работающими через критическую секцию? В оверхеде работы критической секции? Это разве не "ловля блох"? Хотя потоков может быть и штук двести. какая выгода, если если все будет упираться во время запроса к БД? я повторюсь, сложно судить не зная деталей зы почему топил за такой вариант один из примеров, есть задача - раздача экономических новостей клиентам по вебсокету данные в памяти, несколько фидов, в каждом по несколько тыс записей, в общей сложности около 50т одни поток раз в секунду читает из новые записи БД с банальным условием where id > lastId далее уже в сервисе решается к какому фиду относится новость, какому клиенту ее отправить (у каждого свои фильтры) данные в памяти позволяют обслуживать запросы чтение отдельных новостей или списков с пагинацией, с учетом фильтров и пр требований за микросекунды, для клиента время обработки запроса = времени пинга в моем случае это еще и легко масштабируется без масштабирования БД зызы мне кажется, что в вашем случае при удачной организации структуры таблиц и индексов можно решить задачу на уровне бд ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2019, 09:55 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Дегтярев Евгений, Жаль в форуме нет кнопки "проблема решена", а то можно было бы нажать. Все сделал как здесь вы и другие советовали: 1) В базу лазит только один поток (супервизор), он регулярно создает небольшую очередь (ThreadList) для чтения для каждого из типов потоков-обработчиков и еще одну - для записи в базу. Типов потоков-обработчиков обычно мало (как правило один). Кэш при любых изменениях базы из сторонней программы очищается. 2) Потоки обработчики работают: берут Item из одной очереди, обрабатывают его и кладут в другую. Поток-супервизор регулярно обновляет базу записывая все изменения в одной транзакции и очищая очередь записи. 3) Аккуратно сгладил все потенциальные затыки и сейчас уже при 10ти потоках этот механизм работает намного веселее а при 200х - вообще небо и земля 4) Также изначально с FB была проблема, что выборка по условию осуществлялась долго, если поле условия (приоритет) находится в отдельной таблице и везде одинаково (В MS SQL этой проблемы не было). Поэтому сделал дополнительное поле в основной таблице выборки, куда и дублирую значение приоритета. Все стало работать идеально: со скоростью сравнимой с MS SQL (всего раза в 2-3 медленннее, а не на 3 порядка на 50 тыс записей). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2019, 13:28 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
вот это поворот ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2019, 12:22 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
2Molochnik, Прочитал все пять страниц взахлеб. Свежо, интригующе. У меня только один вопрос. WTF? Я понимаю, что задача как минимум взломать пентагон, но все же можно доступным языком понять что именно за хрень за шедевр вы автоматизируете? Т.е. именно постановка задачи, а не ваша реализация. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2020, 23:25 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Троглодиты среди нас. =8-[ ] ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2020, 00:23 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Troglodit, там реально было две проблемы. 1) Первая, медленно запрос делался. Сейчас есть свободное время, сделал тесты, урезал базу и запрос до минимума. Вот что получилось: Сама заполненная база - ссылка (ссылка неделю хранится) Медленный запрос: Код: sql 1. 2. 3. 4.
Быстрый запрос по "лишнему полю" Priority, которое оказалось совсем нелишним и с помощью которого я обошел проблему (здесь посоветовали): Код: sql 1. 2. 3. 4.
2) Вторая, много потоков, каждый из которых лазил в базу на чтение и на запись. Работало на небольшом числе потоков, но очень плохо масштабировалось. Если потоков становилось несколько десятков уже довольно сильно тормозило, а если их сотня система вообще становилась неработоспособной. Эту я решил сделав один поток работающим с базой, а остальные потоки работающими с очередями запросов. Вложенный файл таблицы стилей это я просто тесты с форумом проводил - не мог поверить что 150 кб это максимум (архив базы у меня 500 занимает). Причем удалить сылку уже нельзя как я понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2020, 04:26 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik Troglodit, там реально было две проблемы. 1) Первая, медленно запрос делался. Сейчас есть свободное время, сделал тесты, урезал базу и запрос до минимума. Вот что получилось: Сама заполненная база - ссылка (ссылка неделю хранится) Медленный запрос: Код: sql 1. 2. 3. 4.
Быстрый запрос по "лишнему полю" Priority, которое оказалось совсем нелишним и с помощью которого я обошел проблему (здесь посоветовали): Код: sql 1. 2. 3. 4.
2) Вторая, много потоков, каждый из которых лазил в базу на чтение и на запись. Работало на небольшом числе потоков, но очень плохо масштабировалось. Если потоков становилось несколько десятков уже довольно сильно тормозило, а если их сотня система вообще становилась неработоспособной. Эту я решил сделав один поток работающим с базой, а остальные потоки работающими с очередями запросов. Вложенный файл таблицы стилей это я просто тесты с форумом проводил - не мог поверить что 150 кб это максимум (архив базы у меня 500 занимает). Причем удалить сылку уже нельзя как я понял. Это все очень познавательно, но , внезапно, у меня опять 2 вопроса. 1. Зачем вам автор LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId во втором запросе, вы явно не используете contacts, пытаетесь запутать оптимизатор? 2. Что именно тормозит можете по человечески объяснить. 2.1 Это вашe приложение на delphi? может проще воспользоваться готовыми проверенными очередями, которые работают без проблем? По моей памяти с мультитредом в делфи все очень плохо. Вы давно слышали фразу "Гляди какой классный http-сервер, наверно он написан на Delphi"? 2.2 СУБД? крайне странно с учетом малого количества потоков. В мое время птица спокойно держала десятки коннектов в рабочем порядке на железе 15 летней давности. Думаю текущая версия еще лучше. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2020, 00:23 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Troglodit Это все очень познавательно, но , внезапно, у меня опять 2 вопроса. 1. Зачем вам автор LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId 2. Что именно тормозит можете по человечески объяснить. 2.1 Это вашe приложение на delphi? может проще воспользоваться готовыми проверенными очередями, которые работают без проблем? По моей памяти с мультитредом в делфи все очень плохо. Вы давно слышали фразу "Гляди какой классный http-сервер, наверно он написан на Delphi"? 2.2 СУБД? крайне странно с учетом малого количества потоков. В мое время птица спокойно держала десятки коннектов в рабочем порядке на железе 15 летней давности. Думаю текущая версия еще лучше. Ответы 1. Почему не использую? Contacts не используется в тестовом примере, а вообще используется, причем много полей 2. Просто можете проверить выполнение запроса в IBExpert, первый ("медленный") выполняется на этой базе у меня около 200 мс, а второй ("быстрый") - мгновенно. Причем с увеличением числа записей скорость "меленного" падает в геметрической прогрессии. Причем: а) в запросе нет условий и берется всего одна запись (по логике первая попавшаяся) и запрос по идее не должен тормозить б) значение поля приоритета везде одинаковое, но индекс по нему в ActiveTaskContacts очень важен и без него "быстрый" запрос выполняется также медленно. Где то на форуме давно читал что в firebird/interbase по маломеняющемуся полю индексы смысла нет строить. Этот же пример говорит об обратном - индекс точно нужен даже для неменяющегося поля. в) в то же время индекс по полю приоритета в таблице Contacts не влияет на скорость г) в MS SQL скорость выполнения обоих запросов одинаково быстрая и независимая от наличия индексов (быстрее "быстрого" запроса в Firebird раза в три), т.е. именно так и должно быть по логике запроса (достань первую попавшуюся запись) 2.1 Здесь все нормально, в Дельфях сейчас все хорошо и с потоками и параллелелизмом, сам пользуюсь TThread, TThreadList и TParallel когда по смыслу надо. С TThreadedQueue у меня не заладилось, возможностей мало, проще здесь свое было сделать. Сейчас тестировал на ноутбуке 400 потоковую систему, тормозов нет вообще, все идеально работает. 2.2 сейчас использую FB 3.0. Коннекты держит, не падает, это точно, но даже визуально (у меня работа потоков визуализирована) видно что схема с одним потоком "базы" работает на порядок быстрее уже при 10 потоках-обработчиках. При схеме с одним потоком в базу много запросов выполняется в одной траназкции и это сильно ускоряет дело. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2020, 07:45 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik Где то на форуме давно читал что в firebird/interbase по маломеняющемуся полю индексы смысла нет строить. гм, что? Может, не по "маломеняющемуся", а по имеющему сильно мало разных значений относительно количества записей? И то тут ситуации разные бывают, в зависимости от распределения таких значений. Судя по вашим описаниям, вы просто "тыкаете палочкой в Firebird", хотя уже давно можно было разобраться, по статьям и видео. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2020, 12:46 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
если заменить left join на join, то медленный запрос становится быстрым ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2020, 12:50 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
vvvait, а если поставить SSD вместо HDD, то запрос становится еще быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2020, 13:06 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
kdv, Да, имел ввиду поле с малым разнообразием значений, в данном случае их максимальное количество 5 но обычно используется одно ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2020, 15:31 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik Troglodit Это все очень познавательно, но , внезапно, у меня опять 2 вопроса. 1. Зачем вам пропущено... во втором запросе, вы явно не используете contacts, пытаетесь запутать оптимизатор? 2. Что именно тормозит можете по человечески объяснить. 2.1 Это вашe приложение на delphi? может проще воспользоваться готовыми проверенными очередями, которые работают без проблем? По моей памяти с мультитредом в делфи все очень плохо. Вы давно слышали фразу "Гляди какой классный http-сервер, наверно он написан на Delphi"? 2.2 СУБД? крайне странно с учетом малого количества потоков. В мое время птица спокойно держала десятки коннектов в рабочем порядке на железе 15 летней давности. Думаю текущая версия еще лучше. Ответы 1. Почему не использую? Contacts не используется в тестовом примере, а вообще используется, причем много полей 2. Просто можете проверить выполнение запроса в IBExpert, первый ("медленный") выполняется на этой базе у меня около 200 мс, а второй ("быстрый") - мгновенно. Причем с увеличением числа записей скорость "меленного" падает в геметрической прогрессии. Причем: а) в запросе нет условий и берется всего одна запись (по логике первая попавшаяся) и запрос по идее не должен тормозить б) значение поля приоритета везде одинаковое, но индекс по нему в ActiveTaskContacts очень важен и без него "быстрый" запрос выполняется также медленно. Где то на форуме давно читал что в firebird/interbase по маломеняющемуся полю индексы смысла нет строить. Этот же пример говорит об обратном - индекс точно нужен даже для неменяющегося поля. в) в то же время индекс по полю приоритета в таблице Contacts не влияет на скорость г) в MS SQL скорость выполнения обоих запросов одинаково быстрая и независимая от наличия индексов (быстрее "быстрого" запроса в Firebird раза в три), т.е. именно так и должно быть по логике запроса (достань первую попавшуюся запись) 2.1 Здесь все нормально, в Дельфях сейчас все хорошо и с потоками и параллелелизмом, сам пользуюсь TThread, TThreadList и TParallel когда по смыслу надо. С TThreadedQueue у меня не заладилось, возможностей мало, проще здесь свое было сделать. Сейчас тестировал на ноутбуке 400 потоковую систему, тормозов нет вообще, все идеально работает. 2.2 сейчас использую FB 3.0. Коннекты держит, не падает, это точно, но даже визуально (у меня работа потоков визуализирована) видно что схема с одним потоком "базы" работает на порядок быстрее уже при 10 потоках-обработчиках. При схеме с одним потоком в базу много запросов выполняется в одной траназкции и это сильно ускоряет дело. 1. Телепаты в отпуске. Тупая вводная->тупой комментарий. б) маломеняющееся поле, что это за зверь применимый к индексу. Индексу плохо только когда поле имеет мало уникальных значений. в) т.е. в сортировке он не участвует? г) настройки птицы и mssql одинаковые? 2.1 Вы уверены, что делфевая реализация потоков,сервисов не медленная по сравнению с традиционным стэком серверных ЯП? 2.2 А не следует ли скорость 1 поток базы ->10 потоков в ваших терминах,что вы не реализовали коннектпул, и все ваше богатство в скорости, что в каждом потоке вы создаете новый коннект к примеру? "При схеме с одним потоком в базу много запросов выполняется в одной траназкции" Это вообще за гранью моего понимания. Если вы перемешиваете запросы из разных потоков в 1-й транзакции-это феерический выстрел в ногу. Если вам нужна очередь используйте готовые вещи, что умные дядьки не чета нам сирым и убогим написали. И вы удивитесь скорости и надежности. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2020, 16:09 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnikно обычно используется одно если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе. Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2020, 20:35 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
kdv если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе. Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет. Есть и менее очевидные выгоды от индекса по "слабоселективному" полю. Например, есть таблица в 100 полей, одно из которых F и есть "слабоселективное" поле. Нужно часто вычислять select F, count(*). Скан индекс по полю F будет работать быстрее чем скан всех данных таблицы. PS Да, какое-нибудь материализованное агрегатное вью или колоночное хранение выиграют у простого индекса по полю F, но мы же сравниваем варианты с наличием и отсутствием этого индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 13:44 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
msLex, смотря где. В Firebird или не будет или даст очень слабый прирост, если конечно там больше 1 уникального значения. Нету у нас only index scan ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 14:03 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Troglodit б) маломеняющееся поле, что это за зверь применимый к индексу. Индексу плохо только когда поле имеет мало уникальных значений. в) т.е. в сортировке он не участвует? г) настройки птицы и mssql одинаковые? 2.1 Вы уверены, что делфевая реализация потоков,сервисов не медленная по сравнению с традиционным стэком серверных ЯП? 2.2 А не следует ли скорость 1 поток базы ->10 потоков в ваших терминах,что вы не реализовали коннектпул, и все ваше богатство в скорости, что в каждом потоке вы создаете новый коннект к примеру? "При схеме с одним потоком в базу много запросов выполняется в одной траназкции" Это вообще за гранью моего понимания. Если вы перемешиваете запросы из разных потоков в 1-й транзакции-это феерический выстрел в ногу. Если вам нужна очередь используйте готовые вещи, что умные дядьки не чета нам сирым и убогим написали. И вы удивитесь скорости и надежности. б) Это поле (Priority) имеет не мало, а "одно" значение. Индексу может и плохо но запросу хорошо. в) Участвует, в запросе это видно невооруженным взглядом г) fb настройки оптимизированные, ms sql все по умолчанию 2.1 Исходные коды всех дельфийских реализаций присуствуют, там очень быстрый спуск на нижний уровень WinApi, чтото там новое делать это ловить блох 2.2 Да раньше каждый поток создавал полностью независимое соединение по которому соединялся с БД в начале своей работы и отключался в конце. А потоки работали все время работы программы. Так что можно конечно такую реализацию и пулом назвать просто "пулом постоянных соединений". В другом месте у меня переменное число потоков (обработка сетевых запросов) разного времени жизни, там как раз нормальный пул: коннекты по мере надобности создаются и живут своей жизнью. Изредка происходит очистка. Обрабатываеть в одной транзакции данные от разных потоков согласен в общем случае может и не совсем верно. Но в данном случае все хорошо - запросы же одни и же просто с разными параметрами. Если теоретически один запрос завалит всю транзакцию (реально это невозможно) ничего страшного, в следующий раз пройдет. "Умные дядьки" уже придумали вместо критических секций использовать TMonitor, который вроде как быстрее, я туда и не лезу, может и правда быстрее, надежность точно не ниже. Я уже говорил, сейчас все работает близко к идеалу и поэтому вопрос организации монгопоточности меня не так сильно волнует - на ноуте у меня 400 потоков работало почти не напрягая проц. kdv если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе. Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет. Да, значение в поле только одно, по нему сортировка и индекс очень даже нужен оказывается. Так чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить. У меня часто бывает что клиент видит сразу то чего не вижу я, может и здесь так же ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 15:29 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
msLexНужно часто вычислять select F, count(*). Скан индекс по полю F будет работать быстрее чем скан всех данных таблицы. в Firebird такого нет. Индекс содержит все значения всех версий записи (стольбца), но не содержит номеров транзакций, поэтому по индексу нельзя определить, можно конкретной транзакции видеть некий ключ, или нельзя. Определить это можно только читая версию записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 18:43 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikТак чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить если это предложение в мою сторону, то увы - я бесплатно не работаю. Да и вообще, мы оптимизируем системы комплексно, "от 70к руб и полутора месяцев". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 18:46 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
kdv MolochnikТак чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить если это предложение в мою сторону, то увы - я бесплатно не работаю. Да и вообще, мы оптимизируем системы комплексно, "от 70к руб и полутора месяцев". А ясно, значит на форуме просто так, палкой воду мутите. Если вы не заметили, то я вам не работу предлагал, а возможность убедиться в собственной неправоте (или правоте). Но если вам это неинтересно, то мне тем более, можете проходить мимо, просто троглодит заинтересовался, пришлось напрячься. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 19:24 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik kdv пропущено... если это предложение в мою сторону, то увы - я бесплатно не работаю. Да и вообще, мы оптимизируем системы комплексно, "от 70к руб и полутора месяцев". А ясно, значит на форуме просто так, палкой воду мутите. Если вы не заметили, то я вам не работу предлагал, а возможность убедиться в собственной неправоте (или правоте). Но если вам это неинтересно, то мне тем более, можете проходить мимо, просто троглодит заинтересовался, пришлось напрячься. Ну словами-то не бросайся Для того чтобы убедиться совершенно не обязательно скачивать твою базу, ибо с этими двумя запросами и так все ясно А вот насколько именно такие запросы нужны это тебе виднее ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 19:46 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikА ясно, значит на форуме просто так, палкой воду мутите. Если вы не заметили, то я вам не работу предлагал, а возможность убедиться в собственной неправоте (или правоте). у меня несколько другой подход. Я предпочитаю дать системные знания. Например, на сайте есть статья http://www.ibase.ru/dataaccesspaths/ (и другие) про оптимизатор. На ютубе сделали несколько роликов про оптимизатор https://www.youtube.com/user/ibdeveloper/videos ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 20:55 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
MolochnikДа, значение в поле только одно, по нему сортировка и индекс очень даже нужен оказывается. кстати, в чистом виде вот такой вывод - ахинея полная. Потому что сортировать N записей с одним значением в столбце - это пустая трата времени, и индекс тут абсолютно лишний, потому что ключи в этом индексе всё равно одинаковые. На эту тему есть специальное видео и статья http://www.ibase.ru/files/articles/performance/Firebird Optimizer - ORDER vs SORT.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2020, 21:22 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
kdv кстати, в чистом виде вот такой вывод - ахинея полная. Не только вывод. Налицо классический стук в подвале. DDL нет, планов нет, запрос не реальный, а "иллюстративная" вырезка. Наличие бредового индекса на короткой таблице случайно привело к отказу от использования не менее бредового на длинной, вот и вся нЕдолга. Чего можно было добиться и традиционными средствами. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2020, 01:57 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik б) Это поле (Priority) имеет не мало, а "одно" значение. Индексу может и плохо но запросу хорошо. в) Участвует, в запросе это видно невооруженным взглядом г) fb настройки оптимизированные, ms sql все по умолчанию 2.1 Исходные коды всех дельфийских реализаций присуствуют, там очень быстрый спуск на нижний уровень WinApi, чтото там новое делать это ловить блох 2.2 Да раньше каждый поток создавал полностью независимое соединение по которому соединялся с БД в начале своей работы и отключался в конце. А потоки работали все время работы программы. Так что можно конечно такую реализацию и пулом назвать просто "пулом постоянных соединений". В другом месте у меня переменное число потоков (обработка сетевых запросов) разного времени жизни, там как раз нормальный пул: коннекты по мере надобности создаются и живут своей жизнью. Изредка происходит очистка. Обрабатываеть в одной транзакции данные от разных потоков согласен в общем случае может и не совсем верно. Но в данном случае все хорошо - запросы же одни и же просто с разными параметрами. Если теоретически один запрос завалит всю транзакцию (реально это невозможно) ничего страшного, в следующий раз пройдет. "Умные дядьки" уже придумали вместо критических секций использовать TMonitor, который вроде как быстрее, я туда и не лезу, может и правда быстрее, надежность точно не ниже. Я уже говорил, сейчас все работает близко к идеалу и поэтому вопрос организации монгопоточности меня не так сильно волнует - на ноуте у меня 400 потоков работало почти не напрягая проц. kdv если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе. Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет. Да, значение в поле только одно, по нему сортировка и индекс очень даже нужен оказывается. Так чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить. У меня часто бывает что клиент видит сразу то чего не вижу я, может и здесь так же б) вообще непонятно зачем поле с сортировкой,в котором 1 значение. в) ну значит я пацифист, и глаза пацифистские г) Без комментариев, меня еще в школе отучили сравнивать груши и помидоры. 2.1 Без обид, но выбор делфи в таких задачах, это клиническая ошибка. При чем здесь winapi. На нем и бешенной обезъяне пытаются лепить на андроиде и даже вебсервер я когда то видел, но это не отменяет факта, что делфи было не про то. У него до сих пор есть своя очень уже узкая ниша (славься эмбаркадеро), но использовать в бэкенде-это надо очень сильно ненавидеть своих заказчиков. 2.2 " коннекты по мере надобности создаются и живут своей жизнью"-это не коннекшнпул, у вас беда с матчастью. "Умные дядьки"-это те кто юзает HighLoad, а не пинает труп мертвой коровы. Я что то не слышал про классный софт с очередями на делфи. Почему же каффка, rabitmq не на делфи. Странно. Ваш идеал, это повышенное ЧСВ, если вам так важны потоки, с оговорками посмотрите сколько котлин корутин вам выдаст, будете долго думать. На реальных данных, в 100-500гб вас ждет еще много открытий, когда ваше волшебное приложение превратиться в тыкву. У меня давно был случай. В одну контору много лет назад принудительно заставили внедрить софт от очередного гения, угадайте на каком языке этот софт был. У него все летало. На нашем объеме данных, все умерло так и не родившись, в итоге программу поставили, под ковер ее зачистили, галочку поставили и выдохнули. Зачем наезжать на kdv? Он уже забыл то, что мы может быть узнаем. :) Вы хоть узнайте на кого вы бросаетесь. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 01:02 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Troglodit делфи было не про то. У него до сих пор есть своя очень уже узкая ниша (славься эмбаркадеро), но использовать в бэкенде-это надо очень сильно ненавидеть своих заказчиков. авторкотлин Ахаха, опускать Дельфи и восхвалять надстройку над Джавой для бэкенда - это сильно! ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 10:23 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Василий 2 Ахаха, опускать Дельфи и восхвалять надстройку над Джавой для бэкенда - это сильно! У вас видимо пятница пораньше началась. Где я восхвалял котлин? И почему нельзя использовать JVM-языки на бэкенде можете просветить? И кто сказал, что Kotlin надстройка над java? Kotlin (Ко́тлин) — статически типизированный язык программирования, работающий поверх JVM и разрабатываемый компанией JetBrains. Также компилируется в JavaScript и в исполняемый код ряда платформ через инфраструктуру LLVM. * Делфи я не опускал, он более чем мертв очень давно, просто по медицинским показателям формально еще жив. Что для меня прискорбно. * ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 17:09 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
24.01.2020 17:09, Troglodit пишет: > > И почему нельзя использовать JVM-языки на бэкенде можете просветить? потому, что ГОВНО. сужу по Oracle SQL Developer. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 17:16 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Мимопроходящий 24.01.2020 17:09, Troglodit пишет: > > И почему нельзя использовать JVM-языки на бэкенде можете просветить? потому, что ГОВНО. сужу по Oracle SQL Developer. Вы точно про бэкенд, а не фронт говорите? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 17:20 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Симонов Денис msLex, смотря где. В Firebird или не будет или даст очень слабый прирост, если конечно там больше 1 уникального значения. Нету у нас only index scan Упс... Будем считать что я писал только про SQL Server ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 18:16 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
kdv в Firebird такого нет. Индекс содержит все значения всех версий записи (стольбца), но не содержит номеров транзакций, поэтому по индексу нельзя определить, можно конкретной транзакции видеть некий ключ, или нельзя. Определить это можно только читая версию записи. Понятно, спасибо за инфу. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 18:17 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Troglodit б) вообще непонятно зачем поле с сортировкой,в котором 1 значение. я же его не сделал его уникальным, пусть одно значение будет Troglodit г) Без комментариев, меня еще в школе отучили сравнивать груши и помидоры. задача то одна - сохранить много и быстро достать одно, впрочем как и у груш с помидорами Troglodit 2.1 Без обид, но выбор делфи в таких задачах, это клиническая ошибка Странно, но у меня все работает и быстро, кастомеров устраивает. Но правда бэкэнд использует не только дельфи, там скорее мидлэнд (клиенты, база, потоки), нижняя часть чисто сишная. С потоками я уже сказал проблем пока нет, возможно появятся с обработкой многих клиентов если их будет несколько сотен одновременно, но такого пока не было, поэтому по индукции считаем что такого не бывает никогда. Troglodit Зачем наезжать на kdv? Он уже забыл то, что мы может быть узнаем. :) да признаю, грубовато выразился, но на этом форуме это в порядке вещей, как я понял, все богатые, самодостаточные и поэтому никто не обижается. Troglodit Вы хоть узнайте на кого вы бросаетесь. :) Смысла нет - тут айкью форума зашкаливает. Я тоже не лыком шит - в детстве Олимпиаду городскую по физике выиграл! ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2020, 11:35 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
Molochnik я же его не сделал его уникальным, пусть одно значение будет задача то одна - сохранить много и быстро достать одно, впрочем как и у груш с помидорами Странно, но у меня все работает и быстро, кастомеров устраивает. Но правда бэкэнд использует не только дельфи, там скорее мидлэнд (клиенты, база, потоки), нижняя часть чисто сишная. С потоками я уже сказал проблем пока нет, возможно появятся с обработкой многих клиентов если их будет несколько сотен одновременно, но такого пока не было, поэтому по индукции считаем что такого не бывает никогда. да признаю, грубовато выразился, но на этом форуме это в порядке вещей, как я понял, все богатые, самодостаточные и поэтому никто не обижается. Смысла нет - тут айкью форума зашкаливает. Я тоже не лыком шит - в детстве Олимпиаду городскую по физике выиграл! 1. Ответ достойный Сократа. 2. Сохранить много и быстро и наверно еще надо добавлять надежно, это каффка, а не ваш велосипед. Но судя по тому, что вы описывали ранее объем данных у вас очень малый, поэтому каффка-это как микроскопом забивать гвозди, но то, что вы собственные костыли внедряете клиентам вместо устоявшихся,проверенных инструментов-это просто показатель вашей квалификации, вашей ответственности перед клиентами. 3. Есть и еще одна часть самописная часть, уже на си. Прэлестно, просто прэлестно. Я уже выше писал, как только пойдут объемы данных ваш софт превратиться в тыкву, особенно будет интересно когда ресурсов на сервере перестанет хватать. 5. Смысл всегда есть осмотреться, чтобы понять кто есть ваш собеседник. Но это видимо только участь моего поколения. Я уверен, что ваш зоопарк технологий в данном случае как то работает, но для эксплуатации это ад. Вы внедрили и уехали в другой город/страну/галактику, а потом кто то будет разгребать ваш шедевральный софт. Скорее всего дело закончиться тем, что ваше поделие аккуратно выпилят и сделают как положено, но ваш клиент потеряет время и деньги. Дальше не вижу смысла со своей стороны вмешиваться в дискуссию. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2020, 00:11 |
|
Firebird vs MS SQL
|
|||
---|---|---|---|
#18+
WildSery Так-с, горячие парни. Попрошу! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2020, 17:58 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1560461]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
73ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
184ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 308ms |
0 / 0 |