Встретил интересное сообщение в дискуссии
Речь, скорее, идёт о системе типа той, что собирает данные с электросчётчиков в Германии. Несколько десятков миллионов штук, данные отправляются ежеминутно (!). Ораклом там и не пахнет -- загнётся, болезный. Отсюда -- http://www.cnews.ru/news/top/index.shtml?2012/07/06/495657
Последнее утверждение автора мне показалось неочевидным.
Проверим на модели... Будем использовать мой десктоп, выделим Ораклу 1ГБ оперативы, датафайлы на одном диске, редологи -- на другом. Всё остальное по дефолту.
Легенда.
Имеем сервер, на которой поступают данные телеметрии (в нашем случае -- результаты измерений потребляемой мощности, с частотой 1 минута). В Германии 80 млн жителей. Автор пишет, что счетчиков там десятки милиионов штук. Будем считать, что 40 миллионов, что означает по одному счётчику на каждых двух жителей, включая младенцев.
Для заполнения таблиц будем использовать следующую процедуру. Добавляем 10 миллионов строк, измеряем время (многократно, усредняем)
procedure F is
T timestamp with local time zone default systimestamp;
begin
for i in 1..10000000
loop
insert into MEASUREMENTS1 (SNAPSHOT_TSZ, METER_ID, MEASUREMENT_VALUE)
values (i, T, 500);
-- insert into MEASUREMENTS2 (SNAPSHOT_ID, METER_ID, MEASUREMENT_VALUE)
-- values (1, i, 500);
end loop;
commit;
exception when others then
rollback;
raise;
end;
Тест 1. Дефолтная таблица, причем без первичного ключа
create table MEASUREMENTS1
(SNAPSHOT_TSZ timestamp (0) with local time zone not null,
METER_ID number not null,
MEASUREMENT_VALUE number not null)
pctfree 10 storage (initial 65536 next 1048576)
nocache monitoring noparallel logging
Результат -- 5 минут 25 секунд
Тест 2.
Приложение проектировали, данные старались уложить плотно, сессию записи вынесли в отдельную мастер таблицу, т.е. храним не длинный таймстэмп, а короткий ID сессии (минуты снятия показаний) загрузки. PCTFREE -- 0. Тип -- IOT, compress 1
create table MEASUREMENTS2
(SNAPSHOT_ID number not null,
METER_ID number not null,
MEASUREMENT_VALUE number not null,
constraint MEASUREMENTS2_PKIOT primary key (SNAPSHOT_ID, METER_ID))
organization index compress 1 pctthreshold 50
pctfree 0 storage (initial 32M next 32M)
noparallel logging
Результат -- 6 минут. Это больше, чем в прошлом тесте, но у нас есть первичный ключ, плюс данные лежат плотно, за счёт COMPRESS 1. Плотно -- значит читаться будут быстрее.
Т.о. 40 млн записей будут добавятся за 24 минуты, а нам надо обеспечить 1 минуту, т.е. ускорить процесс в 24 раза.
Но пробовал я это на обычном десктопе с двумя винчестерами, без параллелизма и с 1 ГБ памяти. Причем диски не сильно и напрягались, вообще не слышно. Параллелизма не было, одно ядро процессора -- 100%, второе в айдле.
По моим ощущениям (предположениям), Exadata с таким объемом справится. И добавлять измерения, и прореживать, и отчеты строить, и прогнозы. Ведь писать в датафайлы надо всего лишь со скоростью 10 МБ в секунду (нетто). В чем же тут проблема ? Что должно загнуться ?
В системах подобного рода (SCADA) также используется "прореживание" данных: сегодня нам нужны минутные срезы, завтра -- пятиминутные. Через год -- часовые.
Одна строка измерений во второй таблице занимает 16 байт. В нашем гипотетическом примере за год это будет 305 ТБ БЕЗ "ПРОРЕЖИВАНИЯ".
Без прореживания -- это много.
А с прореживанием можно сократить объем раз в сто или больше. А это уже совсем немного.
Плюс, в Exadata есть гибридная колоночная компрессия.
Как итог, мне трудно согласиться с автором что оракл там "загнётся, болезный"
Подобная задача на Оракле вполне решаема, и всё это можно сделать компактно и аккуратно -- может быть даже и без Exadata.
Для особых скептиков -- посмотрите презентацию CERN
http://canali.web.cern.ch/canali/docs/Compressing_VLDS_Oracle_UKOUG09_LC_CERN.ppt
Речь, скорее, идёт о системе типа той, что собирает данные с электросчётчиков в Германии. Несколько десятков миллионов штук, данные отправляются ежеминутно (!). Ораклом там и не пахнет -- загнётся, болезный. Отсюда -- http://www.cnews.ru/news/top/index.shtml?2012/07/06/495657
Последнее утверждение автора мне показалось неочевидным.
Проверим на модели... Будем использовать мой десктоп, выделим Ораклу 1ГБ оперативы, датафайлы на одном диске, редологи -- на другом. Всё остальное по дефолту.
Легенда.
Имеем сервер, на которой поступают данные телеметрии (в нашем случае -- результаты измерений потребляемой мощности, с частотой 1 минута). В Германии 80 млн жителей. Автор пишет, что счетчиков там десятки милиионов штук. Будем считать, что 40 миллионов, что означает по одному счётчику на каждых двух жителей, включая младенцев.
Для заполнения таблиц будем использовать следующую процедуру. Добавляем 10 миллионов строк, измеряем время (многократно, усредняем)
procedure F is
T timestamp with local time zone default systimestamp;
begin
for i in 1..10000000
loop
insert into MEASUREMENTS1 (SNAPSHOT_TSZ, METER_ID, MEASUREMENT_VALUE)
values (i, T, 500);
-- insert into MEASUREMENTS2 (SNAPSHOT_ID, METER_ID, MEASUREMENT_VALUE)
-- values (1, i, 500);
end loop;
commit;
exception when others then
rollback;
raise;
end;
Тест 1. Дефолтная таблица, причем без первичного ключа
create table MEASUREMENTS1
(SNAPSHOT_TSZ timestamp (0) with local time zone not null,
METER_ID number not null,
MEASUREMENT_VALUE number not null)
pctfree 10 storage (initial 65536 next 1048576)
nocache monitoring noparallel logging
Результат -- 5 минут 25 секунд
Тест 2.
Приложение проектировали, данные старались уложить плотно, сессию записи вынесли в отдельную мастер таблицу, т.е. храним не длинный таймстэмп, а короткий ID сессии (минуты снятия показаний) загрузки. PCTFREE -- 0. Тип -- IOT, compress 1
create table MEASUREMENTS2
(SNAPSHOT_ID number not null,
METER_ID number not null,
MEASUREMENT_VALUE number not null,
constraint MEASUREMENTS2_PKIOT primary key (SNAPSHOT_ID, METER_ID))
organization index compress 1 pctthreshold 50
pctfree 0 storage (initial 32M next 32M)
noparallel logging
Результат -- 6 минут. Это больше, чем в прошлом тесте, но у нас есть первичный ключ, плюс данные лежат плотно, за счёт COMPRESS 1. Плотно -- значит читаться будут быстрее.
Т.о. 40 млн записей будут добавятся за 24 минуты, а нам надо обеспечить 1 минуту, т.е. ускорить процесс в 24 раза.
Но пробовал я это на обычном десктопе с двумя винчестерами, без параллелизма и с 1 ГБ памяти. Причем диски не сильно и напрягались, вообще не слышно. Параллелизма не было, одно ядро процессора -- 100%, второе в айдле.
По моим ощущениям (предположениям), Exadata с таким объемом справится. И добавлять измерения, и прореживать, и отчеты строить, и прогнозы. Ведь писать в датафайлы надо всего лишь со скоростью 10 МБ в секунду (нетто). В чем же тут проблема ? Что должно загнуться ?
В системах подобного рода (SCADA) также используется "прореживание" данных: сегодня нам нужны минутные срезы, завтра -- пятиминутные. Через год -- часовые.
Одна строка измерений во второй таблице занимает 16 байт. В нашем гипотетическом примере за год это будет 305 ТБ БЕЗ "ПРОРЕЖИВАНИЯ".
Без прореживания -- это много.
А с прореживанием можно сократить объем раз в сто или больше. А это уже совсем немного.
Плюс, в Exadata есть гибридная колоночная компрессия.
Как итог, мне трудно согласиться с автором что оракл там "загнётся, болезный"
Подобная задача на Оракле вполне решаема, и всё это можно сделать компактно и аккуратно -- может быть даже и без Exadata.
Для особых скептиков -- посмотрите презентацию CERN
http://canali.web.cern.ch/canali/docs/Compressing_VLDS_Oracle_UKOUG09_LC_CERN.ppt
UPDATE
Есть решение для ускорения работыhttp://yaroslavbat.blogspot.com/2012/07/2.html
Комментариев нет:
Отправить комментарий