IBM Netezza

© 2011 IBM CorporationApril 11, 2011

IBM Netezza - новаятехнология для

высокопроизводительных

аналитических приложений

Сергей Лихарев, IBM Information Management Software

[email protected]

© 2011 IBM Corporation2

План доклада

� Обзор Netezza TwinFin Appliance

� Опыт клиентов

� Описание технологии


Что такое настоящий Appliance

� Специализированное устройство

� Оптимизиованное с определенной

целью

� Полное решение

� Быстрая установка

� Легкая эксплуатация

� Стандартные интерфейсы

� Низкая цена


� Специализированный аналитический движок

� Интегрированные БД, сервер и хранение

� Стандартные интерфейсы

� Низкая стоимость владения

� Скорость: 10-100 раз быстрее традиционных систем

� Простота: Минимальное администрирование инастройка

� Масштабируемость: Петабайты данных

� Сообразительность: Высокопроизводительнаярасширенная аналитика

TwinFinTM Appliance – преобразовывая аналитику


Сильные заявления, которые можно доказать

� Мы докажем что мы проще

� Мы докажем производительость

� Мы докажем работу в вашей среде с

вашими инстументами

� Мы докажем что у нас очень низкий TCO

� Мы докажем ценность для бизнеса


“…when something took 24 hours I could only do so much with it, but when something takes 10 seconds, I may be able to completely rethink the business process…”

- SVP Application Development, Nielsen

� 15,000 пользователей

� Выполнение 800,000+ запросов в день

� В 50 раз быстрее чем раньше

Source: http://www.youtube.com/watch?v=yOwnX14nLrE&feature=player_embedded

Скорость


DAYS

WEEKS

MONTHS

“Allowing the business users access to the Netezza box was what sold it.”

Steve Taff,

Executive Dir. of IT Services

� Установлена и работала за 6 месяцевдо прохождения формальногообучения

– В 200 раз быстрее Oracle системы

– ROI менее чем за 3 месяца

Простота


“NYSE … has replaced an Oracle IO relational

database with a data warehousing appliance from

Netezza, allowing it to conduct rapid searches of 650

terabytes of data.”

ComputerWeekly.com

Source: http://www.computerweekly.com/Articles/2008/04/14/230265/NYSE-improves-data-management-with-datawarehousing.htm

� 1 PB данных на Netezza

� 7 лет исторических данных

� Ежегодный рост данных 100-200%

Масштабируемость


“Because of (Netezza’s) in-database

technology, we believe we'll be able to do 600

predictive models per year (10X as many as

before) with the same staff."

Eric Williams,

CIO and executive VP

� Предсказание того что будутпокупать в следующие визиты

� Погашение купонов на уровне25% - высокий результат

Сообразительость


Page 10

Digital Media

Financial Services

Government

Health & Life Sciences

Retail / Consumer

Products

Telecom

Other


Описание технологии:Простота


Сложность традиционных хранилищ


Упрощение архитектуры хранилища


Интеграция данных

Data In

Загрузка данных в Netezza

Ab Initio

Business Objects/SAP

Composite Software

Expressor Software

GoldenGate Software (Oracle)

Informatica

IBM Information Server

Sunopsis (Oracle)

WisdomForce

SQ

L O

DB

C JD

BC

O

LE

-DB


Отчетность и анализ

Запросы к Netezza

Actuate

Business Objects/SAP

Cognos (IBM)

Information Builders

Kalido

KXEN

MicroStrategy

Oracle OBIEE

QlikTech

Quest Software

SAS

SPSS (IBM)

Unica (IBM)

Data Out

SQ

L O

DB

C JD

BC

O

LE

-DB


Управление Netezza

� No dbspace/tablespace sizing and configuration

� No redo/physical/Logical log sizing and configuration

� No page/block sizing and configuration for tables

� No extent sizing and configuration for tables

� No Temp space allocation and monitoring

� No RAID level decisions for dbspaces

� No logical volume creations of files

� No integration of OS kernel recommendations

� No maintenance of OS recommended patch levels

� No JAD sessions to configure host/network/storage

Нет управления хранением

Нет индексов и настройки

Нет установок ПО


Традиционная сложность … Простота Netezza

0. CREATE DATABASE TEST LOGFILE 'E:\OraData\TEST\LOG1TEST.ORA' SIZE 2M, 'E:\OraData\TEST\LOG2TEST.ORA' SIZE 2M,

'E:\OraData\TEST\LOG3TEST.ORA' SIZE 2M, 'E:\OraData\TEST\LOG4TEST.ORA' SIZE 2M, 'E:\OraData\TEST\LOG5TEST.ORA' SIZE 2M EXTENT MANAGEMENT LOCAL MAXDATAFILES 100 DATAFILE 'E:\OraData\TEST\SYS1TEST.ORA' SIZE 50 M DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'E:\OraData\TEST\TEMP.ORA' SIZE 50 M

UNDO TABLESPACE undo DATAFILE 'E:\OraData\TEST\UNDO.ORA' SIZE 50 M NOARCHIVELOG CHARACTER SET WE8ISO8859P1;

1. Oracle* table and indexes2. Oracle tablespace3. Oracle datafile4. Veritas file5. Veritas file system

6. Veritas striped logical volume7. Veritas mirror/plex8. Veritas sub-disk 9. SunOS raw device

10. Brocade SAN switch11. EMC Symmetrix volume 12. EMC Symmetrix striped meta-volume

13. EMC Symmetrix hyper-volume14. EMC Symmetrix remote volume (replication)

15. Days/weeks of planning meetings

Netezza: Low (ZERO) Touch:

CREATE DATABASE my_db;


ORACLECREATE TABLE "MRDWDDM"."RDWF_DDM_ROOMS_SOLD" ("ID_PROPERTY" NUMBER(5,

0) NOT NULL ENABLE, "ID_DATE_STAY" NUMBER(5, 0) NOT NULL ENABLE,

"CD_ROOM_POOL" CHAR(4) NOT NULL ENABLE, "CD_RATE_PGM" CHAR(4) NOT

NULL ENABLE, "CD_RATE_TYPE" CHAR(1) NOT NULL ENABLE,

"CD_MARKET_SEGMENT" CHAR(2) NOT NULL ENABLE, "ID_CONFO_NUM_ORIG"

NUMBER(9, 0) NOT NULL ENABLE, "ID_CONFO_NUM_CUR" NUMBER(9, 0) NOT

NULL ENABLE, "ID_DATE_CREATE" NUMBER(5, 0) NOT NULL ENABLE,

"ID_DATE_ARRIVAL" NUMBER(5, 0) NOT NULL ENABLE, "ID_DATE_DEPART"

NUMBER(5, 0) NOT NULL ENABLE, "QY_ROOMS" NUMBER(5, 0) NOT NULL

ENABLE, "CU_REV_PROJ_NET_LOCAL" NUMBER(21, 3) NOT NULL ENABLE,

"CU_REV_PROJ_NET_USD" NUMBER(21, 3) NOT NULL ENABLE,

"QY_DAYS_STAY_CUR" NUMBER(3, 0) NOT NULL ENABLE, "CD_BOOK_SOURCE"

CHAR(1) NOT NULL ENABLE) PCTFREE 5 PCTUSED 95 INITRANS 4 MAXTRANS 255

STORAGE( FREELISTS 6) TABLESPACE "DDM_ROOMS_SOLD_DATA" NOLOGGING

PARTITION BY RANGE ("ID_PROPERTY" ) (PARTITION "PART1" VALUES LESS

THAN (600) PCTFREE 5 PCTUSED 95 INITRANS 4 MAXTRANS 255

STORAGE(INITIAL 16777216 FREELISTS 6 FREELIST GROUPS 1) TABLESPACE

"DDM_ROOMS_SOLD_DATA" NOLOGGING NOCOMPRESS, PARTITION "PART2" VALUES

LESS THAN (1200) PCTFREE 5 PCTUSED 95 INITRANS 4 MAXTRANS 255












LESS THAN (MAXVALUE) PCTFREE 5 PCTUSED 95 INITRANS 4 MAXTRANS 255


"DDM_ROOMS_SOLD_DATA" NOLOGGING NOCOMPRESS ) ;

ORACLE IndexesCREATE INDEX "MRDWDDM"."RDWF_DDM_ROOMS_SOLD_IDX1" ON "RDWF_DDM_ROOMS_SOLD"

("ID_PROPERTY" , "ID_DATE_STAY" , "CD_ROOM_POOL" , "CD_RATE_PGM" ,

"CD_RATE_TYPE" , "CD_MARKET_SEGMENT" ) PCTFREE 10 INITRANS 6 MAXTRANS 255

STORAGE( FREELISTS 10) TABLESPACE "DDM_DATAMART_INDEX_L" NOLOGGING

PARALLEL ( DEGREE 4 INSTANCES 1) LOCAL(PARTITION "PART1" PCTFREE 10

INITRANS 6 MAXTRANS 255 STORAGE(INITIAL 4194304 NEXT 4259840 MINEXTENTS 1

MAXEXTENTS 100000 PCTINCREASE 0 FREELISTS 10 FREELIST GROUPS 1 BUFFER_POOL

DEFAULT) TABLESPACE "DDM_DATAMART_INDEX_L" NOLOGGING, PARTITION "PART2"

PCTFREE 10 INITRANS 6 MAXTRANS 255 STORAGE(INITIAL 4194304 NEXT 4259840

MINEXTENTS 1 MAXEXTENTS 100000 PCTINCREASE 0 FREELISTS 10 FREELIST GROUPS

1 BUFFER_POOL DEFAULT) TABLESPACE "DDM_DATAMART_INDEX_L" NOLOGGING,

PARTITION "PART3" PCTFREE 10 INITRANS 6 MAXTRANS 255 STORAGE(INITIAL

4194304 NEXT 4259840 MINEXTENTS 1 MAXEXTENTS 100000 PCTINCREASE 0

FREELISTS 10 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE

"DDM_DATAMART_INDEX_L" NOLOGGING, PARTITION "PART4" PCTFREE 10 INITRANS 6

MAXTRANS 255 STORAGE(INITIAL 4194304 NEXT 4259840 MINEXTENTS 1 MAXEXTENTS

100000 PCTINCREASE 0 FREELISTS 10 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)

TABLESPACE "DDM_DATAMART_INDEX_L" NOLOGGING, PARTITION "PART5" PCTFREE 10

INITRANS 6 MAXTRANS 255 STORAGE(INITIAL 4194304 NEXT 4259840 MINEXTENTS 1

MAXEXTENTS 100000 PCTINCREASE 0 FREELISTS 10 FREELIST GROUPS 1 BUFFER_POOL

DEFAULT) TABLESPACE "DDM_DATAMART_INDEX_L" NOLOGGING, PARTITION "PART6"

PCTFREE 10 INITRANS 6 MAXTRANS 255 STORAGE(INITIAL 4194304 NEXT 4259840

MINEXTENTS 1 MAXEXTENTS 100000 PCTINCREASE 0 FREELISTS 10 FREELIST GROUPS

1 BUFFER_POOL DEFAULT) TABLESPACE "DDM_DATAMART_INDEX_L" NOLOGGING ) ;

ORACLE Bitmap indexCREATE BITMAP INDEX "CRDBO"."SNAPSHOT_MONTH_IDX13" ON

"SNAPSHOT_OPPTY_MONTH_HIST" ("SNAPSHOT_YEAR" ) PCTFREE 10 INITRANS 2

MAXTRANS 255 STORAGE(INITIAL 4194304 NEXT 4194304 MINEXTENTS 2 MAXEXTENTS

2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL

DEFAULT) TABLESPACE "SFA_DATAMART_INDEX" NOLOGGING ;

ORACLE Table ClustersCREATE CLUSTER "MRDW"."CT_INTRMDRY_CAL" ("ID_YEAR_CAL" NUMBER(4, 0),

"ID_MONTH_CAL" NUMBER(2, 0), "ID_PROPERTY" NUMBER(5, 0)) SIZE 16384

PCTFREE 10 PCTUSED 90 INITRANS 3 MAXTRANS 255 STORAGE(INITIAL

83886080 NEXT 41943040 MINEXTENTS 1 MAXEXTENTS 1017 PCTINCREASE 0

FREELISTS 4 FREELIST GROUPS 1 BUFFER_POOL RECYCLE) TABLESPACE

"TSS_FACT" ;

NetezzaCREATE TABLE MRDWDDM.RDWF_DDM_ROOMS_SOLD (

ID_PROPERTY numeric(5, 0) NOT NULL ,

ID_DATE_STAY integer NOT NULL ,

CD_ROOM_POOL CHAR(4) NOT NULL ,

CD_RATE_PGM CHAR(4) NOT NULL ,

CD_RATE_TYPE CHAR(1) NOT NULL ,

CD_MARKET_SEGMENT CHAR(2) NOT NULL ,

ID_CONFO_NUM_ORIG integer NOT NULL ,

ID_CONFO_NUM_CUR integer NOT NULL ,

ID_DATE_CREATE integer NOT NULL ,

ID_DATE_ARRIVAL integer NOT NULL ,

ID_DATE_DEPART integer NOT NULL ,

QY_ROOMS integer NOT NULL ,

CU_REV_PROJ_NET_LOCAL numeric(21, 3) NOT NULL ,

CU_REV_PROJ_NET_USD numeric(21, 3) NOT NULL ,

QY_DAYS_STAY_CUR smallint NOT NULL ,

CD_BOOK_SOURCE CHAR(1) NOT NULL)

distribute on random;

•No indexes

•No Physical Tuning/Admin

•Stripe data randomly, or by Columns

Традиционная сложность … Простота Netezza


Simple to Deploy and Operate� Простота

– Включил и работай .… это классический appliance

– Установка и готовность к работе примерно за 2 дня

� Разработчики и администраторы – быстрый результат– Нет конфигурации и физического моделирования

– Нет индексов или тонкой настройки – производительность «из

коробки»

– Нет зависимости от модели данных

� Разработчики ETL– Нет необходимости в агрегатах – упрощение логики ETL

– Более быстрая загрузка и преобразования

� Бизнес аналитики– Скорость анализа – 10и – 100и раз быстрее

– Настоящие случайный запросы – без индексов и настроек

– Сложные запросы по большим объемам данных

– Свежие данные – загрузка и запросы к данным параллельно

– Расширенная аналитика на сотнях узлах обработки


Описание технологии:Архитектура


Netezza AMPP™ архитектура

Advanced Analytics

Advanced Analytics

LoaderLoader

ETLETL

BIBI

Applications

FPGA

Memory

CPU

FPGA

Memory

CPU

FPGA

Memory

CPU

HostsHost

Disk

EnclosuresS-Blades™

Network

Fabric

Netezza Appliance


Специальные возможности Netezza

FPGA Core CPU Core

Uncompress ProjectRestrict,Visibility

Complex ∑Joins, Aggs, etc.

select DISTRICT,

PRODUCTGRP,

sum(NRX)

from MTHLY_RX_TERR_DATA

where MONTH = '20091201'

and MARKET = 509123

and SPECIALTY =

'GASTRO'

Slice of table

MTHLY_RX_TERR_DATA

(compressed)

Slice of table

MTHLY_RX_TERR_DATA

(compressed)


and MARKET = 509123

and SPECIALTY = 'GASTRO'


and MARKET = 509123

and SPECIALTY = 'GASTRO'

sum(NRX)sum(NRX)

select DISTRICT,

PRODUCTGRP,

sum(NRX)

select DISTRICT,

PRODUCTGRP,

sum(NRX)


Optimized Hardware + Software

Purpose-built for high performance analytics; requires no tuning

Streaming Data

Hardware-based query acceleration for blistering fast results

True MPP

All processors fully utilized for maximum speed and efficiency

Deep Analytics

Complex analytics executed in-database for deeper insights

Архитектура IBM Netezza TwinFinTM


Netezza S-Blade™


Компоненты S-Blade™

Intel Quad-Core

Dual-Core FPGADRAM

IBM BladeCenter Server Netezza DB Accelerator

SAS Expander

Module

SAS Expander

Module


Зеркалирование дисков и отказоустойчивость

� Все пользовательские данные и временные данные

заркалируются

� Отказы дисков прозрачны для запросов и транзакций

� Даные на отказавших дисках автоматически регенирируются

� Плохие сектора автоматически перезаписываются или

перемещаются

Primary

Mirror

Temp


Спецификация TwinFin™ 24

� 16 (8*2) Disk Enclosures:– 192 (96*2) 1TB SAS Drives – (8 hot spares)– RAID 1 Mirroring

� 24 Netezza S-Blades:–192 Core’s ( Intel Quad-Core 2.5 GHz)– 192 FPGA’s ( 125 MHz )– 384 GB DDR2 RAM (1+TB compressed)– Linux 64-bit Kernel

� 2 Hosts (Active-Passive):–24 Cores (Quad-Core Intel 2.6 GHz)–96 GB Memory–4x146 GB SAS Drives–Red Hat Linux 5 64-bit–10G Internal Network

� User Data Capacity: 250 TB

� Data Scan Speed: 290 TB/hr

� Load Speed (per system): 2.0 TB/hr

� Power/Rack: 7,400 Watts

� Cooling/Rack: 25,500 BTU/Hour


Спасибо за внимание!

[email protected]

Корпоративные базы данныхМосква, 15 апреля 2011 г.

1

Транзакционныепараллельные СУБД:новая волна

С.Д. КузнецовИнститут системного программирования РАН

ЦИТФорум

[email protected]


2

Введение (1)

Возможность дешевого построения неограниченногоризонтально масштабируемых кластерныхпривела к активизации исследований и разработокархитектур систем управления данных безсовместного использования ресурсов (sharednothing)

Два фронта работ: «NoSQL»: отказ от существующих решений «один размер непригоден для всех»: прошло времяуниверсальных СУБД; необходимо пользоватьсявсеми полезными технологиями и идеями,накопленными в сообществе баз данных


3


Представители обоих фронтов сходятся попервому пункту

Второй пункт их разделяет

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

второй лагерь относится к ним, как кценному наследию, жертвовать которымнельзя


4


Ведутся работы в двух наиболее важных направленияхуправления данными

аналитические системы управления данными

транзакционные системы управления данными

В прошлые годы разделяло отношение к NoSQL-технологии

анализа данных MapReduce

Однако это время, как кажется, миновало

см. «MapReduce: внутри, снаружи или сбоку отпараллельных СУБД?»(http://citforum.ru/database/articles/dw_appliance_and_mr/)


5


Цель: разобраться в происходящем в областисредств управления данными категории OLTP

Значительную часть современных Interner-приложений составляют транзакционныеприложения

Необходимо уметь легко, быстро и эффективномасштабировать свои системы управленияданными

речь идет именно о горизонтальноммасштабировании


6


Горизонтальное масштабирование (scaling out)СУБД является необходимым условием развитиябизнеса

Транзакции обычно являются очень короткими исостоят из простых операций

время реакции неперегруженного запросамиприложения обычно пользователей вполне

устраивает


7


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

Такие задержки могут оказаться губительнымидля бизнеса

Поэтому не менее важным требованием к СУБДявляется доступность (availability),

гарантирующая отсутствие таких задержек


8


Хуже всего на отношение клиентов к Internet-компаниидействуют сообщения типа service unavailable

Поэтому многие онлайновые компании готовы согласиться стем, что в некоторых случаях результаты выполнениятранзакций системой управления данными будутнекорректными, если при этом доступность системы будетмаксимально возможной

Выстраивается некоторая "теоретическая" база,оправдывающая перед пользователями возможноенекорректное поведение приложений тем, что "потребностьв извинениях возникает в любом бизнесе"


9


Более серьезным «теоретическим» основанием NoSQL-разработок, в которых общепринятые полезные свойстваСУБД приносятся в жертву доступности этих систем,является так называемая «теорема CAP»

впервые сформулированная Эриком Брювером (EricBrewer)

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

Распространено мнение, что эта «теорема» означаетневозможность поддержки в одной распределенной системеуправления данных свойств Consistency, Availability иPartitioning


10


Обобщая consistency в смысле Брювера до полного наборасвойств ACID классических транзакций баз данных,сообщество NoSQL с готовностью отказывается отреальной поддержки транзакций в своих системах

NoSQL -> NoACID

Не буду касаться "экстремистских" решений для поддержкионалайновых "OLTP"-приложений

С практической точки зрения они очень важны, но,

не вписываются в контекст доклада

у разработок этой категории нет какой-либо общейидеологии, кроме отрицания SQL и ACID

Internet Request Processing?


11


Имеется и другая ветвь - ETH Цюрих и, преждевсего, Дональд Коссманн (Donald Kossmann)

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

Вокруг этих идей выполняются интересныеисследования и разработки, заслуживающиеанализа


12


Среди работ, в которых не затрагиваютсясвойства ACID и обеспечивается горизонтальноемасштабирование параллельных СУБД, наиболееинтересен проект H-Store, в котором участвуютисследователи MIT, Yale и Brown

при участии Майкла Стоунбрейкера и СтенлиЗдоника (Stanley Zdonik)

Основана компания VoltDB, выпустившаякоммерческий программный продукт

с открытыми исходными текстами и лицензией

GPL3


13


Основной упор делается на достижение высокойэффективности и обеспечение линейной горизонтальноймасштабируемости при полной поддержке ACID-транзакций

Майкл Стоунбрейкер доказывает, что отказ от свойств ACIDникоим образом не способствует повышению уровнядоступности распределенных систем управления данными

Высокой производительности и горизонтальноймасштабируемости массивно-параллельных систем базданных в наибольшей степени мешают распределенныетранзакции и, в особенности, их двухфазная фиксация


14


Устранению отрицательного влияния распределенныхтранзакций и посвящается большая часть исследованийпроекта H-Store

Кроме того, в параллельных СУБД shared-nothing базаданных должна быть разделена на части, каждая из которыхуправляется локальным компонентом СУБД в отдельномузле кластера

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

Предлагается интересный подход к обнаружению методов

таких разделений


15


Параллельным транзакционным СУБД свойственна еще однапроблема, к которой, на мой взгляд, недостаточно внимательноотносятся участники проекта H-Store

Они отказываются от использования общих ресурсов даже внутриодного узла, в котором установлен компьютер с многоядернымпроцессором

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

В статье Айламаки (Ailamaki ) и др. обосновываетсянеэффективность такого подхода и предлагается оригинальнаяархитектура параллельной "одноузловой" СУБД, работающей намашине с многоядерным процессором


16

ACID и «теорема» CAP (1)

Аббревиатура ACID появилась в 1983 г. встатье Тео Хаердера (Theo Haerder) иАдреаса Рейтера (Andreas Reuter)

«Транзакция, достигающая своего нормального завершения(EOT – end of transaction, завершение транзакции) и, темсамым, фиксирующая свои результаты, сохраняетсогласованность базы данных. Другими словами, каждаяуспешная транзакция по определению фиксирует толькодопустимые результаты. Это условие являетсянеобходимым для поддержки четвертого свойства –

долговечности.»


17


«Эти четыре свойства – атомарность,согласованность, изоляция идолговечность (ACID) – описываютосновные черты парадигмы транзакций,которые влияют на многие аспектыразработки систем баз данных. Поэтомумы считаем, что способность какой-либосистемы к поддержке транзакций являетсяпробным камнем (ACID test) качества этойсистемы.»


18


Свойства ACID, с одной стороны, можно рассматривать кактребования к любой СУБД, претендующей на поддержкутранзакций, а с другой стороны, – как определениетранзакции в системе баз данных

Это определение полностью соответствует житейскойпрактике.

Трудно представить, например, чтобы клиент,выполняющий банковскую транзакцию, не рассчитывал на

удовлетворение банком всех свойств ACID


19


Свойства ACID являются нераздельными, отбрасываниелюбого из них делает оставшуюся комбинациюбессмысленной

Если отбросить свойство согласованности, то мы потеряемкритерий корректности транзакции

СУБД не сможет каким-либо осмысленным образомпринимать решение о допустимости или недопустимостификсации транзакций, и все проверки корректностивыполнения операций при текущем состоянии базы данныхпридется выполнять в коде приложений


20


Речь идет о логической согласованности

Клиенту банка нужно, чтобы банк работал поустановленным им и известным клиентам правилам

Клиенту онлайнового магазина нужно, чтобы заказанный иоплаченный им товар был своевременно ему доставлен

Ни клиенту банка, ни клиенту Internet-магазина нет никакогодела до внутренней кухни предприятия

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


21


Отказ от ACID-транзакций создает немереные трудности дляразработчиков приложений, которым придется самимреализовывать нечто похожее, чтобы удовлетворить естественныепотребности своих клиентов.

Свойства ACID, фактически, определяют понятие транзакции

Чтобы иметь возможность говорить о транзакционной системеуправления данными, в которой не поддерживается свойствосогласованности транзакций, необходимо определить, что в этомслучае понимается под термином транзакция

Сегодня во многих случаях люди говорят о поддержке OLTP-приложений, совершенно не уточняя, что за транзакции имеются ввиду


22


В области распределенных систем имеется своетолкование тех же терминов

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


23


Согласованность в конечном счете (eventualconsistency) означает, что если в течениедостаточно долгого периода времени в системуне поступают новые операции обновленияданных, то можно ожидать, что результаты всехпредыдущих операций обновления данных вконце концов распространятся по всем узламсистемы, и все реплики данных согласуются

Скорее всего, Брювер под согласованностьюпонимал именно мгновенную согласованностьданных


24


Имея в виду этот смысл понятиясогласованности, можно считать "теорему"Брювера вполне понятной и очевидной:

в любой распределенной системе сразделенными данными можноодновременно обеспечить только любыедва свойства из согласованности,доступности и устойчивости кразделению сети


25


Брювер даже противопоставляет набор свойствACID предлагаемому им набору свойств BASE

Basically Available, Soft-state, Eventual consistency –доступность в большинстве случаев; неустойчивоесостояние; согласованность в конечном счете

Но это противопоставление неправомерно,поскольку в первом случае речь идет о логическиххарактеристиках транзакций, а во втором – офизических свойствах распределенных систем


26


Сет Гильберт (Seth Gilbert) и Нэнси Линч(Nancy Lynch) доказали невозможностьодновременного обеспечения в однойраспределенной системе свойств атомарнойсогласованности, доступности и устойчивостик разделению сети

Но какое отношение это имеет к транзакциямбаз данных вообще и к ACID-транзакциям в

частности?


27


«Гильберт и Линч используют вместо терминасогласованность термин атомарность, что стехнической точки зрения более осмысленно,потому что, строго говоря, согласованность всмысле ACID относится к идеальнымсвойствам транзакций баз данных и означает,что никакие данные не станут долговременнохранимыми, если они нарушают некоторые

заранее установленные ограничения.»


28


Согласованность по Брюверу не имеет ничего

общего с согласованностью в смысле ACID,

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

Это не свойство ACID, а техническая(физическая) особенность массивно-параллельных СУБД, облегчающая разработку

приложений


29


В области транзакционных параллельных систем базданных отказ consistency по Брюверу в пользу availability иpartitioning является плохим компромиссом, поскольку

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

свойством системы

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

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


30


Таким образом, высокая активность представителей лагеряNoSQL связана не с теоретической невозможностьюпостроения массивно-параллельных транзакционных СУБД,

поддерживающих ACID-транзакции, а с тем, что

упрощенные системы, не поддерживающие не толькоACID-транзакции, но и согласованность реплик,создаются проще и быстрее

Из-за своей упрощенной организации они способныобеспечивать очень быструю обработку данных,

и для ряда приложений это оказывается более важным,чем все удобства, свойственные технологии баз данных


31

Новые архитектуры с ACID (1)

На рынке OLTP с традиционными системами можетконкурировать только СУБД, обладающая некоторымипринципиально отличными качествами

Потенциально достижимыми новыми качествами являетсясущественно большая пропускная способность транзакций игоризонтальная масштабируемость

Такие качества можно обеспечить только прииспользовании архитектур (shared-nothing)

Свидетельством правильности этого мнения являютсяпроект H-Store и достижения компании VoltDB


32


Впервые краткое описание исходных идейпроекта H-Store появилось в 2007 г. The End of an Architectural Era (It's Time for a

Complete Rewrite)http://citforum.ru/database/articles/end_of_arch_era/

Специализированные транзакционныесистемы, основанные на следующих пятиосновных соображениях


33


В основной памяти недорогой массивно-параллельной системы уже сейчас можноразместить базу данных объемом до одноготерабайта

Этого достаточно для большинстваприложений OLTP

Поэтому будущее за системамитранзакционных баз данных, полностью

размещаемых в основной памяти


34


В системах OLTP транзакции являются очень легковесными

При работе с базой данных в основной памяти времявыполнения наиболее тяжелой транзакции из тестовогонабора TPC-C составляет менее одной миллисекунды

В большинстве приложений отсутствуют задержки по винепользователей

Поэтому имеет смысл выполнять все операции каждой

транзакции последовательно в одном потоке управления


35


В следующем десятилетии будут доминироватькомпьютерные системы без общих ресурсов, ивсе СУБД следует оптимизировать в расчете наиспользование такой архитектуры

Если система с N узлами не обеспечиваетдостаточной мощности, должна иметьсявозможность добавления к ней дополнительных Kузлов без потребности в каких-либо сложных

действиях над используемой СУБД


36


В будущем высокий уровень доступности иотказоустойчивость станут важными чертамирынка OLTP, поэтому:

потребуется согласованная репликация данных

наиболее эффективной является поддержкаархитектуры shared-nothing на всех уровняхсистемы

наилучший способ поддержки архитектуры безобщих ресурсов состоит в использованиинескольких машин в одноранговой (peer-to-peer)конфигурации


37


Основные расходы IT-подразделений уходятна содержание персонала

Единственным выходом из этого положенияявляется перевод систем на«самообслуживание»

Требуется полный пересмотр процессанастройки системы без явных ручекуправления

Из всего этого следуют выводы:


38


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

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


39


Следующим по значимости узким местомсистемы является вызов в ней операций ивозврат результатов в приложение

Наиболее эффективным способомрешения этой проблемы являетсявыполнение логики приложений в видехранимых процедур внутри системы базданных


40


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

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


41

Новые архитектуры с ACID(10) Желательно освободиться и от синхронизации наоснове "защелок« (latch) при доступе к одним итем же структурам данных из нескольких потоковуправления

С учетом кратковременности транзакций этинакладные расходы можно устранить путемперехода к однопотоковой модели выполнениятранзакций

По мере возможности следует избегатьприменения двухфазного протокола фиксации

распределенных транзакций


42

Новые архитектуры с ACID(11) H-Store выполняется в кластере компьютеров

При конфигурировании системы можно указатьжелаемый уровень ее надежности – число узлов,при выходе из строя которых система можетвосстановить работоспособность без потеривыполняемых транзакций в течение заданноговремени

В каждом узле строки разделов таблицразмещаются вплотную одна к другой, и доступ кним производится на основе B-деревьев


43

Новые архитектуры с ACID(12) В каждом узле H-Store поддерживает ровно один поток

управления, в котором полностью, без каких-либо задержеквыполняется каждая поступающая операция SQL

Узлы, в процессорах которых имеется несколько ядер,разбиваются на соответствующее число логических узлов

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

узлами


44

Новые архитектуры с ACID(13) Транзакции представляются в виде хранимых

процедур базы данных, и в системе поддерживаетсятолько одна внешняя операция Execute transaction(parameter_list)

Внутри таких хранимых процедур сочетается логикаприложений и операции манипулирования базамиданных, причем вызовы SQL производятся, каклокальные вызовы

Журнал повторного выполнения операций неподдерживается, а журнал отката ведется только длятранзакций, не являющихся двухфазными


45

Новые архитектуры с ACID(14) Для обеспечения возможности использования H-

Store без потребности в "ручках управления"планировалось создание средстваавтоматического проектирования физическихсхем баз данных (дизайнера баз данных),

определяющего горизонтальное разделение,репликацию и выбор ключей индексов

Цель дизайнера состоит в том, чтобы сделать какможно больше транзакций одноузловыми (т.е.избежать распределенных транзакций)


46

Новые архитектуры с ACID(15) Выполнение транзакций в соответствии свременными метками

Для выделенных «хороших» классов транзакцийне требуются блокировки и двухфазная фиксация

Для распределенных транзакций –оптимистические методы (с отслеживаниемнаборов чтения и записи)

На практике исследование методов продолжается


47

Новые архитектуры с ACID(16) Low Overhead Concurrency Control for Partitioned Main

Memory Databases http://citforum.ru/database/articles/h-store-sigmod2010/

Многораздельные транзакции поступают через центральныйкоординатор, устанавливающий их глобальный порядок

Координатор разбивает транзакцию на фрагменты ипосылает их потокам управления соответствующихразделов

После получения ответов от этих потоков управления вкоординаторе выполняется код приложения,

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

В каждом разделе фрагменты выполняютсяпоследовательно.


48

Новые архитектуры с ACID(17) Основная идея спекулятивноговыполнения состоит в том, что когда внекотором потоке управления основногораздела возникает задержка из-завыполнения двухфазного протоколараспределенной фиксации транзакций,

этот поток не простаивает, а выполняетдругие фрагменты транзакций из своейвходной очереди


49

Новые архитектуры с ACID(18) Это выполнение на фоне фиксации транзакции является

спекулятивным

результаты спекулятивно выполненных транзакцийбудут некорректными, если транзакция, на фонефиксации которой эти транзакции выполняются, незафиксируется, а откатится

Спекулятивно выполненные транзакции не фиксируются дотех пор, пока не будет зафиксирована первая транзакция, вслучае ее отката – все тоже откатываются

Очевидно, что спекулятивная схема обеспечивает

сериальный план выполнения транзакций


50

Новые архитектуры с ACID(19) Блокировочная схема почти всегда существенно уступает и

спекулятивной схеме, и схеме с синхронизационнымиблокировками

Спекулятивная схема работает значительно лучше двухдругих схем при наличии многораздельных транзакций содним циклом коммуникаций транзакции с координатором инебольшой доли аварийно завершающихся транзакций

Схема с синхронизационными блокировками обеспечиваетнаилучшие результаты при наличии многих транзакций снесколькими циклами коммуникаций


51

Новые архитектуры с ACID(20) The Case for Determinism in Database Systems

http://citforum.ru/database/articles/abadi_vldb2010/

При детерминированной сериализации смеси транзакций{T1, T2, ..., Tn} требуется эквивалентность планавыполнения этих транзакций некоторомупредопределенному последовательному плану ихвыполнения (Ti1, Ti2, ..., Tin)

Предлагается использовать синхронизационныеблокировки, но с гарантией эквивалентности получаемого

сериального плана предопределенному плану


52

Новые архитектуры с ACID(21) Если двум транзакции Ti и Tj требуются блокировки одной и

той же записи r, и в предопределенном плане Ti находитсяраньше, чем Tj, то Ti должна запросить блокировку rраньше, чем Tj

Каждая транзакция, не ожидающая удовлетворения запросаблокировки, должна продолжать выполняться до тех пор,пока не зафиксируется или не будет завершена аварийнымобразом детерминированным образом

Если выполнение какой-либо транзакции задерживается, тосистема должна поддерживать эту транзакцию активной,пока она не завершится, или пока не будет ликвидированасама система


53

Новые архитектуры с ACID(22) Детерминированная схема непригодна для СУБД,работающих с базами данных в дисковой памяти

Однако в системах, обрабатывающих данныеисключительно в основной памяти, ситуацияменяется

В ряде случаев детерминизм позволяет повыситьпроизводительность систем, упрощая при этомрепликацию и избавляя от потребности вдвухфазном протоколе фиксации

распределенных транзакций


54

Новые архитектуры с ACID(23) Для поддержки упорядоченности запросовблокировок предлагается запрашивать всеблокировки, требуемые для каждой транзакции,перед началом ее выполнения

Если это возможно, то после этого транзакциявыполняется вплоть до своего завершения (надданным разделом), не освобождая блокировок

Однако не для всех транзакций заранее известно,

какие записи в них будут читаться и изменяться


55

Новые архитектуры с ACID(24) T(x): y := read(x)

write(y)

Зависимость первого порядка; преобразуется в

T1(x): y := read(x)запрос_следующей_транзакции(T2(x, y))

T2(x, y): y´ := read(x)if (y´ ≠ y)запрос_следующей_транзакции(T2(x, y))abort()

else

write(y)


56

Новые архитектуры с ACID(25) Возможны зависимости более высокого порядка, но

встречаются редко

Детерминированная обработка многораздельныхтранзакций описана только на уровне общей идеи

Перспектива обойтись без двухфазного протоколафиксаций за счет детерминированного выполнениятранзакций кажется очень привлекательной и потенциальнодостижимой

Как бы только не оказалось, что для этого требуется ещеболее сложный статический анализ транзакций


57

Новые архитектуры с ACID(26) Schism: a Workload-Driven Approach to Database

Replication and Partitioninghttp://citforum.ru/database/articles/madden_vldb2010/

Многораздельные транзакции останутся болеедорогостоящими, чем однораздельные

Нужно стремится к тому, что в любой рабочейнагрузке OLTP их было как можно меньше

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


58

Новые архитектуры с ACID(27) Методы циклического разделения и хэш-разделения, как правило, не подходят длятранзакционных массивно-параллельных систембаз данных, поскольку способствуют появлениюбольшого числа многораздельных транзакций

Хорошие результаты может обеспечитьразделение по диапазонам значений кортежей, новыбор соответствующих диапазонов с учетомзаданной рабочей нагрузки вручную производить

очень трудно


59

Новые архитектуры с ACID(28) В Schism на основе однораздельногопредставления базы данных и заданной рабочейнагрузки производится разделение базы данныхна заданное число сбалансированных разделов сцелью минимизации числа многораздельныхтранзакций в рабочей нагрузке

Далее система пытается аппроксимироватьполученное разделение разделением подиапазонам значений на основе автоматическипроизводимого условного выражения


60

Новые архитектуры с ACID(29) Наконец, производится сравнение числараспределенных транзакций в исходнойрабочей нагрузке, получаемого приприменении полученного метода разделения,с числом распределенных транзакций,которые возникают при использовании хэш-разделения и разделения на уровне таблиц,

и для реального использованиявыбирается метод, обеспечивающийнаилучший результат


61

Новые архитектуры с ACID(30) Основные черты H-Store

бескомпромиссное использование подхода shared-nothing – каждому разделу базы данных (основномуили резервному) соответствует в точности одинпоток управления, и в потоках управления неиспользуются общие ресурсы, даже если ониреализуются ядрами одного и того же процессора

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


62

Новые архитектуры с ACID(31)

выполнение транзакций поблизости отданных без потребности в передаче посети операций SQL и их результатов

стремление к минимизации числараспределенных транзакций за счетстатического анализа и преобразованийтранзакций, а также за счет разделенияданных с учетом рабочей нагрузки


63

Новые архитектуры с ACID(32) Чудеса производительности именно при наличиитолько однораздельных транзакций

Появление распределенных транзакцийполностью исключить не удастся, и поэтому основной текущей задачей проекта H-Storeявляется нахождение способов выполненияраспределенных транзакций, которые позволили бы

свести к минимуму накладные расходы на их фиксацию

Тем не менее, VoltDB успешно работает


64

Новые архитектуры с ACID(33) В H-Store приносятся в жертву аппаратные возможности

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

Кажется очень поучительным проект DORA, в которомразрабатывается архитектура СУБД, обладающаясвойствами shared-nothing на логическом уровне, ноиспользующая аппаратные возможности shared-everythingна физическом уровне

Data-Oriented Transaction Executionhttp://citforum.ru/database/articles/ailamaki_vldb2010/


65

Новые архитектуры с ACID(34) В качестве экспериментальной аппаратнойплатформы в DORA использовалсякомпьютер Sun T5220 "Niagara II«

8 ядер, в каждом из которых нааппаратном уровне поддерживается 8потоков управления, т.е. на уровнеоперационной системы в компьютереимеется 64 процессора, каждому изкоторых доступны все остальные ресурсысистемы


66

Новые архитектуры с ACID(35) Используется транзакционная системауправления базами данных Shore-NT

полная изоляция на основе иерархическихблокировок

управление буферным пулом

индексы на основе B-деревьев

классическое управление журнализацией ивосстановлением баз данных

Каждой транзакции назначается отдельный потокуправления


67

Новые архитектуры с ACID(36) По мере роста числа активных транзакций растетобъем работы, требуемой для удовлетворениязапросов на получение или освобождениеблокировок, поскольку удлиняются спискизапросов блокировок

Дополнительные обходы списков блокировокнужны для выявления синхронизационныхтупиков

Возникающие последствия губительны дляпроизводительности системы


68

Новые архитектуры с ACID(37)


69

Новые архитектуры с ACID(38) Основные идеи DORA (Data-ORiented Architecture)состоят в следующем:

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

система распределяет работу каждой транзакциипо потокам управления в соответствии с тем, ккаким данным обращается транзакция

при обработке запросов система по меревозможности избегает взаимодействий сцентрализованным менеджером блокировок


70

Новые архитектуры с ACID(39) Несмотря на наличие многих неясностей, основная идея

DORA – при наличии в системе физически общих ресурсовпроизводить разделение данных не на физическом, а налогическом уровне – кажется очень привлекательной

Прототип DORA рассчитан на традиционную работу сдисками, в нем поддерживаются общая система буферов ижурнализация (на уровне Shore-NT) и поэтому:

можно спокойно делить данные на логическом уровне сточностью до кортежа (все буферные страницыдоступны всем потокам управления)

в нем удается обойтись без двухфазного протоколафиксации транзакций

и он плохо согласуется с общими идеями H-Store


71

Новые архитектуры с ACID(40) Однако мне кажется, что возможенкомпромисс между архитектурами H-Storeи DORA внутри одного многоядерногокомпьютера для поддержки баз данных восновной памяти без журнализацииизменений

Для этого нужно добиться полногоотсутствия потребности вцентрализованных блокировках

Подробности в моей статье


72

Новые архитектуры с ACID(41) Будущее поколение ACID-транзакционных систембудет опираться на две основные параллельныеархитектуры одноузловую и многоузловую

Одноузловая архитектура предполагает наличиемощного многоядерного компьютера ииспользование энергонезависимой внешнейпамяти, в которой, в частности, долженподдерживаться журнал повторного выполнениятранзакций

И в этом направлении хороший фундаментзакладывает DORA


73

Новые архитектуры с ACID(42) Многоузловая архитектура строится на основедостаточно большого числа, вообще говоря,недорогих компьютеров, связанных сетью

Базы данных хранятся только в основной памяти,для обеспечения отказоустойчивостииспользуется репликация

В этом направлении хорошей основой являетсяH-Store (и VoltDB), хотя следовало бы учестьвозможности использования физически общихресурсах в многоядерных узлах подобных систем


74

Новые архитектуры с ACID(43) К сожалению, эти две архитектуры являются

взаимоисключающими Трудно представить компанию, которая хорошо потратилась на

приобретение мощного многоядерного сервера с дорогой дисковойподсистемой, а потом решается отказаться от использованиядисков и перейти к использованию многоузловой архитектуры

Трудно представить себе и ситуацию, когда сначала был выбранподход с использованием дешевых кластерных архитектур почтибез дисков, а потом вдруг покупается отдельный дорогой сервер, икомпания переходит к использованию одноузловой архитектуры

Так что, скорее всего, будет продолжать существовать инаправление shared disks, свойственное, например, Oracle,поскольку оно позволяет достаточно эффективно использоватькластеры, построенные с использованием мощных дисковыхсерверов, которые до этого использовались автономно


75

Рационализация согласованности (1)

Новый подход к оптимизации СУБД

Rethinking Cost and Performance of DatabaseSystemshttp://citforum.ru/database/articles/rethinking/

Новые тенденции: для многих Web-приложений строгаясогласованность данных в соответствии спарадигмой ACID не требуется; требуетсямасштабируемость до миллионов пользователей игарантированное время ответа

использование SOA

«облачные вычисления»


76


В «прошлой» жизни в системе управленияданными

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


77


В новых условиях

при заданных требованиях кпроизводительности приложений (пиковаяпропускная способность, максимальнодопустимое время ответа) требуетсяминимизировать требуемые аппаратныересурсы и максимизироватьсогласованные данные


78


• Основным показателем системы баз данных, нуждающемсяв оптимизации, является денежная оценка затрат

• Производительность является заданным ограничением

приложения, а не целью оптимизации


79


• Традиционная архитектура системы базданных


80


• Архитектура Sausalito (28msec.com)


81


• Основные функции СУБД – обработка запросов иуправление транзакциями – переносятся наприкладной уровень

• На нижнем уровне поддерживается толькораспределенное хранение данных за счетиспользования службы Amazon S3

• Согласованность данных поддерживается не науровне хранения, а на прикладном уровне

• Отсутствует какой-либо объект, контролирующийвесь доступ к данным, и согласованность данныхобеспечивается за счет применения во всехсерверах приложений общих протоколовраспределенных систем


82


• Все данные и заранее откомпилированный код приложениясохраняются в среде Amazon S3 в виде BLOB'ов

• При обработке каждого HTTP-запроса (поступающего,например, по инициативе пользователя из Web-браузера)служба Amazon EC2 c учетом балансировки нагрузкивыбирает доступный сервер EC2

• В этом сервер из S3 загружается код приложения, которыйзатем интерпретируется подсистемой поддержки временивыполнения Sausalito с доступом при необходимости кобъектам базы данных, хранимым в S3

• Особенностью Sausalito является то, что для реализациилогики приложений и доступа к базе данных в системеиспользуется язык XQuery, расширенный средствамиобновления данных и написания скриптов


83


• У системы с такой архитектурой с мало шансов сравняться склассическими системами баз данных в отношениипроизводительности и согласованности данных

– Это обратная сторона отказа от принципов контроля над даннымии пересылки запросов

• Однако эта архитектура хорошо соответствует новым требованиям• Архитектура экономически эффективно реализуется с

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

• Гибкость достигается за счет упрощения платформы ииспользования на всех уровнях единой модели программированияи данных (XML/XQuery)

• Для многих рабочих нагрузок обеспечивается предсказуемостьрасходов и производительности


84


• Consistency Rationing in the Cloud: Pay only when it mattershttp://citforum.ru/database/articles/kossmann_vldb_2009/

• Основная идея исследования состоит в том, что не вседанные требуется обрабатывать на одном и том же уровнесогласованности

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

• Обеспечение дополнительных уровней согласованностизначительно повышает стоимость выполнения операций

• С другой стороны, стоимость несогласованности данныхтакже можно измерить, оценив относительное числоопераций, которые выполняются некорректно из-заотсутствия согласованности, и переведя эту оценку вденежные расходы


85


• Нахождение баланса между стоимостью выполненияопераций, согласованностью данных и их доступностьюявляется нетривиальной задачей

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

• Предлагается использовать динамическую стратегиюподдержки согласованности данных – снижать уровеньтребований к согласованности, когда это не приводит кслишком большим убыткам, и повышать их, если убыткимогут оказаться слишком большими

• Этот подход называется рационализациейсогласованности (consistency rationing) по аналогии спонятием рационализации управления запасами (inventoryrationing), когда запасы отслеживаются в разной точности взависимости от их наличного объема


86


• Все управляемые данные разделяются на три категории A,B и C, и для каждой категории применяются свои методыобработки в зависимости от обеспечиваемого уровнясогласованности

• К категории A относятся данные, нарушениесогласованности которых привело бы к крупным убыткам

• Несогласованность данных категории C являетсяприемлемой (несогласованность либо вызывает лишьнебольшие убытки, либо в действительности не возникает)

• Наконец, категория B включает данные, требования ксогласованности которых изменяются во времени

• Для данных категории B можно добиться оптимальногосоотношения расходов на выполнение операций иобеспечиваемого уровня согласованности


87


• Гарантии согласованности в обеспечиваются для данных, а не длятранзакций

• В результате ослабляются только свойства изоляции исогласованности ACID-транзакций, а атомарность и долговечностьобеспечиваются в полном объеме

• Для данных возможны два уровня согласованности – сессионнаясогласованность (session consistency) и сериализуемость(serializability)

• Сессионная согласованность данных подразумевает, что клиентыподключаются к системе в контексте сессий

• Во время сессии система гарантирует монотонность по чтениюсобственных записей

– результат записи процесса в элемент данных x всегда виденпоследующим операциям чтения x того же процесса

• За границы сессии гарантии монотонности не распространяются


88


• Для данных категории A обеспечивается сериализуемость втрадиционном транзакционном смысле

• Все транзакции, модифицирующие данные категории A,изолируются и оставляют данные согласованными

– здесь имеются в виду и согласованность в смысле ACID,и строгая согласованность в смысле распределенныхсистем

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

• Для поддержки сериализуемости используется двухфазныйпротокол синхронизационных блокировок


89


• Для данных категории B во время работы системы наоснове разработанных авторами политик производитсяпереключение между режимами сессионнойсогласованности и сериализуемости

• Если одна транзакция работает с некоторой записью врежиме сериализуемости, а другая обновляет ее в режимесессионной согласованности, то обеспечивается сессионнаясогласованность

• Если в одной транзакции одновременно обрабатываютсяданные категорий A и C, то при выполнении операциичтения данных категории A эта транзакция всегда получаетих последнее согласованное состояние и оставляет ихсогласованными после своей фиксации

• При чтении данных категории C транзакция может получитьих в несогласованном и/или устаревшем состоянии


90


• Разработчики Sausalito вполне смогли справитьсяс поддержкой ACID-транзакций и• ослабляют требования к согласованности совсемне на основе ограничений, которые ставит теоремаCAP,

• а с целью вполне разумной оптимизации стоимостислужбы управления данными


91

Заключение (1)

• Теорема CAP Эрика Брювера не имеет никакого отношенияк возможности или невозможности поддержки ACID-транзакций в горизонтально масштабируемых кластерныхсистемах

• Проект H-Store показывает, что в параллельной архитектуреshared-nothing основную проблему представляютраспределенные транзакции, накладные расходы нафиксацию которых могут заметно снижать пропускнуюспособность системы

• Однако полученные результаты показывают, что для рядаважных типов рабочей нагрузки этих расходов можноизбежать


92


• Другую проблему транзакционных параллельныхсистем без совместно используемых ресурсовсоставляет потребность в массовой физическойпересылке данных при балансировке нагрузки

• И здесь может несколько помочь подход проектаDORA, в котором вместо физического разделенияданных в многоядерном компьютере используетсяих логическое разделение за счет наличия общейпамяти


93


• Наконец, подход Sausalito показывает, что• при отказе от основных принципов разработкиСУБД – контроля над данными и передачизапросов – в угоду более точному следованиюархитектуре SOA расходы на поддержку ACID-транзакций существенно возрастают

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


94


• Исследования и разработки массивно-параллельных транзакционных СУБД вближайшие годы будут активнопродолжаться, и нам предстоит ещеувидеть и услышать много интересного

• Полный текст статьи:Транзакционные параллельные СУБД:новая волнаhttp://citforum.ru/database/articles/kuz_oltp_2010/


95

Спасибо, с наступающей Весной!

1

Шесть компонент

успешных проектов

Корпоративные БД

2011

2

Индустриальный подход

• Решения последних лет

прокладывают путь к

дальнейшей

индустриализации отрасли

создания систем БД

3

• Использование накопленных данных

является основой современных

информационных систем.

• Обработка данных заложена в

фундамент бизнес-технологий.

• Желание компаний хранить все

больше данных и необходимость

управлять ими создают серьезные

проблемы как для для

разработчиков, так и

администраторов баз данных.

Данные представляют один из

важнейших активов бизнеса

4

Мир изменений

В ходе миграции, обновления и

настройки в среду баз данных

вносятся многочисленные

изменения

• как модели данных,

• так и схемы/структуры их

хранения,

• проводятся дополнительные

настройки и оптимизация

критически важных БД

• изменяются правила

обработки данных, чтобы

отражать новые требования, в

том числе и регуляторного

характера.

6

Успех проекта определяется:

6

• Увеличением прибыли

• Управлением рисками

• Визуализация в течение жизненного цикла проекта

– Оценка требуемой задачи на раннем этапе

– Точность в прогнозе и определении текущего положения дел

– Использование приоритетов в оценке бизнес-потребностей

• Улучшенные качество и продуктивность– Качество и эффективность архитектуры и кода– Методы определения соответствия требованиям

• Эффективность затрат– Способность вносить изменения без увеличения затрат– Устранение лишней и бесполезной работы– Постоянная и частая переоценка требований

• Соответствием внешним требованиям

Более успешными являются проекты, в которых

использовался Agile-подход. Это также касается и

корпоративных баз данных.

7

АGILE manifesto

• Изложенные в АGILE manifesto

характеристики направлены на

борьбу с недостатком текущих

знаний у разработчиков и

некомпетенцией, организацию

продуктивного сотрудничества

создателей систем и их

заказчиков.

• Следование этим принципам

подразумевает использование

эволюционного подхода и

сокращение времени циклов при

увеличении их количества

•Люди и взаимодействие важнее

процессов и инструментов

•Работающий продукт важнее

исчерпывающей документации

•Сотрудничество с заказчиком важнее

согласования условий контракта

•Готовность к изменениям важнее

следования первоначальному плану

То есть, не отрицая важности того,

что справа,

мы всѐ таки больше ценим то, что

слева.

8

В области управления данными

Применяются Agile-технологии:

• рефакторинг БД,

• Agile-моделирование данных,

• управление конфигурациями и изменениями,

• организация тестовых площадок (sandbox),

• Agile MDM

• и др

10

Множество типов СУБД и их версий

• СУБД продолжают развиваться и

расширяться с каждой версией

продукта

• Администраторам БД приходится

быть экспертами по ВСЕМ(!)

версиям

• Многие новейшие функции

заставляют АБД вторгаться в

непривычные для них области

деятельности, которые были ранее

в компетенции разработчиков

• Стандартные средства работы

становятся все сложнее и

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

числом версий

90% компаний в мире

применяют более одной СУБД

11

Продукты Embarcadero используют

• 90 из списка Fortune 100

• 3.2 million клиентов во всем мире

• Хорошая позиция в отраслях:

– Финансовые услуги– Производство– Наука (Life science)– Телекоммуникации

• Применяются:

– Вертикальными рынками (финансовый сектор, промышленное производство, ИТ

и телекоммуникации, медицина)

– Независимыми поставщиками ПО, разработчиками приложений,

профессионалами БД, крупными ИТ-службами

12

Подход Embarcadero к достижению эффективной

производительности

• Понимание модели /

устройства БД

• Выявление проблем на

более ранней стадии

• Управление пространством

для хранения

• Управление

производительностью

• Управление объемами

• Управление изменениями

6 компонент стратегии

13

Выбор правильного средства

• Выбор правильного средства –

ответственное дело.

Важнейшие функции

• Моделирование данных

• Интегрированная разработка

кода SQL.

• Управление изменениями.

• Оптимизация баз данных

14

Моделирование: UML и

данных

• Поддержка разных

СУБД

• Анализ БД с

помощью моделей

• Визуализация

структур БД

• Оптимизация

производитель-

ности

• Анализ влияния

изменений

• Коллективное

моделирование

15

ER/Studio – состав продуктов

DA - Моделирование

данных

SA - UML


BA – Моделирование бизнес

процессов

Repository – хранилище

моделей и

метаданных

MetaWizard – обмен

метаданными

Portal – WEB-

интерфейс к

репозиторию

Universal Data

Models

Viewer

16

Совместное использование метаданных

Проектировщики

Бизнес

аналитики

Executives

Разработчики

Data Stewards

DBAs

17

Гетерогенная среда

Embarcadero DB Tools

AzureAmazon VM

Windows

Unix

Mac

Rapid SQL DBArtisan DB Optimizer Change Manager

Performance Monitor

18

• Отладка, оптимизация и профилирование SQL-кода

– Отладка хранимых процедур, функций и триггеров– Интеграция с Embarcadero SQL Tuner– Анализ времени отклика и процедуры тестирования с

помощью Code Analyst (только в Rapid SQL Professional)

Code Analyst

SQL Debugger

Rapid SQL: основные возможности

• Microsoft SourceSafe

• IBM Clear Case

• Serrano PVCS

• etc.

Система контроля версий– Бесшовная интеграция с

ведущими коммерческими системами контроля версий

– Поддержка всех операций (get, checkout, check-in, history и diff)

19

DBArtisan: основные возможности

• Автоматизированное кросс-платформенное решение для администрирования баз данных

– Инструменты и мастера для частых задач

– Поддержка IBM DB2® for Open Systems, z/OS, OS/390, Oracle®, Microsoft SQL Server®, MySQL, и Sybase®

• Управление схемой– Редакторы и мастера для управления объектами

схемы на всех платформах

• Управление безопасностью– Мощные возможности для управления

пользователями баз данных

• Управление SQL– Богатые возможности ISQL редактора для создания и

исполнения SQL-кода в различных СУБД

• Управление задачами– Интеграция с Планировщиком задач Embarcadero или

Microsoft Windows Task Scheduler

• Мощные инструменты диагностики и управления

– Space Analyst:– Capacity Analyst:– Performance Analyst:

• Управление данными– Мастера для миграции объектов схемы

– Настраиваемые задачи миграции

• Мощные возможности для резервного копирования и восстановления

– Сокращение требований к дисковому пространству и ускорение процессов backup и restore

20

Для чего нужен DB Optimizer

• Промышленная эксплуатация– Быстро распознать проблемы с SQL-запросами

– Поставить верный диагноз и сообщить о проблемах разработчикам

– Профилировать базы данных и предупреждать возможные проблемы с

производительностью чтобы уменьшить или ликвидировать необходимость

замены аппаратных средств и улучшить производительность приложений

• Разработка– Обнаружить проблемы с производительностью до того как они попадут в БД

находящиеся в промышленной эксплуатации

– Гарантировать качество SQL-запросов в конкретных приложениях

– Ускорить тестирование и лучше обрабатывать результаты нагрузочного

тестирования

Предотвратить попадание некачественного непроизводительного SQL-кода в промышленную

эксплуатацию и исправить его до того, как возникнут проблемы.

21

DB Optimizer

Пример: проблема на сервере БД

Слежение за изменением показателей

• Начать с фильтра ORDERS (0.34%)

• Отобрать CUSTOMERS по связке дает 8 строк

• Затем ORDER_LINESдает 115 строк

• И т.д.

22

Проактивный контроль состояния: Performance Center

• 24x7 защита– Постоянное отслеживание


• Enterprise Ready Interface– Единый интерфейс для DB2,

Oracle, Sybase, и SQL Server баз данных

– Определяемые пользователей индикаторы проблем

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

• Отчеты с историей изменений– Отчеты со статистикой производительности

– Планировщик с возможностью экспорта

• Предупреждения– Индикаторы проблем

– Настраиваемые уведомления о проблемах на базе шаблонов

• Запрограммированные реакции– Автоматическое исполнение скрипта (SQL

или запуск задачи) в ответ на проблему

22

• Уменьшить проблемы с производительностью и снизить стоимость обслуживания

• Улучшить уровень обслуживания и соответствовать SLA

• Решать новые и усложняющиеся задачи силами текущего персонала

Преимущества для бизнеса

23

Управление изменениями в базах данных

• Учет и контроль изменений

• Многоверсионность

конфигураций

• Синхронизация состояний

• Контроль неизменности

• Восстановление состояния

• Обмен с «песочницами»

• Тестовые данные

• Как на уровне объектов схемы

так на уровне конфигураций и

данных

24

Типичный процесс управления изменениями

1. Определить необходимость

изменения

2. Запротоколировать изменение

3. Проанализировать влияние

4. Спроектировать изменение

5. Закодировать

6. Проверить

7. Запланировать

8. Применить изменение

9. Наблюдать

10. Продолжать мониторинг

11. Закрыть запрос на изменение

Change

Ticketing

SystemModeling &

Impact

(ER/Studio)

Development

(RapidSQL)

Software

Source

Control

Change

Manager

Monitor/

Manage

Production

Databases

Dev/Test Databases

Change Manager поддерживает 2 мира

Ориентированный на модели (Model Driven) и

ориентированный на разработку (Development Driven)

25

Change Manager

• CM/Data • Высокоскоростной инструмент для сравнения и синхронизации

данных, который сравнивает, проверяет и синхронизирует данные в

рамках одной или нескольких СУБД

• CM/Config• Инструмент для конфигурации и сравнения настроек БД, который

сравнивает и отслеживает изменения

• CM/Schema– Автоматически снимает и отслеживает копии схемы данных,

сравнивает и быстро идентифицирует изменения и устраняет

изменения

Вместе с CM/Config и CM/Data, Change Manager

охватывает все три размерности управления

изменениями в базе данных

Кросс-платформенный инструмент

для сравнения данных, схем и

конфигураций, который поддерживает

весь цикл жизни базы данных

26

Комплексные решения Embarcadero

Embarcadero предлагает комплексные

решения перечисленных проблем в

виде наборов инструментальных

программных средств,

оптимизированных с точки зрения

выполнения той или иной функции

управления и обслуживания баз

данных.

• Это Embarcadero DB PowerStudio XE

или для одного типа СУБД: MS SQL

Server, Oracle, Sybase, DB2

• или отдельные продукты «линейки»

Embarcadero DB Tools: DBArtisan,

RapidSQL, DB Change Manager,

DBOptimizer c DB Performance Center.

Важнейшие функции

• Моделирование данных

• Интегрированная разработка

кода SQL.

• Управление изменениями.

• Оптимизация баз данных

28

Продукты

Целевые области- Client/Server, Multi-Tier, Web 2.0,

SOA, Native/Managed Dynamic

Languages, DB

Технологии-Win32 -Linux -Oracle -Ruby on Rails -Blackfish SQL -Sybase

-Net -Solaris -SQL Server -Apached/IIS -DB2 -PostgreSQL

-Java -PHP -Interbase -MySQL -iSeries

Полный набор

инструментов

All-Access

Управление и мониторинг БД

DBArtisan

Rapid SQL

Change Manager

БД уровня подразделения,

встраиваемые БД

InterBase SMP

InterBase To-Go

Проектирование,


ER/Studio Enterprise

Data Architect

Business Architect

Software Architect

ER/Studio Portal

Настройка


DB Optimizer

Performance Center

J Optimizer

Разработка приложений

RAD Studio

Delphi

C++Builder

Delphi Prism

JBuilder

RAD for PHP

3rdRail

Turbo Ruby

29

Трансляция приложений

30

Представительство

Embarcadero Technologies в России и СНГ

Телефон +7(495)708 4393

Контакты

Андрей Совцов

email: [email protected]

Blog: http://blogs.embarcadero.com/asovtsov/


http://blogs.embarcadero.com/asovtsov/





mailto:[email protected]


Система управленияпроектами

Шестнадцатая ежегодная техническая конференция

Корпоративные базы данных 20011

Сергей ЛитовченкоВиталий Максимов

Слайд 2

Содержание

Основные функции

Работа с требованиями

Работа с запросами на изменение

Ресурсы и разграничение доступа

Слайд 3

Комплексная ALM (Application Lifecycle Management) системаорганизации разработки и поддержки продуктов за счет

автоматизации и контроля бизнес-процессов.

Слайд 4

Основные функции

Управлениепроектами

Управлениепродуктами

Учётрабочего времени

Управлениересурсами

Интеграция с другимипродуктами

Управлениеконтрактами

Управлениеконтрагентами

Управлениесчетами

Формированиеотчетов

Управление запросамина изменение

Управлениезадачами

Управлениетребованиями

Управление документамии контрольными

листами

Управлениетестированием

Слайд 5

Проблема формирования требований

Слайд 6

ЗаданияЗадания

Формирование требований

Проект Продукт

ПроектПроектТребования Задания

Запросы на изменения

Техническоезадание

Слайд 7

Управление требованиями

Импорт требований

Планирование заданий по требованиям

Отслеживание статуса и версий требований

Накопление истории изменений

Создание требований на основе запросов на изменение

Слайд 8

Управление требованиями

Слайд 9

Какими бывают запросы на изменение

Видызапросов наизменение

Новое требование Дефект Улучшение

Слайд 10

Формирование запросов на изменение

ПроектПроектПроектПроектПроектПродукты

ПроектПроектТребования Задания

Запросы на изменения

Техническоезадание

Ошибки

Заказчик / Команда модернизации

Слайд 11

Управление запросами на изменение

Предоставление возможности заказчику самостоятельноформировать запросы на изменение

Отслеживание жизненного цикла запроса

Привязка к требованиям по проекту

Определение приоритета

Обсуждение запросов

Слайд 12

Управление запросами на изменение

Слайд 13

Управление ресурсами

Управление ролямии привилегиями

Управление компаниями

Управлениеподразделениями

Управление группами

Слайд 14

Ресурсы и разграничение доступа

ЗаказчикРуководитель

проекта

Аналитик

Командаразработчиков

Командатестирования

Командатехническо

йподдержки

Слайд 15

Учёт рабочего времени

Отчёты

Контрольприсутствия

Регистрацияприхода и ухода

Регистрация командировок,отпусков, больничных

Слайд 16

Преимущества

ДляЗаказчика

Дляруководителя

проекта

Длякомандытехническо

йподдержки

Дляаналитика Для команды

тестирования

Для командыразработчиков

Слайд 17

Преимущества

Снижениерасходов

Укреплениебезопасности

Ориентацияна потребителя

Обеспечениетрассируемости

Слайд 18

Поддерживаемые платформы и технологии

Рекомендуемые браузеры

Поддерживаемые ОС

СУБДСервер приложений Технология

Слайд 19

План развития

Быстродействие

Usability

Отчеты для руководства

ДокументооборотФинансы

Словари объектов

Слайд 20

Информация о Project Tracking 2.0

www.linter.ru

Слайд 21

Соотношение стоимости и функционала

функциональность

стоимость

Trackstudio

Teamwork

Мегаплан

Comindwork

MS Project 2010

Primavera

Слайд 22

Вопросы?

Сергей Литовченко

[email protected]

Слайд 23

Спасибо за внимание

www.relex.ru

[email protected]

Новые возможностиСУБД Линтер

Шестнадцатая ежегодная техническая конференция

Корпоративные базы данных 20011

Алексей ЕгоровМихаил Ермаков

Слайд 2

Кэширование

select id, ch from test /* +ANSCASHE*/

select * from $$$SYSRL

select * from SYSTEM.$$$SYSRL

Кэш результатов выполнениязапросов выполнен на двух

уровнях: кэш оттранслированныхзапросов и кэш результатоввыполненных запросов.

Слайд 3

Квантование

• Улучшено квантование вычисления предикатовIN/NOT IN в отсутствие индексов

Пример:select smth from T1 where T1.C1 in(select T2.C2 from T2 where condition) and …T1.C1 и T2.C2 – не индексированы.

• улучшено квантование запросов, требующиеперенумерации ответов, приемущественнозапросы ко VIEW и содержащие подзапросы воFROM конструкциях

Слайд 4

• Добавлена функциональностьпользовательских сообщений в AUDIT

• Изменена структура фразовых индексов

• Разрешено индексирование BLOB влюбых кодировках

Слайд 5

Оптимизации

• Оптимизировано создание бит-векторов для временных таблиц

• Ускорена процедура восстановленияБД после сбоев, в том числе врежиме горячего резервирования

Слайд 6

Оптимизации

Доработано использование хинта/*+LAST*/ для предиката BETWEEN.

1>select name from A

2>where A.id between 10 and 10000000

3>and A.id=B.id

4>and B.id=25

Слайд 7

Расширение SQL

• Реализована поддержка PREFERENCES

• Возможность удаления столбца таблицы

• Разрешены выражения в конструкцииDEFAULT (Generated columns)

• Введен оператор MERGE

• Введена конструкция IF NOT EXIST

Слайд 8

Выполнение блока кода

Введен механизм исполнения блока execute block

Слайд 9

Транзакции

• Реализован механизм двухфазнойфиксации коммита.

• Добавлена возможность управлятьзакрытием подчиненных курсоров вкомандах COMMIT и ROLLBACK

Слайд 10

SQL-транслятор

• Существенно уменьшен размервнутреннего представления запроса.

• Появилась возможность с помощью SQL-запросов напрямую работать с колонкамиBLOB

create or replace table test(bl blob character set "UCS2");

insert into test(bl) values('0123456789 aaa 0123456789');

select lenblob(bl), getblobstr(bl, 1, 60) from test;

| 50|0123456789 aaa 0123456789.....|

Слайд 11

SQL-транслятор

update test set bl=insert(bl, 3, 10, 'aa');


| 50|0aa 6789 aaa 0123456789.....|

update test set bl=insert(bl, 23, 6,HEX('31003100310031003100'));


| 50|0aa 6789 111 0123456789.....|

-----------------------------------

update test set bl=replace(bl, '12345', 'jjj');

| 50|0jjj 6789 aaa 0jjj 6789.....|

|update test set bl=replace(bl,HEX('37003800'), HEX('780078007800'));


| 50|0jjj 6xx9 aaa 0jjj 6xx9.....|

Слайд 12

Размер сообщений

• Появилась возможность использовать приобработке запроса неограниченный объемпамяти

• Добавлена возможность сортировкишироких записей (более 4 К)

• Размер сообщений между компонентамиЛИНТЕР увеличен до 64 К.

Слайд 13

Работа со временем

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

• Реализована поддержка операций надинтервальным временем:1. Вычисление интервала времени междузначениями дата-время

2. Сложение/вычитание интервалов времени

3. Умножение/деление интервалов времени

Слайд 14

Поддержка платформ

Новые платформы• On-Time RTOS32

• Apple iOS

• Google Android

• Maemo

• AstraLinux

Обновления на платформах•Windows

•SUN Solaris

•HP-UX

•Linux

•MAC OS X

•FreeBSD

•Unix System V

•QNX

•ОСРВ (ОС 2000)

•OS-9000

•VxWorks

•OS-9

Слайд 15

Интерфейсы

• ADO.NETдобавлена поддержка Mono 2 в Linux, LINQ,

интеграция с Microsoft VS, .Net4, Nhibernate

• Добавлена поддержка интерфейса RUBY

• Добавлен XPO для пакета DevExpress

Слайд 16

Интерфейсы

• PHPДобавлено автоматическое получение BLOB

полей, добавлена возможность BIND дляBLOB, добавлены интерфейсы PDO и ADO,внесены многочисленные оптимизации.

• PerlДобавлены дополнительные функции работы с

BLOBдоработан интерфейс для 6-й версии,добавлена GetColInfo и другие функции.

Слайд 17

Мастер запросов

Слайд 18


Слайд 19


Слайд 20

Новые возможности редакторав рабочем столе

Слайд 21

Спасибо за внимание

www.relex.ru

[email protected]

Слайд 22

Вопросы?

Последняя миля BI проекта:визуализация и анализ данных

Последняя миля BI проекта

•Каждый BI проект заканчиваетсянабором отчётов

•Отчёты – единственное «лицо» BIсистемы для сотен пользователей

•Всё ли вы учитываете припроектировании?

Последняя миля BI проекта

•10-15% затрат проекта – создание отчётов•Подход «Удобный инструмент, все отчётыпользователи сделают сами»:• тысячи отчётов;• пользователи – эксперты в бизнесе, ане в создании аналитических приложений

• IT проще наращивать объём ХД, чемпомогать анализировать данные

Usability Design отчётов

•Левый верхний угол – зона наибольшеговнимания. Там чаще всего ставят логотипкомпании – это неправильно для«внутренних» отчётов

•Намечайте «точки внимания» в отчёте•Используйте микрографики•Приглашайте юзабилити-специалистов

В зависимости от того, какпользователи используют отчёты, развивайте ихдля решения аналитических задач:

• Сравниваете данные отчёта с другими данными?Вам нужен «drill-through»• Смотрите значения за предыдущий период?Нужны подобные колонки в отчёте

От отчётов к BI приложениям

• Регулярные командировки «в бизнес»для создателей отчётов

• Воспитание ключевых бизнес-пользователей

• Не бойтесь предлагать новыепоказатели для анализа

www.kpilibrary.com

Пользователи и отчёты

• Пользователям нужен Excel? Им трудноработать с вашими инструментами

• ...или их возможностей не хватает дляанализа

• Общайтесь с пользователями. Учите их

Экспорт отчёта в Excel

• Обращайте внимание на дизайнотчётов

• Посадите разработчиков отчётоврядом с пользователями – хотя бы напару недель

• Отчёты не удовлетворяют всеманалитическим потребностям

Как анализировать данные?

•Людям проще считывать визуальныешаблоны, чем цифры

•Хотите выделить паттерны в данных –покажите их графически

• Человек поймёт их раньше, чем любыетаблицы с цифрами и процентами

В течение 10 секунд найдите самое большое число:

Это – те же данные:

Ещё аналитика:

Отчёт vs. график:

• Изучая отчёты, люди тренируют свое восприятие

• У них формируются паттерны обработки отчётов

• Настоящим бизнес-экспертам достаточно одноговзгляда на «простыню»

• «Простыня» – готовый набор вопросов и ответов

Но что если у вас возникает новый вопрос?

Визуализация данных

Книга «The Back of the Napkin» («Визуальное мышление»)http://www.thebackofthenapkin.com/

Основная цельBI систем

Эффективные графики

Соотношение «чернила/данные»Спидометры и chart-junkВендоры стремятся к WOW!

•3D•Блики и источники света•Прозрачность•Сложные текстуры•Анимация

А если смотреть на это каждый день?

Эффективность – это скучно:

500’000 цифр на одном экране

Теория визуализации данных:

• Как создавать эффективные графики?Этому научному направлению 50 лет, естьмасса исследований и экспериментов

• Выбирайте типы графиков, атрибуты и цветав соответствии с теорией визуализации

•Книги, блоги, статьи:- Stephen Few- Edward Tufte- Colin Ware

Подходят ли ваши системы аналитикам?

•Насколько просто построить типичныеаналитические запросы – нарастающий итогили отношение к прошлому году?

•Оставляйте систему на тестирование•Проверяйте графические возможности•Оценивайте скорость работы с большимиобъёмами данных

Чем мы можем помочь:

• OLAP-решения, повышающие скорость:•Oracle Essbase•другие

• Новые технологии визуализации:•Oracle Essbase Visual Explorer (Tableau)•другие

• Помощь в создании отчетов и визуальных панелей:• консультации•тренинги•любая

Спасибо!

Юрий Кудрявцев[email protected]

Обработка больших научных массивов данныхПавел Велихов, НИИСИ РАН

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

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

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

Например, SciDB избегает большинства накладных расходов связанных с сихнронизацией в OLTP базах данных; моделью данных в SciDB является многомерный массив; SciDB хранит данные с перехлестом, позволяющим параллельно обрабатывать данных с малымколичеством коммуникаций между узлами. В докладе будут детально освещены проблемы, стоящие перед научным сообществом и решения, которые предлагает система SciDB.

Более подробные материалы доклада будут доступны на страничке конференцииhttp://citforum.ru/seminars/cbd2011/ через несколько дней после её окончании.

Опыт использованияFirebird для критическиважных бизнес-приложений

Кузьменко Дмитрий,iBase.ru

Рождение в 2000!

Firebird: 10 лет успешного развитияFirebird: 10 лет успешного развития

Характерные особенности

Версионная архитектура

Почти не требует настройки

Легкое сопровождение иадминистрирование

Подходит-ли для серьезных систем?

2009 год

Тест базы данных размером в 1терабайт

www.ibase.ru/devinfo/fb1tb.htm

Сбор информации по крупнымсистемам

Bas-X (450 гигабайт)

Watermark (множество ~100 гигабайт баз)

другие…

Профитмед

Оптовая торговля медикаментами

До 400 одновременных пользователей

ERP (на базе AVARDA)

База данных 50 гигабайт

ГКБ № 31 – Firebirdпротив Oracle?

Oracle – высокий уровень затрат насопровождение и разработку

В среднем 100 пользователей

OLTP, аналитика

[email protected]

Возможные проблемы

Аппаратное обеспечение

Резервное копирование

Версионность

«Железо»

«еще один аспект - это те самые условияэксплуатации. Oracle/MSSQL - это значит заведомонормальный сервер, инфраструктура и наличиеобслуживающих админов. PostgreSQL/MySQL -наличие в дельта-окрестности следящего заинфраструктурой красноглазика.Для Firebird же типичная инфраструктура – “первыйпопавшийся десктоп с виндой, с матерью на nvidiaчипсете, съеденными мышами проводами, накотором кишат вирусы, админов нет, а пользователикачают с китайских серверов зоофильское порно строянами и червями”»

metaclass.livejournal.com


До версии 2.0 – только online-backup

C 2.0 и выше – incremental backup

См. предыдущий слайд

Подавляющее большинство систем, вкоторых повреждаются или теряются базыFirebird не имеют схем резервногокопирования БД, и даже RAID

Проблемы версионности

Старое наследие – BDE

Драйверы с неверным сопоставлениемпараметров транзакций и уровнейизолированности

Накопление версий при плохомуправлении транзакциями

Простота и легкость провоцируют на«тяп-ляп» программирование иэксплуатацию

Системы на Firebird с обработкой ~2млн. транзакций в сутки – не новость

Существуют единичные системы от 23до 30 миллионов транзакций в сутки

Гарантия успеха?

Использование компонент прямогодоступа или драйверов с полноценнымуправлением транзакциями

Слежение за состоянием транзакций

Проработка регламента обслуживанияБД

Использование соответствующего«железа»

www.firebirdsql.org

www.ibase.ru

[email protected]


Опыт использования

Firebird для критически

важных бизнес-

приложений

Кузьменко Дмитрий,

iBase.ru

Рождение в 2000!

Firebird: 10 лет успешного развития

Характерные особенности

Версионная архитектура

Почти не требует настройки

Легкое сопровождение и

администрирование

Подходит-ли для серьезных систем?

2009 год

Тест базы данных размером в 1

терабайт

www.ibase.ru/devinfo/fb1tb.htm

Сбор информации по крупным

системам

Bas-X (450 гигабайт)

Watermark (множество ~100 гигабайт баз)

другие…

http://www.ibase.ru/devinfo/fb1tb.htm

Профитмед

Оптовая торговля медикаментами

До 400 одновременных пользователей

ERP (на базе AVARDA)

База данных 50 гигабайт

ГКБ № 31 – Firebird

против Oracle?

Oracle – высокий уровень затрат на

сопровождение и разработку

В среднем 100 пользователей

OLTP, аналитика

[email protected]

Возможные проблемы

Аппаратное обеспечение


Версионность

«Железо»

«еще один аспект - это те самые условия

эксплуатации. Oracle/MSSQL - это значит заведомо

нормальный сервер, инфраструктура и наличие

обслуживающих админов. PostgreSQL/MySQL -

наличие в дельта-окрестности следящего за

инфраструктурой красноглазика.

Для Firebird же типичная инфраструктура – “первый

попавшийся десктоп с виндой, с матерью на nvidia

чипсете, съеденными мышами проводами, на

котором кишат вирусы, админов нет, а пользователи

качают с китайских серверов зоофильское порно с

троянами и червями”» metaclass.livejournal.com


До версии 2.0 – только online-backup

C 2.0 и выше – incremental backup

См. предыдущий слайд

Подавляющее большинство систем, в

которых повреждаются или теряются базы

Firebird не имеют схем резервного

копирования БД, и даже RAID

Проблемы версионности

Старое наследие – BDE

Драйверы с неверным сопоставлением

параметров транзакций и уровней

изолированности

Накопление версий при плохом

управлении транзакциями

Простота и легкость провоцируют на

«тяп-ляп» программирование и

эксплуатацию

Системы на Firebird с обработкой ~2

млн. транзакций в сутки – не новость

Существуют единичные системы от 23

до 30 миллионов транзакций в сутки

Гарантия успеха?

Использование компонент прямого

доступа или драйверов с полноценным

управлением транзакциями

Слежение за состоянием транзакций

Проработка регламента обслуживания

БД

Использование соответствующего

«железа»

www.firebirdsql.org

www.ibase.ru

[email protected]


http://www.ibase.ru/

Oleg Bartunov PGDay-2010, Roma, Dec 10, 2010

Efficient K-nearest neighbour search in PostgreSQL

Oleg Bartunov, Teodor Sigaev


Knn-search: The Problem

knn=# select id, date, event from events order by date <-> '1957-10-04'::date asc limit 10; id | date | event--------+------------+----------------------------------------------------------------- 58137 | 1957-10-04 | U.S.S.R. launches Sputnik I, 1st artificial Earth satellite 58136 | 1957-10-04 | "Leave It to Beaver," debuts on CBS 117062 | 1957-10-04 | Gregory T Linteris, Demarest, New Jersey, astronaut, sk: STS 83 117061 | 1957-10-04 | Christina Smith, born in Miami, Florida, playmate, Mar, 1978 102670 | 1957-10-05 | Larry Saumell, jockey 31456 | 1957-10-03 | Willy Brandt elected mayor of West Berlin 58291 | 1957-10-05 | 12th Ryder Cup: Britain-Ireland, 7 -4 at Lindrick GC, England 58290 | 1957-10-05 | 11th NHL All-Star Game: All-Stars beat Montreal 5-3 at Montreal 58292 | 1957-10-05 | Yugoslav dissident Milovan Djilos sentenced to 7 years 102669 | 1957-10-05 | Jeanne Evert, tennis player, Chris' sister(10 rows)

Time: 115.548 msTime: 115.548 ms

● Very inefficient:

– Full table scan, btree index on date won't help.

– Sort full table


Knn-search: Existing solutions

● Traditional way to speedup query

– Use indexes - very inefficient (no searchsearch query !)● Scan full index● Full table scan, but in random order !● Sort full table● Better not to use index at all !Better not to use index at all !

– Constrain data space (range search)● Incremental search → to many queries● Need to know in advance the size of neighbourhood,

how ? 1 Km is ok for Paris, but too small for Siberia● Maintain 'density map' ?


Knn-search: What do we want !

● We want to avoid full table scan – read only rightright tuples

– So, we need index

● We want to avoid sorting – read rightright tuples in rightright order

– So, we need special strategy to traverse index

● We want to support tuples visibility

– So, we should be able to resume index traverse


R-tree index

● Visualization of R-tree index usingGevel

● Greece (data fromrtreeportal.org)


Knn-search: Index traverse

● Depth First Search (stack, LIFO)

R-tree search

● Breadth First Search (queue, FIFO)

● Both strategies are not good for us – full index scan


Knn-search: Index traverse

● Best First Search (PQ, priority queue). Maintain order of items in PQ according their distance from given point

– Distance to MBR (rectangle for Rtree) for internal pages – minimum distance of all items in that MBR

– Distance = 0 for MBR with given point

– Distance to point for leaf pages

● Each time we extract point from PQ we output it – it is next closest point ! If we extract rectangle, we expand it by pushing their children (rectangles and points) into the queue.

● We traverse index by visiting only interesting nodes !


Knn-search: Performance

● SEQ (no index) – base performance

– Sequentually read full table + Sort full table (can be very bad, sort_mem !)

● DFS – very bad !

– Full index scan + Random read full table + Sort full table

● BFS – the best for small k !

– Partial index scan + Random read k-recordsT(index scan) ~ Height of Search tree ~ log(n)

– Performance win BFS/SEQ ~ Nrelpages/k, for small k. The more rows, the more benefit !

– Can still win even for k=n (for large tables) - no sort !



● + We want to avoid full table scan – read only rightright tuples


● + We want to avoid sorting – read rightright tuples in rightright order


● + We want to support tuples visibility


● We want to support many data types

– So, we need to modify GiST


Knn-search: modify GiST

● GiST – Generalized Search Tree, provides

– API to build custom disk-based search trees (any tree, where key of internal page is a Union of keys on children pages)

– Recovery and Concurrency

– Data type and query extendability

● GiST is widely used in GIS (PostGIS), text search, astro,bio,...

● Current strategy of search tree traverse is DFS

– Change to BFS (Best First Search) strategy

– Retain API compatibility


GiST: Technical details

Depth First Searchpush Stack, Root;While Stack { If p is heap { output p; else { children = get_children(p); push Stack, children; }}

Best First Searchpush PQ, Root;While PQ { If p is heap { output p; else { Children = get_children(p); push PQ, children; }}

● For non-knn search all distances are zero, so PQ => Stack andBFS => DFS

● We can use only one strategy (BFS) for both – normal search and knn-search !



● + We want to avoid full table scan – read only <right> tuples


● + We want to avoid sorting – read <right> tuples in <right> order


● + We want to support tuples visibility


● + We want to support many data types

– So, we need to modify GiST


Knn-search: syntax

● Knn-query uses ORDER BY clause

SELECT … FROM … WHERE … ORDER BY p <-> '(0.,0.)'::point

LIMIT k;

<-> - distance operator, should be provided for data type


Knn-search: Examples

● Synthetic data – 1,000,000 randomly distributed points

create table qq ( id serial, p point, s int4);

insert into qq (p,s) select point( p.lat, p.long), (random()*1000)::intfrom ( select (0.5-random())*180 as lat, random()*360 as long from ( select generate_series(1,1000000) ) as t) as p;create index qq_p_s_idx on qq using gist(p);analyze qq;

● Query – find k-closest points to (0,0)

set enable_indexscan=on|off;explain (analyze on, buffers on) select * from qq order by (p <-> '(0,0)') asc limit 10;



● postgresql.conf: shared_buffers = 512MB #32MB work_mem = 32MB #1MB maintenance_work_mem = 256MB #16MB checkpoint_segments = 16 effective_cache_size = 1GB #128MB

● Index statistics (n=1000,000) Number of levels: 3 Number of pages: 8787 Number of leaf pages: 8704 Number of tuples: 1008786 Number of invalid tuples: 0 Number of leaf tuples: 1000000 Total size of tuples: 44492028 bytesTotal size of leaf tuples: 44104448 bytesTotal size of index: 71983104 bytes



k=1, n=1,000,000

Limit (cost=0.00..0.08 rows=1 width=24) (actual time=0.104..0.104 rows=1 loops=1) Buffers: shared hit=4 -> Index Scan using qq_p_idx on qq (cost=0.00..82060.60 rows=1000000 width=24) (actual time=0.104..0.104 rows=1 loops=1) Sort Cond: (p <-> '(0,0)'::point) Buffers: shared hit=4

Total runtime: 0.117 ms 4000 times faster !--------------------------Limit (cost=24853.00..24853.00 rows=1 width=24) (actual time=469.129..469.130 rows=1 loops=1) Buffers: shared hit=7353 -> Sort (cost=24853.00..27353.00 rows=1000000 width=24) (actual time=469.128..469.128 rows=1 loops=1) Sort Key: ((p <-> '(0,0)'::point)) Sort Method: top-N heapsort Memory: 25kB Buffers: shared hit=7353 -> Seq Scan on qq (cost=0.00..19853.00 rows=1000000 width=24) (actual time=0.007..241.539 rows=1000000 loops=1) Buffers: shared hit=7353 Total runtime: 469.150 ms



N=1,000,000

k :hit :knn : seq :sortmem ( seq )---------------------------------------------------1 :4 :0.117 :469.150 : 2510 :17 :0.289 :471.735 : 25100 :118 :0.872 :468.244 : 321000 :1099 :7.107 :473.840 : 12710000 :10234 :31.629 :525.557 : 1550100000 :101159:321.182:994.925: 13957



n=10,000

K :hit :knn : seq---------------------------------- 1 :3 :0.117 :6.07210 :13 :0.247 :5.014 100 :103 :0.295 :6.381 1000 :996 :1.605 :8.670 10000 :9916 :16.487 :14.706 -> knn lose if k=n, n is small



● Real data 2 mln pointsUS, geonames



● Query: find 10 closest points in US to the point (5,5) with 'mars' in names - create composite index:

create index pt_fts_idx on geo create index pt_fts_idx on geo using gist(point, to_tsvector('english',asciiname));using gist(point, to_tsvector('english',asciiname));

=# explain (analyze on, buffers on) explain (analyze on, buffers on) select asciiname,point, (point <->'5.0,5.0'::point) as dist from geo select asciiname,point, (point <->'5.0,5.0'::point) as dist from geo where to_tsvector('english', asciiname) @@ to_tsquery('english','mars') where to_tsvector('english', asciiname) @@ to_tsquery('english','mars') order by dist asc limit 10;order by dist asc limit 10; QUERY PLAN --------------------------------------------------------------------------------------- Limit (cost=0.00..33.55 rows=10 width=35) (actual time=0.452..0.597 rows=10 loops=1) Buffers: shared hit=56 -> Index Scan using pt_fts_idx on geo (cost=0.00..34313.91 rows=10227 width=35) (actual time=0.452..0.592 rows=10 loops=1) Index Cond: (to_tsvector('english'::regconfig, (asciiname)::text) @@ '''mar'''::tsquery) Sort Cond: (point <-> '(5,5)'::point) Buffers: shared hit=56 Total runtime: 0.629 msTotal runtime: 0.629 ms




Time: 115.548 msTime: 115.548 ms


– Full table scan, btree index on date won't help.

– Sort full table




Time: Time: 0.590 ms0.590 ms


– 8 index pages read + 10 tuples read, no sorting

– No sorting

– 200 times faster !

contrib/btree_gist


Committed to 9.1

Knn-search: Status

1

СУБДUMS-FADтм

Компания «Х-Технология»www.x-tex.ru

Москва 2011

2

Системотехническоерешение СУБД UMS-FADтм

Административный клиент GAI

Фреймворк UMS:

веб-сервер UNET

виртуальная машина UVM

компилятор байт-кода UBC

сетевой шлюз UGW

Двигатель FADтм

Драйвер LCD

База данных repoDB

3

ОсобенностиСУБД UMS-FADтм

Расширенная реляционная модель данных ERM

Денормализованные отношения

Ассоциативные массивы данных

Служебные домены первичных ключей данных

Мультиверсионная архитектура

Отсутствие блокировок объектов базы данных

Отсутствие журналов транзакций и сегментов отката

Сериализуемый уровень изоляции транзакций

Механизм поиска в виде матричных деревьев

4

Ассоциативный массив

1 1 1 ХХХХ 2 1 2 ХХХХХХХ 3 1 3 ХХХХХХХХХХХХХХХ

4 1 4 ХХХХ 5 1 5 ХХХХХ 5 1 6 ХХХХХХХ 6 1 7 ХХХХХХХХХ

1 1 1 ХХХХ 2 1 2 ХХХХХХХ 3 1 3 ХХХХХХХХХХХХХХХ

Реляционное отношение

Домен Версия Уровень иерархии

Начало первого кортежа

Начало второго кортежа

Значение атрибута

Атрибут кортежа

5

Расширенная реляционнаямодель данных ERM

Денормализованные отношения – максимально полныеинформационные образы типов объектов предметной области

В типах объектов поддерживаются логические связи междусоставляющими доменами (в виде иерархий)

Первичные ключи – функционально независимые атрибутыслужебного домена уникальных идентификационных номеров

Вторичные ключи – соответствуют вторичным ключам базовойреляционной модели данных RM

Манипуляционный и целостный аспекты модели ERMсоответствуют подобным аспектам модели RM

Доменный состав отношений модели ERM соответствуетатрибутному составу классов объектно-ориентированноймодели данных прикладных решений

6

Кортеж данного -мультимножество

Фамилия - Кузнецов

Имя - Иван

Телефон - Рабочий

Номер - 495 365 2987

Телефон - Мобильный

Номер - 916 120 6582

Телефон - Неизвестно

Номер - 499 268 5049

УИН - 27498752063

7

Структура кортежей данных

Атрибуты каждого кортежа связаны в иерархическую структуру

Арность кортежей в общем случае не равна арности отношений

Кортежи могут содержать повторяющиеся атрибуты или группыатрибутов

Каждое отношение содержит головной кортеж, содержащийстандартный набор атрибутов, имеющих неопределенныезначения, и соответствующий одному из типов объектовпредметной области

Максимальный размер одного кортежа ограниченвозможностями файловой системы

Кортеж может содержать ссылки на фрагментынеструктурированной информации, хранимые в файле базыданных или в отдельных файлах

8

Мультиверсионная архитектураСУБД UMS-FADтм

Значение УИН данного Новое значениеатрибута

ID атрибута

ID

Значение УИН данного Старое значениеатрибута

ID атрибута

Адрес УИН данногоУзлы

М-дерева

Стараяверсияданного

Новаяверсияданного

Адрес атрибута

9

Структура версий данных

Каждое данное состоит из первичной версии и набора дельта-версий, логически связанных совпадающим уникальнымидентификационным номером (УИН)

Версии содержат номера транзакций записи

Модифицированные атрибуты в составе версий данныхлогически связаны служебным идентификатором экземпляраатрибута (ID)

Запись новых версий данных осуществляется без чтения иблокировки старых версий, на основании УИН данных и IDатрибутов

Все версии данных хранятся в одном отношении

Очистка базы данных от устаревших версий данныхпроизводится в фоновом режиме путем консолидации версий

10

Двоичное сбалансированноематричное дерево поиска

Корневой указатель

7

3 11

1 5 9 13

8

4 12

2 6 10 14

Значение ключа четного поддерева = 2L x Y , где L – уровень дерева, Y - сомножитель

Позиция узла дерева на уровне = (Y + 1) / 2

Значение ключа нечетного поддерева = (2L x Y) - 1

Значение ключа общей вершины = (K1 + K2) / 2, где K1,2 – значение ключей нижних узлов

11

Особенности матричныхдеревьев поиска

Матричные деревья поиска относятся к самобалансирующимсядвоичным деревьям

Включению элемента в матричное дерево предшествуетприсвоение номера элементу в порядке записи в базу данных

Отдельное матричное дерево состоит из четного и нечетногоподдеревьев (поиск во вдвое меньшем числе элементов)

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

В случае монотонно возрастающего порядка записи элементовматричные деревья не требуют балансировки

Механизм поиска состоит из нескольких ярусов матричныхдеревьев – типы данных, домены, дескрипторы атрибутов

12

Сравнение эффективности реализацииRM и ERM моделей данных

УзлыB+деревьев

Узлы M-деревьев

Списокданных,узлов M-деревьев,кодов изначенийатрибутов

Списоклистьев

B+деревьев

Словарькодов изначенийатрибутов

Таблицыданных

ER модельA – индексируемые атрибуты, N – нормальная

форма, F – сканирование файлов

ERM модельA = max, N = 1, F = 0

Обращения к диску

Запись ~ L/2Чтение ~ 0

Запись ~ 0Чтение ~ 0



Запись ~ NЧтение ~ 1 (+ F) Запись ~ 1

Чтение ~ 1

Запись = A x (L/2 + 2) + 2NЧтение = A x 3 + 2F x N

Запись = 1Чтение = 1

Обращения к диску

Итого: Итого:

Сегментыотката

Запись ~ NЧтение ~ 1 (+ F)

Оперативная память

Энергонезависимаяпамять

13

Основные инновацииСУБД UMS-FADтм

Многомерная база данных, полностьюразмещенная на внешнем носителе

Физическая структура данных,включающая только значимуюинформацию

Схема базы данных, изменяемая вфоновом режиме

14

Компоновочные решения UMS-FADтм

Клиентское приложение

Фреймворк UMS

LCD

FAD

Базаданных

Веб-браузерВеб-браузер

Триггеры, хранимыепроцедуры,

пользовательскиефункции,

представления,серверные приложения

Клиентскоеприложение

FAD

Базаданных

БиблиотекафункцийБиблиотека

функцийБиблиотекафункций

12

3 4

Способы реализации:1 - клиент-серверная архитектура2 - распределенные базы данных3 - библиотеки расширения4 - серверные приложения5 и 6 - встраивание двигателя FAD

6

UNET

UVM

UGW

СУБДСУБД

СУБД

5

4

15

работает на платформе 64-разрядных операционныхсистем UNIX/Linux

работает на платформе 32/64-разрядныхоперационных систем Unix/Linux и MicrosoftWindows

обеспечивает обмен информацией среляционными базами данных, аналитическимисистемами и табличными процессорами

Клиентская часть

Серверная часть

СУБДСУБД UMSUMS--FADFADтмтм реализованареализованавв клиентклиент--сервернойсерверной архитектуреархитектуре

16

Масштабирование СУБД UMS-FADтм

Слейв-сервер

Реплика БД

Запись

Репликация

Чтение

Мастер-сервер Слейв-сервер

Мастер БД Реплика БД

Запись

Репликация

Запись Запись Чтение

Клиент

Клиент

Клиент

Клиент

Клиент

Клиент

17

Индустриальный тест ТРС-Спо оперативной обработкетранзакций OLTP

Пиковая производительность СУБД UMS-FADтм

составила 1 миллион транзакций в минуту врасчете на одно ядро процессора

Цена одной транзакции в минуту СУБД UMS-FADтм составила единицы центов США

18

Зависимость времени чтения от объемареляционной и многомерной баз данных:5, 10 15 и 20 млн. данных

10 20 30 40

0,01

0,02

0,03

0,04

Время, секунды

Данные,млн. единиц

СУБДUMS-FADтм

РеляционнаяСУБД

19

Контакты

ООО «Х-Технология»

127051, Москва, Малый Сухаревский пер.,дом 9, строение 1, офис 36

тел. +7 (495) 960-0050

http: ///www.x-tex.ru

e-mail: [email protected]


DB2 pureScale: особенности

Неограниченная мощность–Начинайте с малого–Растите легко вместе с Вашим бизнесом

Прозрачность для приложений–Избегайте риск и стоимость настройки приложений для работы в кластере

Постоянная доступность–Предоставьте непрерывный доступ к данным с соответствующей производительностью


Межузловое соединение

DB2 pureScale: технологический обзор

БД видна как единое целое

Клиенты

Разделяемая БД

Разделяемый доступ к дискам

CS CSCS CS

CS CS

УзелУзелУзел Узел

CF 1-чный

CF 2-чный

Ядро DB2 работает на нескольких компьютерах– Взаимодействуют друг с другом для обеспечения

согласованного доступа к БД с любого узла

Архитектура разделения данных– Разделяемый доступ к БД– Узлы пишут в собственный журнал на общем диске– Журналы доступны с других узлов (используется во время

восстановления после сбоя)

Технология Cluster Facility– Эффективное централизованное управление блокировками

и общим кэшем– Синхронная дуплексная передача на вторичный для

обеспечения доступности

Высокоскоростное соединение между узлами с низкими накладными расходами

– Специальная оптимизация предоставляет значительные преимущества соединений с возможностью RDMA (Infiniband)

Клиенты соединяются с любым узлом,…… видят БД как единое целое

– Клиент соединяется с любым узлом– Автоматическое управление нагрузкой и

перенаправление клиентов могут изменить физический узел, с которым соединён клиент

Интегрированный кластерный сервис– Обнаружение отказа, автоматизация восстановления после

сбоя, кластерная файловая система– Совместно с STG и Tivoli

Журнал Журнал ЖурналЖурнал


Основные компоненты Аппаратное обеспечение:

– 3 легковесные и недорогие машины, каждая с 2-х ядерным процессором Intel Atom D510, 4 GB RAM, 160 GB HDD

– 1 Gigabit Ethernet коммутатор– 8 GB USB флэш-накопитель

Программное обеспечение:– SUSE Linux Enterprise Server 11 SP1– DB2 9.8 FP3

Демонстрационные примеры:– Technology Explorer for DB2 with SDTW workload demo

• Демонстрация active-active высокой доступности DB2 pureScale – DayTrader Java demo

• Демонстрация интеграции с приложениями на основе WebSphere Application Server 7 без изменения кода приложений

– Oracle Compatibility PHP demo• Демонстрация веб-приложения, написанного на PL/SQL и

запускаемого на DB2 pureScale в режиме совместимости с Oracle


ОС (Novell):Novell SUSE Linux Enterprise Server 11 SP1

Программные компоненты:● Tech Explorer for DB2 9.8● DB2 Express-C 9.7.3● WAS 7● Apache● PHP/Perl● iSCSI target

● DB2 Discovery Kit● Demo Webpages

ОС (Novell):Novell SUSE Linux Enterprise Server 11 SP1

Программные компоненты:● DB2 Enterprise 9.8 FP3● IBM GPFS● IBM TSAMP● iSCSI client

Программные компоненты

Приложения и общая система хранения

2 Узла Данных


Все компоненты в рабочем состоянии


Восстановление после kill -9 процесса DB2 для Member


Восстановление после kill -9 процесса DB2 для Member (прод.)


Восстановление после kill -9 процесса DB2 для CF


Запланированное обслуживание одного из компьютеров

<Insert Picture Here>

Машина баз данных Oracle - Oracle Exadata

Марк РивкинOracle CIS

Шестнадцатая ежегоднаятехническая конференция

«Корпоративные базы данных-2011»

Время доступа к сверхбольшим ХД

Table Scan Time

Table Size1TB 10 TB 100TB

1 Hour

10 Hour

5 Hour

Обычноехранилище

Exadata

• Большие хранилища сканируют десятки, сотни и тысячи дисков

• Соединения между дисками и серверами ограничивают скоростьпередачи данных в десятки и сотни раз

• В результате хранилища становятся медленнее по мере роста

Проблема производительностисверхбольших ХД

Решение проблемы

• Прокачивать меньше данных

• Увеличить количество каналов связи

• Сделать каналы связи шире

Пропускная способность Infiniband

0

200

400

600

800

1000

1200

1400

Gigabit Ethernet 4Gb Fibre 20Gb Infiniband

MB/sec

В 12 размедленнее

В 3 разамедленнее

Пропускная способность одного соединения

Конфигурация системы с Exadata

• Каждая ячейка Exadata – самостоятельный сервер сустановленными дисками и ПО Exadata

• Данные «размазаны» между многими ячейками Exadata

• Нет ограничения на количество ячеек в системе

Exadata Cell

InfiniBand Switch/Network

Single-InstanceDatabase

RACDatabase

Exadata Cell Exadata Cell

Традиционное выполнение запроса

• Пример:

• Оператор хочет найтиклиентов, которые тратятбольше $200 на одинзвонок

• С традиционнымхранилищем, анализ данныхпроизводится сервером БД

• Большая часть данныхотсеивается заненадобностью

• Данные, которыеотсеиваются, тем не менеетратят время на их передачу

Поиск завершен:

1 ТБ данныхвозвращается на

сервер

БД уменьшает

терабайт данных до1000 имен, которые

возвращаютсяклиенту

Возвращаетсярезультат

SELECT

customer_idFROM calls where

amount > 200;

Определяются

экстентытаблиц

Выполняется

поиск

Выполнение запросов с Exadata

• Только нужные колонки

• customer_id

И нужные записи

• where amount>200

Возвращаются на сервер БД

• Разгружается процессор БД

• Не передается лишнийобъем данных

2MB данных

возвращается насервер

Возвращаются

записи

Умный запроспередаетсяячейкам

Определяются

записи и колонкивнутри терабайтной

таблицы,удовлетворяющие

условиям

Обобщаютсярезультатыполученныес разныхячеек

SELECT

customer_idFROM calls where

amount > 200;

Exadata Smart Scan

• Ячейки Exadata реализуют механизм передачизапросов на сторону хранилища (scan offload) с тем,чтобы значительно уменьшить объем данныхвозвращаемых на сторону серверов БД

• Фильтрация строк на основе “where” предиката• Фильтрация колонок• Фильтрация соединений (join)• Фильтрация инкрементального backup• Фильтрация зашифрованных данных• Работа с функциями Data Mining

• 10x уменьшение данных являетсяобычным (на тестах заказчиков)

• Полностью прозрачно для приложения• Даже если происходит сбой ячейки или диска вовремя запроса

11.2

11.2

Прозрачность технологии Smart Scan дляприложений

• Smart scans прозрачен для приложения• Не требуется изменения приложения или SQL кода

• Возвращаемые данные полностью консистентны

• В случае выхода из строя ячейки во время smart scanнезавершенная часть запроса прозрачноперенаправляется на ячейку, содержащую копиюданных

• Smart Scans корректно обрабатывает следующиеслучаи:• Неподтвержденные записи (uncommitted) изаблокированные записи

• Цепочки строк (chained rows)

• Сжатые таблицы

• Обработку национальных языков

• Работа с датами

• Регулярные выражения

• Партиционированные таблицы

Database Machine SoftwareАрхитектура

• Oracle Database 11g на8 или 2 узлах RAC

• ASM обеспечиваетзеркалирование,чередование ибалансировку

• ПО Exadataобеспечивает smartscan с помощьюпротокола iDB

ASMУправление

пулом хранения

11g DatabaseServer

ExadataИнтеллектуальнаясистема хранения

Автоматическая степень параллелизмаКак это работает

SQLоператор

SQL разобран иоптимизатор определил

план выполнения

SQL выполняется безпараллелизма

SQL выполняетсяпараллельно

Оптимизаторопределяет

идеальную DOP

Если оцениваемоевремя выполнениябольше чем заданопараметром

Реальная DOP = MIN(default DOP, ideal DOP)Если оцениваемоевремя выполнения

меньшеPARALLEL_MIN_TIME_THRESHOLD

© 2009 Oracle Corporation – Proprietary and Confidential

New

11.2

Параллельное выполнение в памятиКак это работает

SQLоператор

Определяет размерпросматриваемой

таблицы

Читает в буферныйкэш любого узла

Таблица оченьмаленькая

Всегда используетпрямые чтения с

диска

Таблица – хорошийкандидат дляпараллельного

выполнения в памяти

Таблица оченьбольшая

Фрагменты таблицычитаются в буферныекэши каждого узла

Только параллель-ныйсервер того же узла

RAC будетобрабатывать этот

фрагмент

© 2009 Oracle Corporation – Proprietary and Confidential

New

11.2

Инновации Exadata Storage Server

• Intelligent storage• Smart Scan query offload

• Масштабируемый storage

+ ++

• Hybrid Columnar Compression– Сжатие до 10 раз для DW

– Сжатие до15-50 раз для архивов

Сжатые

primary

standby

test

dev’t

backup

Несжатые

• Smart Flash Cache– Ускорение случайного I/O до 20 раз

– Удваивает скорость сканирования

данных

Данныеостаютсясжатыми

Выгодымультиплек-сируются

Copyright © 2011, Oracle Corporation and/or its affiliates

Copyright © 2009, Oracle Corporation and/or its affiliates – 15 –

Exadata Smart Flash CacheРасширяет ограничения произвольного в/в дисков

• Компромисс между традиционными дисками и Флэшпамятью

• Диски дешевы, имеют большую ёмкость, но ограниченынизким в/в (300 IOPS на диск)

• Флэш память дорогая, имеет малую ёмкость, но можетподдержать тысячи операций в/в в секунду

• Идеальное решение - Exadata Smart Flash Cache• Хранение данных на диске из-за стоимости• Прозрачно перемещает “горячие” данные на флэш кэш• Используются флэш карты вместо флэш дисков, чтоисключает ограничения дисковых контроллеров

• Флэш карты в Exadata

• Высокая пропускная способность, низкая лэтентность• 4 x 96GB PCI Express Flash Cards на Exadata Server

300 I/O в секунду

Десятки тысячопераций в секунду

Почему кэш SMART ?

• Exadata интегрирована с СУБД Oracle, поэтому умеет точноопределять что и когда кэшировать:• Согласно атрибутам объекта CELL_FLASH_CACHE

• NONE, DEFAULT & KEEP

• DB caching hint (defined for different I/O types)

• CACHE, NOCACHE, EVICT

• ASM primary/secondary IOs

• I/O size (Small I/O are cached if KEEP is not set)

• < 128KB IO is small

• Подозрителен к сканированию таблиц – большим операциямчтения

Примеры:• Операции с Control File кэшируются

• Заголовки файлов, блоки индексов и таблиц кэшируются

• Пропускает кэширование операций записи зеркальных копий

• Пропускает кэширование форматирования табличных пространств

Гибридное колоночное сжатиеHybrid Columnar Compression

• Данные группируются поколонкам и затем сжимаются

• Query Mode для хранилищданных

• Оптимизированы для быстрогодоступа

• 10X сжатие• Время сканирования уменьшается

соответственно

• Archival Mode для редкоиспользуемых данных

Оптимизировано для уменьшениязанимаемо места

• 15X сжатие

• До to 50X раз для некоторых данных

• Помощник по сжатиюDBMS_COMPRESSION PL/SQL пакет

Exadata Hybrid Columnar CompressionКак это работает

• Таблица делится на группы из нескольких тысяч строк• Compression Units (CUs)

• В CU данные режутся по колонкам и затем сжимаются• Колонка позволяет хранить похожие данные вместе,увеличивая степень сжатия

• Полезно при прямой загрузке и выборке данных• Низкая активность по обновлению

• Степень сжатия как у лучших промышленныхалгоритмов – Gzip, Bzip2 (LZO/ZLIB/BZ2 )

• Exadata выгружает на ячейки фильтрацию, проекциии т д для сканирования сжатых данных

• Выборка по индексу возвращает сжатые блоки в БД, такчто экономится буферный кэш

Reduces

Table Size

4x to 40x

4x to 50xReduction

CompressionUnit

Co

lum

n1

Co

lum

n2

Co

lum

n3


10 10 10 1116

19 19 19 20 21

29

43

05

101520253035404550

Siz

eR

ed

ucti

on

Facto

rb

yT

ab

le

OLTP Compression (avg=3.3)

Query Compression (avg=14.6)

Archive Compression (avg=22.6)

Реальные результатыOracle Production E-Business Suite

• Коэффициенты колоночного сжатия• Query = 14.6X• Archive = 22.6X• Зависит от приложения

52


Другие возможности ПО Exadata

• Exadata Storage Indexes• Структура в памяти, которая исключаетненужные дисковые операции В/В

• Хранит МИН и МАКС значения для каждойколонки

• Обычно одна запись в индексе для каждогоМб диска

• I/O Resource Manager (IORM)• Обеспечивает приоритет операций В/В дляобеспечения предсказуемойпроизводительности


Exadata резко снижает трафик

1 TB

после сжатия

10 TB данныхтребуют IO для 10 TB

100 GB

с partition pruning

20 GB

с Storage Indexes5 GB

с Smart Scans

милисекундына Database

Machine

Данных в десятки раз меньше, Scans в 2000 раз быстрее

Архитектура Exadata

DB Server

DB InstanceDBRM

ASM

Single-InstanceDatabase

RACDatabase

DB Server

DB InstanceDBRM

ASM

DB Server

DB InstanceDBRM

ASM

OELCELLSRV MS

RSIORM

Exadata Cell

iDB Protocol overInfiniBand withPath Failover

InfiniBand Switch/Network

CellControl

CLI

EnterpriseManager

OELCELLSRV MS

RSIORM

Exadata Cell

OELCELLSRV MS

RSIORM

Exadata Cell

Oracle Grid Computing

Кластеры серверов приложений

Кластеры баз данных

Сетевые устр. хранения

• Storage Grid

• Database Grid

• Application Grid

• Grid Control

Grid Control

Архитектура Exadata X2-2

Database Grid• 8 compute servers (1U)

• 2 Intel Sockets

Storage Grid

• 14 storage servers (2U)

• 2 Xeon CPUs per server

• 100 TB High Speed disk,or336 TB High Capacitydisk

• 5 TB PCI Flash

• Data mirrored acrossstorage servers

InfiniBand Network

• Redundant 40Gb/s switches

• Unified server & storage net

Новая модель. Exadata X2-8

Database Grid

• 2 64-core Intel EX Servers

• 2 TB Memory

•Выбор:

• Oracle Linux UnbreakableEnterprise Kernel

• Solaris 11 Express

Storage Grid

• Same Storage Grid asExadata X2-2

• CPUs updated to latest6-core Xeon

Network

• Redundant 40Gb/s Infiniband

• 10 Gb Ethernet to Data Center

Можно начать с четверти Exadata

FullRack

Half RackQuarterRack

Масштабируемость до 8 шкафов

2368 ядер

2.6 петабайт несжатых данных


Радикальное упрощение развертывания

• Database Machine упрощаетразвертывание систем БД

• Месяцы конфигурации, разрешение проблем, настройки

• Database Machine готова кназначенному сроку

• Уже созданная, протестированная , стандартная иподдерживаемая конфигурация

• Прозрачно для существующих приложений – ненужно никаких изменений!

• Экстремальная производительность“прямо из коробки”

Не месяцы,

а дни

Sun Oracle Database MachineЭкстремальная Производительность для всего

• Для хранилищ данных• Параллельные запросы в памяти или в Flash• Сжатые 4TB данных в памяти, 50 TB на flash• В среднем в 10X-20X быстрее традиционных хранилищ

• Для OLTP-систем• Масштабирование реальных приложений в grid - среде• Smart flash кэш обеспечивает 1 млн операций ввода/выводав секунду

• Сжатые 1.2 TB данных в памяти, 15 TB в Flash• Сжатие в 50x для архивных данных• Защищенность и отказоустойчивоть

• Для консолидации баз данных• Поддерживает масштабирование любых типов нагрузки• Предсказуемое время отклика в многопользовательскомокружении

Машина БД ExadataКонсолидация всех существующих приложений

• На Exadata могут совместно выполнятьсяприложения любого типа. Это гарантируется:

• Широкими каналами и масштабируемой системойввода/вывода;

• Instance Caging – ограничение на ресурсы ЦПУ междуБД на одном узле;

• Менеджер ресурсов ввода/вывода;

• Большой объем памяти и процессорныемощности для онлайн задач;

• Оффлоадинг операций (smart scans, storageindexes) для пакетных задач, отчетности,

хранилищ;

• Встроенная компрессия – существеннаясэкономить на дисковом пространстве длялюбых приложений.

• Архивы и данные для отчетности

ERP

CRM

Warehouse

Data Mart

HR


• Была выпущена в 2008

• Применяется в всех регионах и индустриях

Exadata на рынке

© 2010 Oracle Corporation 31

Поколоночное сжатие

Распарралеливание запроса на 128+ процессоров

Огромная память 2 Тб на 1 машине

Компактность (1 холодильник вместо 22 комп + диски)

Масштабируемость – 0.25 -> 1 -> 8 …..

HA внутри коробки

Сбалансированная архитектура

Предустановлено, преконфигурировано

Быстрое развертывание

Единая точка тех поддержки

Единая консоль управления, патчи и т д

Дешево (особенно если oracle уже есть)

DSS+DW+OLTP+ mixed

И т д

33Why Should Customers Upgrade to 11g Training

Сравнение моделей Exadata

v2 Full Rack x2-2 Full Rack x2-8 Full Rack

Database servers 8 x Sun Fire x4170 1U 8 x Sun Fire x4170 M21U

2 x Sun Fire x4800 5U

Database CPUs Xeon E5540 quad core2.53GHz

Xeon X5670 six cores2.93GHz

Xeon X7560 eightcores 2.26GHz

Database cores 64 96 128Database RAM 576GB 768GB 2TBStorage cells 14 x SunFire X4275 14 x SunFire X4270 M2 14 x SunFire X4270 M2

Storage cell CPUs Xeon E5540 quad core2.53GHz

Xeon L5640 six cores2.26GHz

Xeon L5640 six cores2.26GHz

Storage cells CPUcores

112 168 168

Flash Cache 5.3TB 5.3TB 5.3TBInfiniBand Switches QDR 40Gbit/s wire QDR 40Gbit/s wire QDR 40Gbit/s wire

Database Servers OS Oracle Linux only Oracle Linux (possibleSolaris later, still unclear)

Oracle Linux or Solarisx86

Copyright © 2010 Oracle Corporation and/or its affiliates – 35 –

X2-2 Database Server (Sun Fire X4170 M2)

Processors 2 Six-Core Intel® Xeon® X5670 Processors (2.93 GHz)

Memory 96GB (12 x 8GB)

Local Disks 4 x 300GB 10K RPM SAS Disks

Disk Controller Disk Controller HBA with 512MB Battery Backed Cache

Network 2 (Two) x InfiniBand 4X QDR (40Gb/s) Ports (1 Dual-port PCIe 2.0

HCA)

4 (Four) x 1GbE Ethernet Ports

2 (Two) x 10GbE Ethernet SFP+ Ports (1 Dual-port 10GbE PCIe2.0 network card based on the Intel 82599 10GbE Controller

technology)

RemoteManagement

1 Ethernet port (ILOM)

Power supplies 2 Redundant Hot-Swappable power supplies

X2-8 Database Server (Sun Fire X4800)

Processors 8 x Eight-Core Intel® Xeon® X7560 Processors (2.26 GHz)

Memory 1 TB (128 x 8GB)

Local Disks 8 x 300GB 10K RPM SAS Disks


Network 8 (Eight) x InfiniBand 4X QDR (40Gb/s) Ports (4 Dual-port PCE 2.0

Express Modules)

Two Network Express Modules (NEM), providing a total of

• 8 (Eight) x 1GbE Ethernet Ports

• 8 (Eight) x 10 GbE Ethernet SFP+ Ports (via 4 Fabric ExpressModules (FEM) based Intel 82599 10GbE Controller technology)

RemoteManagement


Power supplies 4 Redundant Hot-Swappable power supplies



Exadata Storage Server X2-2 (Sun Fire X4270 M2)

Processors 2 Six-Core Intel® Xeon® L5640 Processors (2.26 GHz)

Memory 24 GB (6 x 4GB)

Disks 12 x 600 GB 15K RPM High Performance SAS

OR

12 x 2 TB 7.2K RPM High Capacity SAS

Flash 4 x 96 GB Sun Flash Accelerator F20 PCIe Cards


Network 2 (Two) InfiniBand 4X QDR (40Gb/s) Ports (1 Dual-port PCIe

2.0 HCA)

4 Embedded Gigabit Ethernet Ports

RemoteManagement


Power Supplies 2 Redundant Hot-Swappable power supplies

Date post:	17-Jan-2023
Category:	Documents
Upload:	khangminh22
View:	1 times
Download:	0 times

IBM Netezza

Documents