да я понял что редиректов в пределах пары тысяч.

P.S. @aekorotkov, вы делаете крутую работу! Жаль, что этот вариант не совсем подходит ?

и да я понял почему патч не приняли. это не индекс в его нормальном понимании.

Я бы смотрел в сторону разделения роута на фикс и регулярку, например /page/ и (\d+), индекс по строке, нахождение по индексу подходящих роутов с наилучшим совпадением и потом уже регулярка без всяких индексов

@pasha_golub, @Komzpa алярмо! Хулиганы пакости читать принуждапютЪ!

та они всегда ночью, ближе к утру пакостят ))

нужен админ из зауралья

можете меня выбрать админом :)

А ты насколько с востока?

С Хабаровска

И я тоже)) Го пить пиво?

о, комрады местные

го как-нибудь, почему нет, ты на чем пишешь?

В основном на plpgsql. Но могу и питон, шарп кор и 1С (но про последнее стараюсь не распространяться)

ого, уже пошла пропаганда не только алкоголя но и более тяжелых веществ ))

@priroda1vip ты бот?

@priroda1vip ты бот?

Эта борьба бесконечна. У ботов - у них как у воров - ты ему - ты бот, а он в отказ не может )

Эта борьба бесконечна. У ботов - у них как у воров - ты ему - ты бот, а он в отказ не может )

Тут все проще - он не ответил, значит бот и его может сразу банить один из админов

Подскажите запрос для частого юзкейза (имхо). Нужно выбрать последнюю книгу для каждого автора, например. Как это делается?

Тут все проще - он не ответил, значит бот и его может сразу банить один из админов

Его за аватарку сразу в бан

select first /* таблицы условия */ order by create_date desc

Подскажите запрос для частого юзкейза (имхо). Нужно выбрать последнюю книгу для каждого автора, например. Как это делается?

сначала отсортирует по убыванию в плане даты, то есть найдет по сути самую новую книгу, а после выберет только первую

Так ему же по каждому автору )

for select author_id /* условия */ do запрос

но не уверен в конструкции

Подскажите запрос для частого юзкейза (имхо). Нужно выбрать последнюю книгу для каждого автора, например. Как это делается?

JOIN LATERAL (... LIMIT 1)

ну или так..)

group by не?

create table books(authorid integer, bookid integer, pubdate date); insert into books values (1,1,'2017-01-02'); insert into books values (1,1,'2010-01-01'); insert into books values (1,2,'2017-01-02'); insert into books values (2,3,'2017-10-03'); select distinct authorid, first_value(bookid) over(partition by authorid order by pubdate desc, bookid) from books;

Сколько вариантов) А вот этот самый простой для меня https://stackoverflow.com/a/28085821/293962 Он не очень в плане произвоидтельности?

Сколько вариантов) А вот этот самый простой для меня https://stackoverflow.com/a/28085821/293962 Он не очень в плане произвоидтельности?

Он не подходит, вы получаете не самую последнюю книгу автора, а последнюю дату для каждой книги автора

Ну будет у меня там таблица с редиректами занимать гигабайт. Да хоть два, всем вообще до лампочки будет ) Это не вопрос для 2017го года. Те цифры что в рассылке приводятся вообще смешные. Я бы прямо сейчас побежал перекомпиливать контриб руками, если бы у нас не RDS был )

Очень похоже на работу для https://01.org/hyperscan https://github.com/01org/hyperscan https://m.habrahabr.ru/post/275507/

@priroda1vip ты бот?

это тот самый наркоман-аккаунт, который здесь уже рекламировали несколько раз, баньте его

Очень похоже на работу для https://01.org/hyperscan https://github.com/01org/hyperscan https://m.habrahabr.ru/post/275507/

Но опять же, этого нету "из коробки" в базе. Надо биндингами обмазываться и экстеншен пилить

Но опять же, этого нету "из коробки" в базе. Надо биндингами обмазываться и экстеншен пилить

Я думаю, это нужно делать в самом приложении, а не в базе (да простят меня гуру постгресса).

Я думаю, это нужно делать в самом приложении, а не в базе (да простят меня гуру постгресса).

Не совсем ясно как вы решили решать такую задачу в приложении.

Т.е. регулярки можно хранить в базе, но вытягивать их в приложение и компилировать hyperscan выражение. Да, нужно будет обновлять при изменении в базе.

да сделайте просто таблицу с кэшем урлов

Человек на хабрахабре, по-моему, решал очень похожую задачу.

Вы прочитали статью с хабра?

Поверхностно

Я пробежался, понял что это либа, и да что она компилит и на входтекст принимает

Но без допила мою задачу это не решает (условием было просто сделать запрос в базу)

Если вы пляшете от условия "нам, блин, обязательно нужно делать запрос в базу, иначе нам не заплатят", то жуйте кактус.

В текущих реалиях можно в целоми на Seq Scan жить, никто не помрет

Но

У нас еще намечается другой проект, я только сегодня вспомнил. Там так вообще хардкор, тоже надо будет в базе хранить регулярки похожим образом, только база регулярок должна будет пополняться редакторами

(прошу прощения за грубость. Накрутил себя по другому поводу, и не остыл ещё).

У вас есть, грубо говоря, горячие урлы, по которым реально человек придет и редирект должен сработать, и холодные урлы, по которым нужны редиректы, но на которые на самом деле никто не придет или придет раз в месяц. Для первого можно сделать просто key-value lookup, второй пусть идет другим путем и ждет свои N мс.

Типа делается запрос через "прокси" если матчится регексп то грубо говоря пользователю накидывается идентификатор к урлу и редиректится

А если регекспа нет то просто прозрачное проксироваие а урл уходит в таблицу "pending_urls_for_approvals"

Из которых потом ренерят регекспы на основе того, каких урлов больше в базе к которым нету регулярок

Вот там бы реально патч Короткова пригодился серьезно так

яб говноскрипт на ноде напесал, который реги скомпиленые кеширует и успокоился. + ключ в мемкеш на тему обновления списочка.... работы на пару часов

У вас есть, грубо говоря, горячие урлы, по которым реально человек придет и редирект должен сработать, и холодные урлы, по которым нужны редиректы, но на которые на самом деле никто не придет или придет раз в месяц. Для первого можно сделать просто key-value lookup, второй пусть идет другим путем и ждет свои N мс.

У нас горячих урлов для переадресаций и нету (чтобы куча трафика шло через них) т.е. только второй вариант, поэтому я и говорю, что и с Seq Scan можно пожить в целом

яб говноскрипт на ноде напесал, который реги скомпиленые кеширует и успокоился. + ключ в мемкеш на тему обновления списочка.... работы на пару часов

Прочитайте про upcoming проект чуть выше. Там нода загнется сразу )

ага. и бд положить можно. в целом. на 404 хорошо ддосить эти ваши цмс

(:

Счет будет идти на миллионы урлов. Там вообще не понятно как решать задачу

Самое время начать давать фидбэк продуктовому отделу по поводу технических сложностей

делайте не регулярные выражения, а какие-нибудь другие

Какие?

токенизируйте и по fts ищите ближайшее

Какие?

тебе ж сказали выше что это можно категоризовать по началу урла. /article/* /about/* итд

таким образом уменьшив перебор

сильно уменьшив кстати

Т.е. вот лежит у меня в базе миллион записей условных регулярок. Я делаю запрос https://entrypoint.com/proxy?url=https://google.com а на выходе должен получить 301 вида https://google.com/?affiliate_id=12345 если запись найдена для домена google.com

можно даже этот начальный кусок из рег выкусывать и требование редакторам на реги выставить под это дело

Проблема в том, что в том проекте все урлы не наши будут

мол никакних рег типа ^/(\d+)

Пример из реальной жизни. Есть магазин, ru.asus.com, de.asus.com и т.д.

Вот по сути это регулярка на ^(\w+)\.asus.com$

Если домен ru то один id надо ставить, если de то другой.

Таких примеров неограниченное кол-во ?

ну тогда страдай

Типа для немецкого стора одна партнерская сеть а для российского другая (маркировка юзеров)

Илья, ваши советы такие полезные!

это можно и иначе сделать, посплитать по точке, собрать массив и проверять вхождения в массив

это можно и иначе сделать, посплитать по точке, собрать массив и проверять вхождения в массив

Есть еще сторы которые делят страны в path части

ну в общем задав на реги ограничения хеш можно придумать

Простите, если я сильно далеко забегаю, но у меня ощущение, что продуктовый отдел и вправду не знает, что с технической стороны все очень плохо, и, возможно, надо спасать хотя бы готовящийся продукт.

Потому что есть ощущение, что они не знают/неверно оценивают влияние всего вот этого вот

Простите, если я сильно далеко забегаю, но у меня ощущение, что продуктовый отдел и вправду не знает, что с технической стороны все очень плохо, и, возможно, надо спасать хотя бы готовящийся продукт.

Это вопрос реализации. У нас есть другие варианты без этого. Но если сделать через боль как я описываю, получится большое конкурентное приемущество на рынке.

Есть еще сторы которые делят страны в path части

сплитай по слешу, точке, вопросу, амперсанду и равно

и ищи в токнах язык, например

сплитай по слешу, точке, вопросу, амперсанду и равно

И как мне потом среди этой кучи мусора разобрать где нужные данные а где нет?)

В целом я понял, что, похоже, вариант по регуляркам не особо рабочий и надо будет что-то другое придумывать

а кто ещё не обновился на Postgres 10 и хочет, чтобы обновление прошло менее болезненно, чем у нас, голосуйте за тикет про валидацию синтаксиса Set Returning Functions в DataGrip :) https://youtrack.jetbrains.com/issue/DBE-5117

Попробуйте hyperscan в приложении, как это описано в статье на хабре.

Попробуйте hyperscan в приложении, как это описано в статье на хабре.

В статье написано что перекомпиляция долгая. При постоянно добавляющихся регэкспах это может быть неприемлимо.

"постоянно добавляющиеся" - это 10 раз в секунду?

Если я правильно понял, по производительности @korotovskii и nginx устраивает, просто поддержание конфига в n-тысяч строк вызывает боль. Поэтому он и решил проверить вариант "а что это если все положить в базу и в приложении все удобно админить". Если все так, то hyperscan для него ещё больший головняк, чем конфиг nginx