У меня был HP-41CV, инфракрасный принтер, считал на нем свой диплом в 1981 году. До сих пор помню, как извращался, чтобы в память уместиться, любил его нежной любовью, у нас на физфаке было несколько любителей этих калькуляторов, помню даже журналы их америки гуляли со всякими фишками, типа вход в инженерное меню.
Я когда-то писал про логотип постгреса obartunov.livejournal.com/186860.html
Если в кратце, то предложил его David Yang 3 апреля 1997 года, а сделали наши ребята из Питера.
Мне кажется, что с полнотекстовым поиском вы поторопились. Надо поставить русскую морфологию, например, отсюда github.com/postgrespro/hunspell_dicts и все должно работать. Дело в том, что по-умолчанию используется стеммер snowball, который довольно тупой.
Понятно, что ничего хорошего не получится. Если поставить hunspell_ru_ru, то ситуация лучше select ts_lexize('russian_hunspell','Иванова'), ts_lexize('russian_hunspell','Иванов'), ts_lexize('russian_hunspell','Иван');
ts_lexize | ts_lexize | ts_lexize
-----------+-----------+-----------
(null) | {иван} | {иван}
(1 row)
Можно в конце-концов сделать словарь синонимов и вбить туда исключения, я рекомендую использовать dict_xsyn для гибкости.
Короче говоря, можно все настроить с постгресом. У меня в ЖЖ есть несколько постов на тему FTS . Прошлой осенью я делал доклад в Лиссабоне на PGConf.eu, там тоже можно посмотреть на предмет словарей. Если что непонятно, обращайтесь. Меньше зависимостей, проще система.
Алексей, а трудно графику добавить? Я gnuplot использую, чтобы глядеть вживую на изменение параметров. Организуй трубу в гнуплот и он в соседнем окне будет показывать бегущий график.
Вот здесь можно посмотреть http://www.sai.msu.su/~megera/postgres/talks/pgopen-2016-rum.pdf и ранняя версия доклада http://www.sai.msu.su/~megera/postgres/talks/pgcon-2016-fts.pdf
Два года назад рассказывал в Токио про hstore и jsonb, может кому пригодится — http://www.sai.msu.su/~megera/postgres/talks/semi-structured-postgresql-japan.pdf
но, как бы, в 2015 (2015, Карл!) году когда даже в десктопах торчат по 6-8 ядер, обрабатывать клиентский запрос ОДНИМ потоком…
Уже сейчас можно писать расширения, которые могут пользовать несколько ядер. Hans-Jürgen Schönig скоро выпустит такое расширение (не трогая ядра базы!) для агрегатов, вот его пример:
agg=# SET agg.hash_workers = 1;
SET
Time: 0.269 ms
agg=# SELECT val1,
avg(id),
sum(id),
min(id),
max(id)
FROM t_agg
GROUP BY 1
LIMIT 2;
val1 | avg | sum | min | max
------+----------------------+----------------+-----+---------
34 | 2500014.000000000000 | 12500070000000 | 34 | 4999994
25 | 2500005.000000000000 | 12500025000000 | 25 | 4999985
(2 rows)
Time: 62983.545 ms
agg=# SET agg.hash_workers = 10;
SET
Time: 0.161 ms
agg=# SELECT val1,
avg(id),
sum(id),
min(id),
max(id)
FROM t_agg
GROUP BY 1
LIMIT 2;
val1 | avg | sum | min | max
------+----------------------+----------------+-----+---------
34 | 2500014.000000000000 | 12500070000000 | 34 | 4999994
25 | 2500005.000000000000 | 12500025000000 | 25 | 4999985
(2 rows)
Time: 8265.947 ms
Таким образом, многое в ваших руках уже сейчас. Но это конечно только часть того, что планируется.
Отсутствие партицирования — тоже огромный недостаток.
Да, схему секционирования надо менять, мы этим тоже занялись и даже есть рабочее название проекта «pg_pathman», которые поможет нам генерить только нужные path-ы и передавать их планеры и избежать гигантского оверхеда перебора кучи ненужных планов. Это тоже часть работ по секционированию, но приятно, что она вполне обозримая и уже даст возможность работать с большим количеством разбиений. Возможно, надо будет объединиться с pg_partman.
Передайте Андресу
Передал, более того, Андрес приедет зимой на pgconf.ru с докладом по масштабируемости постгреса, так что вы сможете с ним поговорить лично.
У нас технический блог по постгресу, а нам предложили читать про мифы о MySQL. Текст написан складно, но вот только непонятны цели. Зачем-то оскорбили нашу компанию Postgres Professional, которая образовалась только в феврале и где она могла обидеть MySQL, мне непонятно. Автор не сознается, ну да ладно с ним. Я приведу несколько ссылок, чтобы люди смогли посмотреть технические детали двух субд.
Последняя ссылка особенно хороша и без каких-либо холиваров. В частности, там написано: «PostgreSQL was not available on Windows. First windows native version was 8.0. This was an advantage for MySQL.» Вот с этим я согласен.
Вы написали про нашу компанию нелестные слова, мне это неприятно, я хочу у вас узнать, почему вы допускаете такие слова в публичном блоге PostgreSQL. Я завтра спрошу ребят, кто вам так не угодил, раз вы не признаетесь.
Вы меня не поняли, кого вы посчитали сотрудниками Postgres Professional? Ни одного сотрудника в обсуждении я не увидел. Если вы считаете Мишу Тюрина нашим сотрудником, так это не так, увы. Миша является VIP в Avito.ru, главный за все базы. Поэтому, поправьтесь еще раз и окончательно.
Я не обижаюсь, а наоборот, хочу вас немного поправить, чтобы больше таких конфузов не было. Неужели вы не видите, что я до сих пор никого не заминусовал :) У вас есть слог и рвение, что не очень часто совпадает в нашем техническом мире, поэтому я вас призываю к созиданию, а не к обидкам и нападкам. Можете представить, сколько всего я наблюдал за 20 лет опенсорса :)
Читал-читал и все жду, когда вы исправите «полуграмотные утверждения» на что-то более нейтральное.
Что касается конференций, то я еще раз утверждаю, что у вас просто эффект преломления сознания. Дискусии бывают жаркие, но специально никто ни на кого не наезжают, только технические споры. Вот пример, кстати, с моим участием, совместной встречи двух сообществ, найдите там наезды :) postgresmen.ru/articles/postgresql-vs-mysql-moscow-2009
Ну вот, вы все-таки холивар развиваете. Вы про фичи напишите, мы же тут разработчики и инженеры. Вы же просто не представляете, как делается выбор в больших проектах, а мы говорим про нашу реальную головную боль. Под религиозными взглядами я имел ввиду то, какой опыт уже имел конкретный человек и с чем знакома его команда. Если все имели опыт работы с mysql, то скорее всего и надо выбирать ее. Если вы хотите помочь человеку с нуля, причем этому человеку совсем по барабану мифы и наследия прошлых времен, то ему нужна совсем другая статья. Холиварщиков хватает и без вас, давайте позитив делать, а это означает употребите ваши умения на благо.
Можете мне скинуть dump базы, я сейчас тестирую новые индексы для ltree, хочу производительность померять.
Как верхний и нижний графики соотносятся друг с другом ? Желтый цвет вы специально выбрали, чтобы мы глаза ломали ?
apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-rum
Я думаю про то, чтобы RUM сделать GIN-ом в сообществе.
www.sai.msu.su/~megera/postgres/talks/pgopen-2016-rum.pdf
Если в кратце, то предложил его David Yang 3 апреля 1997 года, а сделали наши ребята из Питера.
select ts_lexize('russian_stem','Иванова'), ts_lexize('russian_stem','Иванов'), ts_lexize('russian_stem','Иван');
ts_lexize | ts_lexize | ts_lexize
-----------+-----------+-----------
{иванов} | {иван} | {ива}
(1 row)
Понятно, что ничего хорошего не получится. Если поставить hunspell_ru_ru, то ситуация лучше
select ts_lexize('russian_hunspell','Иванова'), ts_lexize('russian_hunspell','Иванов'), ts_lexize('russian_hunspell','Иван');
ts_lexize | ts_lexize | ts_lexize
-----------+-----------+-----------
(null) | {иван} | {иван}
(1 row)
russian_aot_hunspell выдает побогаче
select ts_lexize('russian_aot_hunspell','Иванова'), ts_lexize('russian_aot_hunspell','Иванов'), ts_lexize('russian_aot_hunspell','Иван');
ts_lexize | ts_lexize | ts_lexize
----------------------------------+-----------+-----------
{иванов,иваново,ивановец,иванов} | {иванов} | {иван}
(1 row)
Можно в конце-концов сделать словарь синонимов и вбить туда исключения, я рекомендую использовать dict_xsyn для гибкости.
Короче говоря, можно все настроить с постгресом. У меня в ЖЖ есть несколько постов на тему FTS . Прошлой осенью я делал доклад в Лиссабоне на PGConf.eu, там тоже можно посмотреть на предмет словарей. Если что непонятно, обращайтесь. Меньше зависимостей, проще система.
Алексей, а трудно графику добавить? Я gnuplot использую, чтобы глядеть вживую на изменение параметров. Организуй трубу в гнуплот и он в соседнем окне будет показывать бегущий график.
Уже сейчас можно писать расширения, которые могут пользовать несколько ядер. Hans-Jürgen Schönig скоро выпустит такое расширение (не трогая ядра базы!) для агрегатов, вот его пример:
Таким образом, многое в ваших руках уже сейчас. Но это конечно только часть того, что планируется.
Да, схему секционирования надо менять, мы этим тоже занялись и даже есть рабочее название проекта «pg_pathman», которые поможет нам генерить только нужные path-ы и передавать их планеры и избежать гигантского оверхеда перебора кучи ненужных планов. Это тоже часть работ по секционированию, но приятно, что она вполне обозримая и уже даст возможность работать с большим количеством разбиений. Возможно, надо будет объединиться с pg_partman.
Передал, более того, Андрес приедет зимой на pgconf.ru с докладом по масштабируемости постгреса, так что вы сможете с ним поговорить лично.
1. Википедия — https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
2. http://sql-workbench.net/dbms_comparison.html
3. https://www.wikivs.com/wiki/MySQL_vs_PostgreSQL?
Последняя ссылка особенно хороша и без каких-либо холиваров. В частности, там написано: «PostgreSQL was not available on Windows. First windows native version was 8.0. This was an advantage for MySQL.» Вот с этим я согласен.
Я не обижаюсь, а наоборот, хочу вас немного поправить, чтобы больше таких конфузов не было. Неужели вы не видите, что я до сих пор никого не заминусовал :) У вас есть слог и рвение, что не очень часто совпадает в нашем техническом мире, поэтому я вас призываю к созиданию, а не к обидкам и нападкам. Можете представить, сколько всего я наблюдал за 20 лет опенсорса :)
Что касается конференций, то я еще раз утверждаю, что у вас просто эффект преломления сознания. Дискусии бывают жаркие, но специально никто ни на кого не наезжают, только технические споры. Вот пример, кстати, с моим участием, совместной встречи двух сообществ, найдите там наезды :)
postgresmen.ru/articles/postgresql-vs-mysql-moscow-2009