Я в 1980 г поработал на С-25, станция Б-200МР, бетонка, отвечал за блок выработки команд. Непрограммируемый компьютер на лампах, изучали на военке схемы, до сих пор помню гигантскую "клеенку" на всю стену, панел 5-Ю. Ходили слухи, что там была ртутная память типа линии задержек, но не могу найти документов про устройство этого нашего компа.
У меня был 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.» Вот с этим я согласен.
Скачал книгу, там 46 страниц всего.
Я в 1980 г поработал на С-25, станция Б-200МР, бетонка, отвечал за блок выработки команд. Непрограммируемый компьютер на лампах, изучали на военке схемы, до сих пор помню гигантскую "клеенку" на всю стену, панел 5-Ю. Ходили слухи, что там была ртутная память типа линии задержек, но не могу найти документов про устройство этого нашего компа.
Книга написана по заказу Минобороны или просто там напечатана ?
Wow !
Можете мне скинуть 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.» Вот с этим я согласен.