Hello! On Tuesday 09 February 2010 23:42:08 Serhiy Storchaka wrote: > > Десятикратная разница в скорости показывает проблему реализации. Но все > > равно непосредственно сам поиск как минимум на два порядка быстрее, нежели > > построение фрагмента с найденным текстом. > > Это вы тестируете когда база закеширована в памяти? На стогигабайтной базе с > случайным запросом результаты будут несколько отличаться.
Поскольку эскулайт - файловая СУБД, то _умеет_ работать с данными, не кэшируя всю базу или значительную ее часть в ОЗУ. Стогиговую базу я тестировал много лет назад, когда еще только начинал работать с эскулайт, и скорость выборки записи по ключу была весьма высокой (на машинке с 1 Гб ОЗУ, точных цифр сейчас просто не помню). Проблемы есть при заполнении больших таблиц (неоптимальная работа с индексами), а с выборками все хорошо. См. один из тестов здесь: http://geomapx.blogspot.com/2010/01/sqlite-fts3.html В статье параметры железа не указаны, но это выполнено на кореквадро с 8 гиг ОЗУ, из которых около половины занято безобразием в образе постгреса. Также см. http://geomapx.blogspot.com/2009/09/sqlite-3617-mobigroup2.html И добавлю ссылку на тесты, демонстрирующие проблемы индексов: http://geomapx.blogspot.com/2009/11/degradation-of-indexing-speed.html И еще патч FTS3 для сжатия контента поисковой БД http://geomapx.blogspot.com/2009/11/tests-of-zlib-patched-fts3.html http://geomapx.blogspot.com/2009/11/fts3-compression.html Там наблюдалась странная деградация скорости при запросах с count(*), апстрим эти тесты видел и кое-что правили, но я на новых версиях эскулайт не экспериментировал. Best regards, Alexey Pechnikov. http://pechnikov.tel/
