dbf vs sql - производельность
Модераторы: Trinity admin`s, Free-lance moderator`s
dbf vs sql - производельность
взяли небольшую базу (4 гига), загрузили в sql, запустили перепроведение. точные измеренеия проводить желание сразу отпало - sql медленнее где-то на порядок (то бишь в 10 раз).
перепроведение было выбрано по простой причине: для нас сейчас больная тема - транзакции, внутри транзакций то же самое проведение документов и идет (нам его требуется максимально ускорить).
вопрос - это нормальный результат или руки кривые?
перепроведение было выбрано по простой причине: для нас сейчас больная тема - транзакции, внутри транзакций то же самое проведение документов и идет (нам его требуется максимально ускорить).
вопрос - это нормальный результат или руки кривые?
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: dbf vs sql - производельность
SQL медленнее. Она предназначена прежде всего для целостности. В зависимости от конфигурации системы SQL может быть чуть медленнее, но никак не в разы. Если вы напишите хотя бы приложение, конфигурацию сервера, дисковую систему, распределение данных по дисковым системам. Плюс скажете настраивали ли SQL или по умолчанию, а может еще запустите счетчики, то вам может быть и ответят, в чем вы не правы.edo писал(а):взяли небольшую базу (4 гига), загрузили в sql, запустили перепроведение. точные измеренеия проводить желание сразу отпало - sql медленнее где-то на порядок (то бишь в 10 раз)
Пока имхо вы где-то не правы.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Самое смешное - упор у Вас был в сеть или производительность писюка, на котором крутилась 1С .Фишка в том, что по сети клиент тянет к себе все - что с SQL, что с dbf - и SQL действительно по определению медленнее. Особенно - когда его используют как тупое хранилище Именно из-за этого с 1С7.7 часто используются терминальные решения.
А RAID0 - никогда не используйте для хранения данных.
Самая забавная картина по этому поводу - в гугле: поищите по словам "Помогите" и RAID0
А RAID0 - никогда не используйте для хранения данных.
Самая забавная картина по этому поводу - в гугле: поищите по словам "Помогите" и RAID0
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
И еще самая забавная штука, что за словом SQL 1C 7.7 скрывается так называемые портированные DBF с их плоской структурой. Единственный момент, который позволяет SQL, это увеличить надежность записываемых данных за счет транзакций записи этих самых данных. В этом случае надобность в переиндексации отпадает. А в скорости здесь не выиграть, тем более на 7.7
Для решения этой проблемы можно воспользоваться внешней компонентой 1с++ (http://www.1cpp.ru), которая позволяет получать с SQL сервера то, что нужно. В нашем случае выборка данных и соответственно проведение ускорилось до 10-15 раз.Фишка в том, что по сети клиент тянет к себе все - что с SQL, что с dbf - и SQL действительно по определению медленнее.
PS при условии того, что у нас SQL сервер отдельно, терминал отдельно.
реально индексы в 1с портятся не так уж и часто (при сетевой работе), при работе в терминале - фактически никогда.
а запрос на переиндексацию означает просто, что какой-то процесс 1с завершился не совсем нормально и это отражено в базе. грубо говоря аналогично поступает винда на fat-разделах - после некорректного завершения работы она запускает проверку файловой системы (в случае ntfs же происходит откат журнала - неожиданная ассоциация с sql).
таким образом, при терминальной работе запрос на переиндексацию можно спокойно игнорировать, хотя повторюсь - мы для успокоения совести каждую ночь делаем автоматическую переиндексацию.
подводя итог - довод о отсутствии переиндексации в sql достаточно спорен. с другой стороны sql имеет неспоримые плюсы - возможность снимать бэкапы с рабочей базы, теоретически большую надежность, быстрые отчеты и т.д.
но вот наша проблема - ступор 1с при массовом проведении документов, и sql её не только не решит, а только усугубит.
объясняю - sql не отменяет транзакцию как блокировку всего и вся на запись и при этом увеличивает продолжительность проведения документов (то есть продолжительность транзакции).
2a_shats: я толком не понял во что всё уперлось. сеть и процессор клиента нагружены очень слабо, дисковая сервера тоже
2NetIq: про тот баг я внимательно читал - он проявляется как постепенное замедление проведенния документов. у меня же sql начинает перепроводить документы сущесвенно медленнее dbf. падает ли ещё скорость перепроведения в дальнейшем - не проверял и желания такого не имею
а запрос на переиндексацию означает просто, что какой-то процесс 1с завершился не совсем нормально и это отражено в базе. грубо говоря аналогично поступает винда на fat-разделах - после некорректного завершения работы она запускает проверку файловой системы (в случае ntfs же происходит откат журнала - неожиданная ассоциация с sql).
таким образом, при терминальной работе запрос на переиндексацию можно спокойно игнорировать, хотя повторюсь - мы для успокоения совести каждую ночь делаем автоматическую переиндексацию.
подводя итог - довод о отсутствии переиндексации в sql достаточно спорен. с другой стороны sql имеет неспоримые плюсы - возможность снимать бэкапы с рабочей базы, теоретически большую надежность, быстрые отчеты и т.д.
но вот наша проблема - ступор 1с при массовом проведении документов, и sql её не только не решит, а только усугубит.
объясняю - sql не отменяет транзакцию как блокировку всего и вся на запись и при этом увеличивает продолжительность проведения документов (то есть продолжительность транзакции).
2a_shats: я толком не понял во что всё уперлось. сеть и процессор клиента нагружены очень слабо, дисковая сервера тоже
2NetIq: про тот баг я внимательно читал - он проявляется как постепенное замедление проведенния документов. у меня же sql начинает перепроводить документы сущесвенно медленнее dbf. падает ли ещё скорость перепроведения в дальнейшем - не проверял и желания такого не имею
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Лет 5-6 назад я долго пытался понять, чем занимается сервер и клиент 1С в сети. Отслеживал сетевые пакеты, снимал статистику по процессору, памяти, дискам на сервере. Речь тогда шла о 7.7 билд 014 по сети. Честно говоря причину найти не удалось. Видимо в момент проведения документов 1С пытается по сети блокировать базу целиком, ей это долго не удается. Решение простое - терминалка. На базах до пары гигов идеальна.edo писал(а):но вот наша проблема - ступор 1с при массовом проведении документов, и sql её не только не решит, а только усугубит.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 20 гостей