Re: Продолжение [вопрос с библиотекой решен]
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/
Reply to: