> iop ©   (19.12.16 22:06) [39]


Хороший тезис. Продолжаем)

Как вы в своей масштоасинхронногетерогеннокроссплтформенной системе решаете следующую задачу: построение отчетов?

Вот есть, например, отчет, который затрагивает таблицу, в которую ведутся постоянные (раз в секунду, например) добавления. Отчет на sql строится долго - несколько минут.

Вот как вы избегаете deadlock'ов?

> Вот есть, например, отчет, который затрагивает таблицу,
> в которую ведутся постоянные (раз в секунду, например) добавления.
>  Отчет на sql строится долго - несколько минут.
>
> Вот как вы избегаете deadlock'ов?


Используя соответствующие уровни изоляции транзакций, вроде, иначе трудно.

> Игорь Шевченко ©   (19.12.16 22:33) [41]
>
> Используя соответствующие уровни изоляции транзакций, вроде,
>  иначе трудно.


Игорь, неужели у вас не бывает deadlock'ов?
Ну вот представь, что нужен серьезный отчет - из 10 таблиц да еще и за год.
А при этом в таблицы добавляются данные, изменяются данные, удаляются данные.

Неужели нет проблем?

ЗЫ Знаю, что у тебя Оракл. Петр Абрамов мне рассказывал, что Оракл творит чудеса, будучи версионником. Но поверить сложно...

> Неужели нет проблем?


А с чего бы им появиться ?
Тебя не удивляет же тот факт, что штатными средствами делается резерная работоспособная копия базы данных, в которую во время копирования могут также вноситься изменения.
Про изоляцию транзакций в MS SQL тут все вроде написано
https://msdn.microsoft.com/ru-ru/library/ms173763.aspx

> Отчет на sql строится долго - несколько минут.

Это не долго. Проходил практику, там бывало отчёты по 15 минут думали (запросы сами).
Запихнуть весь этот запрос в штатный профилировщик и создать в БД индексы, которые тот посоветует?

An a Student   (20.12.16 00:24) [44]

"Вы, сударь, ерунду говорите. И хуже всего то, что говорите безапеляционно и уверенно"

> http://regexpstudio.com/TRegExpr/TRegExpr.html
тоже раньше пользовался, пока не наткнулся на какое то ограничение (там в модуле посмотри 2004го года вроде последнее обновление) пришлось срочно переделывать на http://www.regular-expressions.info/pcre.html (перловский синтаксис)

> хочу некоторую фильтрацию делать на клиенте
> если мне нужен реально быстрый like, то нужно его писать самому
сам быстрый вряд ли сделаешь, к примеру вот до этого думал о индексах? like поддерживает, в некоторых случаях. вообще индексы в твоей локальной структуре есть?
+
локальный рекордсет ADO поддерживает и локальные индексы и локальный же, убогий (с некоторыми отличиями от серверного MSSQL-евского) like, который тем не менее наверняка круче любого "велосипеда".

> sniknik ©   (20.12.16 13:34) [46]


1. Ты только не подумай, что на основе одного примера я делаю выводы, что все, что написано другими - плохо, а все мое - хорошо.
Вот сам пример (понятно, что утрированный):


У меня на Дельфи2007 он выполняется 2808 сек. Причина в StringReplace (жуткий алгоритм).
Мой аналогичный алгоритм делает это за 0.2 сек.

Это я к тому, что генофонд от производителя не всегда безупречен.
И в определенных случаях, возможно, что самописное решение будет лучше стандартного.
Так... немного философии.

2. Теперь по сути. Все обсуждаемое еще не написано полностью, но все требуемые компоненты (сервисы, сервер на им. каналах,  пр.) есть из других проектов. Пока думаю над горизонтальным масштабированием: считать некоторые отчеты не в БД, а рядом. Хочу пилота сделать и представить остальному коллективу.
Но коллега iop (с) поселил во мне сомнения в правильности того, что я хочу сделать. Возможно, он прав и надо убиться об стену, но считать все в БД. Буду думать.

3. Насчет ADO. Спасибо, посмотрю.

4. Индексы есть. По сути вариантов key не так много (несколько тысяч). Все различные варианты key+индексы соответствующих строк в А по сути и есть индекс.
С учетом малости вариантов key согласен с коллегой iop (c), что можно воспользоваться TRegExpr, а не писать свой like.

> Это я к тому, что генофонд от производителя не всегда безупречен.


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

Ты привел неудачный пример для иллюстрации. Можно и содержимое большого файла обрабатывать, прочитав его в TMemo, и так тоже делают, но этот вовсе не повод для критики TMemo.

> Игорь Шевченко ©   (21.12.16 14:31) [48]
> Ты привел неудачный пример для иллюстрации.


Ну почему же?

Вот нужно тебе в большом тексте заменить одно на другое. Берешь StringReplace (а с чего бы взять другую функцию? функция есть, она описана, не сказано, что не подсовывать большие строки). И получаешь результат в 2808 секунд.

Вот ты бы в подобной ситуации (когда надо заменить в большой стоке одно на другое) взял бы другой овощ (функцию)? Какую? Как бы ты, опытный разработчик, понял, что использовать StringReplace не надо ибо она медленная?

Пример, кстати жизненный. В доке к MSSQL сказано, что sp_exec кеширует план запроса, если все объекты fully qualified, т.е. имеют префикс [DataBaseName].[dbo] перед таблицами, процедурами и вьюхами. Я собрал батч, где место для [DataBaseName].[dbo] помечено маркером, вызвал замену маркера на [DataBaseName].[dbo] и сижу жду... Честно говоря, я когда наконец понял, почему у меня стало в порядок работать медленнее, был поражен неоптимальностью алгоритма в StringReplace...

> Мой аналогичный алгоритм делает это за 0.2 сек.
сравни вот с этим http://www.loginovprojects.ru/index.php?page=faststringreplace
у меня он показал 16 милисекунды, хотя это на разных машинах ничего не значит, StringReplace проверять не стал (подождал с минуту и прервал)

время засекал так

> Вот нужно тебе в большом тексте заменить одно на другое


а) Мне крайне редко нужно менять "в большом тексте одно на другое"
б) Еще в 1988 году я написал себе функцию замены текста (на С, разумеется), которая приемлемо по скорости работала и если мне таки потребуется поменять в "большом" тексте, я буду использовать приемлемый алгоритм.

> sniknik ©   (21.12.16 17:24) [50]
> > Мой аналогичный алгоритм делает это за 0.2 сек.
> сравни вот с этим http://www.loginovprojects.ru/index.php?
> page=faststringreplace

Спасибо. Быстрее в 4 раза. Возьму его. Пусть будет. К тому же мой не работает в режиме IngnoreCase (не нужно было и не написал).

Тимохов Дима ©   (19.12.16 22:13) [40]

   Честно говоря не совсем понятно с чем связаны deadlock у вас, но это не причина, писать какой-то свой сервер подобие SQL, в крайнем случае можно использовать  2 SQL сервера для разных задач.
  Рассмотрите повышение производительности другими путями, пересмотрите код (к стати в некоторых отчетах можно использовать "грязное чтение"), возможно серверу можно добавить просто ОЗУ либо более быстрые диски поставить.
Не забывайте о том что в итоге такой проект выйдет дороже чем апгрейд сервера. Сделать пилот это одно, а потом провести его тестирование, вылавливать баги и заниматься поддержкой - другое.

> Игорь Шевченко ©   (19.12.16 22:33) [41]
>
> > Вот есть, например, отчет, который затрагивает таблицу,
>  
> > в которую ведутся постоянные (раз в секунду, например)
> добавления.
> >  Отчет на sql строится долго - несколько минут.
> >
> > Вот как вы избегаете deadlock'ов?
>
>
> Используя соответствующие уровни изоляции транзакций, вроде,
>  иначе трудно.

Исчерпывающий ответ!
Просто это сообщение... возникает в процессе развития БД, от его очень трудно избавиться, не переписывая логику. А так чтение ни при чем.

> трудно избавиться, не переписывая логику


Это придется сделать рано или поздно. т.к. частые deadlock это не нормально при любой нагрузке.
А какая версия MS SQL ?