ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Целостность vs Быстродействие. Переносить ли в архивную таблицу?
34 сообщений из 34, показаны все 2 страниц
  все  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412061
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
Данная тема также размещена в форуме Проектирование БД. сорри.
Есть система под Oracle с более 300 клиентами. В данный момент система не устраивает по некоторым требования и принято решение о переписывании всего с нуля.
Требуется разработать структуру БД для реализации под Oracle и Interbase (для установки на объекты с меньшим количеством пользователей и интенсивностью запросов).
Есть основная таблица, в которой много полей, основные - Идентификатор и Состояние.
Добавление записей в эту таблицу - 10 тыщ в день.
У каждой добавленной записи поле Состояние почти последовательно проходит значения от 1 до 10.
После достижения значения 10 запись становится архивной - поля не меняются.
Сегодняшняя реализация:
Все клиенты раз в 15 секунд делают выборку из этой таблицы с условием Состояние = Некоторой_константе, эта константа определяет тип приложения. Т.е. разные клиентские места выбирают записи с определенным состоянием и производят дальнейшую их обработку, меняя Состояние, тем самым передавая данную запись другим клиентам.
В сегодняшней реализации из-за большой загрузки сервера (доходит почти до 100%) сделано архивирование данных - объекты с Состоянием = 10 переносятся в другую таблицу. Через месяц еще в одну - для статистики. Все 3 таблицы имеют одинаковую структуру.
Обрабатывать 3 таблицы конечно не удобно, сделаны view`шки объединяющие все 3 таблицы и т.д.
Разработчиками были приняты следущие тезисы:
1. Алерты (события) - глючность, они не всегда работают. Поэтому выборка данных производится исключительно селектами.
2. Уменьшение количества записей в основной таблице до 1000 приводит к приемлимой нагрузке, доведение до 3-4 тысяч - к неприемлимой.
3. Для обеспечения приемлимой работоспособности необходимы архивные таблицы (они сделаны на других серверах).

Для нормальной структуры БД с ссылочной целостностью оч. большой геморрой делать архивные таблицы - практически целостность убивается т.к. объект на который ссылаются может кочевать по разным таблицам.

ХОЧЕТСЯ И ЦЕЛОСТНОСТИ И БЫСТРОДЕЙСТВИЯ!
Часть базы является динамической - должна быть быстрой, часть архивной - десятки миллионов записей.

Есть понятие секционированные таблицы - но они тока в Оракле.
Можно сделать ключ на вьюшку, объединяющую основную и архивную таблицы - тоже тока в Оракле.

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

Мой вариант: одна таблица с индексом по Состоянию. 2 вьюшки - одна заточена на Состояние = 10 (архив) другая наоборот Состояние <> 10 (рабочая). Вьюшки предназначены для большего разграничения доступа к таблице, что б каждая использовалась в своем контексте.
Думается, что select * from work_view where State = n не должен занимать много ресурсов?

Что посоветуете?
...
Рейтинг: 0 / 0
17.02.2004, 14:47
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412234
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
IB - это не Оракл и запросы на представления с UNION ALL мягко говоря буду мало оптимальными.
Я тут вижу 2 направления, над которыми можно поразмыслить:
1) Всё будет лежать в одной таблице с целочисленным первичным ключём. Также должна быть таблица, в которой будут храниться пороговые значения ключа, например сегодня записи начиная с номера 1000 - это оперативные данные, а начиная с номера 500 - это данные за текущий месяц. Ну и соответственно построить представления, в которых для отбора будет использоваться этот ключ (возможно его лучше сделать составным).
2) Создать несколько таблиц с избыточностью данных. Организовать бизнес логику так, чтобы при изменении данных в основной таблице делались нужные изменения также в таблице оперативных данных и таблице данных за весь месяц.

Что бы я из этого выбрал - я не знаю. Тут надо думать...
...
Рейтинг: 0 / 0
17.02.2004, 15:50
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412254
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
Собственно порогом является архивное значение Состояния (10).
Вопрос насколько быстродействующая схема получится если в одну таблицу все забабахать?
...
Рейтинг: 0 / 0
17.02.2004, 16:01
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412277
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
Ну всё это сложно, конечно. Быстродействие зависит от многих факторов. Вот я когда-то тупо свою базу на Линукс скопировал и там расчёты запустил - чудеса!!! всё раза в 3 быстрее считалось.
Почитай статьи на ibase.ru о стоимости доступа к данным, о выборе оборудования, о выборе размеров страницы БД и т.п. - всё это может сильно повлиять на конечный результат.
Я думаю что тормозить начнёт когда в таблице будет записей миллионов эдак надцать... Хотя это отфонарная оценка. Можно и на тысяче записей тормоза поиметь...
...
Рейтинг: 0 / 0
17.02.2004, 16:10
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412296
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mv
Участник
1. Алерты (события) - глючность, они не всегда работают. Поэтому выборка данных производится исключительно селектами.
?

В смысле, как второе вытекает из первого?
...
Рейтинг: 0 / 0
17.02.2004, 16:17
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412309
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
to Gold:
О том и речь, что можно (и нужно) много чего почитать, но наверняка кто-нить делал что то подобное и знает чем это кончилось. Передо мной - негативный пример, но там много огрехов, потому и переписываем.
Живая ли схема что я предложил? Т.е. записи из таблицы не удаляются вообще. И добавляются тысячами в день. Порядка 20 выборок в секунду с 300 клиентов select count(*) from sometable where State=n. По State построен индекс. Время добавления записи не так критично.
...
Рейтинг: 0 / 0
17.02.2004, 16:20
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412334
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
авторПорядка 20 выборок в секунду с 300 клиентов select count(*)
Я бы такое на IB не рискнул делать...
...
Рейтинг: 0 / 0
17.02.2004, 16:30
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412336
Dedushka Mazai
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dedushka Mazai
Участник
сталкивался с аналогичной проблемой. из-за тормозов данные пришлось разнести на две таблицы: оперативные - в одной, архивные - в другой. СУБД: MSSQL.
...
Рейтинг: 0 / 0
17.02.2004, 16:30
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412337
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
to mv:
Как мне видится варианты обновления информации на клиентах:
1. Подписка на событие. По приходу события выборка. Наиболее грамотно. Но есть подозрение что не устроит по надежности. Думаю, что можно контрольный селект сделать, зарядить его если алерт не появляется минут 5. Типа повысить надежность. Хотя мне кажется инфа о глючности алертов преувеличена. Все зависит от рук.
2. Селект по таймеру. Не грамотно. Сопряжено с серьезным увеличением нагрузки на сервак.
3. Написать тригер, который что-нить выполняет. Например, заносит нечто в вспомогательную таблицу, откуда клиенты селектом выбирают признак обновления данных. Коллеги отговаривают.
4. Написать свою реализацию алертов. Пожалуй самый тернистый путь. Хотя много где обсуждался и есть с чего сдирать. Тернист из-за завязки на конкретную реализацию. Хотелось бы от этого уйти.
По большому счету - выбор между селектами и алертами. Или еще чего-то?
...
Рейтинг: 0 / 0
17.02.2004, 16:30
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412349
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
2 Dedushka Mazai:
Как с целостностью порешили? Отказались или наворачивали дубляжи таблиц?
...
Рейтинг: 0 / 0
17.02.2004, 16:34
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412405
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mv
Участник
Порядка 20 выборок в секунду с 300 клиентов select count(*) from sometable where State=n.

Мысли вслух:

Если вариантов значений State немного, можно поступить как-нибудь так: Табличка State_T:
(state : integer
Counter : integer);

Триггеры - After Insert
---------
declare variable cnt integer;
...
select count(*) from State_T into :cnt where State = New.State;
if cnt <> 0 then
insert into State_t (State, Counter) values (New.State, 1)
else
update State_t set Counter = Counter + 1 where
State_t.State = New.State

After delete
---------
...
update State_t set Counter = Counter - 1 where
State_t.State = Old.State

After update
---------
if (old.State <> new.State) then begin
UPDATE State_t T SET T.Counter=T.Counter-1
WHERE T.State = old.State;
UPDATE State_t T SET T.Counter=T.Counter+1
WHERE T.State = new.State;
end

И далее в том же духе.

Естественно, "пишущие" транзакции д.б. с соответствующим уровнем изоляции.

А юзеры просто выбирают вместо
select count(*) from sometable where State=n
-
select State_t.Counter from State_t where State=n

Ну, еслши нужно, чтобы не заводить много табличе, можно завести доп поле - идентификатор, что это за sometable:

select State_t.Counter from State_t where State=n and Sometable = 'Table_One'
...
Рейтинг: 0 / 0
17.02.2004, 16:51
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412406
Dedushka Mazai
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dedushka Mazai
Участник
к сожалению, не помню, так как это было давно и делалось не мной. вроде как с целостностью проблем не было, так как на данные никто не ссылался: они просто накапливались и по ним строилась статистика
...
Рейтинг: 0 / 0
17.02.2004, 16:51
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412494
Фотография ytenok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ytenok
Участник
2 mv

IMHO: этот эффект можно получить индексом: (status_id, id), притом индекс может работать быстрее т.к. нету расходов на вызов update/insert.
...
Рейтинг: 0 / 0
17.02.2004, 17:29
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32412993
Фотография Я и ёжик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Я и ёжик
Участник
Вообще странно, что выборка 1000 или 3000-4000 тысяч активных записей может вызывать проблемы.

Для Oracle если по state сделать индекс и если при этом занчением "архивная" будет не 10 а NULL (NULL значения в Oracle не попадают в индекс) то мы получим маленький компактненький индекс для выборки записей в активном состоянии (от 1 до 9), и не надо никаких архивных таблиц.
Соответственно никаких проблем со ссылочной целостностью, запись как лежала в одной таблице , так и продолжает лежать.

Как поступает IB с NULL значениями в индексе не знаю.
...
Рейтинг: 0 / 0
18.02.2004, 10:19
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32413356
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
ИБ вроде как тоже NULL-значения не индексирует...
...
Рейтинг: 0 / 0
18.02.2004, 12:51
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32413375
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Ошибаешься
...
Рейтинг: 0 / 0
18.02.2004, 12:58
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32413395
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
Хм, помниться ещё об этом в конференции споры были. Я Д. Еманову показывал из Open feature request:

автор 451953 Indexes with NULLs Feature request

Allow for NULL values to be included in the index data, using the syntax:

CREATE [WITHNULLS] INDEX...

Он мне тогда сказал что это совсем из другой оперы, но чё-то мне показалось что NULLы не индексируються :-/
...
Рейтинг: 0 / 0
18.02.2004, 13:06
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32413441
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Индексируются.
...
Рейтинг: 0 / 0
18.02.2004, 13:18
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32413456
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
А что это тогда за CREATE [WITHNULLS] INDEX... ???
...
Рейтинг: 0 / 0
18.02.2004, 13:22
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32413469
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
CREATE TABLE Demo(ID INTEGER);
CREATE INDEX IDX1 ON Demo(ID);

INSERT INTO Demo VALUES( 0 );
INSERT INTO Demo VALUES( 1 );
INSERT INTO Demo VALUES( 2 );
INSERT INTO Demo VALUES( 3 );
INSERT INTO Demo VALUES( 4 );
INSERT INTO Demo VALUES(NULL);

COMMIT WORK;

SET PLAN
SET STATS

SELECT * FROM Demo WHERE ID IS NULL;

         ID 
=========== 
     <null> 

PLAN (DEMO INDEX (IDX1))
...
Рейтинг: 0 / 0
18.02.2004, 13:26
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32413495
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
GoldА что это тогда за CREATE [WITHNULLS] INDEX... ???

Понятия не имею. Этот feature request не я писал ;-)
...
Рейтинг: 0 / 0
18.02.2004, 13:33
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32414485
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
Хм... я чего-то не понимаю... Вы извините, я человек простой и привык все ручками щупать. Так вот:


Машина:
PIV2GHz 256RAM Win2K Prof FB.RC7 Super


База:
Естественно кеш не 2048 а немного больше, всего на один нолик.
Остальное в конфигурации by default.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
create table tbl1
(
Id     integer,
Status integer
);

create generator gen1;

create index IDX_STATUS on tbl1 (Status);

set term ^ ;
create or alter procedure AddRecs(I integer, Status integer)
as begin
while (:I> 0 ) do
  begin
  insert into tbl1(Id, Status) values (gen_id(gen1,  1 ), :Status);
  I=:I- 1 ;
  end
end ^
set term ; ^




Скрипт заполения базы:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
execute procedure AddRecs( 1000000 ,  10 );
commit;
.... и так  10  раз.

execute procedure AddRecs( 1000 ,  1 );
execute procedure AddRecs( 1000 ,  2 );
.... и так  10  раз.
commit;



Клиент:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
while not NeedStop do
  begin
  Tr.StartTransaction;
  Q.SQL.Text:=' select count(*) from tbl1 where Status='+IntToStr(Random( 9 )+ 1 );
  TStart:=Now;
  Q.ExecQuery;
  TEnd:=Now;
  Tr.Commit;
  Sleep(Random( 10000 ));
  end;



Да, я понимаю что записи отбираются каждый раз одни и те же, но т.к. у dao+ обновление данных идет не очень активно я решил им пренебречь, но чтобы как-то компенсировать, клиенты дают запрос не каждые 15, а каждые 10 секунд.

Итак:
400 коннектов загрузка процессора ~80%
500 коннектов загрузка процессора ~95%

так же немогу не отметит что запуганый этим топиком я сначала тестировал не на такой базе, а на базе заполненой так:
execute procedure AddRecs(100, 1);
execute procedure AddRecs(100, 2);
...
результаты были лишь немного лучше.


Ктому же, господин dao+ говорит что "Есть система под Oracle", а InterBase это "для установки на объекты с меньшим количеством пользователей и интенсивностью запросов". 400 запросов достаточно меньшая интенсивность?


Причина по которой такая система может тормозить, приходит на ум такая: в Informix если в предложении select были только те поля которые есть в индексе который использовался при отборе, то страници самой таблици не считывались в память а значения в результат брались из самого индекса. То же самое и для результирующих запросов при отборе которых использовался один индекс. Проще говоря в Informix запрос
Код: plaintext
select count(*) from tbl1 where Status= 1

был бы выполнен без чтения страниц таблици tbl1 с диска.

У меня есть подозрение, что IB/FB так неможет впринципе. Почему: потому что даже при чтении вопервых должна идти уборка мусора, а вовторых IB/FB должен поставить какой-то флаг в заголовке записи. Хотя помоему для red_committed транзакций это возможно лишнее.

Короче. Есть предложение разделить таблицу, но не вертикально (архив/актив), а горизонтально (ключ/данные) тоесть:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create table TStatus
(
Id  integer,
Status integer
);

create table TData
(
Id  integer,
...
...
);

Связь по Id 1к1. Тогда если при выполнении запроса дергаются страници данных таблици, страниц будет гораздо меньше. Можно даже в TData завести копию поля Status, чтоб при запросах к TData не надо было лезть за статусом в TStatus.
...
Рейтинг: 0 / 0
18.02.2004, 22:59
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32414712
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
Andrey_
Короче. Есть предложение разделить таблицу, но не вертикально (архив/актив), а горизонтально (ключ/данные) тоесть

Совершенно верно, так и надо. Пришел к тем же результатам.
С индексами IB 6.5 (думаю что и другие версии IB тоже) работает самым непонятным образом. И для моей задачи эти капризы не подходят. (Смотрел планы и Performance analysis в IBManager). Так что первоначальный вариант с индексацией по полю state в IB может не прокатить.
Кстати, господа, советую поглядывать в Performance analysis - оч интересные и неочевидные вещи можно обнаружить. Например, select .... where state > 1 и where state >=2 совершенно разные запросы в моем случае, хотя результат и смысл один. И если архивные записи хранятся state = 1 то первый запрос сделает посути fullscan хотя и по индексу а второй пробежит тока нужные записи. А если архивные записи хранятся state = 10 а не архивные значение меньше, то как не крути - fullscan. Индексы сделал и восходящие и нисходящие - бестолку.
А вот с внешней таблицей все вроде как хорошо получается и не зависит от выбранной СУБД. С планами и анализом выполнения тоже все хорошо.
...
Рейтинг: 0 / 0
19.02.2004, 10:06
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32414963
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
>select .... where state > 1 и where state >=2 совершенно разные запросы\r
\r
>если архивные записи хранятся state = 10 а не архивные значение меньше, то как не крути - fullscan\r
\r
Вы сами себе противоречите, а как же state<=9 :)\r
\r
Если интересно, я когда-то делал еще тест на этом же железе.\r
\r
\r
Мой вывод такой: при отсутствии тяжелых запросов и присутствии PIV2GHz c Win2K Prof, FB1.5 RC7 спокойно держит 300 пишущих/читающих коннектов.\r
\r
Естественно объем RAM подлежит расчету. Для такого расчета можно отталкиватся от статьи . + от того что для любого запроса происходит чтение страниц даннх таблиц.
...
Рейтинг: 0 / 0
19.02.2004, 11:59
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415355
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Andrey_У меня есть подозрение, что IB/FB так не может в принципе. Почему: потому что даже при чтении во-первых должна идти уборка мусора, а во-вторых IB/FB должен поставить какой-то флаг в заголовке записи. Хотя по-моему для read_committed транзакций это возможно лишнее.

Это все сочинительство. Ключ индекса не хранит номер транзакции, так что для определения валидности записи для текущей транзакции надо лезть за этой записью на страницы данных и читать tra_number для всех ее версий с целью поиска подходящей. Других причин невозможности full index scan нет.

dao+С индексами IB 6.5 (думаю что и другие версии IB тоже) работает самым непонятным образом.

Все зависит от желания разобраться.

dao+Кстати, господа, советую поглядывать в Performance analysis - оч интересные и неочевидные вещи можно обнаружить. Например, select .... where state > 1 и where state >=2 совершенно разные запросы в моем случае, хотя результат и смысл один. И если архивные записи хранятся state = 1 то первый запрос сделает посути fullscan хотя и по индексу а второй пробежит тока нужные записи.

Угу, есть такая негативная особенность. Хотя с неочевидностью я бы поспорил ;-)
...
Рейтинг: 0 / 0
19.02.2004, 14:04
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415918
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
>dimitr
>Это все сочинительство...
Спасибо что поправили. Это было всего лишь предположение.

А позвольте тогда вопрос. Ведь одна запись может иметь несколько версий. И в каждой версии ключевые значения могут быть разные. И на каждую такую версию должна быть ссылка на странице индекса (пусть индекс ссылается на элемент из Pointer Page не так важно). Тоесть фактически в индексе хрянятся ссылки на все версии, в том числе и давно устаревшие.

Пример: когда-то была одна версия записи Id=1. Потом в результате update появилась новая версия Id=2, и стала актуальной (commit). Сейчас когда я делаю select Id from ... where Id=1 сервер вынужден читать страницу на которой когда-то была версия Id=1.

Я понимяю что это нужно для очистки мусора. Но может быть лучше было бы отказатся от такой политики очистки мусора и с целью ускорения поиска по индексу в элементы индекса добавить tra_number? Понятно что это некоторая избыточность, но это значительно ускорит поиск по индексу, а значит и общую производительность.

Если так уж нужна чистка при select то можно будет по tra_number в индексе определить устарела ли версия на которую указывает этот элемент. В таком случае всеравно получаем выиграш за счет того что ненадо читать страници с немусорными записями (ведь мы уже при чтении индекса знаем что они не мусор).

P.S. Вы извините если я глупости давно понятные говорю. Просто проявляю любопытство.
...
Рейтинг: 0 / 0
19.02.2004, 17:20
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415931
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
авторПример: когда-то была одна версия записи Id=1. Потом в результате update появилась новая версия Id=2, и стала актуальной (commit). Сейчас когда я делаю select Id from ... where Id=1 сервер вынужден читать страницу на которой когда-то была версия Id=1.

Угу, все приблизительно так и происходит.

авторЯ понимяю что это нужно для очистки мусора. Но может быть лучше было бы отказатся от такой политики очистки мусора и с целью ускорения поиска по индексу в элементы индекса добавить tra_number? Понятно что это некоторая избыточность, но это значительно ускорит поиск по индексу, а значит и общую производительность.


Это не некоторая, а вполне конкретная избыточность. Ибо теперь придется хранить в индексе все версии ключа, включая неизмененные . Т.е. в индексе будет (1, 1, 1, 2, 3, 2, 2, 2 и т.п.) вместо текущих (1, 2, 3). Т.е. индекс распухнет и его чтение обойдется дороже, чем чтение страниц с данными.
...
Рейтинг: 0 / 0
19.02.2004, 17:27
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415959
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
Andrey_
Вы сами себе противоречите, а как же state<=9 :)

А вот и не фига :-)))) state <=9 обрабатывается также глупо как и state >1 и state = 10.
Почему и говорю что неочевидно и без тестов не обойтись.

dimitr
Все зависит от желания разобраться.
...
Угу, есть такая негативная особенность. Хотя с неочевидностью я бы поспорил ;-)


Я согласен с тем, что разработчик должен хорошо знать особенности СУБД. Но не всегда возможно охватить тонкости весего спектра требуемых по ТЗ поддерживаемых СУБД.
...
Рейтинг: 0 / 0
19.02.2004, 17:46
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415979
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
>dimitr
Хм... из статьи в котокой сказано "IB читает все записи таблицы в их естественном порядке собирая пары из ключевого значени и идентификатора записи (так называемого db-key). Затем этот набор сортируется по ключевому значению и создается нижняя часть индекса, со сжатием дубликатов ключевых значений ." мне показало что должно существовать промежуточное звено через которое устанавливается ссответствие "в каких записях были версии с таким ключевым значением".
Аналогия: как промежуточная таблица в отношение могие-ко-многим между "набором сжатых дубликатов ключевых значений" и "записями в таблице"

Вот в элементах этого звена я и предлогал разместить tra_number.

Иначе как установлена связь между "набором сжатых дубликатов ключевых значений" и "записями в таблице"?


>dao+
Стоп секунду. Есть таблица в которой 10001000 записей. 10000000 из них Status=10 у остальных Status<10. При выборке select count(*) where Status<10 сервер действительно замирает на какое-то время. А выборка select count(*) where Status<=9 отрабатывает почти мгновенно. Отсюда можно сделать вывод что я непонимаю термина fullscan который вы привели.
...
Рейтинг: 0 / 0
19.02.2004, 17:55
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32416112
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Andrey_Иначе как установлена связь между "набором сжатых дубликатов ключевых значений" и "записями в таблице"?

"asdf" -> <сжатый ключ 1> + rec_number 1
"qwerty" -> <сжатый ключ 2> + rec_number 2

Т.е. каждая запись (все ее версии) представлена одним ключом индекса. Скорее всего, тебя ввела в замешательство фраза про "набор сжатых дубликатов ключевых значений". Это не единое целое, а набор отдельных ключей - т.е. значения ключа в неуникальном индексе дублируются. Просто сжимаются они инкрементно, с общим префиксом и динамическим суффиксом. Это позволяет сэкономить на хранении и в то же время обеспечить первую фазу поиска в b-tree без необходимости декомпрессии.
...
Рейтинг: 0 / 0
19.02.2004, 19:54
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32416151
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
Мда... Лоханулся я немного :)

Но тогда всеравно непонимаю почему это приведет к распуханию индекса. Ведь элементы индекса нижнего уровня итак содержат динамический суффикс+указатели на PointerPage (минимум 4 байта) и наверняка на элемент врутри PP (минимум 1, а скорее 2 байта). А идентификатор транзакции состоит из 4 байт. Тоесть в лучшем случае мы имеем элемент размером 6 байтов, а в худшем 6+полная длина ключа (если нельзя выделить общий префикс). Думаю лишних 4 байта (идентификатор транзакции) небудут лишними и погоды не сделают.

Хотя... Скорее всего я где-то ошибаюсь... Ведь наверняка не я первый такое придумал :)
...
Рейтинг: 0 / 0
19.02.2004, 20:54
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32416933
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
авторНо тогда всеравно непонимаю почему это приведет к распуханию индекса. Ведь элементы индекса нижнего уровня итак содержат динамический суффикс+указатели на PointerPage (минимум 4 байта) и наверняка на элемент врутри PP (минимум 1, а скорее 2 байта). А идентификатор транзакции состоит из 4 байт. Тоесть в лучшем случае мы имеем элемент размером 6 байтов, а в худшем 6+полная длина ключа (если нельзя выделить общий префикс). Думаю лишних 4 байта (идентификатор транзакции) небудут лишними и погоды не сделают.

50% прирост среднего размера индекса ты считаешь незначительным? ;-) Но на самом деле, проблема-то в другом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
start transaction  1 ;
insert into my_table (fld) values ( 1 );
commit;
start transaction  2 ;
update my_table set fld =  1  where fld =  1 ;
commit;
start transaction  3 ;
update my_table set fld =  2  where fld =  1 ;
commit;


Сейчас:
<key1><rec_number1>
<key2><rec_number1>

Будет:
<key1><rec_number1><tra_number1>
<key1><rec_number1><tra_number2>
<key2><rec_number1><tra_number3>

Где key >=1 байта, rec_number = tra_number = 4 байта.

Разница понятна?
...
Рейтинг: 0 / 0
20.02.2004, 13:57
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32417125
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
dimitrСейчас:
<key1><rec_number1>
<key2><rec_number1>

Будет:
<key1><rec_number1><tra_number1>
<key1><rec_number1><tra_number2>
<key2><rec_number1><tra_number3>

Где key >=1 байта, rec_number = tra_number = 4 байта.

Вы меня убили :) Все понятно, слов нет... туплю по черному...

P.S. Спасибо за объяснения.



Все ниженаписаное было придумано и написано до э...озарения :)

dimitr50% прирост среднего размера индекса ты считаешь незначительным?
Хм...
rec_number=4 байта
Key=минимум 3 байта (почему 3: минимум 1 байт на значение и 2 байта на длинну значения. Почему на длинну 2 а не 1: потому что как я слышал в FB2 будет снято ограничени на длинну ключа в 256 байт)

Тоесть уже один элемент имеет минимальную длинну 7 байт. + 4 байта на tra_number будет 11. Тоесть в худшем случае размер индекса увеличится на ~70% от первоначального. Если на ключ приходится 2 байта то на 50%.

Мда... многовато... Хотя увеличение размера страници... Нет! Много... Да еще и если учесть, что худший случай (на ключ 1 байт) случается при индексировании уникальных полей (Id например)... Совсем плохо...

Хотя конечно это тема отдельного исследования, и повышение производительности может покрыть расходы HDD и RAM...

Кстати, сейчас ведь чтение осуществляется так как сказано в стаье . Если да то пример:

Есть база с размером страници 4096.
Есть индекс с глубиной 3.
Сейчас чтение: Индекс(L2)->Индекс(L1)->Индекс(L0)->PP->DP =4096*5=20480 байт

Таже база с размером страници 8192 и с tra_number в индексе.
Чтение: Индекс(L2)->Индекс(L1)->Индекс(L0) =8192*3=24576 байт

Тоесть при глубеине индекса 3 объем чтения увеличится на 20% от начального, при глубине 4 (я такого ниразу не встречал) на ~33%.
...
Рейтинг: 0 / 0
20.02.2004, 15:29
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32420442
Vladimir_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir_
Участник
в любом случае гибридная система никогда не даст преимуществ по отношению к каждой составляющей в отдельности. Каждая система имеет свои методы решения и настройки. Я бы выбрал ORACLE и рассматривал решение задачи только в рамках его возможностей
...
Рейтинг: 0 / 0
25.02.2004, 11:14
| Ответить | Цитировать | Написать  
34 сообщений из 34, показаны все 2 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Целостность vs Быстродействие. Переносить ли в архивную таблицу?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1579154]:
 0ms
get settings:
 9ms
get forum list:
 18ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 175ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 84ms
get tp. blocked users:
 1ms
others: 225ms
total:  535ms
созд. / загр.: 535ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]