Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 11 [12] 13   вперед  Ctrl
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Николай
TPC - это правила игры. Да он не оптимален, но дает хоть какое-то представление о системах и БД.


А вот, что, кстате Oracle пишет про тест TPC-C:

автор
...Consequently, a TPC-C benchmark implementation is really nothing more than a
number of mostly independent databases running mostly local transactions. By
amassing huge numbers of CPUs in loosely coupled configurations, various
vendors have obtained very large TPC-C numbers. It is difficult to find this kind
of workload in real-world applications – neither the data nor the transactions can
be shoehorned to fit neatly into well-defined partitions.



Видишь, не только Терадата придерживается такого мнения о тестах TPC.


Ну я тоже могу закинуть 10 инсталяций DB2 больше 20ТБ c туевой хучей конкурентных пользователей и запросами такими что 5 терабайт во временном пространсве мало :). Это не показатель.
И там будет и telco и retail, но это опять все маркетинг.


Было бы интересно посмотреть. Не думаю, что всё маркетинг.
Реальные работающие внедрения говорят о чём-то, не так ли?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 23:11    [895659]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Nikolay Kulikov
Ну-ну...
автор
Recovery cannot start until the GCS finishes rebuilding the
information.


А кэш не начнет синхронизироваться пока не определим что боец умер. Это как минимум 10 секунд. Синхронизация а потом recovery... Может быть приведем какие нибудь более менее официальные результаты??? Я могу найти презентацию с Oracle User Group где один из заказчиков Oracle говорит что у него время failover это 51 sec....


Вообще говоря, ситуацию что умер боец определяет не Оракл, а то кластерное обеспечение поверх которого он работает. Я так понимаю, в случае IBM - это HACMP в concarent-конфигурации. Сколько у него уходит времени на обнаружение сбоя нода?

51 сек. - а сколько нодов в кластере этого заказчика? И какая платформа?
19 авг 04, 23:27    [895663]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Yo!
db2 cluster vs RAC
http://www.oracle.com/technology/products/database/clustering/pdf/RACvDB2.pdf


Прочитал я эту штуку. Стало немного обидно за DB2 и массивно-параллельные базы данных в целом.

Во-первых:
With only two real parallel database choices to pick from, Oracle9i Real
Application Clusters and IBM’s DB2 Universal Database ESE V8.1, the choice
should be easy.


С точки зрения маркетинга - отлично. Типа "больше никого нету, а сейчас и этих опустим".
Наверное не знали, что бывает Терадата и Informix. IQ тоже параллельный, вроде. В общем, технически выглядит не очень профессионально.


Дальше:
автор
Shared nothing database systems may use a dual ported disk subsystem so that
each set of disks has physical connectivity to two nodes in the cluster with a
notion of “primary and secondary disk ownership.” Such a configuration protects
against system unavailability due to node failures. It requires two node failures to
render the system unavailable. While this is unlikely to occur, a single node
failure may cause significant performance degradation. This is due to the fact that
the one node (in some n node cluster) is now processing roughly twice the work
that any other node is processing and it is on the critical path for transaction completion.


Думаю, что это не совсем так. Рассуждая по аналогии с Терадатой, в которой узлы можно объединять в клики, которые служат для перераспределения нагрузки в случае падения узла клики, думаю, в DB2 тоже должно быть что-то такое. Если, скажем, в клике 4 узла, то при падении узла, нагрузка на 3 оставшихся узла клики будет равномерно распределена. Где тут twice the work не очень понятно.


Дальше:
A benefit of the shared disk approach is it provides unmatched levels of faulttolerance
with all data remaining accessible even if there is only one surviving
node. If a node in the shared disk cluster fails, the system dynamically redistributes
the workload among all the surviving cluster nodes. This ensures
uninterrupted service and balanced cluster-wide resource utilization.


А если этот shared disk из строя выйдет, то вся система накроется, так что ли?
Объясните, пожалуйста.

Дальше:

автор
In addition to requiring a great deal of
expensive manual intervention, the
partitioned approach creates significant
difficulties in capacity planning,
performance tuning and availability.


А разве в DB2 патишионинг не автоматически выполняется? Это же хэширование, как в Терадате.
Правда, где-то читал, что хэш-бакетов поменьше (вроде бы 4К против 64 у Терадаты), ну, ещё, вроде бы, тэйблспейсы надо руками создавать (в Терадате не надо). Ну, остальное-то, наверное DB2 сам делает? Или нет?

А, вот в Oracle с партишионингом как интересно? Я слышал, что надо сильно колдовать над ним. Есть опыт у кого?


Дальше:
In summary, shared nothing databases usually require that you manually partition the data for optimal performance.


Это при условии, что весь партишионинг в Терадате выполняется полностью автоматически. Вывод - не надо обобщать. Получается очень непрофессионально.


Кстати, дальше по поводу кэша, про размер которого тут шла дискуссия:
автор
Oracle uses direct reads and direct writes to disk to avoid cache coherency overhead in DSS applications.


Вот так.



С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 23:50    [895672]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Nikolay Kulikov
автор

автор

Нода не нужна. А то что она в базу писала нужно и как ты это вытащишь что закомичено что нужно откатить, если ты не хочешь получить нецелостные данные.
Нужно делать RECOVERY черным по белому написано в документации.

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

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



Давайте определимся, мы опять про OLTP рассуждаем?
Если про DW, то проблем нет.
Если про OLTP, то что вас смущает? Механизм рекавери такой же, с поправкой на синхронизацию GCS как в обычной (single-instance) базе :

When one or more instances fail, Oracle automatically recovers the lost changes associated with the instance or instances. Crash or instance recovery consists of the following steps:

   1. Rolling forward to recover data that has not been recorded in the datafiles, yet has been recorded in the online redo log, including changes to undo blocks. This phase is called cache recovery.
   2. Opening the database. Instead of waiting for all transactions to be rolled back before making the database available, Oracle allows the database to be opened as soon as cache recovery is complete. 
Any data that is not locked by unrecovered transactions is immediately available.
   3. Marking all transactions systemwide that were active at the time of failure as DEAD and marking the rollback or undo segments containing these transactions as PARTLY AVAILABLE.
   4. Rolling back dead transactions as part of SMON recovery. This phase is called transaction recovery.
   5. Resolving any pending distributed transactions undergoing a two-phase commit at the time of the instance failure.
   6. As new transactions encounter rows locked by dead transactions, they can automatically roll back the dead transaction to release the locks. If you are using Fast-Start Recovery, 
then only the data block is immediately rolled back, as opposed to the entire transaction.

Объем rolling forward можно контролировать настройками. Жестче требования ко времени восстановления - чаще пишем в файлы. Tradeoff.

Фаза rolling back - обратите внимание на п. 2
Если не пересекаемся по строкам (обратите внимание не по блокам/страницам, а по строкам) - вообще проблем не должно быть.
Если пересекаемся - , то процесс пытающийся изменить данные откатывает только блок, где лежат нужные ему данные (миллисекунды). Откат всей транзакции в целом этому процессу не нужен, это фоновая задача процесса SMON.

Кроме всего этого есть возможности parallel recovery и fast-start parallel rollback для дальнейшей оптимизации процесса восстановления.

Общий смысл - что время восстановления поддается комплексной настройке, и мы не являемся заложниками высокого transaction rate конкретной системы. Посмотри ссылку ниже, после этого 51 сек. восстановления у кого-то - сама по себе не говорит ни о чем

Configuring Instance Recovery Performance
20 авг 04, 00:22    [895683]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>А если этот shared disk из строя выйдет, то вся система накроется, так что ли?
Объясните, пожалуйста.

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

>А, вот в Oracle с партишионингом как интересно? Я слышал, что надо сильно колдовать над ним. Есть опыт у кого?

Что вас интересует?

>Кстати, дальше по поводу кэша, про размер которого тут шла дискуссия:
автор
Oracle uses direct reads and direct writes to disk to avoid cache coherency overhead in DSS applications.


Я извиняюсь, если ошибся, но по-моему вы не поняли, что речь в предложении выше шла про кэш ОС а не Оракла. Это разные вещи. Пользы от кэша ОС практически нет.
20 авг 04, 00:32    [895690]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
А если этот shared disk из строя выйдет, то вся система накроется, так что ли?
Объясните, пожалуйста.

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


Понятно.

>А, вот в Oracle с партишионингом как интересно? Я слышал, что надо сильно колдовать над ним. Есть опыт у кого?

Что вас интересует?



В Терадате чтобы создать базу надо только написать:

CREATE DATABASE mydb
FROM dbc
AS
PERM = 2000000
SPOOL = 5000000
FALLBACK
ACCOUNT= 'ACCTG'
NO AFTER JOURNAL
DUAL BEFORE JOURNAL
DEFAULT JOURNAL TABLE = mydb.journals;

Потом чтобы создать таблицу можно написать:
CREATE TABLE mydb.mytable
(
col1 INTEGER,
col2 .....
)
UNIQUE PRIMARY INDEX( col1);


Не надо создавать тэйблспейсов, не надо создавать вручную партишионы. База готова к работе, создана таблица, которая автоматически партицируется.
Управление дисковым пространством полностью автоматическое и не требует действий со стороны администратора.

А как это выглядит в Oracle?




>Кстати, дальше по поводу кэша, про размер которого тут шла дискуссия:
автор
Oracle uses direct reads and direct writes to disk to avoid cache coherency overhead in DSS applications.


Я извиняюсь, если ошибся, но по-моему вы не поняли, что речь в предложении выше шла про кэш ОС а не Оракла. Это разные вещи. Пользы от кэша ОС практически нет.



Не очень понимаю, что такое cache coherency тогда. Мне почему-то казалось, что речь идёт о когерентности кэшей инстансов Оракла.
А разве кэш инстансов операционки может быть когерентным. И зачем? Разве ОС нодов знают о существовании друг друга?

Ещё - разве Оракл пользуется вводом-выводом операционки, а не напрямую с дисками работает?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
20 авг 04, 01:06    [895698]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
автор
Просто в БД ничего не бывает. Ты утверждаешь что после синхронизации GCS выжившие узлы стразу начинают работать и в параллель запусается процесс востановления.


да, им ничто не меншает. бд в консистентном состоянии в любой момент времени. вам лучше почитать oracle concepts, там всего пара страниц.
выжевшие ноды не прерывают работу, просто на них перебрасываются сесии с умершей ноды (там какие-то ограничения были типа alter session теряется и еще что-то, я давал линк на документ ). пока данные не закомичены другие транзакции берут соответствующие блоки из undo.

автор

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


какой кэш ? писать минуя кеши оси прямая обязаность любой субд, если вы имели дело с дб2 то наверно вкурсе, транзакция не может быть закомиченой прежде чем данные попали в файл данных (в версионике и undo).
20 авг 04, 01:48    [895703]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Константин Лисянский


[quot ]>А, вот в Oracle с партишионингом как интересно? Я слышал, что надо сильно колдовать над ним. Есть опыт у кого?

Что вас интересует?



В Терадате чтобы создать базу надо только написать:

CREATE DATABASE mydb
FROM dbc
AS
PERM = 2000000
SPOOL = 5000000
FALLBACK
ACCOUNT= 'ACCTG'
NO AFTER JOURNAL
DUAL BEFORE JOURNAL
DEFAULT JOURNAL TABLE = mydb.journals;

Потом чтобы создать таблицу можно написать:
CREATE TABLE mydb.mytable
(
col1 INTEGER,
col2 .....
)
UNIQUE PRIMARY INDEX( col1);


Не надо создавать тэйблспейсов, не надо создавать вручную партишионы. База готова к работе, создана таблица, которая автоматически партицируется.
Управление дисковым пространством полностью автоматическое и не требует действий со стороны администратора.

А как это выглядит в Oracle?

>Кстати, дальше по поводу кэша, про размер которого тут шла дискуссия:
автор
Oracle uses direct reads and direct writes to disk to avoid cache coherency overhead in DSS applications.


Я извиняюсь, если ошибся, но по-моему вы не поняли, что речь в предложении выше шла про кэш ОС а не Оракла. Это разные вещи. Пользы от кэша ОС практически нет.



Не очень понимаю, что такое cache coherency тогда. Мне почему-то казалось, что речь идёт о когерентности кэшей инстансов Оракла.
А разве кэш инстансов операционки может быть когерентным. И зачем? Разве ОС нодов знают о существовании друг друга?

Ещё - разве Оракл пользуется вводом-выводом операционки, а не напрямую с дисками работает?


С уважением,
Константин Лисянский
http://lissianski.narod.ru


1. Про partitioning.

Примерно также все и происходит. При создании таблицы указывается перечень партиций с привязкой к нужным табличным пространствам. Если не делать вообще никакой кастомизации, то будет также как Террадате. А что вас пугает насчет создания тейблспейсов и партиций? Это просто дополнительная степень гибкости. Можно конечно забабахать всю базу из одного таб.пространства SYSTEM, но это будет не гибко.

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

1)Range partitioning - партицирование по диапазону значений ключа. Наиболее востребованный вариант на практике. Особенно для хранения историчных данных
2)Hash partitioning
3)Composite partitioning - это совокупность первых двух. Сначала разбиение по диапазонам на партиции (кот. в этом случае будут чисто логическими объектами) и затем по хэшу на субпартиции.
4) List partitioning - для каждой партиции определен вектор скаляров ключа


2. Про кэш и ввод-вывод.

Скорее всего речь идет о том, что оракловый кэш имеет больше знаний о приложении. Есть варианты настройки как кэшировать или не кэшировать нужные данные. Кэш ОС этого не знает по определению. Поэтому если ВВ интенсивный, то на DW кэш ОС будет постоянно флашиться без особой пользы с точки зрения кэширования данных. Получается двойная буферизация, которая не имеет особой пользы.

Разумеется Оракл кроме файлов, работает и с сырыми устройствами тоже, что даже приветствуется, поскольку автоматом решается проблема с кэшем ОС, размер которого на многих операционных системах не поддается ограничению.
20 авг 04, 09:55    [896003]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
транзакция не может быть закомиченой прежде чем данные попали в файл данных (в версионике и undo).

имелось ввиду в файл redo log, в файл данных оно попозжее другим процессом сваливается.
20 авг 04, 10:41    [896222]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Константин Лисянский
С точки зрения маркетинга - отлично. Типа "больше никого нету, а сейчас и этих опустим".
Наверное не знали, что бывает Терадата и Informix. IQ тоже параллельный, вроде. В общем, технически выглядит не очень профессионально.

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

ЗЫ
Константин, я думаю, хватит флейма. Когда Терадата будет поддерживать и продвигать свою СУБД так же, как Oracle и MS, когда я смогу у себя в Киеве спокойно в книжном магазине или на рынке найти книги по Терадате, когда будет ваше представительство в моей стране, когда можно будет пойти в учебный центр и послушать курсы по Терадате, когда я свободно смогу сам выбирать аппаратную часть, на которой будет работать СУБД, тогда вы будете вправе писать, что Oracle забыл про Терадату и упомянул лишь DB2...

ЗЗЫ
Давайте закрывать топик. ИМХО, один флейм пошел :-(.
20 авг 04, 11:01    [896325]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
killed
[quot Константин Лисянский]

В Терадате чтобы создать базу надо только написать:
СREATE DATABASE mydb
FROM dbc
AS
PERM = 2000000
SPOOL = 5000000
FALLBACK
ACCOUNT= 'ACCTG'
NO AFTER JOURNAL
DUAL BEFORE JOURNAL
DEFAULT JOURNAL TABLE = mydb.journals;

Потом чтобы создать таблицу можно написать:
CREATE TABLE mydb.mytable
(
col1 INTEGER,
col2 .....
)
UNIQUE PRIMARY INDEX( col1);


Не надо создавать тэйблспейсов, не надо создавать вручную партишионы. База готова к работе, создана таблица, которая автоматически партицируется.
Управление дисковым пространством полностью автоматическое и не требует действий со стороны администратора.

А как это выглядит в Oracle?

С уважением,
Константин Лисянский
http://lissianski.narod.ru


В версии 9i Oracle есть возможность использовать Oracle-Managed Files
Примеры можно посмотреть здесь.
[url=http://]http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/omf.htm#1011497[/url]

В результате создание БД выполняется так:

The following statement is issued at the SQL prompt:
SQL> CREATE DATABASE sample;

В версии 10g Oracle стал использовать ASM.
В этом случае как бы и файлы не нужны.
Оracle умеет работать с дисковым разделом без файловой системы.
20 авг 04, 11:11    [896370]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Константин Лисянский


А разве в DB2 патишионинг не автоматически выполняется? Это же хэширование, как в Терадате.
Правда, где-то читал, что хэш-бакетов поменьше (вроде бы 4К против 64 у Терадаты), ну, ещё, вроде бы, тэйблспейсы надо руками создавать (в Терадате не надо). Ну, остальное-то, наверное DB2 сам делает? Или нет?

А, вот в Oracle с партишионингом как интересно? Я слышал, что надо сильно колдовать над ним. Есть опыт у кого?



Противоречие получается, мы как-то уже начинали разговор
о партиционировании и я говорил что отсоединяю 20 000 000 от
100 000 000 таблицы за 10 -20 минут, помните?

Вы мне говоирили что это занимает секунды в терадате , а что вы отсоединяете за секунды если добавление производится по хешу
(случайным образом).
Я для себя вижу смысл партиционирования
для того чтобы разделить данные по каким то критериям.
За критерии партиционирования и производительность должен
отвечать ДБА, а продукт
должен предоставить механизмы, а не решать за человека.
База данных должна иметь возможность администратору управлять ее поведением.
С ваших слов складывается впечатление, что терадата это
просто easy way. Не буду сравнивать, хотя на языке одна извесная
софтверная компания.
Или вы хотите доказать кастомерам, что купив терадату можно экономить
на зарплате ДБА.

С уважением, onstat-

ps если флеймить так уж флеймить.
20 авг 04, 11:46    [896578]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
onstat

Противоречие получается, мы как-то уже начинали разговор
о партиционировании и я говорил что отсоединяю 20 000 000 от
100 000 000 таблицы за 10 -20 минут, помните?

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


Извините, вылетел ненадолго из дискуссии.
Да, противоречие есть, согласен.
Тут нужно сделать уточнение. Такая штука возможна при использовании PARTITIONED PRIMARY INDEX. Это двухуровневый партишионинг когда один уровень - хэширование, а второй определяется руками (наиболее распространённое применение - партишионинг по датам).
Если используется PPI, то отсоединение партиции - секундное дело.
Если PPI не используется, то партиции недоступны напрямую пользователю и удаление будет происходить в обычнои режиме.
Естественно, что если критерий удаления - первичный индекс, то такое удаление будет происходить тоже достаточно быстро.
Про PPI я уже приводил ссылку выше.

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

Я для себя вижу смысл партиционирования
для того чтобы разделить данные по каким то критериям.
За критерии партиционирования и производительность должен
отвечать ДБА, а продукт
должен предоставить механизмы, а не решать за человека.


Я согласен отчасти. Это вопрос правильной балансировки нагрузки между DBA и машиной. На мой взгляд, выигрывает подход, когда машина выполняет большинство задач автоматически. Вам нужно только сесть за руль, повернуть ключ и нажать педаль газа :) Если педалей очень много, в один прекрасный момент становится вопрос о втором пилоте, ну и так далее. Опять таки, ИМХО.

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


С ваших слов складывается впечатление, что терадата это
просто easy way. Не буду сравнивать, хотя на языке одна извесная
софтверная компания.

:)


В принципе, да. По крайней мере рычагов и кнопочек у неё значительно меньше. Архитектура просто очень хорошая.
Похоже, к сожалению, здесь это не все понимают. Другая известная компания очень хороший маркетинговый отдел имеет :)

Или вы хотите доказать кастомерам, что купив терадату можно экономить
на зарплате ДБА.

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

если флеймить так уж флеймить

Да, но только, если это на пользу. Иначе только время будем зря терять.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
25 авг 04, 18:53    [908391]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Константин, хорошим показателем прототы администрования является количество гигабайт на одного DBA???

Кстати обещанный список DB2 инсталяций

Deutche Telecom - 90 ТБ
Sprint Telecom - 86 ТБ
StateFarm Insurance - 72 TB (Marketing)
JP Morgan Chase - 50 TB
StateFarm Insurance - 36 TB (Actuarial)
Bank One - 35 TB (3 DBA)
Kroger - 24 (2 DBA)

Могу еше.
26 авг 04, 11:15    [909313]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Константин, хорошим показателем прототы администрования является количество гигабайт на одного DBA???


Даже знаю следующую ссылку, которая последует на мой ответ на этот вопрос :)

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


Кстати обещанный список DB2 инсталяций

Deutche Telecom - 90 ТБ
Sprint Telecom - 86 ТБ
StateFarm Insurance - 72 TB (Marketing)
JP Morgan Chase - 50 TB
StateFarm Insurance - 36 TB (Actuarial)
Bank One - 35 TB (3 DBA)
Kroger - 24 (2 DBA)


Николай, а если не секрет, на каких платформах все эти инсталляции?

Могу еше.


Не сомневаюсь :)
Думаю, что все уже попадали в обморок от рефернсов, которые мы с тобой привели. У меня уже тут пара человек возле офиса тусуются. Жаждут ещё :) Скандируют и трясут транспорантами.
Посмотри, может к тебе тоже уже клиенты выстроились :)


С уважением,
Константин Лисянский
http://lissianski.narod.ru
26 авг 04, 13:10    [910083]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
3 копейки ;) Линк искать не буду, но помню что какой то аналитик писал

ТД - ~1.5 админ на 1Тб
IQ - ~0.5 админа
другие - ~2 и больше.

Думаю, simple, админ базы может быть и один, а рядом 2-3 технаря зоопарк серверов присматривают.
26 авг 04, 13:20    [910151]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Nikolay Kulikov
Константин, хорошим показателем прототы администрования является количество гигабайт на одного DBA???

Кстати обещанный список DB2 инсталяций

Deutche Telecom - 90 ТБ
Sprint Telecom - 86 ТБ
StateFarm Insurance - 72 TB (Marketing)
JP Morgan Chase - 50 TB
StateFarm Insurance - 36 TB (Actuarial)
Bank One - 35 TB (3 DBA)
Kroger - 24 (2 DBA)

Могу еше.


Интерестно, сколько там самих данных а сколько индексы и т.д. Просто AC Nielsen case: 24ТБ данных цчаты до 12Гб в IQ, (~72TB в стандартной базе, Оракле, МС и проч.)
26 авг 04, 13:24    [910178]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Nikolay Kulikov
Константин, хорошим показателем прототы администрования является количество гигабайт на одного DBA???



Еще нужно в попугаях замерить
26 авг 04, 13:42    [910281]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
killed
Nikolay Kulikov
Константин, хорошим показателем прототы администрования является количество гигабайт на одного DBA???



Еще нужно в попугаях замерить

Попугаи хорошо.

А вообще, есть такая методика (админы - одна из компонент TCO).
Весьма актуальна, особенно, когда админу надо 80-100к$ платить.
26 авг 04, 13:50    [910333]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
2 Павел Новокшонов:

Павел, а сколько у вас администраторов Терадаты на 1 ТБ?

_Dog
Просто AC Nielsen case: 24ТБ данных цчаты до 12Гб в IQ

Это в 2000 раз что ли? А это не сказка?

С уважением,
Константин Лисянский
http://lissianski.narod.ru
26 авг 04, 17:07    [911811]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Константин Лисянский
2 Павел Новокшонов:

Павел, а сколько у вас администраторов Терадаты на 1 ТБ?

_Dog
Просто AC Nielsen case: 24ТБ данных цчаты до 12Гб в IQ

Это в 2000 раз что ли? А это не сказка?

С уважением,
Константин Лисянский
http://lissianski.narod.ru


soosry конечно 12тб
26 авг 04, 18:13    [912111]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
блин , и sorry и 12tb
26 авг 04, 18:14    [912115]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
_Dog
killed
Nikolay Kulikov
Константин, хорошим показателем прототы администрования является количество гигабайт на одного DBA???



Еще нужно в попугаях замерить

Попугаи хорошо.

А вообще, есть такая методика (админы - одна из компонент TCO).
Весьма актуальна, особенно, когда админу надо 80-100к$ платить.


OFF
Вспомнилось, как одна крупная консалтинговая фирма (ну знаете, их всего штук пять таких на слуху написала нам заключение на ИС. Так вот, там была замечательная фраза, что-то типа того, что: "Оракл - это хорошо, поскольку для обслуживания вашей системы Оракл 9i требует в 2.75 (точную цифру не помню) раз меньше администраторов чем на DB2."

Полез я гугл и практически сразу нашел эту фразу где-то в дебрях оракловых анонсов. Мне интересно, что за методики рассчетов такие? И как кол-во админов может коррелировать с объемом данных?
26 авг 04, 22:11    [912502]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Павел Новокшонов
Member

Откуда: Moscow -> Atlanta, GA
Сообщений: 90
Константин Лисянский

2 Павел Новокшонов:

Павел, а сколько у вас администраторов Терадаты на 1 ТБ?


2 DBA на ХД из ~1TB. В отделе 4 DBA плюс манагер. Помимо Терадаты мы администрим ряд OLTP систем на DB2 (EE) и Информиксе. Так что есть с чем сравнивать.

onstat-

Противоречие получается, мы как-то уже начинали разговор
о партиционировании и я говорил что отсоединяю 20 000 000 от
100 000 000 таблицы за 10 -20 минут, помните?


А зачем в хранилище данных вообще отсоединять 20 000 000 записей от 100 миллионной таблицы? Какой смысл? Смысл партицирования в Терадате один - это равномерно размазать данные во узлам кластера и по виртуальным процессорам СУБД внутри узлов. Тем самым система максимально сбалансирована и позволяет максимально быстро выполнять DSS запросы.

Здесь важно понимать архитектуру самой СУБД. В Терадате существует всего два типа виртуальных процессоров, в отличие от Информикса к примеру где их до тучи. Один тип PE (Parsing Engine) отвечает за обработку пользовательских сессий, парсинг SQL и генерацию плана запроса. Другой тип виртуальных процессоров, называемый AMP отвечает за храниние и обработку данных. При начальной конфигурации системы каждому AMP'y жестко нарезается одинаковый кусок дискового пространства. Когда я заливаю таблицу скажем из одного миллиарда строк все что делает хэш это берет значение колонки, объявленной
как первичный индекс, прогоняет через хэш-алгоритм и определяет AMP на который пойдет запись. Таким образом если значения первичного индекса достаточно уникальны, то таблица будет равномерно размазана по вирт. процам СУБД.

Да еще про защиту инвестиций на уровне железа. По началу Терадата у нас жила на 4-х узлах, сейчас в системе 14 узлов с тремя генерациями CPU. 2 узла с 8 CPU (700 МГц), 4 узла с 8 CPU (2.8 ГГц) и 8 узлов с 32 CPU (3 ГГц). Т.е. межнодовая шина Bynet позволяет цеплять в кластер узлы с разными CPU, но с точки зрения СУБД это по прежнему одна система. Это удобно когда ХД строится на одной системе и по мере прогресса технологий и роста объема данных старое железо может со-существовать с новым. Опять же один вендор разрабатывает
и железо и СУБД и ОС.

Как с этим в Оракле и ДБ2?

Сергей Тихонов
когда я смогу у себя в Киеве спокойно в книжном магазине или на рынке найти книги по Терадате


Все книги можно заказать на амазоне
27 авг 04, 04:51    [912641]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
nkulikov
Guest
Я не понял почему все так на меня накинулись не на утверждение, а на вопрос
Ну да ладно.

автор

хорошим показателем прототы администрования является количество гигабайт на одного DBA???


На DB2 тоже можно объединять разные узлы с разными характеристиками.
Только это не всегда гуд, Ибо производительность узлов с 700Mgz и 2Gz отличается, для уравнивания загрузки можно правда подправлять partition map.

автор

Здесь важно понимать архитектуру самой СУБД. В Терадате существует всего два типа виртуальных процессоров, в отличие от Информикса к примеру где их до тучи. Один тип PE (Parsing Engine) отвечает за обработку пользовательских сессий, парсинг SQL и генерацию плана запроса. Другой тип виртуальных процессоров, называемый AMP отвечает за храниние и обработку данных. При начальной конфигурации системы каждому AMP'y жестко нарезается одинаковый кусок дискового пространства. Когда я заливаю таблицу скажем из одного миллиарда строк все что делает хэш это берет значение колонки, объявленной
как первичный индекс, прогоняет через хэш-алгоритм и определяет AMP на который пойдет запись. Таким образом если значения первичного индекса достаточно уникальны, то таблица будет равномерно размазана по вирт. процам СУБД.

В DB2 немного другая архитектура. Примерный эквивалент AMP - это Database Partition, набор процессов/threads со своим куском дискового пространства. Табличные пространства автоматически не выделяются. Нужно создавать ручками.
27 авг 04, 11:25    [913371]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 11 [12] 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить