Кто и как решает проблемы со скоростью и объемом данных?
- Anderyt
- Активный участник
- Сообщения: 777
- Зарегистрирован: 15 июл 2004, 13:15
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Тюмень
- Контактная информация:
Кто и как решает проблемы со скоростью и объемом данных?
в продолжение темы http://www.lplm.ru/phpBB2/viewtopic.php?p=2190#2190
у нас сейчас около 260 тыс. записей об объектах (object_reference) и более 4 млн записей об атрибутах (attrib_value).
проблем в принципе не замечаем. но уже стараемся оптимизировать структуру данных, а то не ровен час...
одно время кстати была проблема, некоторые операции (особенно удаление объекта из проекта) выполнялись неадекватно долго. но кто-то (то ли Теххелп, то ли кто-то с форума) посоветовал обновлять статистику. сейчас эта работа постоянно активна на сервере и та проблема, снявшись сразу же, больше не возникала.
но про размеры БД и оптимизацию данных мы сейчас думаем практически постоянно...
у нас сейчас около 260 тыс. записей об объектах (object_reference) и более 4 млн записей об атрибутах (attrib_value).
проблем в принципе не замечаем. но уже стараемся оптимизировать структуру данных, а то не ровен час...
одно время кстати была проблема, некоторые операции (особенно удаление объекта из проекта) выполнялись неадекватно долго. но кто-то (то ли Теххелп, то ли кто-то с форума) посоветовал обновлять статистику. сейчас эта работа постоянно активна на сервере и та проблема, снявшись сразу же, больше не возникала.
но про размеры БД и оптимизацию данных мы сейчас думаем практически постоянно...
лучше день потерять, потом за пять минут долететь!
- Старик Крупский
- Активный участник
- Сообщения: 803
- Зарегистрирован: 27 июл 2006, 22:17
- Откуда: Москва
- Anderyt
- Активный участник
- Сообщения: 777
- Зарегистрирован: 15 июл 2004, 13:15
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Тюмень
- Контактная информация:
я просто ожидал конкретики от других участников
минимизировать число атрибутов у объектов - это наверное слишком банально (но все равно мы стараемся это учитывать)..
а вот недавно наткнулся на таблицы с записью о правах - и понял, что в них практически основное зло каждая запись хранится отдельно и при этом каждый раз при обращении к чему либо происходит обращение и к этим таблицам. поэтому решили немного почистить права у объектов. чем меньше записей - тем, по идее, должно быть лучше. начали с архивных документов. оставили там простой доступ для одной группы (до этого там были права, необходимые для оперативной работы, а при перемещении проектов в архив мы права не изменяли). я не имею в виду права на документы, они конечно забираются перед началом согласований. а вот права на объекты... с ними уже все было не так хорошо...
минимизировать число атрибутов у объектов - это наверное слишком банально (но все равно мы стараемся это учитывать)..
а вот недавно наткнулся на таблицы с записью о правах - и понял, что в них практически основное зло каждая запись хранится отдельно и при этом каждый раз при обращении к чему либо происходит обращение и к этим таблицам. поэтому решили немного почистить права у объектов. чем меньше записей - тем, по идее, должно быть лучше. начали с архивных документов. оставили там простой доступ для одной группы (до этого там были права, необходимые для оперативной работы, а при перемещении проектов в архив мы права не изменяли). я не имею в виду права на документы, они конечно забираются перед началом согласований. а вот права на объекты... с ними уже все было не так хорошо...
лучше день потерять, потом за пять минут долететь!
- Disillusioned
- Активный участник
- Сообщения: 420
- Зарегистрирован: 15 июл 2004, 15:12
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Подольск
- Контактная информация:
Указанные размеры БД проблемными не являются (если я правильно понял, речь идет о Sybase), особенно, если нет необходимости в выборке больших наборов данных.
По моему опыту, основная проблема производительности при росте размера БД, выборка атрибутов. Боремся написанием хранимых процедур на основе динамического SQL для БД Sybase, но это именно для сложных выборок типа ведомости материалов. Выборки малого объема пока проблем не вызывали.
По моему опыту, основная проблема производительности при росте размера БД, выборка атрибутов. Боремся написанием хранимых процедур на основе динамического SQL для БД Sybase, но это именно для сложных выборок типа ведомости материалов. Выборки малого объема пока проблем не вызывали.
Ах и с ними невозможно
И без них никак нельзя
И без них никак нельзя
- Anderyt
- Активный участник
- Сообщения: 777
- Зарегистрирован: 15 июл 2004, 13:15
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Тюмень
- Контактная информация:
у нас MS SQL Server..
я не говорю, что проблема уже на уровне сервера БД, вовсе нет (а ксати, когда проблемы должны начаться на MS SQL??). здесь вопрос в другом. чем больше записей в таблицах - тем медленнее работают запросы. или это не так?
просто мне кажется, что это является причиной снижения производительности (не единственной, конечно), вот мы и боремся с этим всеми возможными силами.
другой момент. иногда есть реальная возможность отказаться от обращений к таблицам с правами (ведь включать в вид только те объекты, которые в любом случае доступны на просмотр абсолютно всем). и если делать отчеты по ЭТИМ видам, то работать они будут быстрее.
или нет?
я не говорю, что проблема уже на уровне сервера БД, вовсе нет (а ксати, когда проблемы должны начаться на MS SQL??). здесь вопрос в другом. чем больше записей в таблицах - тем медленнее работают запросы. или это не так?
просто мне кажется, что это является причиной снижения производительности (не единственной, конечно), вот мы и боремся с этим всеми возможными силами.
другой момент. иногда есть реальная возможность отказаться от обращений к таблицам с правами (ведь включать в вид только те объекты, которые в любом случае доступны на просмотр абсолютно всем). и если делать отчеты по ЭТИМ видам, то работать они будут быстрее.
или нет?
лучше день потерять, потом за пять минут долететь!
- Disillusioned
- Активный участник
- Сообщения: 420
- Зарегистрирован: 15 июл 2004, 15:12
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Подольск
- Контактная информация:
- Anderyt
- Активный участник
- Сообщения: 777
- Зарегистрирован: 15 июл 2004, 13:15
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Тюмень
- Контактная информация:
(говорю про MS SQL Server) был настроен Database Maintenance Plan, в котором была поставлена галочка Update the statistics used by the query optimizer (80%).
работа была создана автоматом, настроили запуск раз в неделю.. в таком режиме уже работаем чуть больше года
работа была создана автоматом, настроили запуск раз в неделю.. в таком режиме уже работаем чуть больше года
лучше день потерять, потом за пять минут долететь!
-
- Новый участник
- Сообщения: 2
- Зарегистрирован: 15 май 2007, 13:48
- Откуда: Тюмень
- Контактная информация:
Спасибо) Правда, у нас Sybase ASA, но посмотрим в этом направлении, ибо проблема с тормозами точь-в-точь как у вас: неправдоподобно долгие операции и особенно удаление из проектаAnderyt писал(а):(говорю про MS SQL Server) был настроен Database Maintenance Plan, в котором была поставлена галочка Update the statistics used by the query optimizer (80%).
работа была создана автоматом, настроили запуск раз в неделю.. в таком режиме уже работаем чуть больше года
- Disillusioned
- Активный участник
- Сообщения: 420
- Зарегистрирован: 15 июл 2004, 15:12
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Подольск
- Контактная информация:
В Sybase ASA это делается всего одним оператором DROP OPTIMIZER STATISTICS
Зато в Sybase SQL Anywhere 10 обрубать статистику надо на каждую таблицу отдельно, да к тому же требуется монопольная блокировка таблицы (а проблемы-то с оптимизатором возникают не реже)
Зато в Sybase SQL Anywhere 10 обрубать статистику надо на каждую таблицу отдельно, да к тому же требуется монопольная блокировка таблицы (а проблемы-то с оптимизатором возникают не реже)
Ах и с ними невозможно
И без них никак нельзя
И без них никак нельзя