Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! В большой таблице имеются даные за несколько лет. Данные за прошлые года изменяются очень редко. Отчеты чаще всего формируются за один какой-то год (в основном за текущий). Имеет ли смысл для увеличения производительности выносить данные за прошлые года в другие таблицы(архивные)? P.S. БД: ASA9.0.2, ОС: WinXP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 14:19 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
сколько строк в большой таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 14:42 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Filimonenko SergeyИмеет ли смысл для увеличения производительности выносить данные за прошлые года в другие таблицы(архивные)? А проблемы с производительностью присутствуют только при построении аналитической отчетности, или при текущей каждодневной работе пользователей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 15:47 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Filimonenko SergeyЗдравствуйте! В большой таблице имеются даные за несколько лет. Данные за прошлые года изменяются очень редко. Отчеты чаще всего формируются за один какой-то год (в основном за текущий). Имеет ли смысл для увеличения производительности выносить данные за прошлые года в другие таблицы(архивные)? P.S. БД: ASA9.0.2, ОС: WinXP Смысл есть. Мы, например, бъем по кварталам, так как штатного сегментирования таблиц в ASA нет. В ORACLE есть, но у нас нет ORACLE :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 15:48 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Рыжий Котсколько строк в большой таблице? Предполагается, что будет по 10000 строк в год. Одна запись приблизительно 600 байт (22 колонки) A.K.А проблемы с производительностью присутствуют только при построении аналитической отчетности, или при текущей каждодневной работе пользователей? Система пока только разрабатывается, но будут присутствовать сложные аналитические отчеты за определенный период. Вот и хотелось бы узнать, как правильнее будет сделать, чтоб в дальнейшем при наполнении таблицы не возникало проблем с производиельностью. michael_Смысл есть. Мы, например, бъем по кварталам, так как штатного сегментирования таблиц в ASA нет. В ORACLE есть, но у нас нет ORACLE :) А вы не могли бы опасать хоть как-то количественно увеличение производительности? Или на таком объеме может лучше просто установить индекс по дате и не мучаться с разбиением таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 16:22 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Filimonenko Sergey wrote: > Предполагается, что будет по 10000 строк в год. Дальше не читаем. Вот если было бы 10 000 000 в год ... Или у вас в качестве сервера П2-300/64 ;)? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 16:25 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
michael_ wrote: > Смысл есть. Мы, например, бъем по кварталам, так как штатного > сегментирования таблиц в ASA нет. Геморрой, думаю, тоже есть ;)? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 16:25 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Dim2000 > Предполагается, что будет по 10000 строк в год. Дальше не читаем. Вот если было бы 10 000 000 в год ... Или у вас в качестве сервера П2-300/64 ;)? +1. При таких объемах даже о-о-очень сложные аналитические отчеты могут строиться быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 17:58 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Filimonenko Sergey пишет: > В большой таблице имеются даные за несколько лет. > Данные за прошлые года изменяются очень редко. > Отчеты чаще всего формируются за один какой-то год (в основном за текущий). > Имеет ли смысл для увеличения производительности выносить данные за > прошлые года в другие таблицы(архивные)? Смысла нет. Доступ по индексу имеет стоимость log(N) , где N - размер таблицы. Поэтому что 1 млн записей, что 10 - абсолютно все равно. Имеет смысл только чистить таблицу когда места нет или хочется его съэкономить. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 18:32 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Filimonenko Sergey пишет: > Предполагается, что будет по 10000 строк в год. Одна запись > приблизительно 600 байт (22 колонки) Это ОЧЕНЬ МАЛО, это не те объемы при которых надо об этом думать. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 18:33 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
При таких обьемах будет иметь смысл структура базы, запросы и индексы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 20:44 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Dim2000 michael_ wrote: > Смысл есть. Мы, например, бъем по кварталам, так как штатного > сегментирования таблиц в ASA нет. Геморрой, думаю, тоже есть ;)? Posted via ActualForum NNTP Server 1.4 Конечно, есть :) Но и производительность не проседает. Об особенностях оптимизатора тут не раз писалось. 2 автор 10 000 не объем. Серьезный объем начинается где-то с 1 000 000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2007, 09:54 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
MasterZiv Filimonenko Sergey пишет: > В большой таблице имеются даные за несколько лет. > Данные за прошлые года изменяются очень редко. > Отчеты чаще всего формируются за один какой-то год (в основном за текущий). > Имеет ли смысл для увеличения производительности выносить данные за > прошлые года в другие таблицы(архивные)? Смысла нет. Доступ по индексу имеет стоимость log(N) , где N - размер таблицы. Поэтому что 1 млн записей, что 10 - абсолютно все равно. Имеет смысл только чистить таблицу когда места нет или хочется его съэкономить. Posted via ActualForum NNTP Server 1.4 Это не совсем так, если сложные условия фиьтра, особенно если может присутствовать неравенство, то объем имеет значение. У нас, например, пользователь может наложить любые условия на просмотр. Кроме этого, не забывайте, речь идет не об ASE. Там, действительно, с этим получше. Метод сегментирование таблиц является классическим и описан в литературе. Повторюсь, в ORACLE он реализован штатно и я думаю не просто так они себе геморой искали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2007, 10:00 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
Да и еще :) Это конечно же надо делать только тогда, когда производительность реально проседает и никакими другими способами разогнать запросы не удается. И применять это надо только к данным пополняющимся ежедневно, например, бухпроводки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2007, 10:13 |
|
||
|
Разбиение большой таблицы на несколько
|
|||
|---|---|---|---|
|
#18+
michael_ пишет: > Это не совсем так, если сложные условия фиьтра, особенно если может > присутствовать неравенство, то объем имеет значение. Нет, это именно так. При больших объемах данных какие-то способы доступа кроме индексного не работают (быстро). Поэтому другой способ доступа не должен рассматриваться вообще. Разбиение же таблицы на куски (partitioning by criteria) можно запросто заменить созданием соответствующего индекса. У нас, например, > пользователь может наложить любые условия на просмотр. Это не очень хорошо, но если в запросе есть помимо этих условий еще обязательно присутствующий SARG, то это ничего. Если его нет - это вообще недопустимо. > Кроме этого, не забывайте, речь идет не об ASE. Там, действительно, с > этим получше. А это все равно. ASA ничем не хуже ASE, индексы есть практически везде. > Метод сегментирование таблиц является классическим и описан в > литературе. Повторюсь, в ORACLE он реализован штатно и я думаю не просто > так они себе геморой искали. Не все золото, что блестит. Не все хорошо, что ORACLE. Но на счет partitioning by criteria я согласен, достаточно хорошее свойство. Но не так уж и необходимое. Сейчас оно вроде бы и в ASE 15 появилось. Обещали по крайней мере. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2007, 10:31 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=34409273&tid=2012189]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
66ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 437ms |

| 0 / 0 |
