...

или внеочередные заметки


[sticky post]Случайные фотки
trekking, Himalaya
obartunov
Этот пост - моя фоторамка. Весь дневник так или иначе построен вокруг моих впечатлений, которые я попытался сохранить в своих фотографиях. Можно подписаться на rss.
Oleg Bartunov - View my most interesting photos on Flickriver
ненужные подробности для историиCollapse )
Tags:

Вершины крупным планом
trekking, Himalaya
obartunov
Решил собрать здесь вершины гор, снятые мною крупным планом. Буду потихоньку добавлять, поэтому пусть этот пост повисит немного. Пока добавил фотографии из района Эвереста.
Upd. Добавил фотографии из Пакистана.

Read more...Collapse )

Расширяем SQL для эффективной работы с JSON документами в PostgreSQL
trekking, Himalaya
obartunov
Чем мы сейчас занимаемся ? На фотографии Федя Сигаев у нас в 38 комнате ГАИШ задумавшись смотрит на Сашу Короткова. А мысли у нас о том, что делать с jsquery. Надо сказать, что jsquery мы придумали для возможности играться с нашими индексами. Кстати, сейчас jsquery уже имеет поддержку хинтов, которыми можно управлять использование индексами, а также поддержка схемы (IS BOOLEAN, IS NUMERIC, IS ARRAY, IS STRING). Однако, jsquery имеет проблемы с расширяемостью, и вообще, как-то противоречит общей концепции SQL.

DSCF2631
ВВЕДЕНИЕ.
Read more...Collapse )
Tags: ,

Интервью для журнала "Хакер"
trekking, Himalaya
obartunov


В июльском номере журнала "Хакер" вышло интервью со мной, взятое наспех у меня в ГАИШ. Не знаю, как и где этот журнал можно взять, но интервью можно прочитать здесь Прокачать память слону. Название, кстати, не мое.

Tags:

Быть или не быть Национальной СУБД ?
trekking, Himalaya
obartunov
На конференцию в Абрау-Дюрсо я подал вот такие тезисы. Тему я выбрал неслучайно, дело в том, что сейчас после американских санкций опять начала муссироваться тема национальной программной платформы (которую благополучно завалили в прошлом), ну и одновременно всплыла тема национальной СУБД. Ко мне стали обращаться разные лица с предложением подумать над этим вопросом (памятуя о моем выступлении в 2011 году), так что я решил выступить перед научным айтишным сообществом. Так что, это только тезисы и они не претендуют на полное освещение проблемы.

================================================================================================

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

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

Во-вторых, представим, что у нас появились требования к СУБД и даже открылось финансирование на разработку. Означает ли, что мы соберем команду ученых и квалифицированных разработчиков, которые смогут за конечное время (2-3 года) сделать такой грандиозный проект ? На самом деле, во всей большой России практически нет научной школы по теории и практике технологий баз данных (для этого достаточно посмотреть на DBLP) и команды сильных разработчиков, имеющих опыт разработки СУБД с нуля. Единственным выходом в такой ситуации является ориентация на свободные СУБД, которые имеют большое сообщество пользователей и разработчиков. Наиболее продвинутая и открытая СУБД PostgreSQL имеет хорошую и долгую историю, ведущую из известной школы баз данных в Беркли, а также, лицензию BSD, которая не накладывает никаких ограничений на использование исходных кодов. Богатство функциональности, качество кода и открытость PostgreSQL проявляется не только в большом количестве пользователей, но и в количестве открытых и коммерческих форков. Серьезным аргументом в пользу PostgreSQL является наличие российских разработчиков, которые входят в международную команду разработчиков, в которой занимают серьезное положение. Кроме того, PostgreSQL уже давно используется в силовых структурах и входит в отечественные дистрибутивы Linux, версия 9.0 сертифицирована министерством обороны под именем СУБД Заря. Крупные интернет-проекты также используют PostgreSQL, например, Rambler, Yandex. Mail.ru, avito.ru и другие. Если мы пустим финансирование на подготовку разработчиков, которых направим на разработку важнейших подсистем PostgreSQL, то мы получим со временем, не только команду квалифицированных разработчиков, но и большое сообщество пользователей, которое очень эффективно для тестирования и поддержки. Кроме того, большое количество российских разработчиков может играть важную роль в выборе приоритетов развития базы данных, например, если придется защищать важную для России функциональность.

Помимо разработчиков и исследователей, необходимо иметь инфраструктуру по подготовке администраторов и пользователей, которая в настоящее время в России практически отсутствует. Именно ее отсутствие сдерживает распространение PostgreSQL и других открытых СУБД, так как государственным организациям и коммерческим компаниям требует качественная поддержка, возможность обучения их сотрудников. Требуется организовать перевод документации на русский язык с поддержкой версионности, разработать курсы для администраторов, разработчиков, менеджеров.

Итак, нам не нужна Национальная СУБД ! Нам нужны люди, способные включиться в разработку свободной и развитой СУБД и вырасти, нам нужны люди, которые могут организовать процесс поддержки и обучения, нам нужна внятная государственная политика по поддержке своих разработчиков.
Tags:

New GIN opclass for hstore (Faster and smaller) !
trekking, Himalaya
obartunov
We feel a bit uncomfortable after cancellation of nested hstore project for jsonb sake,so we decide to release new hash-based GIN-opclass (from jsonb) for hstore, which greatly improves the performance of @> operator (we expect an order of magnitude). We expect it should works for 9.2+ postgres, but you can test it for older releases too. Patches are welcome. Please, download it from https://github.com/akorotkov/hstore_ops and sent us feedback, so we could officially release it. This is a separate extension, so you need contrib/hstore already installed.
UPDATE: It is has no problem with long keys (values) !

Here is a short example:

create extension hstore;
select hstore(t) as h into proc from pg_proc t;
create index hstore_gin_idx on proc using gin(h);
=# explain analyze select count(*) from proc where h @> 'proargtypes => "2275"';
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=30.97..30.98 rows=1 width=0) (actual time=0.201..0.201 rows=1 loops=1)
-> Bitmap Heap Scan on proc (cost=20.02..30.96 rows=3 width=0) (actual time=0.094..0.196 rows=76 loops=1)
Recheck Cond: (h @> '"proargtypes"=>"2275"'::hstore)
Rows Removed by Index Recheck: 93
Heap Blocks: exact=50
-> Bitmap Index Scan on hstore_gin_idx (cost=0.00..20.02 rows=3 width=0) (actual time=0.082..0.082 rows=169 loops=1)
Index Cond: (h @> '"proargtypes"=>"2275"'::hstore)
Planning time: 0.067 ms
Execution time: 0.222 ms
(9 rows)

Now, we install hstore_ops

create extension hstore_ops;
create index hstore_gin_hash_idx on proc using gin(h gin_hstore_hash_ops);
=# explain analyze select count(*) from proc where h @> 'proargtypes => "2275"';
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=18.97..18.98 rows=1 width=0) (actual time=0.008..0.008 rows=1 loops=1)
-> Bitmap Heap Scan on proc (cost=8.02..18.96 rows=3 width=0) (actual time=0.006..0.006 rows=0 loops=1)
Recheck Cond: (h @> '"proargtypes"=>"2275"'::hstore)
Heap Blocks:
-> Bitmap Index Scan on hstore_gin_hash_idx (cost=0.00..8.02 rows=3 width=0) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: (h @> '"proargtypes"=>"2275"'::hstore)
Planning time: 0.067 ms
Execution time: 0.032 ms
(8 rows)

One can see considerable improvement from 0.222ms to 0.032 ms, but the table proc has only 2744 rows and we need more results from hstore users.


Also, we added support of ?, ?|, ?& operators to gin_hstore_hash_ops (jsonb lacks them), but we didn't tested it and, again, we need your help.


Here is size comparison:

=# \dt+ proc
List of relations
Schema | Name | Type | Owner | Size | Description
--------+------+-------+----------+---------+-------------
public | proc | table | postgres | 1616 kB |
=# \di+
List of relations
Schema | Name | Type | Owner | Table | Size | Description
--------+---------------------+-------+----------+-------+--------+-------------
public | hstore_gin_hash_idx | index | postgres | proc | 232 kB |
public | hstore_gin_idx | index | postgres | proc | 616 kB |
(2 rows)

Notice, that new opclass is not just faster, but also several times less !

Tags: , ,

Loose Indexscan
trekking, Himalaya
obartunov
Loose indexscan, implemented in MySQL provides effective way to select distinct valuse, since indexscan jumps on distinct values, without scanning all equal values. In case of not so many distinct values, the win may be very big. See an extreme (just 2 distinct values) example:
test=# \d tt
      Table "public.tt"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | 
Indexes:
    "tt_idx" btree (id)
test=# insert into tt(id)  select 0 from generate_series(1,1000000);
test=# insert into tt(id)  select 1 from generate_series(1,1000000);
test=# select distinct(id) from tt;
 id 
----
  0
  1
(2 rows)

Time: 481,807 ms
test=# with recursive t as 
(select min(id) as id from tt 
 union all 
 select (select min(id) from tt where id > t.id) from t where t.id is not null
) 
select id from t where id is not null 
 union all 
select null where exists (select * from tt where id is null);
 id 
----
  0
  1
(2 rows)

Time: 0,959 ms
test=#  select 481.807/0.959 as win_ratio; 
      win_ratio       
----------------------
 502.4056308654848801
(1 row)


500 times win ! PostgreSQL will not use index scan for the first query and this is a right choice !
Tags: ,

PostgreSQL books
trekking, Himalaya
obartunov
Набрел на место, где можно скачать/купить книги по постгресу. Лучше купить,если есть возможность, ибо так авторы что-то получают. На самом деле, писание книг - дело неблагодарное и можно только благодарить авторов за их самоотверженный труд. Практически все авторов я лично знаю, некоторые книги у меня есть в бумажном виде, да еще с авторской подписью :) Вот список книг по постгресу 9:

1. PostgreSQL Server Programming - программирование на C, pl/pgsql, pl/python, pl/proxy.
2. PostgreSQL 9 Admin Cookbook - настольная книга администратора, переведена на русский, Николай Самохвалов знает где ее можно достать.
3. PostgreSQL 9.0 High Performance - для хардкора.

А вот и сама ссылка - http://it-ebooks.info/tag/postgresql/
Tags:

Jsonb: "Wildcard" query
trekking, Himalaya
obartunov
Just to let people know about our experiments.


Consider this top-level query, which well supported by GIN in 9.4.

postgres=# select count(*) from jb where jb @> '{"tags":[{"term":"NYC"}]}'::jsonb;
count
-------
285
(1 row)

What if I want to find just {"term":"NYC"}, or even "NYC" ? Now, with some improvements, jsonb_hash_ops supports such queries with less than 5% bigger index size and not sacrificing performance !

postgres=# select count(*) from jb where jb @>> '{"term":"NYC"}'::jsonb;
count
-------
285
(1 row)
postgres=# select count(*) from jb where jb @>> '"NYC"'::jsonb;
count
-------
285
(1 row)


I can see the use-case for wildcard queries for shop aggregators, which combine different hierachies, so it's difficult to say if some specific key is on the same level in different sources.

Tags: , ,

Nested hstore (hstore 2.0) git repository
trekking, Himalaya
obartunov
We saved for historical reason our nested hstore project at github. I don't recommend to use it, since all development resourse now are concentrated on jsonb.

Expect better jsonb indexing like structural queries support and jsonb query language in 9.5 or 9.6.
AFAIK, Mongodb doesn't support such (subtree, wildcard) queries.

postgres=# explain analyze select count(*) from jb where jb @>> '{"term":"NYC"}'::jsonb;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=4740.72..4740.73 rows=1 width=0) (actual time=0.764..0.764 rows=1 loops=1)
-> Bitmap Heap Scan on jb (cost=41.71..4737.59 rows=1253 width=0) (actual time=0.201..0.735 rows=285 loops=1)
Recheck Cond: (jb @>> '{"term": "NYC"}'::jsonb)
Heap Blocks: exact=285
-> Bitmap Index Scan on gin_jb_bloom_idx (cost=0.00..41.40 rows=1253 width=0) (actual time=0.162..0.162 rows=285 loops=1)
Index Cond: (jb @>> '{"term": "NYC"}'::jsonb)
Planning time: 0.048 ms
Total runtime: 0.799 ms
(8 rows)

postgres=# explain analyze select count(*) from jb where jb @>> '"NYC"'::jsonb;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=4740.72..4740.73 rows=1 width=0) (actual time=0.648..0.648 rows=1 loops=1)
-> Bitmap Heap Scan on jb (cost=41.71..4737.59 rows=1253 width=0) (actual time=0.148..0.618 rows=285 loops=1)
Recheck Cond: (jb @>> '"NYC"'::jsonb)
Heap Blocks: exact=285
-> Bitmap Index Scan on gin_jb_bloom_idx (cost=0.00..41.40 rows=1253 width=0) (actual time=0.119..0.119 rows=285 loops=1)
Index Cond: (jb @>> '"NYC"'::jsonb)
Planning time: 0.051 ms
Total runtime: 0.672 ms
(8 rows)
Tags: , ,

You are viewing obartunov