RXL...пробовал на объемах порядка 2 ГБ, 8 млн. строк...

У вас типичная небольшая база, обычно на таких объемах ничего и оптимизировать-то не надо. Если есть конкретные проблемы/вопросы - озвучьте их.

RXL,

См. параметры моей сборки, например. Страница, скажем, 8к разумнее для "типичных" применений и т.д. Тесты и заметки есть у меня в блоге
http://geomapx.blogspot.com/search?q=sqlite
Патчи и модули см. в моем репозитории
http://sqlite.mobigroup.ru/

Ну и плюс еще море всего в сети найдется, и в рассылке sqlite-users немало интересного проскакивает. Оптимизация же БД зависит от очень многих вещей - например, чтобы быстро работать с базой в десятки и сотни гиг, придется архитектуру приложения соответствующую делать, если же у вас пара гигабайт - вероятно, достаточно выставить разумные прагмы (дисковая страница, кэш, версия формата БД) и, при необходимости конкурентности, включить режим WAL.

На тему выбора размера дисковой страницы интересно посмотреть "Internal Versus External BLOBs in SQLite":

http://www.sqlite.org/intern-v-extern-blob.html

Учтите, что для других сценариев использования результаты несколько отличаются (как правило, выбор все равно стоит между страницами 4к/8к/16к).

RXLЕсть, кстати, у меня оракловая база с картинками: размер 9 ГБ, около 100 тыс. строк. Если не надоест, сделаю тесты и для BLOB-ов.

Если уж тестировать, то при размере базы, более чем в 10 раз превышающем объем ОЗУ. Я тестировал на 100М записей по 1к и 100к записей по 1М - то есть в обоих случаях размер базы 100Гб+, данные генерировались случайным образом. Для задач чтения и записи - оптимальны разные дисковые страницы, разумный компромисс был равен 8к.

Вставка миллиарда записей только с PK не дает измеримой деградации скорости, с обычным индексом - зависит от данных, часто есть неприемлемая для больших баз деградация скорости вставки (с выборками все ок), с FTS индексом - нет деградации вставки, но на 435М записей вылетал сегфолт (думаю, что баг я тогда нашел и сейчас все будет ок, но этот тест я не повторял). На десктопном железе - до 50М особых проблем нет, если воткнете SSD (кардинально уменьшает время модификации индексов при вставке) - то и сотни миллионов записей обработаете. С год назад я репортил баг, возникающий при некоторых условиях для баз более 5Гб размером (сейчас соответствующий тест есть в апстриме), так что сильно старые версии SQLite для таких баз не стоит брать.

RXLИзвестно же, что много-много быстрее удалить индексы, залить данные и после создать индексы заново.

Не везде и не всегда! В эскулайт такая оптимизация сделана только в последнем релизе, см.
http://www.sqlite.org/draft/releaselog/3_7_8.html

Если тестировать эскулайт именно как бэкенд хранения - до миллиарда записей все хорошо :) Деградация скорости вставки возникает только из-за индексов и может быть заметна уже на десятке миллионов записей. Чувствуете разницу? Так что без индексов тестировать смысла мало.

RXLMBG,

Кстати, на счет поиска по индексам. Как я прочитал в доках, уровень дерева у SQLite фиксированный: root page -> internal pages (interior pages) -> leafs. Появляются overflow страницы (цепочки страниц на одном уровне), но сам уровень косвенности не растет. Т.е. при больших количествах строк (от 10^6) не должно быть большой разницы в скорости поиска между смежными порядками. Особенно если индекс организованный. Хорошо бы придумать тест для проверки. У вас нет идей на этот счет?

А чем не устраивают тесты, выложенные в моем блоге? Вот тестирование скорости индексной выборки на таблицах 1М, 10М, 100М записей:
Тестирование SQLite 3.6.17-mobigroup.2 на больших таблицах

А вот другая сторона проблемы - скорость вставки:
Degradation of indexing speed in SQLite 3.6.20
Как видим, индексирование большой таблицы могло быть проблемой до выхода последнего релиза.

RXLMBG,

Читается плохо и там показаны только значения user и system, но не полное время, куда входит ожидание IO.
...


В данном случае не используется ни IO ни CPU, и здесь вовсе нет "ожидание IO". Замерять время простоя - бессмысленно, но, если хотите, никто не мешает делать