GeoMapX

For testing is used the production PostgreSQL database. I did build SQLite database as described here: Trigger-based PostgreSQL to SQLite online replication The test requests is real queries from the production system. The PostgreSQL is too slow on these queries and I search more performance database system for the intranet/internet portal. All tables have needed indices. Some tables are renamed in SQLite database but their names and fields names are similar. Note The PostgreSQL quries is rewrited for better index usage but SQLite query planner work fine without any additional tricks. The query conditions are generated by application query builder for user filters and settings and when you can see identical conditions these are not always identical. Hardware Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz MemTotal: 8310900 kB HDD: 1 VelociRaptor 10000 rpm PostgreSQL parameters work_mem = 100000 # min 64, size in KB maintenance_work_mem = 2000000 # mi

For some reasons may be useful online replication from PostgreSQL database to SQLite database or databases. I write this as set of pltclu procedures for my PostgreSQL database like to CREATE OR REPLACE FUNCTION document_status_sqlite3() RETURNS "trigger" AS $BODY$ set t1 [clock clicks] load /usr/share/tcltk/tcl8.5/sqlite3/libtclsqlite3.so sqlite3 set db_file /var/www/project_name/res/dataset/work.db sqlite3 db $db_file db timeout 4000 # db eval {PRAGMA journal_mode = PERSIST} if { $TG_op eq "INSERT" } { set save_date [string range $NEW(save_date) 0 18] db eval {insert into document_status (save_date,document_id, user_id,value, is_last,is_last_status,is_first) values (julianday($save_date,'-3 hour'),$NEW(document_id), $NEW(user_id),$NEW(value), case when $NEW(is_last)='t' then 1 else 0 end, case when $NEW(is_last_status)='t' then 1 e

Для добавления новых коллекторов данных необходимо и достаточно создать БД определенного формата и заполнять в ней таблицу трафика (telephony_log). Привожу код утилиты, инициирующей структуру требуемой БД (утилита вызывается из коллекторов при создании новой БД при ротации). Также рекомендуем просмотреть код поставляемых коллекторов (файлы telephony_agent_tacacs.tcl и telephony_agent_callbuilder.tcl , размером около 15 килобайт каждый). Использование ./telephony_dataset_init.tcl Утилита инициализации БД для хранения телефонной статистики. Создает БД SQLite3 с указанным именем. Если не удалось создать БД, возвращает ошибку, иначе завершается без выдачи сообщений. Примечание: используются только стандартные функции СУБД SQLite 3.5.9, модули расширения для заполнения базы не требуются. Используйте программу следующим образом: ./telephony_dataset_init.tcl путь_БД telephony_dataset_init.tcl #!/usr/bin/tclsh8.5 # /opt/bin/telephony_dataset_init.tcl /srv/dataset/telephony/test.db pa

Выгрузка отчетов В некоторых случаях бывает удобным иметь возможность получать отчеты с помощью скрипта, например, для их рассылки пользователям на e-mail. Для автоматизации таких задач нами предлагается скрипт-обертка adp_wrapper, обеспечивающий выполнение adp-скриптов без обращения к веб-серверу. Пример: ./adp_wrapper.tcl $MBGROOT/www/ext/report_ext_01/report_html_all.adp date $date user_id $id \ > $dir/${login}_all.html 2>/dev/null В комплект входит скрипт telephony_report_ext_01.tcl для выгрузки форм расширенного отчета №1, который вызывается следующим образом: MBGROOT=/var/www/billing2 ./telephony_report_ext_01.tcl 2009-10-01 2009-11-01 Приведенный ниже скрипт построит отчеты за 10-й и 11-й месяцы 2009 года для всех активных абонентов системы (за исключением провайдеров). Аналогично могут быть написаны скрипты для получения любых других отчетов, также можно добавить рассылку их на e-mail и т.п. telephony_report_ext_01.tcl #!/usr/bin/tclsh8.5 # start as # AOLROOT=/var/www/bi

Представленное решение для биллинга поддерживает распределенную работу компонентов и их дублирование для реализации отказоустойчивости. В случае запуска всех компонентов на одном сервере конфигурация может быть достаточно простой, причем ее настройка для распределенной работы на нескольких хостах не представляет больших сложностей. Представленное решение включает в себя следующие файлы: набор тиклевых библиотек, некоторое множество SQLite баз данных, веб-сервер AOL Server с adp-скриптами для генерации web-интерфейса, набор консольных утилит и некоторые другие ресурсы. Система обрабатывает миллионы звонков в месяц на десктопном оборудовании без каких-либо дополнительных действий по оптимизации баз данных. Для обработки большего числа звонков необходимо ежесуточно выполнять команду VACUUM для БД статистики за текущий месяц. При еще больших масштабах может потребоваться разделять БД не по месяцам, а по неделям или даже дням. "Ядро" биллинговой системы выполняет обработку около

Hardware laptop with Intel(R) Core(TM)2 Duo CPU T5470 1.60GHz (working as 800MHz CPU for low heating) 1 GB RAM HDD Western Digital Scorpio Black 2.5" 7200 rpm 16Mb (FS ext3) OS Debian (lenny+testing+sid). SQLite build My debian package has these options to compile SQLite 3.6.20: DEB_OPT_FLAG := -O2 -fno-strict-aliasing \ -DSQLITE_CORE=1 \ -DSQLITE_ENABLE_COLUMN_METADATA \ -DSQLITE_ENABLE_STAT2 \ -DSQLITE_DEFAULT_RECURSIVE_TRIGGERS=1 \ -DSQLITE_ENABLE_COMPRESS \ -DSQLITE_ENABLE_FTS3 \ -DSQLITE_ENABLE_INET \ -DSQLITE_ENABLE_MD5 \ -DSQLITE_ENABLE_RTREE \ -DSQLITE_ENABLE_TABLEFUNC \ -DSQLITE_ENABLE_VIRTUALTEXT \ -DSQLITE_ENABLE_ICU \ -DSQLITE_ENABLE_UUID \ -DSQLITE_ENABLE_VERSIONING \ -DSQLITE_SOUNDEX \ -DSQLITE_TEMP_STORE=3 \ -DSQLITE_DEFAULT_PAGE_SIZE=4096 \ -DSQLITE_DEFAULT_CACHE_SIZE=128000 \ -DSQLITE_DEFAULT_TEMP_CACHE_SIZE=8000 \ -DSQLITE_DEFAULT_FILE_FORMAT=4 LDFLAGS=-luuid -lz -ldl `icu-config --ldflags` You can get binary and

Ранее приходилось делать финт ушами, дописывая в файл /etc/fstab следующую строку: usbfs /proc/bus/usb usbfs devgid=118,devmode=664 0 0 Теперь же это не нужно, так как появилось правило 10-vboxdrv.rules для udev: KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600" SUBSYSTEM=="usb_device", GROUP="vboxusers", MODE="0664" SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vboxusers", MODE="0664" У меня этот файл датирован 3-м ноября сего года. Конечно, пользователь должен входить в группу vboxusers: $ cat /etc/group|grep vboxusers vboxusers:x:118:veter Добавить пользователей в требуемую группу нетрудно (необходимо перелогиниться для вступления изменений в силу): sudo addgroup veter vboxusers

Получение метаинформации о файлах необходимо, например, для систем полнотекстового поиска. Для этих целей применяются более или менее навороченные скрипты, поставляемые в комплекте. Для меня подобный подход неприемлем, что и побудило меня поискать unix-way для решения поставленной задачи. И он нашелся - это утилита extract из одноименного пакета. Пример использования: $ extract MTS\ Connect.ppt mimetype - application/vnd.ms-powerpoint paragraph count - 215 title - PowerPoint Presentation word count - 741 date - 2008-12-29T09:30:08Z generator - Microsoft PowerPoint last saved by - Иван Иваныч creation date - 2009-04-22T19:24:48Z Что и требовалось получить.

В связи с усложнением логики построения отчетов появилась потребность в предоставлении пользователю возможности самому писать отчеты на скриптовом языке. Задача не новая, однако существующие ее решения зачастую мало приемлемы. Для сохранения высокого быстродействия при построении отчетов необходимо создавать их непосредственно в БД, таким образом, требуется возможность выполнения пользовательского кода в контексте функции в БД. Для защиты БД применим технологию защищенных интерпретаторов tcl. Пример безопасного выполнения пользовательского кода приведен ниже. CREATE OR REPLACE FUNCTION public.interp_test(script text) RETURNS void AS $BODY$ set script $1 interp create -safe slave interp alias slave elog {} elog if {[catch { interp eval slave $script } errmsg]} { interp delete slave elog ERROR $errmsg } interp delete slave return $BODY$ LANGUAGE 'pltcl' VOLATILE SECURITY DEFINER; ALTER FUNCTION public.interp_test(text) OWNER TO offline; select pub

При проведении анализа данных и построении отчетов нередко требуется реализовать сложную логику обработки данных. Написание множества огромных и малопонятных (которые с течением времени становятся и вовсе непонятными) SQL-запросов становится тяжким роком разработчика. Необходимость расширить функциональность или изменить алгоритм вычисления способна привести к тому, что все запросы переписываются заново. Что ж, бывает и так. А если написанные запросы-монстры еще и работают медленно (что прямое следствие их запутанности), то становится совсем непонятно, как бы всего этого избежать. Вот об этом мы и поговорим. После того, как я Вас немного придушил кошмарами, можете вздохнуть свободно: существуют способы сделать все намного удобнее и получить понятный код и отличную скорость работы. Достаточно лишь научиться ориентироваться в мире временных видов и таблиц PostgreSQL. Вы удивлены и полны сомнений? Наверное, Вы думаете о том, почему об их возможностях не пишут во всех справочниках и руков

Создание отчетов по хранимому в базе набору данных сложная и интересная задача. Мы будем рассматривать создание отчетов в реальном времени, то есть не более 4 секунд на генерацию любого отчета для каждого из одновременно работающих пользователей. Под построением отчетов мы будем понимать построение выборок или проведение сложного анализа данных и визуализацию полученных результатов. Как показывает опыт, этап визуализации данных нельзя отделять от этапа анализа данных и создания выборок - интерактивные интерфейсы пользователя могут десятки и сотни раз обращаться к итоговым данным отчета, выполняя над ними различные операции, потому и необходимо предусматривать получение данных в том виде, который необходим для дальнейшей визуализации. Если при каждом обновлении визуального представления отчета (переключение между табличным и графическим представлениями, группировка или сортировка результата, вывод расширенного отчета с использованием дополнительных наборов данных) анализ данных будет по

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

Функционал (functional) — функция, обычно определённая на множестве функций со значениями обычно в вещественных числах. Одним из важнейших шагов при проектировании базы данных является выбор функционалов (вычисленных функций от наборов данных), необходимых для эффективного анализа данных. Вы думаете, что набор функционалов нужен только для ускорения выборки данных? Конечно, нет! Кроме повышения эффективности анализа данных следует помнить о качестве анализа. Вспомним идеи OLAP - набора методик оперативного анализа данных в любой момент на любом уровне детализации. Одной из ошибок OLAP-подхода, погубившей все направление была неверная трактовка технологии. Одно только название "многомерный анализ данных" побудило сломать горы копий и создать множество нежизнеспособных информационных систем. А правильно было бы использовать термин "многоуровневый анализ". Знаете, что такое фрактальное изображение? Это изображение, которое повторяет себя на разных уровнях детализации.