Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Скорость работы БД в приложении
Форум на CrossPlatform.RU > Библиотеки > Qt > Qt Разработка баз данных
AD
Для более быстрого создания файла топографической библиотеки (бинарный файл, в котором хранится содержимое нескольких (многих) карт) определенного формата решено было использовать в качестве промежуточного варианта хранения данных БД. Проблема состоит в том, что после реализации этого подхода выяснилось, что вставка, изменение и выборка из таблиц СУЩЕСТВЕННО замедляет задачу, а не ускоряет ее. Как можно решить данную проблему? Заранее спасибо за подсказку! Как только я комментирую строчки, делающие выборку и внесение данных в таблицы - тут же скорость работы возрастает в разы.
abc
субды быстро работают, сами запросы должны быть, в общем, мгновенны.
или я не сталкивался с гигантским количеством данных.. у тебя гигантское?)
AD
Цитата(abc @ 18.3.2011, 11:06) *
субды быстро работают, сами запросы должны быть, в общем, мгновенны.
или я не сталкивался с гигантским количеством данных.. у тебя гигантское?)

Десятки тысяч, возможно и сотни. Может быть из-за того, что использую Paradox? Если перейти на QSQL-Lite будет лучше?
abc
не знаю, я работаю с PostgreSql
я не работал с таким количеством строк
но, скажем, выборку из таблицы ты можешь задать сложную, где надо будет просмотреть все строки, сравнить тексты.. что-нибудь в этому духе. но вставка и изменение (поиск по уникальному ключу?) медленной быть не должна. кстати, медленно это сколько?
AD
Цитата(abc @ 18.3.2011, 13:17) *
не знаю, я работаю с PostgreSql
я не работал с таким количеством строк

В другом приложении я работал с Microsoft Sql Server. Никаких проблем не было. Тоже было немало строчек.


Цитата(abc @ 18.3.2011, 13:17) *
медленной быть не должна. кстати, медленно это сколько?

Да блин, у меня уже вставка в таблицы идет 2.5 часа. Это ненормально.
Запросы выборки не очень-то и сложные. Выбираем id из одной таблицы, по этим id выбираем что-то из другой таблицы и тому подобные.
abc
это стопудовый нонсенс. а почему взялся за Paradox? вроде бы не очень популярная штука
AD
Цитата(abc @ 18.3.2011, 14:28) *
это стопудовый нонсенс. а почему взялся за Paradox? вроде бы не очень популярная штука

Да сказали, что желательно его использовать. Ладно, сейчас попробую перейти на SQLite. Надеюсь, такой шизни не будет.
Kagami
Иногда работу СУБД сильно заменяют транзакции - с тем же SQLite они выполняются для каждой операции автоматически. Часто можно сильно ускорить работу если начинать транзакции вручную и завершать после выполнения всех (ну или части, если их можно сгруппировать логически) операций.
AD
Цитата(Kagami @ 18.3.2011, 17:45) *
Иногда работу СУБД сильно заменяют транзакции - с тем же SQLite они выполняются для каждой операции автоматически. Часто можно сильно ускорить работу если начинать транзакции вручную и завершать после выполнения всех (ну или части, если их можно сгруппировать логически) операций.

Замедляют в смысле?
А как к примеру это сделать, т.е. запускать и завершать транзакции вручную?

Да читаю ассистент. Возник такой вопрос - могу использовать QSqlTableModel при работе с QSQLite?
abc
можешь, почему нет
Kagami
Цитата(AD @ 18.3.2011, 17:54) *
Замедляют в смысле?
А как к примеру это сделать, т.е. запускать и завершать транзакции вручную?
Пусть тебе надо сделать 5 операций вставки. По-умолчанию для каждой операции будет сделана своя транзакция (причем автоматически), т.е. QSqlDatabase::beginTransaction(); QSqlQuery::exec("..."); QSqlDatabase::commit(); ...
А теперь представь что у тебя таких операций в разы больше. При этом для каждой транзакции тот же QSqlLite создает журнал, а фактически - файл на жестком диске.
А если начать транзакцию самому (с помощью явного вызова QSqlDatabase::beginTransaction()), выполнить все свои запросы, а затем завершить ее, то все будет работать быстрее.
Litkevich Yuriy
Цитата(AD @ 18.3.2011, 13:12) *
Если перейти на QSQL-Lite будет лучше?
быстрее попробовать, чем ждать ответа
AD
Цитата(Kagami @ 18.3.2011, 20:59) *
Пусть тебе надо сделать 5 операций вставки. По-умолчанию для каждой операции будет сделана своя транзакция (причем автоматически), т.е. QSqlDatabase::beginTransaction(); QSqlQuery::exec("..."); QSqlDatabase::commit(); ...
А теперь представь что у тебя таких операций в разы больше. При этом для каждой транзакции тот же QSqlLite создает журнал, а фактически - файл на жестком диске.
А если начать транзакцию самому (с помощью явного вызова QSqlDatabase::beginTransaction()), выполнить все свои запросы, а затем завершить ее, то все будет работать быстрее.

Ясно, спасибо. При работе с SQLite буду иметь в виду. Пока еще на Paradox. Посмотрел с помощью hasFeature() поддерживает ли мой драйвер Paradox транзакции и увидел, что не поддерживает.
AD
Кто-нибудь еще может подсказать, как увеличить скорость работы запросов? СУБД - Paradox. Переход на SQLite не удался в связи с проблемой транзакций. По каким причинам время работы запроса составляет несколько секунд?
Iron Bug
а что в SQLite с транзакциями? по-моему, там не было проблем с ними.
я работала с SQLite - держит очень приличную скорость. я сливала данные очень быстро, и они ещё читались другой софтиной. проблем не было.
но лучше транзакции начинать вручную, как уже написали выше и сливать порциями, чтобы обращение к винту было не слишком частым.
и ещё у SQLite есть две фичи:
1. когда база становится жирнее 300 метров (это под вендой я работала), он начинает иногда глючить при вставке записей (возвращает SQLITE_CORRUPT. они про эту ошибку знают, но вроде пока не исправили). я не уверена, что этот предел зависит именно от размера базы, а не от количества записей. у меня их там были сотни тысяч. но, в принципе, я решила проблему созданием нового файла базы после накопления этого объёма. но если база не может быть разделена на куски и она больше 300 метров - то это может быть проблемой.
2. у него есть несколько настроек, которые позволяют ускорять работу с базой:
  PRAGMA synchronous=OFF;
  PRAGMA count_changes=0;
  PRAGMA journal_mode=OFF;

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

P.S. я пользовалась стандартным интерфейсом SQLite. сама QT тоже может отъесть сколько-то времени, но не думаю, что разница будет существенной.
Litkevich Yuriy
я месяц назад пользовал небольшую (по мегабайтам) SQLite БД, у меня было: вставка без транзакции > 13 сек. Вставка с транзакцией <1 сек.
Iron Bug
Цитата(Litkevich Yuriy @ 1.4.2011, 22:48) *
я месяц назад пользовал небольшую (по мегабайтам) SQLite БД, у меня было: вставка без транзакции > 13 сек. Вставка с транзакцией <1 сек.

транзакция позволяет делать откаты и либо ты не коммитил (данные не сливались реально, а хранились в памяти), либо что-то неправильно делал. потому что с отдельными транзакциями на каждую запись обращение к базам всегда медленнее.
кстати, вставка 13 секунд - это тоже что-то нездоровое. хотя, наверное смотря какой объём. у меня наоборот была задача: довольно мелкие записи, но очень быстро: примерно 30 записей (в разные таблицы, со связями) каждые 50миллисекунд. за час эта хрень отъедала чуть больше гигабайта на винте (но база была поделена на куски по 300 метров) и всё работало на ура и ни грамма не грузило ни проц, ни память, ни винт. при этом параллельно пользователь работал с софтиной, в которой он просматривал и сортировал выборки из данных. и даже при выборках в сотни тысяч записей ничего не тормозило. хотя юзерский интерфейс, конечно, отъедал больше ресурсов. но там ещё на каждую запись отрисовка шла и скорее всего, поэтому. сами обращения к базе не так много брали. в худших случаях ну секунд 5. но это уж когда вообще открывался один целый файл в 300 метров с хитрожопой сортировкой.
Litkevich Yuriy
Цитата(Iron Bug @ 1.4.2011, 23:06) *
потому что с отдельными транзакциями на каждую запись обращение к базам всегда медленнее.
Цитата(Litkevich Yuriy @ 1.4.2011, 22:48) *
вставка без транзакции > 13 сек. Вставка с транзакцией
я использовал одну
AD
Повторюсь. Проблема со скоростью - на Paradox, на SQLite вообще не удавалось записи в таблицу вставить. Даже не знаю почему... Либо он создавал в памяти образ БД, либо еще что-то. Т.е. запись вставлялась, но как только перезапускал приложение, все оставалось по прежнему... commit транзакци не срабатывал. До скорости в SQLite не успел добраться!
Iron Bug
я не раз сталкивалась с SQLite, на предыдущей работе мы тоже её использовали. проблем не было и всё работало. это отличная база для локального использования. лёгкая и быстрая. но мы использовали их родной API, без всяких там оболочек. у них очень простые API-функции и освоение занимает от силы пару дней. я не могу сказать, почему что-то не срабатывало у других, но это точно не проблема SQLite. коммиты и транзакции там работают, как и всё прочее.
AD
Цитата(Iron Bug @ 2.4.2011, 18:16) *
я не раз сталкивалась с SQLite, на предыдущей работе мы тоже её использовали. проблем не было и всё работало. это отличная база для локального использования. лёгкая и быстрая. но мы использовали их родной API, без всяких там оболочек. у них очень простые API-функции и освоение занимает от силы пару дней. я не могу сказать, почему что-то не срабатывало у других, но это точно не проблема SQLite. коммиты и транзакции там работают, как и всё прочее.

Наверное поэтому вопрос данный помимо SQLite затрагивает и Qt. Он потому и задан в разделе Qt. В данном топике меня интересует из-за чего возможны проблемы со скоростью при вставках в таблицы? данная проблема существует при работе с Paradox. Предполагаю, что скорость при работе с SQLite будет не много выше.
Iron Bug
это в любом случае наздоровые задержки.
может, у тебя база такая кривая или запрос? какой-нибудь индекс поставлен на огромное бинарное поле, например? и он считается долго. или что-то подобное.
AD
Цитата(Iron Bug @ 4.4.2011, 20:16) *
это в любом случае наздоровые задержки.

Согласен. Задержки безумно большие. Это неудобно.

Цитата(Iron Bug @ 4.4.2011, 20:16) *
может, у тебя база такая кривая или запрос? какой-нибудь индекс поставлен на огромное бинарное поле, например? и он считается долго. или что-то подобное.

Да вряд ли БД кривая. Схему БД придумал человек, у которого уже есть подобный опыт, в принципе. Индексов вообще нет. Поля, как правило, или строковые, или целочисленные, или вещественные (типа double). Одна табличка содержит поля данных BLOB для хранения картинок, но ее я пока даже не заполнял.
Запросы все подобного плана:
upd_query.prepare("update ScriptLayer set LayerNameId = ? where ScriptItemId = ?");
ins_query.prepare("insert into ScriptLayer(ScriptItemId, LayerNameId) values(?, ?)");
sel_query.prepare(QString("select LayerNameId from ScriptLayer where ScriptItemId = %1 "
                        "and LayerNameId = -1").arg(script_row_index));
Iron Bug
ну, на вид вроде вообще примитив, совершенно ничего особенного. вероятно, есть какие-то тонкости в интерфейсе со стороны Qt. может, тормозит графика, если она навешана на запрос (отрисовки гридов и т.п.)
вообще, базы имеют т.н. синхронизацию: когда при каждом чтении база проверяется на то, что у неё сохранены все последние изменения. это нужно в случае, когда два приложения пишут в базу или когда обязательно считывать прямо самое последнее состояние базы каждый раз. если это не требуется, то это можно отключить и обычно работает быстрее, но я не в курсе, есть ли синхронизация у Paradox'а.
но если база небольшая, то даже с синхронизацией так тормозить не должно. это какие-то запредельные тормоза. может, проблемы с потоками? никто не блокирует ресурсы во время обращения к базе?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2021 IPS, Inc.