Удалено модератором

Сожалею, что дискуссия пошла не туда, но тесты провел.

1. Отсюда http://regexpstudio.com/TRegExpr/TRegExpr.html взял TRegExpr.
2. Написал свою аналогичную функцию: упрощенный like, реализовал только % (другие вайлдкарды мне не нужны).
3. Провел 5млн поисков по выражению '60/1.*/100.*/1' по строке '60/11/1001/1'.
Мой код в ~3 раза быстрее (1.4 сек против 3.9 сек).
4. Отсюда делаю вывод: если мне нужен реально быстрый like, то нужно его писать самому (раз уж нет готовой реализации), а не пользоваться рег. выражениями. Еще лучше, если сделать его на асме, уверен, что будет еще быстрее.

Полагаю, что тема исчерпана.

круто, чо....

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

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

как никак почти сутки потрачены.

> iop ©   (19.12.16 20:05) [22]
> жаль только что мы не узнаем время, требуемое на вытягивание
> с mssql на клиента этих пяти мультов значений для клиентского
> лайка.


А что узнавать, время - 0.
Ибо данные уже находятся на моем же сервисе, в который заталкиваются данные при изменении в БД. Т.е. своего рода репликация... колхозная.
Конечно, есть потери времени при изменении БД. Но для моего случая они приемлемы, ибо специфика такова, что добавление данных не слишком массированное. Также возможна рассинхронизация, т.к. распределенной транзакции нет. Но в моем случае вероятность данной опасности стремится к нулю.

ЗЫ Приятно был удивлен скоростью работы TRegExpr. Изначально полагал, что разница будет существеннее.

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

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

значит данные на mssql.
а это значит, что чтобы отрапортовать шефу об экономии в 2.5 секунды надо сначала положить офисную сеть на время фетча с сервера этих пяти мультов записей.

> iop ©   (19.12.16 20:22) [24]
> данные твои на сервере и им потребовался клиентский лайк.


Серверов несколько.
Один - MSSQL.
Второй - сервис (мой), в котором и нужен like.


> а это значит, что чтобы отрапортовать шефу об экономии в
> 2.5 секунды


Я, пожалуй, обойдусь без репорта: просто перенесу информацию из одной извилины мозга в другую. Вот и весь репорт.

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

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

> iop ©   (19.12.16 20:37) [26]
> даже выиграл 2.5 секунды на пяти мультах значений,
> и даже уже понял, что этого никто не заметит,
> так как эти пять мультов еще выкачать надо......


Коллега, почему вы невнимательно читаете?
Данные выкачены (отреплицированы) в моем сервисе (в его памяти).
И расчеты будут вестись в рамках этого сервиса. Без обращения к БД.
Like'ов будет много. Очень. Поэтому 2.5 секунды большой выигрыш.

Данные выкачены (отреплицированы) в моем сервисе (в его памяти).

я читаю внимательно.

и пишу тоже внимательно.

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

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

и я внимательно после этого пишу и внимательно замечаю,
что реальный выигрыш - он мизерный.

хотя синтетический выигрыш и составляет 2.5 секнды на пять мультов записей.

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

и на этих реальных сутках (или неделе) ты и выиграл те самые две с половиной секунды.

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

> iop ©   (19.12.16 20:54) [28]


0. Время выкачки 5 мультов данных не обсуждаем. Ибо данные вообще могут получаться разными путями (хоть выкачка из БД ночью в файл с последующим использованием файла сервисом).

1. Представь себе, что есть информационная система (специально не говорю про БД, чтобы не было ошибочного мнения, что речь идет про SQL-сервер), в которой есть один большой массив:


Большой, это какой? Ну лям, может два. Пять лямов в моих тестах - это был запас прочности.
Поле key - это что-то типа строки, написанной выше.
Важно! Всего вариантов key не очень много (тысяч 20 максимум).
Про количество вариантов key я говорю, чтобы было понятно, что сервис на клиенте будет возвращать не так много данных (существенно меньше, чем те 5 лямов).

2. Мне нужно получать некую агрегированную информацию по массиву А.
Для этого моему сервису выдается задание: посчитай мне суммы value, у которых key удовлетворяет следующим маскам (т.е. передается набор масок) и верни мне массив этих сумм. Для нахождения суммы мне нужно будет в том или ином виде просматривать А и делать like для key. Фактов вызова like будет много.

3. В итоге время выполнения задания разбивается на две составляющие:
  а. Время like.
  б. Время суммирования value.
Поэтому, если я смогу сэкономить на пункте а, то это уже неплохо.
В общем времени работы сервиса - это будет немалая величина. Особенно при большом входном массиве key.

. Время выкачки 5 мультов данных не обсуждаем.

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

Мне нужно получать некую агрегированную информацию по массиву А.

ой, а разве на sql сервере, в первоисточнике так сказать,
нельзя выполнить запрос с непрокачанным на две секунды sql-лайком?

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

но мы про время фетча не хотим говорить, а как бы считаем что данные сразу у нас.

ой, я кажется понял!

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

не только лишь они!!!!

тебе не нужен настоящий sql сервер!

нужен свой.
умеющий только :
2. Мне нужно получать некую агрегированную информацию по массиву А.

точно!.
это еще пара секунд экономии.

правда года три упорного труда на написание .....
но это же фишня.
это уже само по себе хорошо!

> iop ©   (19.12.16 21:18) [32]

Коллега, а вам вообще знакома архитектура систем типа google?
Или любой другой, где используется горизонтальное масштабирование?

да откуда!
у меня же регексп в юзесах издревле сидел.

Или любой другой, где используется горизонтальное масштабирование?
вот любой другой - да. знаком.
свой.
с масштабированием, асинхронностью, гетерогенностью и кроссплтформенностью во всех трех слоях и прочими поэтессами.

> iop ©   (19.12.16 21:30) [34]
> вот любой другой - да. знаком.
> свой.
> с масштабированием, асинхронностью, гетерогенностью и кроссплтформенностью
> во всех трех слоях и прочими поэтессами.


Вот и вы, коллега, хвастаться начали. Но будем считать, что я этого не заметил.
Завязываем с этим разговором, который ничего полезного никому не принесет.

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

который ничего полезного никому не принесет.

репликация - зло.
любая.
хоть кем реализованная.
хоть студентом, хоть "коллективом солидной серьезной конторы"

есть первичные данные.
хочется отчетов и прочей аналитики - юзай первичные данные.

если кажется что это сложнее и больнее и вообще невозможно и надо реплицировать - стисни зубы, умри но научись юзать первичные данные.

какими бы распределенными они ни были.

> iop ©   (19.12.16 21:44) [37]

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

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

Так какую сущность мы воспринимаем по-разному? Тут лучше всего подойдет первое предложение Анны Карениной Л.Н. Толстого: Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему. Иносказательно я хочу пояснить мысль, что у каждого из нас своя система, которая эксплуатируется и развивается не первый год, есть практика, есть подходы, есть много кода, который написан, есть свои известные архитектурные косяки (или Вы святой и косяков нет?!). У каждого из нас есть представления, как правильно строить такие системы!

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

Мы же не архитектуру исходно моей системы обсуждали, верно?
Вопрос был простой - есть ли реализации like'а.

чо тут понимать-то?

ты вынул данные из их нативного хранилища и засунул в свой сервис.
и по началу все было хорошо.
но вдруг однажды понадобилось ТАМ обрабатывать клиентский массив но как бы по лайку.
и ты начал рисовать свой как бы скл-сервер со своим как бы лайком.

хотя нативный лайк и все остальное многобразие средств tsql никуда не делось.
просто кто-то решил, что данные удобнее хранить и обрабатывать в своих сервисах, а не там где это лучше и проще.

вот и весь сказ.