Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
ChA
Member

Откуда: Москва
Сообщений: 11376
andrey_anonymous
К DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.
Что значит обычно ? Боюсь, это Вы сильно погорячились, манипуляции с данными совсем не подразумевает только изменение этих данных. А то так можно договориться, что SELECT относится к DDL.
27 окт 06, 18:30    [3323218]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
ChA
andrey_anonymous
К DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.
Что значит обычно ? Боюсь, это Вы сильно погорячились, манипуляции с данными совсем не подразумевает только изменение этих данных. А то так можно договориться, что SELECT относится к DDL.

DML
  • Data Manipulation Language
  • Data Modification Language

    Второй вариант - одно из типичных неправильных прочтений. Всякое бывает.
  • 27 окт 06, 20:16    [3323613]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    из микросовтовского хелпа:

    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. и т.д.
    Хотя может в Оракле по-другому считают :)
    27 окт 06, 20:54    [3323732]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    ChA
    Member

    Откуда: Москва
    Сообщений: 11376
    SergSuper
    Хотя может в Оракле по-другому считают
    Если верить google, то уже по первой странице видно, что Oracle тоже считает, что DML - data manipulation language, и в него входит SELECT.
    27 окт 06, 21:45    [3323833]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Константин Лисянский
    Member

    Откуда: Москва
    Сообщений: 902
    kmike
    Константин Лисянский , поясните пожалуйста ваш постулат о том, что в Терадате нужно меньше индексов? За счёт чего это?


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

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


    С уважением,
    Константин Лисянский
    http://lissianski.narod.ru
    27 окт 06, 22:21    [3323904]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Константин Лисянский
    Member

    Откуда: Москва
    Сообщений: 902
    kmike
    В списке переменных, учитываемых оптимизатором, тоже не вижу ничего выдающегося.


    Понятно.

    kmike
    Цифры есть?


    Конечно.

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


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




    С уважением,
    Константин Лисянский
    http://lissianski.narod.ru
    27 окт 06, 22:51    [3323982]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Андрей Прохоров
    Member

    Откуда:
    Сообщений: 146
    andrey_anonymous
    Цитатки неаккуратно из контекста вырезаете.
    В первой, к примеру, обсуждается исключительно PARTITION-WISE JOIN. И ничего более. Вы же цитируете, словно это общее правило и системное ограничение.

    Супер. Расскажите о других способах распаралеливания join-ов в Oracle.
    andrey_anonymous
    1) "Для паралельного выполнения запросов нужно использовать 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_anonymous
    2) "Чтобы обеспечить равномерную загрузку узлов .... придется использовать hash partitioning"
    Утверждение ложно. С учетом конкретного содержимого равномерное распределение данных может быть достигнуто и на range, и на list.

    Готовим partitioning под фиксированные запрос и содержимое. Технологично. Шаг влево, шаг вправо всю оптимизацию сдаем в утиль
    andrey_anonymous
    3) "как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2"
    Для начала сумейте показать, что имеющаяся неравномерность (напомню приведенную Вами цитату, в худшем случае самый большой раздел может оказаться в два раза больше самого маленького) заметно повлияет на время исполнения запроса, если разделов более двух.

    Доказывать, что 2х2=4 не собираюсь.
    andrey_anonymous
    Если же немножко отвлечься от стиля документалистов oracle и вспомнить, что речь таки идет о хеш-функции, то можно достаточно легко предложить пример исходных данных, которые улягутся, к примеру, всей толпой в один и тот же раздел. Актуально и для TeraData, и для Oracle, и вообще для любой системы, разделяющей данные по хеш.
    Берем 200 млн. x N записей, раскладываем по хэш функции по N партициям, потом берем все записи, попавшие в одну партицию и кричим "караул!". Дальше что?
    27 окт 06, 23:42    [3324124]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Константин Лисянский
    Member

    Откуда: Москва
    Сообщений: 902
    kmike
    Можно здесь подробнее? Допустим, есть таблицы T1 и T2 со столбцами A,B,C, и A используется для распределения по узлам. Как будет выполняться join T1 и T2 по условию T1.B=T2.B ?



    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 );

    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 );

    EXPLAIN
    SELECT
      *
    FROM
      SHOPPING_TRANSACTION st
    INNER JOIN
      SHOPPING_TRANSACTION_LINE stl
    ON
      st.Transaction_Dttm=stl.Transaction_Line_Dttm


    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, так как она меньше по размеру.


    EXPLAIN
    SELECT
      *
    FROM
      SHOPPING_TRANSACTION_LINE stl1
    INNER JOIN
      SHOPPING_TRANSACTION_LINE stl2
    ON
      stl1.Transaction_Line_Dttm=stl2.Transaction_Line_Dttm

    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
    28 окт 06, 00:31    [3324225]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    kmike
    Member

    Откуда:
    Сообщений: 286
    Константин Лисянский
    kmike
    Константин Лисянский , поясните пожалуйста ваш постулат о том, что в Терадате нужно меньше индексов? За счёт чего это?


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

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

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

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

    Про джойны без индексов тоже понятно, что они не нужны, но это же наверняка повлияет на производительность, потому я и спросил, каким методом будет выполняться такой джойн (в контексте объёмов пересылки по сети).
    Кстати, у Терадаты ключ секционирования по узлам может не совпадать с первичным?
    28 окт 06, 00:31    [3324228]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    kmike
    Member

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

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

    Читабельность EXPLAIN'a Терадаты впечатляет :)
    "which is redistributed by hash code to all AMPs" - вот этот момент интересен, по какому хэшу оно переспределяется?
    И, получается, с каждого узла все данные, удовлетворяющие фильтру, надо будет отправить на каждый остальной узел? Не возникает ли здесь узкого места? Допустим, 10ГБ при 0.18ГБ/с (и это, небось, теоретически, то есть в вакууме) - это примерно минута.. Кстати, оно широковещательно передаётся или на каждый узел отдельно?
    28 окт 06, 00:52    [3324272]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Павел Новокшонов
    Member

    Откуда: Moscow -> Atlanta, GA
    Сообщений: 90
    andrey_anonymous
    Павел, Константин - моя оценка времени "неделька-другая" на удвоение количества узлов от реальности, скорее всего, далека, не могли бы Вы все-таки привести Вашу оценку?
    Второй вопрос - будет ли база доступна пользователям в процессе?


    Мне сложно дать какую-то конкретную оценку, поскольку я не занимаюсь upgrade'ми. Это зависит наверное от размера кластера и кол-ва данных хэш которых надо пере-рассчитать. В Teradata есть tool - estimator - который позволяет оценить время необходимое на re-config при добавлении новых узлов. Последний upgrade у моего клиента занял порядка 20-25 часов. База при этом не доступна пользователям. Некоторые клиенты имеют резервные системы (в рамках решения dual-active), при этом пользователи перенаправляются на резервную систему если основная не доступна. На практике добавление новых узлов в кластер происходит не так часто, как правило раз в 1,5 - 2 года.
    28 окт 06, 00:55    [3324279]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Павел Новокшонов
    Member

    Откуда: Moscow -> Atlanta, GA
    Сообщений: 90
    kmike
    Читабельность EXPLAIN'a Терадаты впечатляет :)


    Мне тоже нравится. У Оракла и DB2 explain'ы какие-то примитивные что-ли, хотя наверное дело привычки.
    28 окт 06, 01:10    [3324316]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Константин Лисянский
    Member

    Откуда: Москва
    Сообщений: 902
    andrey_anonymous
    В shared disk размещение разделов - нескольк более "творческая" работа.


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

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


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


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


    Teradata Database SQL Reference Statement and Transaction Processing
    Left-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
    28 окт 06, 01:18    [3324342]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Константин Лисянский
    Member

    Откуда: Москва
    Сообщений: 902
    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
    28 окт 06, 01:39    [3324395]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Константин Лисянский
    Member

    Откуда: Москва
    Сообщений: 902
    kmike
    вот этот момент интересен, по какому хэшу оно переспределяется?


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


    С уважением,
    Константин Лисянский
    http://lissianski.narod.ru
    28 окт 06, 01:43    [3324405]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    kmike
    Member

    Откуда:
    Сообщений: 286
    Итак, сухой остаток:
    В Терадате, получается, по ключу распределения ещё автоматом строится локальный хэш-индекс.

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

    Про простоту сопровождения ничего не могу сказать, самая большая инсталляция DB2 DPF, которую мне доводилось видеть-это 16 разделов. И, кстати, это смешанная OLTP+DSS система.
    2 ноя 06, 09:58    [3345295]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 19912
    Андрей Прохоров
    andrey_anonymous
    Цитатки неаккуратно из контекста вырезаете.
    В первой, к примеру, обсуждается исключительно PARTITION-WISE JOIN. И ничего более. Вы же цитируете, словно это общее правило и системное ограничение.

    Супер. Расскажите о других способах распаралеливания join-ов в Oracle.

    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> 
    2 ноя 06, 14:29    [3347676]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 19912
    Андрей Прохоров
    andrey_anonymous
    1) "Для паралельного выполнения запросов нужно использовать 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_anonymous
    2) "Чтобы обеспечить равномерную загрузку узлов .... придется использовать hash partitioning"
    Утверждение ложно. С учетом конкретного содержимого равномерное распределение данных может быть достигнуто и на range, и на list.

    Готовим partitioning под фиксированные запрос и содержимое. Технологично. Шаг влево, шаг вправо всю оптимизацию сдаем в утиль
    Это закон жизни, и TeraData тут находится в том же печальном положении, как и любая другая СУБД...
    Андрей Прохоров
    andrey_anonymous
    3) "как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2"
    Для начала сумейте показать, что имеющаяся неравномерность (напомню приведенную Вами цитату, в худшем случае самый большой раздел может оказаться в два раза больше самого маленького) заметно повлияет на время исполнения запроса, если разделов более двух.

    Доказывать, что 2х2=4 не собираюсь.

    Так и запишем: обоснования предоставить не смог.
    Андрей Прохоров
    andrey_anonymous
    Если же немножко отвлечься от стиля документалистов oracle и вспомнить, что речь таки идет о хеш-функции, то можно достаточно легко предложить пример исходных данных, которые улягутся, к примеру, всей толпой в один и тот же раздел. Актуально и для TeraData, и для Oracle, и вообще для любой системы, разделяющей данные по хеш.
    Берем 200 млн. x N записей, раскладываем по хэш функции по N партициям, потом берем все записи, попавшие в одну партицию и кричим "караул!". Дальше что?

    Дальше понимаем, что абсолютных правил в этой жизни нет и распределение данных по хеш-разделам по-настоящему зависит не от количества этих разделов, а от характера данных.
    Ч.Т.Д. :)
    2 ноя 06, 15:27    [3348171]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 19912
    Павел Новокшонов
    Последний upgrade у моего клиента занял порядка 20-25 часов. База при этом не доступна пользователям. Некоторые клиенты имеют резервные системы (в рамках решения dual-active), при этом пользователи перенаправляются на резервную систему если основная не доступна. На практике добавление новых узлов в кластер происходит не так часто, как правило раз в 1,5 - 2 года.

    Упс... Это грустно.
    В оракеле с этим хоть и неидеально, но как-то попроще - online redefinition всякие и плюс совершенно необязательно сразу кидаться все секционированные таблички перелопачивать, можно и по одной...
    Кроме того, если я правильно понимаю, пользователи резервной системы ограничены только выборкой данных? Или ТераДата предлагает системные механизмы для прогона проведенных в резервной базе изменений по боевой после окончания перераспределения?
    2 ноя 06, 15:35    [3348236]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    MSTR Fan
    Guest
    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 значений.
    2 ноя 06, 21:51    [3350238]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    Андрей Прохоров
    Member

    Откуда:
    Сообщений: 146
    Андрей Прохоров
    Расскажите о других способах распаралеливания join-ов в Oracle.


    andrey_anonymous
    -----------------------------------------------------------------------------------------------------------------
    | 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". Если один из партишенов больше другого, то получается неравномерная нагрузка на серверы, чтобы понять как это увеличивает время выполнения запроса лучше почитать документацию, если сразу не понятно.
    2 ноя 06, 22:11    [3350285]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 19912
    Андрей Прохоров
    Ну где здесь Query Coordinator, где паралелизм?
    Матчасть не знаем, совсем

    Тезка, прежде чем хамить, обращаем внимание на колоночку "PQ Distrib" и вдумчиво размышляем над сутью происходящего.
    2 ноя 06, 23:55    [3350551]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 19912
    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 разделов :)
    3 ноя 06, 00:14    [3350622]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 19912
    Андрей Прохоров
    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 здесь перецитируйте.
    Итак, выяснили - можно получить "перекос данных". Но это мы выяснили еще несколько постов назад.
    И что же Вы ответили на просьбу оценить влияние подобного перекоса на время выполнения запроса? Вот: "получается неравномерная нагрузка на серверы, чтобы понять как это увеличивает время выполнения запроса лучше почитать документацию, если сразу не понятно".
    То есть опять ничего не ответили.
    Создается впечатление, что Вы просто сотрясаете форум неуместными цитатами и надуваете щеки, попутно обсуждая личность собеседника.
    Неспортивно, уважаемый.
    Все-таки попробуйте ответить на этот вопрос, после чего мы сможем продолжить обсуждение этого влияния в несколько ином аспекте, чего лично я уже давно жду :)
    3 ноя 06, 01:08    [3350711]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
    andrey_anonymous
    Member

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

    Константин, спасибо за Ваши комментарии относительно ТераДата.
    Я для себя вынес следующее, поправьте пожалуйста если я где-то неправ:
    1) Количество разделов таблицы в ТераДата обязательно кратно количеству узлов, невозможно "вертикально" распределить вычислительные мощности в соответствии с потребностями приложений (например, днем 8 узлов операторам, 2 узла - batch, ночью наоборот).
    2) Основными конкурентными преимуществами ТераДата на сегодняшний день являются относительно простой синтаксис DDL, user-friendly вывод explain plan, программно-аппаратный комплекс ByNet, значительное количество реальных инсталляций с десятками и сотями узлов.
    3) Основными недостатками ТераДата являются длительные простои при переконфигурировании, практическая непригодность для смешанных oltp+dss приложений, непригодность для систем 24х7 ввиду простоя во время резервного копирования (низкий коэффициент готовности). То есть область ее применения ограничена чистым DWH.

    Еще хотелось бы, если возможно, узнать про возможности системы по обеспечению load balancing и application failover.
    3 ноя 06, 01:29    [3350719]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить