CIDC 2015

Кларионовские новости
Аватара пользователя
Admin
Администратор
Сообщения: 3536
Зарегистрирован: 05 Июль 2005, 14:59
Откуда: Хабаровск
Контактная информация:

CIDC 2015

Сообщение Admin »

kreator писал(а):Скорость надо сравнивать
Только учтите что скуль на "сервере" (обычный комп) и на Сервере это две большие разницы.
Дисковая подсистема хорошая, решает сильно.
Рай совершает ошибки ничуть не реже чем ад. Просто у него хорошая пресса

kreator
✯ Ветеран ✯
Сообщения: 3729
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

CIDC 2015

Сообщение kreator »

Admin писал(а):Только учтите что скуль на "сервере" (обычный комп) и на Сервере это две большие разницы.
Дисковая подсистема хорошая, решает сильно.
Скажу про SQLAnywhere, Firebird - недоскуль в этом смысле. Так вот, SQLAnywhere пытается запихнуть всю базу в память. Даже транзакции на добавление, удаление, изменение не пишутся сразу, ведётся только лог на случай потери питания. Поэтому запрос делается фактически только в памяти. Поэтому, мне кажется, скорость однозначно у SQL будет больше. Даже, если всё не помещается в памяти , то сервак "кэширует" запросы, второй такой-же запрос может идти на порядок быстрее. Сейчас у грандов появился режим In-Memory, при включении даже лог не пишется (страшно аж жуть).
We are hard at work… for you. :)

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1675
Зарегистрирован: 06 Ноябрь 2014, 12:48

CIDC 2015

Сообщение finsoftrz »

kreator писал(а): Не уговоришь на терминалку. Я как-то пропустил эту тему, возможно, тогда и не было терминального сервера. А теперь назад не пойду. Всё равно, мне кажется, скуль быстрее будет (и надёжнее). Скорость надо сравнивать, например, запросом по связанным пяти таблицам, имеющим по паре миллионов записей.
Я не уговариваю. Вопрос о целесообразности перехода. Я когда-то тоже думал на эту тему и экспериментировал с postgresql. Довольно плотно, даже нашел схему, при которой можно не использовать серверные курсоры и достаточно приемлемо работать с постраничным броузом на табличках с несколькими миллионами записей (там через callback подсовывался limit в запросы, а в настройках odbc использование серверных курсоров не включалось).
Но то, что увидел, все равно не впечатлило. Скорость интерактивной работы у sql медленнее, чем у tps на терминальном сервере. Сильно заметно на глаз. У tps вся база висит в кэше, а накладных расходов мало. Возможно, на чтении больших объемов у скуля будет преимущество за счет какой-нибудь хитрой оптимизации. Но в обычном режиме учетные программы большого количества записей не молотят, принято закрывать периоды и сохранять сводные итоги. Для надежности в программе с tps надо лог приделать. Это несложно и в плане аудита все равно нужно. Чинить же гораздо проще tps, так как таблицы плоские. А так сервера работают достаточно надежно. В общем, что надежнее, тоже не совсем однозначно можно сказать. Посмотрел на это, и забил, нет никакого профита, а работы очень много.
Рязань решает.

PavelNK
Старожил
Сообщения: 231
Зарегистрирован: 15 Март 2011, 8:02

CIDC 2015

Сообщение PavelNK »

В 2003 году переехали с DAT и TPS на MSSQL. Все супер, работает очень быстро. И работать гораздо удобнее. Но переехать просто поменяв драйвер вряд-ли получится. Кроме того, скорость работы может не только не увеличиться, но может и упасть. Нужно менять идеологию работы с БД. Поэтому нужно готовиться к тому, что многие вещи придется полностью переписывать.
При работе с файлами (DAT и TPS), основная работа идет на клиенте, а при работе с SQL ее нужно максимально перенести на сервер. Возможно придется менять структуру БД. Да и запросы нужно уметь писать грамотно. Разница во времени выполнения может быть колоссальная! Недавно исправляли один такой запрос: работал больше 20 сек, после оптимизации несколько миллисекунд. Многие вопросы SQL-сервер позволяет решать очень быстро. Тот факт, что все находится в одном файле и если одна таблица сломается, то сломается вся БД - миф. Были случаи когда вырубалось питание, а ИБП не было - был в ремонте. Стандартными процедурами все поправили. Кроме того, если решитесь в какой-то момент сменить инструмент, то процесс будет на порядок проще. Если не нравится ODBC или он чего-то не позволяет, можно работать через ADO - более продвинутая вещь.

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1675
Зарегистрирован: 06 Ноябрь 2014, 12:48

CIDC 2015

Сообщение finsoftrz »

Основной вопрос в том, что когда начинают сравнивать работу tps и sql, все рассматривают только файл-серверный режим. Там да, и скорость, и надежность у sql гораздо выше, если программа с sql сделана оптимально. Но сейчас сравнивать надо с терминальным режимом. Это примерно по скорости работы, как на локальном компьютере. То есть откройте приложение с tps на своем компьютере, посмотрите с какой скоростью оно работает. Примерно с такой скоростью оно будет работать у всех пользователей в терминале. Провал в производительности может быть, если вся база не помещается в кэше. Но это либо крупная контора с действительно очень большой базой данных, либо старый комп под сервер.
Рязань решает.

kreator
✯ Ветеран ✯
Сообщения: 3729
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

CIDC 2015

Сообщение kreator »

finsoftrz писал(а):Провал в производительности может быть, если вся база не помещается в кэше.
А что за кэш? Кто им управляет?
We are hard at work… for you. :)

PavelNK
Старожил
Сообщения: 231
Зарегистрирован: 15 Март 2011, 8:02

CIDC 2015

Сообщение PavelNK »

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

PavelNK
Старожил
Сообщения: 231
Зарегистрирован: 15 Март 2011, 8:02

CIDC 2015

Сообщение PavelNK »

А если в DAT или TPS таблицы нужно добавить поле(поля), то БД достаточно большая(сейчас уже не помню кол-во записей) конвертилась по несколько часов, SQL - доли секунд, если с заполнением вычисленным значением, то несколько секунд.

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1675
Зарегистрирован: 06 Ноябрь 2014, 12:48

CIDC 2015

Сообщение finsoftrz »

kreator писал(а):
finsoftrz писал(а):Провал в производительности может быть, если вся база не помещается в кэше.
А что за кэш? Кто им управляет?
Имеется ввиду дисковый кэш винды. Эффект можно легко увидеть на глаз. После перезагрузки сервера запускаем формирование какого-нибудь сложного отчета. Затем входим под другим пользователем и запускаем тот же отчет. Разница может быть на порядок. Это называют "прогрев кэша".
Рязань решает.

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1675
Зарегистрирован: 06 Ноябрь 2014, 12:48

CIDC 2015

Сообщение finsoftrz »

PavelNK писал(а): А если в DAT или TPS таблицы нужно добавить поле(поля), то БД достаточно большая(сейчас уже не помню кол-во записей) конвертилась по несколько часов, SQL - доли секунд, если с заполнением вычисленным значением, то несколько секунд.
Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
Рязань решает.

PavelNK
Старожил
Сообщения: 231
Зарегистрирован: 15 Март 2011, 8:02

CIDC 2015

Сообщение PavelNK »

finsoftrz писал(а):
PavelNK писал(а): А если в DAT или TPS таблицы нужно добавить поле(поля), то БД достаточно большая(сейчас уже не помню кол-во записей) конвертилась по несколько часов, SQL - доли секунд, если с заполнением вычисленным значением, то несколько секунд.
Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
2002-2003 года, но сервак был крутой - контора солидная. А 10-15 мин все равно не сопоставимо с долями секунд...

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1675
Зарегистрирован: 06 Ноябрь 2014, 12:48

CIDC 2015

Сообщение finsoftrz »

PavelNK писал(а): Так MSSQL, про другие не могу сказать - не знаю, точно также кэширует таблицы. Кроме того, он анализирует запросы и может строить скрытые индексы, которые позволяют существенно быстрее выполнять часть запросов.
Да, это так. При разработке на tps надо заранее предусматривать индексы и использовать их в коде. С одной стороны, это определенная работа, с другой стороны все без сюрпризов. Приложения с tps быстрее обрабатывают отдельные записи, sql-сервера заточены под массовые выборки. И это принципиально влияет на архитектуру приложения. И на мышление при разработке. Но я бы сказал, что в обоих случаях можно получить хороший результат, только несколько разными путями. Одно время sql-сервера были мэйнстримом, их активно продвигали в противовес файл-серверным системам, для оптимизации распределенного управления ресурсами. Сейчас это уже не совсем так, мощности выросли и мэйнстримом стал NoSQL. Пока эта тенденция в основном касается больших баз данных. Кстати, бывшая команда topspeed свалила именно в эту область.
Рязань решает.

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1675
Зарегистрирован: 06 Ноябрь 2014, 12:48

CIDC 2015

Сообщение finsoftrz »

PavelNK писал(а):
finsoftrz писал(а):
PavelNK писал(а): А если в DAT или TPS таблицы нужно добавить поле(поля), то БД достаточно большая(сейчас уже не помню кол-во записей) конвертилась по несколько часов, SQL - доли секунд, если с заполнением вычисленным значением, то несколько секунд.
Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
2002-2003 года, но сервак был крутой - контора солидная. А 10-15 мин все равно не сопоставимо с долями секунд...
Ну, структура данных дл больших таблиц меняется далеко не каждый месяц... В данном случае, операции разные.
Рязань решает.

Shur
Ветеран
Сообщения: 384
Зарегистрирован: 02 Июль 2011, 17:49

CIDC 2015

Сообщение Shur »

kreator писал(а): ODBC, конечно, выход, но не туда. Если сравнивать с SQLite, которому он не нужен. Есть достаточно надёжная, быстро работающая файловая БД (это я про TPS). Осталось только прикрутить SQL-синтакс и давать разработчикам библиотеку для работы. Пусть в dll, пусть за небольшие деньги, пусть с ограниченным функционалом (с неограниченным при работе через Clarion). И дело бы пошло.
Kreator, моё почтение. Здесь речь шла о разработчиках на стороне клиента? Для этого желателен SQL-синтакс? Поясни, пож.

kreator
✯ Ветеран ✯
Сообщения: 3729
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

CIDC 2015

Сообщение kreator »

Shur писал(а):Kreator, моё почтение. Здесь речь шла о разработчиках на стороне клиента? Для этого желателен SQL-синтакс? Поясни, пож.
Я уже где-то писал (может здесь) - у нас есть такой функционал. Пользователь может ввести SQL-запрос (как есть, например) и получить результат в виде банальной не форматированной выгрузки в Excel. Но функционал не востребован совсем. Во-первых, нужно очень хорошо знать структуру данных (таблицы, связи ...). Во-вторых, нужно очень хорошо знать сам SQL, плюс его диалекты. Создать запрос по пяти нетривиально связанным таблицам - уже непростое дело даже для нас. Сидим, например, в IBExpert'е, крутим, вертим, типа оптимизируем. Хотя "потенциальные" заказчики, когда приходят посмотреть продукт, обычно спрашивают - "Можно что-нибудь самим наваять?". Причём, естественно, не хотят сильно вникать в тему, хотят очень простой механизм. У нас нет идеи - как сделать простой механизм как для запросов, так и для генерации, допустим, отчётов. Есть на рынке коммерческие продукты, которые это позволяют сделать, подключившись напрямую к БД (по-моему, IBM Cognos достаточно продвинутая вещь в этом плане).
We are hard at work… for you. :)

Ответить