SQLite в Java: способы оптимизировать мои запросы, чтобы они быстрее возвращались?

Question

Я создаю приложение на Java, которое использует SQLite для хранения и поиска данных в базе данных.

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

Справочная информация: Мое приложение Java анализирует файлы .PDF с помощью библиотеки, которая может преобразовывать необработанный текст из файлов PDF в StringWriter. Затем я анализирую полученные данные и получаю информацию, необходимую для создания новых строк в моей базе данных. Тем не менее, полученные таблицы очень большие, так как существует около 900 PDF-файлов для анализа. Просто чтобы дать вам представление о том, насколько велик я говорю, одна таблица заканчивается примерно 145000 строками, другая - 1550 строками, а другие (3 или 4 других таблицы) - между 75 и 750 строками.

Все работает нормально, но я не уверен, смогу ли я уменьшить необходимое время для создания таблиц и прочего. До сих пор на моем ноутбуке все создавалось с первого раза за 41 минуту (хотя все запускается с USB-накопителя ... Я опробую его на жестком диске позже). Повторный запуск занимает 1,5 минуты, так как он проверяет, был ли файл уже проанализирован, и не создает заново все. Мне не нужно, чтобы это было ОГРОМНОЕ улучшение, так как в идеале я бы запускал эту программу только один раз в неделю примерно с 30 файлами или около того, но все же мне интересно, почему это так медленно с 900 файлами; если это код, который медленно анализирует файлы, или это плохая практика с моей стороны в части SQLite. (Я тестирую его со всеми файлами, созданными за последний год, поэтому у меня их так много)

Итак, каковы лучшие практики для повышения производительности с SQLite в Java? Будет ли заметна разница, если установить autocommit в false и выполнить коммит только после того, как все будет создано? Есть ли способ создания операторов или проверки, если данные уже существуют более эффективным способом?

У меня нет с собой кода, но запросы выглядят примерно так:

public static void insertScores(String league, int playerID, int score, String date)
{
  PreparedStatement ps = new PreparedStatement("INSERT INTO Scores(?,?,?,?)");

  ps.setString(1, league);
  [...]
  ps.executeUpdate();
}

В других запросах я проверяю, существует ли строка, используя что-то вроде этого:

public static void insertScores(int playerID)
{
  ResultSet rs = null;
  PreparedStatement ps = new PreparedStatement("SELECT * FROM Scores WHERE ID = ?");

  ps.setInt(1, playerID);

  rs = ps.executeQuery();

  if(!rs.next())
  {
     [code like in the first example]
  }
}

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

Просто увидев эти примеры и прочитав то, что я должен был сказать, кто-нибудь знает, как повысить производительность моих операторов SQL?

Answer 1

Два предложения:

1) Получить профилировщик. Вы можете догадаться, что делает ваш код медленным, или вы можете просто профилировать его и знать, что делает его медленным.

2) Поскольку ваши данные находятся на медленном устройстве, вы хотите читать / писать как можно меньше. SELECT * возвращает весь ряд, но тогда вы просто проверяете существование. Попробуйте SELECT ID, для чего нужно будет прочитать только одно число.

Answer 2

Сколько записей в Scores будет иметь одинаковый идентификатор игрока? Если этого достаточно, попробуйте определить наличие определенного идентификатора игрока в следующем виде:

select 1 where exists(select 1 from scores where id = ?)

или аналогичный. Я не знаком с диалектом SQL, используемым в SQLite, но этот подход обычно помогает ускорить дальнейшие вычисления при обнаружении первой записи с указанным playerID.

Answer 3

USB-флешки имеют ужасную производительность, когда вы делаете много небольших обновлений.Flash должен прочитать весь блок в буфер, обновить его соответствующую часть, стереть блок и затем записать обратно буфер .(У SSD есть логика, чтобы немного облегчить это.)

Переместите данные на жесткий диск и посмотрите, поможет ли это.