GeoMapX

Собрал некоторые расширения как деб-пакеты, см. репозиторий http://mobigroup.ru/debian/pool-squeeze/main/s/ В апстримовском расширении FTS3 поправлен баг, мешающий собирать его отдельным модулем. Версия из текущего trunk, умеет conflict-resolution для виртуальных таблиц (можно писать insert or replace ...). Также добавлена поддержка стеммеров Snowball . Модуль ICU собран "как есть" апстримовский. Добавлен модуль для подсчета хэша sha1 (используется быстрая реализация из BSD-систем). Для перекомпиляции, в т.ч. под другие ОС, см. в архивах файлик debian/rules, где содержатся команды сборки. Для удобства загрузку нужных расширений можно сделать с помощью файла ресурсов: $ cat ~/.sqliterc .load /usr/lib/libsqlitetcl.so .load /usr/lib/libsqliteicu.so .load /usr/lib/libsqlitefts3.so .load /usr/lib/libsqlitesha1.so $ sqlite3 -- Loading resources from /home/veter/.sqliterc

В очередной раз получаю вопрос, как сделать выравнивание числа в SQLite. Оставляя "за кадром" необходимость это делать в эскулайт, отвечаю - это сделать несложно, вот пример: sqlite> create table a(val integer); sqlite> insert into a(val) values(1); sqlite> insert into a(val) values(10); sqlite> insert into a(val) values(100); sqlite> insert into a(val) values(1000); sqlite> select substr('0000000',1,7-length(val))||val from a; 0000001 0000010 0000100 0001000

Итак, поддержка стеммеров snowball для SQLite: http://sqlite.mobigroup.ru/wiki?name=FTS3+Snowball+Stemmer Пример использования: CREATE VIRTUAL TABLE fts USING fts4(text,TOKENIZE icu russian); insert into fts (text) values ('Нафига'); insert into fts (text) values ('попу'); insert into fts (text) values ('наган'); insert into fts (text) values ('если'); insert into fts (text) values ('поп'); insert into fts (text) values ('не'); insert into fts (text) values ('хулиган'); select * from fts where fts match 'поп'; попу поп sqlite> select * from fts where fts match 'нафиг'; Нафига Примечание: аналогично можно использовать и fts3 виртуальные таблицы, но рекомендуется переходить на fts4.

Приведу пару ссылок на сообщения рассылки: Managing trees in the database Persistent queue implementation based on SQLite

Как ни странно, недавно на одном из форумов снова увидел вопросы по использованию КЛАДР . Вместо того, чтобы разобраться с тем, что из себя представляет КЛАДР , его сначала пытаются как-нибудь преобразовать во что-нибудь, а потом с этим чем-нибудь работать. Делать этого не следует, а чтобы понять, почему - загляните в описание формата КЛАДР . О том, как работать с исходной структурой КЛАДР , сохранив ее для удобства в БД SQLite , я уже писал: Использование адресного справочника КЛАДР в Tcl Преобразование справочника КЛАДР в формат SQLite Утилиты КЛАДР Сейчас я просто перекладываю деб-пакеты (исходного кода и бинарные) с БД и утилитами, описанные в перечисленных статьях, в открытый репозиторий. Скомпилировать утилиты под любую ОС не представляет сложностей, а под убунту можно и просто поставить бинарные деб-пакеты.

Недавно Oracle вознамерился откусить часть чужого пирога в нише встраиваемых СУБД, предлагая пользователям SQLite прозрачный переход на новую версию СУБД BerkeleyDB с встроенной поддержкой программного интерфейса SQLite. Еще бы им не зариться - SQLite используется от смартфонов Android, iPhone и других до ОС Solaris, Linux и прочих. Притом для обеспечения совместимости Oracle использовал код самого SQLite, который распространяется под лицензией Public Domain и доступен для коммерческого использования. Но скорость реакции апстрима SQLite заслуживает всяческих похвал и в ответ на анонс компании Oracle команда разработчиков SQLite предоставляет новый режим работы СУБД SQLite без блокировки при чтении и записи! Таким образом, существующие пользователи SQLite не получат обещанного выигрыша от предлагаемого им Oracle перехода на BerkeleyDB просто потому, что в новой версии SQLite будет почти аналогичная конкурентность и множество других возможностей, которые Oracle еще не успела скопироват...

Из рассылки анонсов SQLite: sqlite-announce Digest, Vol 25, Issue 1 In conjunction with O'Reilly Media, I am happy to announce that the book "Using SQLite" is now available for pre-order. When released later this summer, the title should also be available in several popular ebook formats. O'Reilly Media: http://oreilly.com/catalog/9780596521189/ Amazon: http://www.amazon.com/Using-SQLite-Jay-Kreibich/dp/0596521189/ You can help! "Using SQLite" is taking part in O'Reilly Lab's "Open Feedback Publishing System" (OFPS). While we continue to prepare the final draft, you can read an online version of the book and leave feedback. Changes and edits to the current draft are pushed to the website daily, allowing you to track and watch as the book takes its final form. I invite all SQLite list members to register and participate: http://using-sqlite.labs.oreilly.com/ Thank you for your help and support! -j -- Jay A. Krei...

При разработке больших БД возникает необходимость в использовании множества индексов, но скорость вставки данных при этом падает катастрофически. Проанализировав, пришел к следующему результату - высокоселективный индекс на больших таблицах ведет себя ужасно. То есть, если в таблице 10М записей проиндексировать поле с десятком вариантов значений, это еще ничего, но если значений миллион, то скорость вставки записей снизится на несколько порядков. Для небольших таблиц рекомендации известны: Re: Behavior of SELECT queries during transaction С большими наборами данных все интереснее - в случае единственного индекса потенциально хорошую производительность можно получить при вставке заранее упорядоченного набора записей. Если же индексов много, то даже предварительная подготовка добавляемых записей ничего не даст. Расширение FTS3 предоставляет другую реализацию индекса - и этот индекс отлично работает с высокоселективными значениями. Зато имеет большие проблемы при выборок низкоселек...

Все бы хорошо с zlib-сжатием, но при вставке коротких строк или чисел оверхед получается многократный - сжатая строка в разы больше исходной. В качестве решения я решил не сжимать короткие строки (маньше 80 символов в данный момент), указывая 4-х байтный заголовок такой строки (содержит длину исходной строки, если строка сжата) как FFFFFF. Таким образом, эти строки легко распознаются при распаковке и оверхед минимален. Замечу, что сначала попытался использовать типы данных - если строку не сжимаю, то возвращаю text, а не blob. На выходе функции compress() получается набор сжатых и несжатых строк. Оверхед меньше, но решение потенциально способно породить сложноуловимые грабли. Как минимум, определить, использовано ли сжатие для записей, станет сложно. В моем деб-пакете с эскулайт это усовершенствование уже есть, а в fossil-репозиторий пока не добавил.

.schema CREATE TABLE role ( id INTEGER PRIMARY KEY AUTOINCREMENT, uid BLOB ); CREATE INDEX role_uid_idx on role(uid); Method 10 iterations of the 500 000 inserts: insert into role (uid) values (uid) uid=randomblob(1) $ ./test.tcl 1 7 seconds per iteration 2 7 seconds per iteration 3 7 seconds per iteration 4 7 seconds per iteration 5 7 seconds per iteration 6 7 seconds per iteration 7 7 seconds per iteration 8 7 seconds per iteration 9 7 seconds per iteration 10 7 seconds per iteration uid=randomblob(8) $ ./test.tcl 1 7 seconds per iteration 2 8 seconds per iteration 3 9 seconds per iteration 4 10 seconds per iteration 5 11 seconds per iteration 6 12 seconds per iteration 7 13 seconds per iteration 8 13 seconds per iteration 9 14 seconds per iteration 10 15 seconds per iteration uid=randomblob(16) $ ./test.tcl 1 7 seconds per iteration 2 10 seconds per iteration 3 12 seconds per iteration 4 14 seconds per iteration 5 18 seconds per iteration 6 44 seconds per iteration 7 ...

Выложил свои патчи для zlib-сжатия в модуле полнотекстового поиска FTS3 для SQLite, теперь база данных с полнотекстовым индексом примерно вчетверо компактнее. Патч брать здесь: http://sqlite.mobigroup.ru/src/vinfo/d3d9906674 и функции сжатия/распаковки здесь: http://sqlite.mobigroup.ru/src/dir?name=ext/compress Или качать последнюю версию моей сборки деб-пакета SQLite. Имеется одна неприятность - запрос count(*) выполняется медленно, т.к. приводит к распаковке всего контента базы, так уж в эскулайт работает интерфейс виртуальных таблиц. Решения пока не нашел, но есть обходной путь - обращаться напрямую к таблице %_content: sqlite> select count(*) from file_text; 8430 CPU Time: user 0.508032 sys 0.012000 sqlite> select count(*) from file_text_content; 8430 CPU Time: user 0.004000 sys 0.000000 С учетом размеров современных электронных библиотек считаю, что сжатие критически необходимо, потому и выкладываю патч с вышеназванной недоработкой.

Предупреждение: написано в стиле заметок на полях и воспроизводит ход размышлений автора, у читателей процесс размышления, равно как и наличие этого самого процесса и его результаты, могут отличаться! Посещавшие меня мысли о распределенных базах данных и их применимости начинают обретать законченные черты, а значит, самое время сделать соответствующую реализацию. Поскольку я уже знаю ответ на вопросы "что, как, зачем", то можно погуглить для ознакомления с уже существующими реализациями и лежащими в их основе концепциями. Основная идея состоит в том, что распределенная БД отнюдь не предполагает и не требует распределенную СУБД. Посмотрим на это утверждение с такой стороны - информация первична, а способ ее представления - вторичен. Например, из споры можно "восстановить" бактерию, а бактерии вовсе незачем раздуваться до размеров материка, когда можно просто превратить себя в спору и с попутным ветром этот материк перелететь, после чего "ожить". А дальш...

Сегодня ночью с 3-х до 7-ми часов была придумана, написана, протестирована и документирована вот такая вещь: Tcl VFS integration for Sqlite3 Лично я участвовал только в четных из указанных пунктов, считая с нуля :-) но подтверждаю - под дебианом оно замечательно работает, в том числе позволяет аттачить базы. Спасибо Антону, вещь ценная.

Возвращаясь к вопросу о производительности модуля полнотекстового поиска в SQLite, мы можем наблюдать весьма приятную картину: $ ls -lh|grep test.db|awk '{print $5}' 15G $ sqlite3 test.db SQLite version 3.6.21 sqlite> select count(*) from file_text; 908800 sqlite> select total(length(content)) from file_text; 6552194816.0 sqlite> select count(docid) from file_text where file_text match 'претензия'; 1536 CPU Time: user 0.004001 sys 0.000000 sqlite> select count(docid) from file_text where file_text match 'новости август абонент'; 256 CPU Time: user 0.028002 sys 0.000000 sqlite> select count(docid) from file_text where file_text match 'новости август абонент*'; 512 CPU Time: user 0.420026 sys 0.000000 Резюме : набор из почти миллиона документов общим размером 100 Гб, суммарно содержащих 6,5 миллиардов знаков, хранится в 15 Гб БД и поиск по одному слову занимает единицы миллисекунд, по нескольким словам - десятки миллисекунд, по нескольким сл...

В поисках средства для создания быстро стартующих утилит провел тесты и среди реализаций lisp. Самым быстрым оказался newLISP . Поставил deb-пакет с офсайта, разумеется, с поддержкой unicode . Поскольку у него в комплекте предоставляется и модуль для работы с SQLite, то я сразу же написал соответствующий тест. Ниже приведено сравнение с D-версией: $ time newlisp ./sqlite.lsp 3.6.21 real 0m0.013s user 0m0.008s sys 0m0.004s $ time ./sqlite DB open. sqlite_version() = 3.6.21 DB closed. real 0m0.010s user 0m0.004s sys 0m0.004s $ cat sqlite.lsp (module "sqlite3.lsp") (if (sql3:open "lsp.db") (sql3:error)) (println (((sql3:sql "select sqlite_version()") 0) 0)) (sql3:error) (sql3:close) (exit) $ cat sqlite.d import sqlite3; int main() { sqlite3* db; int code; sqlite3_stmt *stmt; char *sql="select sqlite_version();"; code = sqlite3_open("file.db", &db); if(SQLITE_OK != code) { printf("DB create error...

В поисках С-подобного языка с нативной поддержкой строк решил попробовать язык D . Цель состоит в оптимизации строковых операций в небольших сишных утилитах, в остальном С меня вполне устраивает. Быстродействие циклов и арифметики оказывается полностью идентично сишному варианту: $ cat hello.d int main(char[][] args){ int i; double x; for (i=0,x=0;i x+=1.1*i; printf("i=%d; x=%.2f\n",i,x); return 0; } $ gdc-4.1 hello.d -o hello $ time ./hello i=100000000; x=5499999945475522.00 real 0m0.535s user 0m0.528s sys 0m0.000s $ cat hello.c #include "stdio.h" main(){ int i; double x; for (i=0,x=0;i x+=1.1*i; printf("i=%d; x=%.2f\n",i,x); } $ gcc hello.c -o hello $ time ./hello i=100000000; x=5499999945475522.00 real 0m0.563s user 0m0.524s sys 0m0.004s А теперь рассмотрим более жизненный пример, на примере работы с SQLite базой данных. Элементарный пример взят отсюда , плюс добавлен код для выполнения sql-з...

Шелл lua запускается довольно шустро, решил еще некоторые тесты провести. Итак, встраиваем интерпретатор в сишную программу. Скрипт читается с stdin /* Compile as gcc -o2 -I/usr/include/lua5.1/ -llua5.1 lua.c -o lua Use as echo -e "a = 1 + 1;\nprint( a);\n"|./lua */ #include <stdio.h> #include <string.h> #include <lua.h> #include <lauxlib.h> #include <lualib.h> int main (void) { char buff[256]; int error; lua_State *L = lua_open(); luaL_openlibs(L); while (fgets(buff, sizeof(buff), stdin) != NULL) { error = luaL_loadbuffer(L, buff, strlen(buff), "line") || lua_pcall(L, 0, 0, 0); if (error) { fprintf(stderr, "%s", lua_tostring(L, -1)); lua_pop(L, 1); // pop error message from the stack } } lua_close(L); return 0; } Скрипт вкомпилирован в тело программы /* Compile as gcc -o2 -I/usr/include/lua5.1/ -llua5.1 lua.c -o lua Use as ./lua *...

Статья перемещена по адресу http://sqlite.mobigroup.ru/wiki?name=sqlite3-kladr

Вот интересная ссылка: Работа в 1С-Предприятии 7.7 с базами данных SQLite Автора этого проекта можно найти в форуме SQLite на sql.ru Сам я никогда с 1C не работал, успешно избегая сей участи, но система широко распространенная, так что возможность интеграции с ней вполне востребована. Если этот компонент поможет обмениваться данными, не влезая в саму 1C, то профит.

The new version of sqlite3-rdiff utility can produce really small signatures. See below test on 10 Mb database. The analyze mode will help you to select optimal parameters for your databases.