powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
25 сообщений из 159, страница 5 из 7
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088031
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousК DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.Что значит обычно ? Боюсь, это Вы сильно погорячились, манипуляции с данными совсем не подразумевает только изменение этих данных. А то так можно договориться, что SELECT относится к DDL.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088202
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA andrey_anonymousК DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.Что значит обычно ? Боюсь, это Вы сильно погорячились, манипуляции с данными совсем не подразумевает только изменение этих данных. А то так можно договориться, что SELECT относится к DDL.
DML
Data Manipulation Language

Data Modification Language

Второй вариант - одно из типичных неправильных прочтений. Всякое бывает.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088229
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
из микросовтовского хелпа:

The SQL language has two main divisions: Data Definition Language (DDL), which is used to define and manage all the objects in an SQL database, and Data Manipulation Language (DML), which is used to select , insert, update, and delete data in the objects defined using DDL. и т.д.
Хотя может в Оракле по-другому считают :)
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088264
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperХотя может в Оракле по-другому считаютЕсли верить google , то уже по первой странице видно, что Oracle тоже считает, что DML - data manipulation language, и в него входит SELECT.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088291
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeКонстантин Лисянский , поясните пожалуйста ваш постулат о том, что в Терадате нужно меньше индексов? За счёт чего это?

Можно, просто, Константин. Я не обижусь.

Например, primari index, с одной стороны, является механизмом распределения данных, с другой стороны, используется в качестве метода доступа. Однако это не совсем индекс - это функция.
Далее, поскольку все таблицы в системе размазываются между единицими параллелизма на маленькие кусочки, часто получается быстрее сделать фуллскан, нежели использовать для выборки индекс.
Для джойнов индексы Терадате не нужны, кроме первичного (который суть не индекс).


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088316
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeВ списке переменных, учитываемых оптимизатором, тоже не вижу ничего выдающегося.

Понятно.

kmikeЦифры есть?

Конечно.

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

А я, вроде бы не утверждал, что может. Точно не может, на всякий случай.
Это же shared nothing.
В общем случае перераспределение (или дуплицирование одной из таблиц) нужно во всех случаях, кроме того, когда в условии джойна стоят первичные индексы обеих таблиц.
Таким образом, данные постоянно разгуливают между узлами.




С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088355
andrey_anonymousЦитатки неаккуратно из контекста вырезаете.
В первой, к примеру, обсуждается исключительно PARTITION-WISE JOIN. И ничего более. Вы же цитируете, словно это общее правило и системное ограничение.
Супер. Расскажите о других способах распаралеливания join-ов в Oracle.
andrey_anonymous1) "Для паралельного выполнения запросов нужно использовать partitioning"
Утверждение ложно, поскольку данное ограничение действует не на любые запросы.
Если бы Вы удосужились правильно описать классы запросов, для которых ограничение актуально - проблем бы не было.
Если бы Вы читали ветку, в которую пишите, то таких вопросов бы не возникало:
Зл0йПредположим что есть 2 таблицы table_a и table_b. Предположим что первичные индексы данных таблиц построены по атрибутам column_a1 и column_b1 соответственно. Теперь строим Join такой что column_a1=column_b27. Доступ в table_b идет не по первичному индексу. т.е. amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet. Ведь они же раскиданы по amp'ам исходя из хеширования по column_b1. Теперь предположим что обе таблицы по 200 миллионов записей, чтобы жизнь медом не казалась.
andrey_anonymous2) "Чтобы обеспечить равномерную загрузку узлов .... придется использовать hash partitioning"
Утверждение ложно. С учетом конкретного содержимого равномерное распределение данных может быть достигнуто и на range, и на list.
Готовим partitioning под фиксированные запрос и содержимое. Технологично. Шаг влево, шаг вправо всю оптимизацию сдаем в утиль
andrey_anonymous3) "как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2"
Для начала сумейте показать, что имеющаяся неравномерность (напомню приведенную Вами цитату, в худшем случае самый большой раздел может оказаться в два раза больше самого маленького) заметно повлияет на время исполнения запроса, если разделов более двух.
Доказывать, что 2х2=4 не собираюсь.
andrey_anonymousЕсли же немножко отвлечься от стиля документалистов oracle и вспомнить, что речь таки идет о хеш-функции, то можно достаточно легко предложить пример исходных данных, которые улягутся, к примеру, всей толпой в один и тот же раздел. Актуально и для TeraData, и для Oracle, и вообще для любой системы, разделяющей данные по хеш. Берем 200 млн. x N записей, раскладываем по хэш функции по N партициям, потом берем все записи, попавшие в одну партицию и кричим "караул!". Дальше что?
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088380
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeМожно здесь подробнее? Допустим, есть таблицы T1 и T2 со столбцами A,B,C, и A используется для распределения по узлам. Как будет выполняться join T1 и T2 по условию T1.B=T2.B ?


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE SET TABLE RPDM30.SHOPPING_TRANSACTION ,NO FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT
     (
      Shopping_Transaction_Id INTEGER NOT NULL,
      Shopping_Tran_Type_Cd VARCHAR( 50 ) CHARACTER SET LATIN NOT CASESPECIFIC,
      Shopping_Tran_Status_Cd VARCHAR( 50 ) CHARACTER SET LATIN NOT CASESPECIFIC,
      Visit_Id INTEGER NOT NULL,
      POS_Register_Id INTEGER,
      Transaction_Dttm TIMESTAMP( 6 ) FORMAT 'yyyy-mm-ddbhh:mi:ss.s(6)',
      Reported_As_Dttm TIMESTAMP( 6 ) FORMAT 'yyyy-mm-ddbhh:mi:ss.s(6)',
      Order_Num VARCHAR( 50 ) CHARACTER SET LATIN NOT CASESPECIFIC,
      Related_Shopping_Trans_Id INTEGER,
      Sales_Associate_Id INTEGER,
      Bill_To_Persona_Id INTEGER,
      Ship_To_Persona_Id INTEGER,
      Bill_To_Address_Id INTEGER,
      Ship_To_Address_Id INTEGER)
PRIMARY INDEX XIE1SHOPPING_TRANSACTION ( Shopping_Transaction_Id );

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE SET TABLE RPDM30.SHOPPING_TRANSACTION_LINE ,NO FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT
     (
      Shopping_Transaction_Id INTEGER NOT NULL,
      Shopping_Transaction_Line_Num VARCHAR( 50 ) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL,
      Shopping_Tran_Line_Status_Cd VARCHAR( 50 ) CHARACTER SET LATIN NOT CASESPECIFIC,
      Unit_Selling_Price_Amt DECIMAL( 18 , 4 ) NOT NULL,
      Item_Qty DECIMAL( 18 , 4 ) NOT NULL,
      Item_Id INTEGER NOT NULL,
      Unit_Cost_Amt DECIMAL( 18 , 4 ),
      Transaction_Line_Dttm TIMESTAMP( 6 ) FORMAT 'yyyy-mm-ddbhh:mi:ss.s(6)',
      Unit_Retail_Price_Amt DECIMAL( 18 , 4 ) NOT NULL,
      Orig_Shopping_Transaction_Id INTEGER,
      Orig_Shopping_Tran_Line_Num VARCHAR( 50 ) CHARACTER SET LATIN NOT CASESPECIFIC,
      Promised_Fulfillment_Dt DATE FORMAT 'YYYY-MM-DD',
      Page_View_Id INTEGER)
PRIMARY INDEX XIE1SHOPPING_TRANSACTION_LINE ( Shopping_Transaction_Id ,
Orig_Shopping_Transaction_Id );

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
EXPLAIN
SELECT
  *
FROM
  SHOPPING_TRANSACTION st
INNER JOIN
  SHOPPING_TRANSACTION_LINE stl
ON
  st.Transaction_Dttm=stl.Transaction_Line_Dttm


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
Explanation
   1 ) First, we lock a distinct RPDM30."pseudo table" for read on a
     RowHash to prevent global deadlock for RPDM30.stl. 
   2 ) Next, we lock a distinct RPDM30."pseudo table" for read on a
     RowHash to prevent global deadlock for RPDM30.st. 
   3 ) We lock RPDM30.stl for read, and we lock RPDM30.st for read. 
   4 ) We do an all-AMPs RETRIEVE step from RPDM30.st by way of an
     all-rows scan with a condition of ("NOT
     (RPDM30.st.Transaction_Dttm IS NULL)") into Spool  2  (all_amps)
     fanned out into  29  hash join partitions, which is duplicated on
     all AMPs.  The result spool file will not be cached in memory. 
     The size of Spool  2  is estimated with no confidence to be  24 , 488 
     rows.  The estimated time for this step is  1 . 09  seconds. 
   5 ) We do an all-AMPs RETRIEVE step from RPDM30.stl by way of an
     all-rows scan with a condition of ("NOT
     (RPDM30.stl.Transaction_Line_Dttm IS NULL)") into Spool  3 
     (all_amps) fanned out into  29  hash join partitions, which is built
     locally on the AMPs.  The input table will not be cached in memory,
     but it is eligible for synchronized scanning.  The result spool
     file will not be cached in memory.  The size of Spool  3  is
     estimated with no confidence to be  108 , 508  rows.  The estimated
     time for this step is  6 . 73  seconds. 
   6 ) We do an all-AMPs JOIN step from Spool  2  (Last Use) by way of an
     all-rows scan, which is joined to Spool  3  (Last Use) by way of an
     all-rows scan.  Spool  2  and Spool  3  are joined using a hash join
     of  29  partitions, with a join condition of ("Transaction_Dttm =
     Transaction_Line_Dttm").  The result goes into Spool  1 
     (group_amps), which is built locally on the AMPs.  The result
     spool file will not be cached in memory.  The size of Spool  1  is
     estimated with no confidence to be  4 , 033 , 241  rows.  The estimated
     time for this step is  2  minutes and  17  seconds. 
   7 ) Finally, we send out an END TRANSACTION step to all AMPs involved
     in processing the request.
  -> The contents of Spool  1  are sent back to the user as the result of
     statement  1 .  The total estimated time is  2  minutes and  25  seconds. 


В этом примере видно, что оптимизатор решил не перераспределять большую таблицу SHOPPING_TRANSACTION_LINE, а решил продублировать таблицу SHOPPING_TRANSACTION, так как она меньше по размеру.


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
EXPLAIN
SELECT
  *
FROM
  SHOPPING_TRANSACTION_LINE stl1
INNER JOIN
  SHOPPING_TRANSACTION_LINE stl2
ON
  stl1.Transaction_Line_Dttm=stl2.Transaction_Line_Dttm

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
Explanation
   1 ) First, we lock a distinct RPDM30."pseudo table" for read on a
     RowHash to prevent global deadlock for RPDM30.stl2. 
   2 ) Next, we lock RPDM30.stl2 for read. 
   3 ) We execute the following steps in parallel. 
        1 ) We do an all-AMPs RETRIEVE step from RPDM30.stl2 by way of an
          all-rows scan with a condition of ("NOT
          (RPDM30.stl2.Transaction_Line_Dttm IS NULL)") into Spool  2 
          (all_amps), which is redistributed by hash code to all AMPs. 
          Then we do a SORT to order Spool  2  by row hash.  The result
          spool file will not be cached in memory.  The size of Spool  2 
          is estimated with no confidence to be  108 , 508  rows.  The
          estimated time for this step is  7 . 38  seconds. 
        2 ) We do an all-AMPs RETRIEVE step from RPDM30.stl1 by way of an
          all-rows scan with a condition of ("NOT
          (RPDM30.stl1.Transaction_Line_Dttm IS NULL)") into Spool  3 
          (all_amps), which is redistributed by hash code to all AMPs. 
          Then we do a SORT to order Spool  3  by row hash.  The result
          spool file will not be cached in memory.  The size of Spool  3 
          is estimated with no confidence to be  108 , 508  rows.  The
          estimated time for this step is  7 . 38  seconds. 
   4 ) We do an all-AMPs JOIN step from Spool  2  (Last Use) by way of a
     RowHash match scan, which is joined to Spool  3  (Last Use) by way
     of a RowHash match scan.  Spool  2  and Spool  3  are joined using a
     merge join, with a join condition of ("Transaction_Line_Dttm =
     Transaction_Line_Dttm").  The result goes into Spool  1 
     (group_amps), which is built locally on the AMPs.  The result
     spool file will not be cached in memory.  The size of Spool  1  is
     estimated with no confidence to be  35 , 743 , 135  rows.  The estimated
     time for this step is  21  minutes and  11  seconds. 
   5 ) Finally, we send out an END TRANSACTION step to all AMPs involved
     in processing the request.
  -> The contents of Spool  1  are sent back to the user as the result of
     statement  1 .  The total estimated time is  21  minutes and  19 
     seconds. 

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

Надеюсь, степень подробности удовлетворительная. Если что-то непонятно, готов прокомментировать.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088382
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Константин Лисянский kmikeКонстантин Лисянский , поясните пожалуйста ваш постулат о том, что в Терадате нужно меньше индексов? За счёт чего это?

Можно, просто, Константин. Я не обижусь.

Например, primari index, с одной стороны, является механизмом распределения данных, с другой стороны, используется в качестве метода доступа. Однако это не совсем индекс - это функция.
Далее, поскольку все таблицы в системе размазываются между единицими параллелизма на маленькие кусочки, часто получается быстрее сделать фуллскан, нежели использовать для выборки индекс.
Для джойнов индексы Терадате не нужны, кроме первичного (который суть не индекс).

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

Постулат про предпочтение фулл-сканов индексам я понял примерно понял, но это же верно в любой системе с достаточно большой степенью параллелизма. Либо просто с быстрым i/o по отношению к объёму таблицы.

Про джойны без индексов тоже понятно, что они не нужны, но это же наверняка повлияет на производительность, потому я и спросил, каким методом будет выполняться такой джойн (в контексте объёмов пересылки по сети).
Кстати, у Терадаты ключ секционирования по узлам может не совпадать с первичным?
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088389
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Константин ЛисянскийА в этом примере перед джойном перераспределяются обе таблицы, поскольку они одинаково большие.
Перераспределение таблиц происходит одновременно, то есть, присутствует как внутришаговый параллелизм, так и межшаговый.
Это довольно характерная картина для Терадаты.

Надеюсь, степень подробности удовлетворительная. Если что-то непонятно, готов прокомментировать.

Читабельность EXPLAIN'a Терадаты впечатляет :)
"which is redistributed by hash code to all AMPs" - вот этот момент интересен, по какому хэшу оно переспределяется?
И, получается, с каждого узла все данные, удовлетворяющие фильтру, надо будет отправить на каждый остальной узел? Не возникает ли здесь узкого места? Допустим, 10ГБ при 0.18ГБ/с (и это, небось, теоретически, то есть в вакууме) - это примерно минута.. Кстати, оно широковещательно передаётся или на каждый узел отдельно?
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088392
Павел Новокшонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousПавел, Константин - моя оценка времени "неделька-другая" на удвоение количества узлов от реальности, скорее всего, далека, не могли бы Вы все-таки привести Вашу оценку?
Второй вопрос - будет ли база доступна пользователям в процессе?


Мне сложно дать какую-то конкретную оценку, поскольку я не занимаюсь upgrade'ми. Это зависит наверное от размера кластера и кол-ва данных хэш которых надо пере-рассчитать. В Teradata есть tool - estimator - который позволяет оценить время необходимое на re-config при добавлении новых узлов. Последний upgrade у моего клиента занял порядка 20-25 часов. База при этом не доступна пользователям. Некоторые клиенты имеют резервные системы (в рамках решения dual-active), при этом пользователи перенаправляются на резервную систему если основная не доступна. На практике добавление новых узлов в кластер происходит не так часто, как правило раз в 1,5 - 2 года.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088400
Павел Новокшонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeЧитабельность EXPLAIN'a Терадаты впечатляет :)

Мне тоже нравится. У Оракла и DB2 explain'ы какие-то примитивные что-ли, хотя наверное дело привычки.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088406
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousВ shared disk размещение разделов - нескольк более "творческая" работа.

Одна из причин, почему Терадату легче сопровождать.

andrey_anonymousК DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.

Разумеется. Выборка - часть DML. Поэтому мой вопрос и был. Просто я его немного сумбурно сформулировал (поздно уже было).


andrey_anonymousВообще-то способов всего порядка 10!, что делает Вашу оценку завышенной почти в 5511.5 раз со всеми вытекающими :)

Teradata Database SQL Reference Statement and Transaction ProcessingLeft-Deep Search Trees
When a left-deep search tree is used to analyze possible join orders, the number
of possibilities produced is relatively small, as characterized by the following
equation, where n is the number of tables being joined.
Number of join orders = n!
For a four-table join, the number of join orders using a left-deep search tree is
only 4!, or 24. Left-deep join trees are used by many commercial relational
systems, but there are other methods that can produce many more possible join
sequences, making it more likely to find a better join plan.

...

Bushy Search Trees
Bushy trees are an optimal method for generating more join order
combinations. At the same time, the number of combinations generated can be
prohibitive (see “Possible Join Orders as a Function of the Number of Tables To
Be Joined” on page 2-73), so the Optimizer uses several heuristics to prune the
search space. For example, with the exception of star joins, unconstrained joins
are not considered.
The following equation calculates the total number of join orders (before
pruning) for n tablebased on a bushy join tree search:
Number of join orders = n!(2(n-1) (n-1))*1/n

The term (2(n-1) (n-1)) in this equation represents the number of combinations.

...

Possible Join Orders as a Function of the Number of Tables To Be Joined
The following table illustrates the dilemma the Optimizer faces when it selects
the order in which to join tables in a join plan. The table demonstrates how
rapidly the possibilities for ordering binary joins escalates as the total number
of tables joined increases.
To help paint a picture of how vast the number of combinations becomes as the
number of tables increases, this table uses the metaphor of grains of sand.

Number of Tables Joined Number of Possible Join Orders
3 12.0
4 120.0
10 1.8*10^10
16 2.0*10^20
64 1.2*10^124






С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088417
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeВот про метод доступа интересно... Очевидно, что можно использовать этот самый хэш для определения узла, на котором находится данная строчка. А внутри узла этот самый хэш как-нибудь играет?

Конечно. В памяти каждого узла резидентно находится так называемый Master Index, который указывает на каком циллиндре искать блок данных с искомой записью, дальше есть структура cyllinder index, которая тоже с большой вероятностью находится в памяти, по ней можно найти в каком блоке искать запись с искомым хэшом. Сам хэш хранится как часть записи.


kmikeПостулат про предпочтение фулл-сканов индексам я понял примерно понял, но это же верно в любой системе с достаточно большой степенью параллелизма. Либо просто с быстрым i/o по отношению к объёму таблицы.

Возможно. Есть СУБД, которые практически всё делают full-сканами. Netezza, например.


kmikeПро джойны без индексов тоже понятно, что они не нужны, но это же наверняка повлияет на производительность, потому я и спросил, каким методом будет выполняться такой джойн (в контексте объёмов пересылки по сети).

Повлияет, конечно. Если таблица бльшая, то перераспределение - недешёвая операция.


kmikeКстати, у Терадаты ключ секционирования по узлам может не совпадать с первичным?

Вопрос не совсем корректен. Первичный ключ - это понятие, скорее, логическое. Таблица вполне может быть без первичного ключа. К слову сказать, понятие PRIMARY KEY, по-моему, вообще в Терадате отсутствует.
То, по чему Терадата распределяет данные называется первичный индекс.
В качестве первичного индекса можно выбирать всё что угодно, лишь бы это делу помогало :)
То есть, он может быть неуникальным, если Вы это имели в виду.


kmikeЧитабельность EXPLAIN'a Терадаты впечатляет :)

Все отмечают. Мне тоже очень нравится. По-пусски, правда, не умеет :(


kmike"which is redistributed by hash code to all AMPs" - вот этот момент интересен, по какому хэшу оно переспределяется?
И, получается, с каждого узла все данные, удовлетворяющие фильтру, надо будет отправить на каждый остальной узел? Не возникает ли здесь узкого места? Допустим, 10ГБ при 0.18ГБ/с (и это, небось, теоретически, то есть в вакууме) - это примерно минута.. Кстати, оно широковещательно передаётся или на каждый узел отдельно?

redistributed - это перераспределение. Оно широковещательным не может быть. Данные из одного AMP должны скопироваться на другой, а не на все сразу. Точка-точка будет. Или с маленькой вероятностью за пределы узла не выйдет, если оба AMPа на одном узле.
duplicated - это уже будет копирование. Я не в курсе, будет здесь широковещательное или нет.
В принципе, можно эксперимент провести на 10-гигабайтной таблице на предмет времен её перераспределения.




С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34088419
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeвот этот момент интересен, по какому хэшу оно переспределяется?

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


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34099682
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Итак, сухой остаток:
В Терадате, получается, по ключу распределения ещё автоматом строится локальный хэш-индекс.

В DB2, насколько я помню, хэш используется только для распределения данных по партициям, а строить или нет по этому полю индекс-оставлено на усмотрение пользователя. PRIMARY KEY при этом поддерживается в полном объёме. (Запишем в минус ограничение - Any unique key or primary key must contain all of the partitioning key columns. )

Про простоту сопровождения ничего не могу сказать, самая большая инсталляция DB2 DPF, которую мне доводилось видеть-это 16 разделов. И, кстати, это смешанная OLTP+DSS система.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34101012
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Прохоров andrey_anonymousЦитатки неаккуратно из контекста вырезаете.
В первой, к примеру, обсуждается исключительно PARTITION-WISE JOIN. И ничего более. Вы же цитируете, словно это общее правило и системное ограничение.
Супер. Расскажите о других способах распаралеливания join-ов в Oracle.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
SQL> create table ane_t(a number, b number) partition by hash(a) partitions  5  parallel  4 ;

Table created

SQL> insert into ane_t select rownum, rownum from dual connect by level <  10000 ;

 9999  rows inserted

SQL> create table ane_t2(a number, b number) partition by hash(a) partitions  11  parallel  7 ;

Table created

SQL> insert into ane_t2 select * from ane_t;

 9999  rows inserted

SQL> commit;

Commit complete

SQL> exec dbms_stats.gather_table_stats(user,'ANE_T');

PL/SQL procedure successfully completed

SQL> exec dbms_stats.gather_table_stats(user,'ANE_T2');

PL/SQL procedure successfully completed

SQL> explain plan for select * from ane_t t1, ane_t2 t2 where t1.a=t2.b;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------
| Id  | Operation            |  Name       | Rows  | Bytes | Cost  | Pstart| Pstop |  TQ    |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------
|    0  | SELECT STATEMENT     |             |   9999  |   136K|      5  |       |       |        |      |            |
|*   1  |  HASH JOIN           |             |   9999  |   136K|      5  |       |       |  41 , 01   | P->S | QC (RAND)  |
|    2  |   PARTITION HASH ALL |             |       |       |       |      1  |      5  |  41 , 01   | PCWP |            |
|    3  |    TABLE ACCESS FULL | ANE_T       |   9999  |  69993  |      2  |      1  |      5  |  41 , 01   | PCWP |            |
|    4  |   PARTITION HASH ALL |             |       |       |       |      1  |     11  |  41 , 01   | PCWP |            |
|    5  |    TABLE ACCESS FULL | ANE_T2      |   9999  |  69993  |      3  |      1  |     11  |  41 , 00   | P->P | PART (KEY) |
-----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
    1  - access("T1"."A"="T2"."B")
Note: cpu costing is off

 18  rows selected

SQL> rollback;

Rollback complete

SQL> explain plan for select * from ane_t t1, ane_t2 t2 where t1.a=t2.a;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------
| Id  | Operation            |  Name       | Rows  | Bytes | Cost  | Pstart| Pstop |  TQ    |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------
|    0  | SELECT STATEMENT     |             |   9999  |   136K|      5  |       |       |        |      |            |
|*   1  |  HASH JOIN           |             |   9999  |   136K|      5  |       |       |  42 , 01   | P->S | QC (RAND)  |
|    2  |   PARTITION HASH ALL |             |       |       |       |      1  |      5  |  42 , 01   | PCWP |            |
|    3  |    TABLE ACCESS FULL | ANE_T       |   9999  |  69993  |      2  |      1  |      5  |  42 , 00   | P->P | BROADCAST L|
|    4  |   PARTITION HASH ALL |             |       |       |       |      1  |     11  |  42 , 01   | PCWP |            |
|    5  |    TABLE ACCESS FULL | ANE_T2      |   9999  |  69993  |      3  |      1  |     11  |  42 , 01   | PCWP |            |
-----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
    1  - access("T1"."A"="T2"."A")
Note: cpu costing is off

 18  rows selected

SQL> rollback;

Rollback complete

SQL> alter table ane_t add partition;

Table altered

SQL> alter table ane_t add partition;

Table altered

SQL> alter table ane_t add partition;

Table altered

SQL> alter table ane_t add partition;

Table altered

SQL> alter table ane_t add partition;

Table altered

SQL> alter table ane_t add partition;

Table altered

SQL> select table_name, count(*) from user_tab_partitions where table_name in ('ANE_T','ANE_T2') group by table_name;

TABLE_NAME                       COUNT(*)
------------------------------ ----------
ANE_T                                   11 
ANE_T2                                  11 

SQL> exec dbms_stats.gather_table_stats(user,'ANE_T');

PL/SQL procedure successfully completed

SQL> explain plan for select * from ane_t t1, ane_t2 t2 where t1.a=t2.a;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------
| Id  | Operation            |  Name       | Rows  | Bytes | Cost  | Pstart| Pstop |  TQ    |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------
|    0  | SELECT STATEMENT     |             |   9999  |   136K|      6  |       |       |        |      |            |
|    1  |  PARTITION HASH ALL  |             |       |       |       |      1  |     11  |  43 , 00   | PCWP |            |
|*   2  |   HASH JOIN          |             |   9999  |   136K|      6  |       |       |  43 , 00   | P->S | QC (RAND)  |
|    3  |    TABLE ACCESS FULL | ANE_T       |   9999  |  69993  |      3  |      1  |     11  |  43 , 00   | PCWP |            |
|    4  |    TABLE ACCESS FULL | ANE_T2      |   9999  |  69993  |      3  |      1  |     11  |  43 , 00   | PCWP |            |
-----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
    2  - access("T1"."A"="T2"."A")
Note: cpu costing is off

 17  rows selected

SQL> 
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34101317
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Прохоров andrey_anonymous1) "Для паралельного выполнения запросов нужно использовать partitioning"
Утверждение ложно, поскольку данное ограничение действует не на любые запросы.
Если бы Вы удосужились правильно описать классы запросов, для которых ограничение актуально - проблем бы не было.
Если бы Вы читали ветку, в которую пишите, то таких вопросов бы не возникало:
Зл0йПредположим что есть 2 таблицы table_a и table_b. Предположим что первичные индексы данных таблиц построены по атрибутам column_a1 и column_b1 соответственно. Теперь строим Join такой что column_a1=column_b27. Доступ в table_b идет не по первичному индексу. т.е. amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet. Ведь они же раскиданы по amp'ам исходя из хеширования по column_b1. Теперь предположим что обе таблицы по 200 миллионов записей, чтобы жизнь медом не казалась.Так и не понял, как Вы связали одно с другим.
А речь в посте, на который Вы ссылаетесь, таки шла о ТераДата и противопоставляются модели сборки этих данных по interconnect в shared nothing и чтение всеми узлами с диска в shared disk, просто иллюстрация невсесильности ByNet. Андрей Прохоров andrey_anonymous2) "Чтобы обеспечить равномерную загрузку узлов .... придется использовать hash partitioning"
Утверждение ложно. С учетом конкретного содержимого равномерное распределение данных может быть достигнуто и на range, и на list.
Готовим partitioning под фиксированные запрос и содержимое. Технологично. Шаг влево, шаг вправо всю оптимизацию сдаем в утиль Это закон жизни, и TeraData тут находится в том же печальном положении, как и любая другая СУБД... Андрей Прохоров andrey_anonymous3) "как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2"
Для начала сумейте показать, что имеющаяся неравномерность (напомню приведенную Вами цитату, в худшем случае самый большой раздел может оказаться в два раза больше самого маленького) заметно повлияет на время исполнения запроса, если разделов более двух.
Доказывать, что 2х2=4 не собираюсь.
Так и запишем: обоснования предоставить не смог. Андрей Прохоров andrey_anonymousЕсли же немножко отвлечься от стиля документалистов oracle и вспомнить, что речь таки идет о хеш-функции, то можно достаточно легко предложить пример исходных данных, которые улягутся, к примеру, всей толпой в один и тот же раздел. Актуально и для TeraData, и для Oracle, и вообще для любой системы, разделяющей данные по хеш. Берем 200 млн. x N записей, раскладываем по хэш функции по N партициям, потом берем все записи, попавшие в одну партицию и кричим "караул!". Дальше что?
Дальше понимаем, что абсолютных правил в этой жизни нет и распределение данных по хеш-разделам по-настоящему зависит не от количества этих разделов, а от характера данных.
Ч.Т.Д. :)
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34101351
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел НовокшоновПоследний upgrade у моего клиента занял порядка 20-25 часов. База при этом не доступна пользователям . Некоторые клиенты имеют резервные системы (в рамках решения dual-active), при этом пользователи перенаправляются на резервную систему если основная не доступна. На практике добавление новых узлов в кластер происходит не так часто, как правило раз в 1,5 - 2 года.
Упс... Это грустно.
В оракеле с этим хоть и неидеально, но как-то попроще - online redefinition всякие и плюс совершенно необязательно сразу кидаться все секционированные таблички перелопачивать, можно и по одной...
Кроме того, если я правильно понимаю, пользователи резервной системы ограничены только выборкой данных? Или ТераДата предлагает системные механизмы для прогона проведенных в резервной базе изменений по боевой после окончания перераспределения?
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34102386
MSTR Fan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymousТак и не понял, как Вы связали одно с другим.
А речь в посте, на который Вы ссылаетесь, таки шла о ТераДата и противопоставляются модели сборки этих данных по interconnect в shared nothing и чтение всеми узлами с диска в shared disk, просто иллюстрация невсесильности ByNet.
Уважаемый, BYNET не всесилен, а масштабируем. Многим этого хватает.
В Вашем примере запроса почему-то делается join таблиц по 10к записей. Могу ответственно заявить что join таких таблиц TD тоже сделает очень быстро. Покажите план для 200 млн., и колонок было бы здорово добавить. И узлов в системе, чтобы было понятно как Oracle автоматически распределит работу между узлами, как это делает TD.

andrey_anonymous
Это закон жизни, и TeraData тут находится в том же печальном положении, как и любая другая СУБД...

Вы не понимаете предмета. Range partitioning в TD - это не о том как по AMP-ам данные распределить, а о том как внутри АМР-а отсортировать. И если hash partitioning у Вас сделан нормально (в TD он первичен) то даже если у Вас все записи попали в один range partition, параллелизм от этого не пострадает.

andrey_anonymousДальше понимаем, что абсолютных правил в этой жизни нет и распределение данных по хеш-разделам по-настоящему зависит не от количества этих разделов, а от характера данных.
Ч.Т.Д. :)

В случае равенства количества возможных значений хэша (кол-ва разделов), конечно. В TD 65536 значений.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34102414
Андрей ПрохоровРасскажите о других способах распаралеливания join-ов в Oracle.

andrey_anonymous
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
-----------------------------------------------------------------------------------------------------------------
| Id  | Operation            |  Name       | Rows  | Bytes | Cost  | Pstart| Pstop |  TQ    |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------
|    0  | SELECT STATEMENT     |             |   9999  |   136K|      5  |       |       |        |      |            |
|*   1  |  HASH JOIN           |             |   9999  |   136K|      5  |       |       |  41 , 01   | P->S | QC (RAND)  |
|    2  |   PARTITION HASH ALL |             |       |       |       |      1  |      5  |  41 , 01   | PCWP |            |
|    3  |    TABLE ACCESS FULL | ANE_T       |   9999  |  69993  |      2  |      1  |      5  |  41 , 01   | PCWP |            |
|    4  |   PARTITION HASH ALL |             |       |       |       |      1  |     11  |  41 , 01   | PCWP |            |
|    5  |    TABLE ACCESS FULL | ANE_T2      |   9999  |  69993  |      3  |      1  |     11  |  41 , 00   | P->P | PART (KEY) |
-----------------------------------------------------------------------------------------------------------------

Ну где здесь Query Coordinator, где паралелизм?
Матчасть не знаем, совсем

andrey_anonymousЭто закон жизни, и TeraData тут находится в том же печальном положении, как и любая другая СУБД...
Для сравнения рекомендую разобраться как работает паралельное выполнение join-ов в Oracle, потом уже можно с чем-то сравнивать.

andrey_anonymousДля начала сумейте показать, что имеющаяся неравномерность (напомню приведенную Вами цитату, в худшем случае самый большой раздел может оказаться в два раза больше самого маленького) заметно повлияет на время исполнения запроса, если разделов более двух.
Опять RTFM
"You can also join range partitioned tables with range partitioned tables and list partitioned tables with list partitioned tables in a partition-wise manner, but this is relatively uncommon. This is more complex to implement because you must know the distribution of the data before performing the join. Furthermore, if you do not
correctly identify the partition bounds so that you have partitions of equal size, data skew during the execution may result."
Паралельное выполнение join-ов в Oracle реализуется при помощи full или partial partition-wise join. В обоих случаях "the granule of parallelism is a partition". Если один из партишенов больше другого, то получается неравномерная нагрузка на серверы, чтобы понять как это увеличивает время выполнения запроса лучше почитать документацию, если сразу не понятно.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34102503
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей ПрохоровНу где здесь Query Coordinator, где паралелизм?
Матчасть не знаем, совсем
Тезка, прежде чем хамить, обращаем внимание на колоночку "PQ Distrib" и вдумчиво размышляем над сутью происходящего.
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34102522
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MSTR Fan andrey_anonymousТак и не понял, как Вы связали одно с другим.
А речь в посте, на который Вы ссылаетесь, таки шла о ТераДата и противопоставляются модели сборки этих данных по interconnect в shared nothing и чтение всеми узлами с диска в shared disk, просто иллюстрация невсесильности ByNet.
Уважаемый, BYNET не всесилен, а масштабируем. Многим этого хватает.Вернитесь пожалуйта к предмету обсуждения, для которого с меня был спрошен пример - соединение "мимо" ключа секционирования MSTR FanВ Вашем примере запроса почему-то делается join таблиц по 10к записей. Могу ответственно заявить что join таких таблиц TD тоже сделает очень быстро. Покажите план для 200 млн., и колонок было бы здорово добавить.10000 строк - я на сервере не один живу и мне не очень интересно кушать ресурсы ради дискуссий. Можно и больше, но как, с Вашей точки зрения, должен измениться план? MSTR Fan И узлов в системе, чтобы было понятно как Oracle автоматически распределит работу между узлами, как это делает TD.В данном случае имеем дело с SMP-машиной, подходящего для тестов RAC у меня сегодня под рукой, к сожалению, нет.
MSTR Fan andrey_anonymousЭто закон жизни, и TeraData тут находится в том же печальном положении, как и любая другая СУБД...
Вы не понимаете предмета. Range partitioning в TD - это не о том как по AMP-ам данные распределить, а о том как внутри АМР-а отсортировать. И если hash partitioning у Вас сделан нормально (в TD он первичен) то даже если у Вас все записи попали в один range partition, параллелизм от этого не пострадает.Вы спешите с выводами. Этот тест скорее аналогичен несекционированной, если так можно выразиться, табличке в TD.
Аналогом секционированной будет, к примеру, range+hash секционирование. Но даже простые планы вызывают бурю в стакане воды и недопонимание, что уж говорить о более сложных планах :) MSTR Fan andrey_anonymousДальше понимаем, что абсолютных правил в этой жизни нет и распределение данных по хеш-разделам по-настоящему зависит не от количества этих разделов, а от характера данных.
Ч.Т.Д. :)
В случае равенства количества возможных значений хэша (кол-ва разделов), конечно. В TD 65536 значений.
Маловато будет :)
Если верить Database Limits , то в оракеле таблица может состоять из 1024К-1 разделов :)
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34102554
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Прохоров andrey_anonymousДля начала сумейте показать, что имеющаяся неравномерность (напомню приведенную Вами цитату, в худшем случае самый большой раздел может оказаться в два раза больше самого маленького) заметно повлияет на время исполнения запроса, если разделов более двух.
Опять RTFM
"You can also join range partitioned tables with range partitioned tables and list partitioned tables with list partitioned tables in a partition-wise manner, but this is relatively uncommon. This is more complex to implement because you must know the distribution of the data before performing the join. Furthermore, if you do not
correctly identify the partition bounds so that you have partitions of equal size, data skew during the execution may result."
Паралельное выполнение join-ов в Oracle реализуется при помощи full или partial partition-wise join. В обоих случаях "the granule of parallelism is a partition". Если один из партишенов больше другого, то получается неравномерная нагрузка на серверы, чтобы понять как это увеличивает время выполнения запроса лучше почитать документацию, если сразу не понятно.
Долго думал, стоит ли отвечать на это несколько странный пассаж.
Но таки отвечу.
Итак, что же Вы процитировали? Примерно следующее: "Вы также можете соединять секционированные по range или list таблицы с таблицами, секционированными по list, но это менее универсально, и более сложно в реализации, поскольку надо хорошо представлять себе распределение данных. Более того, если границы разделов не определены таким образом, чтобы получить разделы равных размеров, может иметь место переко данных"
И как это иллюстрирует ход Ваших мыслей? А никак, ибо цитата взята первая попавшаяся. Да, можно сделать плохо. А можно и хорошо. Когда проектируется база, она всегда проектируется под определенные задачи. И никакой "робот" этого факта отменить не в состоянии, хоть весь concepts здесь перецитируйте.
Итак, выяснили - можно получить "перекос данных". Но это мы выяснили еще несколько постов назад.
И что же Вы ответили на просьбу оценить влияние подобного перекоса на время выполнения запроса? Вот: "получается неравномерная нагрузка на серверы, чтобы понять как это увеличивает время выполнения запроса лучше почитать документацию, если сразу не понятно".
То есть опять ничего не ответили.
Создается впечатление, что Вы просто сотрясаете форум неуместными цитатами и надуваете щеки, попутно обсуждая личность собеседника.
Неспортивно, уважаемый.
Все-таки попробуйте ответить на этот вопрос, после чего мы сможем продолжить обсуждение этого влияния в несколько ином аспекте, чего лично я уже давно жду :)
...
Рейтинг: 0 / 0
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
    #34102558
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Константин Лисянский
Константин, спасибо за Ваши комментарии относительно ТераДата.
Я для себя вынес следующее, поправьте пожалуйста если я где-то неправ:
1) Количество разделов таблицы в ТераДата обязательно кратно количеству узлов, невозможно "вертикально" распределить вычислительные мощности в соответствии с потребностями приложений (например, днем 8 узлов операторам, 2 узла - batch, ночью наоборот).
2) Основными конкурентными преимуществами ТераДата на сегодняшний день являются относительно простой синтаксис DDL, user-friendly вывод explain plan, программно-аппаратный комплекс ByNet, значительное количество реальных инсталляций с десятками и сотями узлов.
3) Основными недостатками ТераДата являются длительные простои при переконфигурировании, практическая непригодность для смешанных oltp+dss приложений, непригодность для систем 24х7 ввиду простоя во время резервного копирования (низкий коэффициент готовности). То есть область ее применения ограничена чистым DWH.

Еще хотелось бы, если возможно, узнать про возможности системы по обеспечению load balancing и application failover.
...
Рейтинг: 0 / 0
25 сообщений из 159, страница 5 из 7
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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