Использование баз

[azat20]

Добрый день! Относительно скоро Новый Год. Хотелось бы узнать кто как борется с набравшими гигабайты инфы и тысячи документов базами. Ведь база объемом десятки гигов и десятки тысяч документов может тормозить в работе. И документы не удалишь. Кто что делает, чтобы базы работали оптимально? Пересоздаете базы после нового года, или как?
Может кто-то использует единое место работы для документов, и например в аутлайне разделено все по годам, и соответственные ссылки на другие базы есть?

 

[morpheus]

архив делаеться

а вообще почитайте, недавно поднималось

Ссылка скрыта от гостей

 

[ToxaRat]

Ведь база объемом десятки гигов и десятки тысяч документов может тормозить в работе

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

 

[K-Fire]

Код тут вообще не причем. Если в базе 100к документов и штук 50 тяжелых видов (каждый по 200-300 мегабайт), то база будет тормозить неизбежно. Даже на AS/400

Надо правильно архитектуру системы продумывать, а это не каждому дано

 

[azat20]

Ну красота и оптимальность кода тоже играет свою роль. Если все документы получать по db.Search, это ж тоже не есть хорошо.

TO Тоха: клиентам Eclipse версию ставишь или Basic. Просто Eclipse ресурсов ест немало, а тут порой и 512 МБ не каждому поставишь

Код тут вообще не причем. Если в базе 100к документов и штук 50 тяжелых видов (каждый по 200-300 мегабайт), то база будет тормозить неизбежно. Даже на AS/400 smile.gif

Надо правильно архитектуру системы продумывать, а это не каждому дано

У Вас как решен этот вопрос?

 

[ToxaRat]

TO Тоха: клиентам Eclipse версию ставишь или Basic. Просто Eclipse ресурсов ест немало, а тут порой и 512 МБ не каждому поставишь

я говори исключительно о сервере клиент стоит в основном старый

Если в базе 100к документов и штук 50 тяжелых видов

то это самый тяжелый код!
или виды по вашему не программистами создаются?

 

[TIA]

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

Да вам Нобелевка полагается! У Вас АБСОЛЮТНО МАСШТАБИРУЕМАЯ система! Вы достигли теоретически недостижимого предела!
Но мне что-то подсказывает, что скорее просто масштаб системы игрушечный.

 

[ToxaRat]

Да вам Нобелевка полагается! У Вас АБСОЛЮТНО МАСШТАБИРУЕМАЯ система! Вы достигли теоретически недостижимого предела!
Но мне что-то подсказывает, что скорее просто масштаб системы игрушечный.

последние мои проверки базировались на том, сколько сейчас можно впихнуть в базу - практически
мне удалось залить базу под самое нехочу - 64гига, убедиться что это в среднем 16мл. доков, около 20 видов и всё работает и если доки при этом менять лишь те что требуется системка продолжает адекватно летать
именно из-за этого я и сделал заявку что моя система может хранить данные 45 лет(если вводить по 1000доков в день(и по выходным тоже))
с точки зрения ДБ2 это конечно игрушечный подход, но как для лотуса то весьма сносно

 

[Akupaka]

TIA, браво!

 

[TIA]

мне удалось залить базу под самое нехочу - 64гига, убедиться что это в среднем 16мл. доков, около 20 видов и всё работает и если доки при этом менять лишь те что требуется системка продолжает адекватно летать
именно из-за этого я и сделал заявку что моя система может хранить данные 45 лет(если вводить по 1000доков в день(и по выходным тоже))

Ну, наверно не хранить, а нормально функционировать?
Действительно впечатляющие теоретические результаты! Но это при условии реалистичных оценок многих других показателей. Например,
на каком железе, на скольких серверах реплики , каково общее число пользователей, сколько одновременно работающих, какова интенсивность модификации документов, интенсивность чтений документов и навигаций по представлениям? Разделён ли доступ к документам? Каков процент пользователей видят менее 20% документов, а менее 80%?
В среднем 4кб на документ -- это значит БД почти без вложений?
Есть ли не теоретические, а практические показатели?

 

[K-Fire]

Гмм, "адекватно летать" это такой весьма расплывчатый термин

Интересно, сколько времени БД открывается, сколько времени открывается вид с максимальным кол-вом документов?

Насколько я себе представляю, проблема с производительностью лотуса связана напрямую с размером базы, и 64гиговая БД просто не может работать с такой же скоростью как и 6ти гиговая например. Или в 8.5 сервере у IBM наконец тормоза перестали линейно расти с ростом базы?

 

[Akupaka]

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

 

[K-Fire]

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

 

[ToxaRat]

K-Fire
статью мою по ДАОС читал?
в администраторе теперь два столбца где файлы логический размер и физический размер

 

[azat20]

Обсуждение куда-то немного не в ту степь уходят. Все каждый год пересоздают базы кроме ToxaRat? или что делают?

 

[TIA]

Все каждый год пересоздают базы кроме ToxaRat? или что делают?

ещё архивируют,
ещё не под Новый Год, а чаще
ещё параллельно наполняют не одну БД, а несколько(цепляясь, например, за день недели создания документа),
ещё разбивают документ одной БД на составные части (части - в разных БД, подкачиваются при показе, в пределе - только ярлыки документов)
ещё части агрегируют в один документ (части при этом, как правило, из одной БД)
ещё выносят части в другое, не Notes-хранилище
ещё всё перечисленное в разных сочетаниях

 

[ToxaRat]

Ну, наверно не хранить, а нормально функционировать?
Действительно впечатляющие теоретические результаты! Но это при условии реалистичных оценок многих других показателей. Например,
на каком железе, на скольких серверах реплики , каково общее число пользователей, сколько одновременно работающих, какова интенсивность модификации документов, интенсивность чтений документов и навигаций по представлениям? Разделён ли доступ к документам? Каков процент пользователей видят менее 20% документов, а менее 80%?
В среднем 4кб на документ -- это значит БД почти без вложений?
Есть ли не теоретические, а практические показатели?

+

ещё параллельно наполняют не одну БД, а несколько(цепляясь, например, за день недели создания документа),
ещё разбивают документ одной БД на составные части (части - в разных БД, подкачиваются при показе, в пределе - только ярлыки документов)
ещё части агрегируют в один документ (части при этом, как правило, из одной БД)

=
обычная СЭД в лотусе, всегда всё дробится иначе если всё скинуть в одну кучу все показатели производительности падают на ХХ порядков

как минимум юзаю Optimize document table map - тоесть каждый вид заточен как минимум лишь под один вид доков
TIA
если есть сомнения что всё это лишь "теория" могу организовать встречу с реальными клиентами моей системы на их територии, при условии что ты хочешь купить мою СЭД

из всех теоритических и практических выкладок лично мне интересен последний репорт ИБМ в том, что они смогли на одном домино сервере активно держать 400.000 юзеров, для меня интересно КАК они это сделали?

 

[TIA]

как минимум юзаю Optimize document table map - тоесть каждый вид заточен как минимум лишь под один вид доков

Кстати, айбиэмеры признались, что реального повышения производительности при использовании "Optimize document table map" не происходит.

если есть сомнения что всё это лишь "теория" могу организовать встречу с реальными клиентами моей системы на их територии, при условии что ты хочешь купить мою СЭД

Да нет. Просто для того, чтобы цифры хоть что-то говорили и что бы заявлять о каких-то параметрах системы, надо оговаривать условия их получения.
Иначе числа просто красивая реклама, ничего не обещающая, но такая заманчивая. Ваши заявленные параметры вполне достижимы, но в весьма узком диапазоне прикладных задач.

Ну а если

=
обычная СЭД в лотусе

Так Azat и интересовался, как в разных СЭД решаются подобные задачи. А Вы что советуете -- "оптимизируйте код". В реальных СЭД этого обычно мало и без специальных мер не обойтись. Вот и рассказали бы о своей необычной СЭД.

Ещё мне понравилось утверждение

то это самый тяжелый код!
или виды по вашему не программистами создаются?

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

 

[ToxaRat]

Кстати, айбиэмеры признались, что реального повышения производительности при использовании "Optimize document table map" не происходит.

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

TIA
окей!
давай поговорим что у топиксайдера необычного в СЭД и что у него такого, что нельзя решить обычными мерами?

гигабайты инфы и тысячи документов

это обычная СЭД и всё тут решается обычными методами, причем у каждого тут как минимум есть 3 метода как это решить, правильно?

мне самому интересно, что может заставить к примеру использовать часть данных под DB2 именно не выходя за рамки СЭД

 

[TIA]

но в базах где у меня всего одна форма - всегда включаю, хотя и не исключаю, что если форма одна то и результат всегда будет один

Следуя рекомендациям, достаточно того, что в каждом представлении БД отбираются документы только по одной форме и имя формы у документов не меняется. Одна форма на БД -- это уже частность. Достаточное, но не необходимое условие применимости.

давай поговорим что у топиксайдера необычного в СЭД и что у него такого, что нельзя решить обычными мерами?

Да от куда мне знать-то, что там такого необычного! Это пусть Azat сам расскажет, гадать можно долго. А может ответы и решения уже найдены, что-то мы в этом топике вдвоем остались?