Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Форум на CrossPlatform.RU _ Qt Разработка баз данных _ Скорость работы БД в приложении

Автор: AD 18.3.2011, 10:38

Для более быстрого создания файла топографической библиотеки (бинарный файл, в котором хранится содержимое нескольких (многих) карт) определенного формата решено было использовать в качестве промежуточного варианта хранения данных БД. Проблема состоит в том, что после реализации этого подхода выяснилось, что вставка, изменение и выборка из таблиц СУЩЕСТВЕННО замедляет задачу, а не ускоряет ее. Как можно решить данную проблему? Заранее спасибо за подсказку! Как только я комментирую строчки, делающие выборку и внесение данных в таблицы - тут же скорость работы возрастает в разы.

Автор: abc 18.3.2011, 11:06

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

Автор: AD 18.3.2011, 11:12

Цитата(abc @ 18.3.2011, 11:06) *
субды быстро работают, сами запросы должны быть, в общем, мгновенны.
или я не сталкивался с гигантским количеством данных.. у тебя гигантское?)

Десятки тысяч, возможно и сотни. Может быть из-за того, что использую Paradox? Если перейти на QSQL-Lite будет лучше?

Автор: abc 18.3.2011, 13:17

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

Автор: AD 18.3.2011, 14:03

Цитата(abc @ 18.3.2011, 13:17) *
не знаю, я работаю с PostgreSql
я не работал с таким количеством строк

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


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

Да блин, у меня уже вставка в таблицы идет 2.5 часа. Это ненормально.
Запросы выборки не очень-то и сложные. Выбираем id из одной таблицы, по этим id выбираем что-то из другой таблицы и тому подобные.

Автор: abc 18.3.2011, 14:28

это стопудовый нонсенс. а почему взялся за Paradox? вроде бы не очень популярная штука

Автор: AD 18.3.2011, 14:42

Цитата(abc @ 18.3.2011, 14:28) *
это стопудовый нонсенс. а почему взялся за Paradox? вроде бы не очень популярная штука

Да сказали, что желательно его использовать. Ладно, сейчас попробую перейти на SQLite. Надеюсь, такой шизни не будет.

Автор: Kagami 18.3.2011, 17:45

Иногда работу СУБД сильно заменяют транзакции - с тем же SQLite они выполняются для каждой операции автоматически. Часто можно сильно ускорить работу если начинать транзакции вручную и завершать после выполнения всех (ну или части, если их можно сгруппировать логически) операций.

Автор: AD 18.3.2011, 17:54

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

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

Да читаю ассистент. Возник такой вопрос - могу использовать QSqlTableModel при работе с QSQLite?

Автор: abc 18.3.2011, 20:51

можешь, почему нет

Автор: Kagami 18.3.2011, 20:59

Цитата(AD @ 18.3.2011, 17:54) *
Замедляют в смысле?
А как к примеру это сделать, т.е. запускать и завершать транзакции вручную?
Пусть тебе надо сделать 5 операций вставки. По-умолчанию для каждой операции будет сделана своя транзакция (причем автоматически), т.е. QSqlDatabase::beginTransaction(); QSqlQuery::exec("..."); QSqlDatabase::commit(); ...
А теперь представь что у тебя таких операций в разы больше. При этом для каждой транзакции тот же QSqlLite создает журнал, а фактически - файл на жестком диске.
А если начать транзакцию самому (с помощью явного вызова QSqlDatabase::beginTransaction()), выполнить все свои запросы, а затем завершить ее, то все будет работать быстрее.

Автор: Litkevich Yuriy 18.3.2011, 22:55

Цитата(AD @ 18.3.2011, 13:12) *
Если перейти на QSQL-Lite будет лучше?
быстрее попробовать, чем ждать ответа

Автор: AD 18.3.2011, 22:56

Цитата(Kagami @ 18.3.2011, 20:59) *
Пусть тебе надо сделать 5 операций вставки. По-умолчанию для каждой операции будет сделана своя транзакция (причем автоматически), т.е. QSqlDatabase::beginTransaction(); QSqlQuery::exec("..."); QSqlDatabase::commit(); ...
А теперь представь что у тебя таких операций в разы больше. При этом для каждой транзакции тот же QSqlLite создает журнал, а фактически - файл на жестком диске.
А если начать транзакцию самому (с помощью явного вызова QSqlDatabase::beginTransaction()), выполнить все свои запросы, а затем завершить ее, то все будет работать быстрее.

Ясно, спасибо. При работе с SQLite буду иметь в виду. Пока еще на Paradox. Посмотрел с помощью hasFeature() поддерживает ли мой драйвер Paradox транзакции и увидел, что не поддерживает.

Автор: AD 1.4.2011, 16:41

Кто-нибудь еще может подсказать, как увеличить скорость работы запросов? СУБД - Paradox. Переход на SQLite не удался в связи с проблемой транзакций. По каким причинам время работы запроса составляет несколько секунд?

Автор: Iron Bug 1.4.2011, 17:27

а что в 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 1.4.2011, 19:48

я месяц назад пользовал небольшую (по мегабайтам) SQLite БД, у меня было: вставка без транзакции > 13 сек. Вставка с транзакцией <1 сек.

Автор: Iron Bug 1.4.2011, 20:06

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

транзакция позволяет делать откаты и либо ты не коммитил (данные не сливались реально, а хранились в памяти), либо что-то неправильно делал. потому что с отдельными транзакциями на каждую запись обращение к базам всегда медленнее.
кстати, вставка 13 секунд - это тоже что-то нездоровое. хотя, наверное смотря какой объём. у меня наоборот была задача: довольно мелкие записи, но очень быстро: примерно 30 записей (в разные таблицы, со связями) каждые 50миллисекунд. за час эта хрень отъедала чуть больше гигабайта на винте (но база была поделена на куски по 300 метров) и всё работало на ура и ни грамма не грузило ни проц, ни память, ни винт. при этом параллельно пользователь работал с софтиной, в которой он просматривал и сортировал выборки из данных. и даже при выборках в сотни тысяч записей ничего не тормозило. хотя юзерский интерфейс, конечно, отъедал больше ресурсов. но там ещё на каждую запись отрисовка шла и скорее всего, поэтому. сами обращения к базе не так много брали. в худших случаях ну секунд 5. но это уж когда вообще открывался один целый файл в 300 метров с хитрожопой сортировкой.

Автор: Litkevich Yuriy 2.4.2011, 9:21

Цитата(Iron Bug @ 1.4.2011, 23:06) *
потому что с отдельными транзакциями на каждую запись обращение к базам всегда медленнее.
Цитата(Litkevich Yuriy @ 1.4.2011, 22:48) *
вставка без транзакции > 13 сек. Вставка с транзакцией
я использовал одну

Автор: AD 2.4.2011, 14:13

Повторюсь. Проблема со скоростью - на Paradox, на SQLite вообще не удавалось записи в таблицу вставить. Даже не знаю почему... Либо он создавал в памяти образ БД, либо еще что-то. Т.е. запись вставлялась, но как только перезапускал приложение, все оставалось по прежнему... commit транзакци не срабатывал. До скорости в SQLite не успел добраться!

Автор: Iron Bug 2.4.2011, 17:16

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

Автор: AD 3.4.2011, 12:59

Цитата(Iron Bug @ 2.4.2011, 18:16) *
я не раз сталкивалась с SQLite, на предыдущей работе мы тоже её использовали. проблем не было и всё работало. это отличная база для локального использования. лёгкая и быстрая. но мы использовали их родной API, без всяких там оболочек. у них очень простые API-функции и освоение занимает от силы пару дней. я не могу сказать, почему что-то не срабатывало у других, но это точно не проблема SQLite. коммиты и транзакции там работают, как и всё прочее.

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

Автор: Iron Bug 4.4.2011, 19:16

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

Автор: AD 5.4.2011, 8:32

Цитата(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 5.4.2011, 17:52

ну, на вид вроде вообще примитив, совершенно ничего особенного. вероятно, есть какие-то тонкости в интерфейсе со стороны Qt. может, тормозит графика, если она навешана на запрос (отрисовки гридов и т.п.)
вообще, базы имеют т.н. синхронизацию: когда при каждом чтении база проверяется на то, что у неё сохранены все последние изменения. это нужно в случае, когда два приложения пишут в базу или когда обязательно считывать прямо самое последнее состояние базы каждый раз. если это не требуется, то это можно отключить и обычно работает быстрее, но я не в курсе, есть ли синхронизация у Paradox'а.
но если база небольшая, то даже с синхронизацией так тормозить не должно. это какие-то запредельные тормоза. может, проблемы с потоками? никто не блокирует ресурсы во время обращения к базе?

Форум Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)