|
|
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousК DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.Что значит обычно ? Боюсь, это Вы сильно погорячились, манипуляции с данными совсем не подразумевает только изменение этих данных. А то так можно договориться, что SELECT относится к DDL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2006, 18:30 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
ChA andrey_anonymousК DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.Что значит обычно ? Боюсь, это Вы сильно погорячились, манипуляции с данными совсем не подразумевает только изменение этих данных. А то так можно договориться, что SELECT относится к DDL. DML Data Manipulation Language Data Modification Language Второй вариант - одно из типичных неправильных прочтений. Всякое бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2006, 20:16 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
из микросовтовского хелпа: 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.10.2006, 20:54 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
SergSuperХотя может в Оракле по-другому считаютЕсли верить google , то уже по первой странице видно, что Oracle тоже считает, что DML - data manipulation language, и в него входит SELECT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2006, 21:45 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
kmikeКонстантин Лисянский , поясните пожалуйста ваш постулат о том, что в Терадате нужно меньше индексов? За счёт чего это? Можно, просто, Константин. Я не обижусь. Например, primari index, с одной стороны, является механизмом распределения данных, с другой стороны, используется в качестве метода доступа. Однако это не совсем индекс - это функция. Далее, поскольку все таблицы в системе размазываются между единицими параллелизма на маленькие кусочки, часто получается быстрее сделать фуллскан, нежели использовать для выборки индекс. Для джойнов индексы Терадате не нужны, кроме первичного (который суть не индекс). С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2006, 22:21 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
kmikeВ списке переменных, учитываемых оптимизатором, тоже не вижу ничего выдающегося. Понятно. kmikeЦифры есть? Конечно. kmikeА откуда уверенность, что оно узким местом не является? Пока что не было продемонстрировано, что Терадата может выполнить объединение таблиц по столбцам, не являющимся ключом хэш-секционирования, без их пересылки по сети. А я, вроде бы не утверждал, что может. Точно не может, на всякий случай. Это же shared nothing. В общем случае перераспределение (или дуплицирование одной из таблиц) нужно во всех случаях, кроме того, когда в условии джойна стоят первичные индексы обеих таблиц. Таким образом, данные постоянно разгуливают между узлами. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2006, 22:51 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
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 партициям, потом берем все записи, попавшие в одну партицию и кричим "караул!". Дальше что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2006, 23:42 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Код: 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. В этом примере видно, что оптимизатор решил не перераспределять большую таблицу SHOPPING_TRANSACTION_LINE, а решил продублировать таблицу SHOPPING_TRANSACTION, так как она меньше по размеру. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Код: 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. А в этом примере перед джойном перераспределяются обе таблицы, поскольку они одинаково большие. Перераспределение таблиц происходит одновременно, то есть, присутствует как внутришаговый параллелизм, так и межшаговый. Это довольно характерная картина для Терадаты. Надеюсь, степень подробности удовлетворительная. Если что-то непонятно, готов прокомментировать. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2006, 00:31 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Константин Лисянский kmikeКонстантин Лисянский , поясните пожалуйста ваш постулат о том, что в Терадате нужно меньше индексов? За счёт чего это? Можно, просто, Константин. Я не обижусь. Например, primari index, с одной стороны, является механизмом распределения данных, с другой стороны, используется в качестве метода доступа. Однако это не совсем индекс - это функция. Далее, поскольку все таблицы в системе размазываются между единицими параллелизма на маленькие кусочки, часто получается быстрее сделать фуллскан, нежели использовать для выборки индекс. Для джойнов индексы Терадате не нужны, кроме первичного (который суть не индекс). Вот про метод доступа интересно... Очевидно, что можно использовать этот самый хэш для определения узла, на котором находится данная строчка. А внутри узла этот самый хэш как-нибудь играет? Постулат про предпочтение фулл-сканов индексам я понял примерно понял, но это же верно в любой системе с достаточно большой степенью параллелизма. Либо просто с быстрым i/o по отношению к объёму таблицы. Про джойны без индексов тоже понятно, что они не нужны, но это же наверняка повлияет на производительность, потому я и спросил, каким методом будет выполняться такой джойн (в контексте объёмов пересылки по сети). Кстати, у Терадаты ключ секционирования по узлам может не совпадать с первичным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2006, 00:31 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Константин ЛисянскийА в этом примере перед джойном перераспределяются обе таблицы, поскольку они одинаково большие. Перераспределение таблиц происходит одновременно, то есть, присутствует как внутришаговый параллелизм, так и межшаговый. Это довольно характерная картина для Терадаты. Надеюсь, степень подробности удовлетворительная. Если что-то непонятно, готов прокомментировать. Читабельность EXPLAIN'a Терадаты впечатляет :) "which is redistributed by hash code to all AMPs" - вот этот момент интересен, по какому хэшу оно переспределяется? И, получается, с каждого узла все данные, удовлетворяющие фильтру, надо будет отправить на каждый остальной узел? Не возникает ли здесь узкого места? Допустим, 10ГБ при 0.18ГБ/с (и это, небось, теоретически, то есть в вакууме) - это примерно минута.. Кстати, оно широковещательно передаётся или на каждый узел отдельно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2006, 00:52 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousПавел, Константин - моя оценка времени "неделька-другая" на удвоение количества узлов от реальности, скорее всего, далека, не могли бы Вы все-таки привести Вашу оценку? Второй вопрос - будет ли база доступна пользователям в процессе? Мне сложно дать какую-то конкретную оценку, поскольку я не занимаюсь upgrade'ми. Это зависит наверное от размера кластера и кол-ва данных хэш которых надо пере-рассчитать. В Teradata есть tool - estimator - который позволяет оценить время необходимое на re-config при добавлении новых узлов. Последний upgrade у моего клиента занял порядка 20-25 часов. База при этом не доступна пользователям. Некоторые клиенты имеют резервные системы (в рамках решения dual-active), при этом пользователи перенаправляются на резервную систему если основная не доступна. На практике добавление новых узлов в кластер происходит не так часто, как правило раз в 1,5 - 2 года. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2006, 00:55 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
kmikeЧитабельность EXPLAIN'a Терадаты впечатляет :) Мне тоже нравится. У Оракла и DB2 explain'ы какие-то примитивные что-ли, хотя наверное дело привычки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2006, 01:10 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2006, 01:18 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
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.10.2006, 01:39 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
kmikeвот этот момент интересен, по какому хэшу оно переспределяется? По хэшу столбца (или группы столбцов), по которому будет делаться джойн. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2006, 01:43 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Итак, сухой остаток: В Терадате, получается, по ключу распределения ещё автоматом строится локальный хэш-индекс. В DB2, насколько я помню, хэш используется только для распределения данных по партициям, а строить или нет по этому полю индекс-оставлено на усмотрение пользователя. PRIMARY KEY при этом поддерживается в полном объёме. (Запишем в минус ограничение - Any unique key or primary key must contain all of the partitioning key columns. ) Про простоту сопровождения ничего не могу сказать, самая большая инсталляция DB2 DPF, которую мне доводилось видеть-это 16 разделов. И, кстати, это смешанная OLTP+DSS система. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2006, 09:58 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Андрей Прохоров 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2006, 14:29 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Андрей Прохоров 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 партициям, потом берем все записи, попавшие в одну партицию и кричим "караул!". Дальше что? Дальше понимаем, что абсолютных правил в этой жизни нет и распределение данных по хеш-разделам по-настоящему зависит не от количества этих разделов, а от характера данных. Ч.Т.Д. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2006, 15:27 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Павел НовокшоновПоследний upgrade у моего клиента занял порядка 20-25 часов. База при этом не доступна пользователям . Некоторые клиенты имеют резервные системы (в рамках решения dual-active), при этом пользователи перенаправляются на резервную систему если основная не доступна. На практике добавление новых узлов в кластер происходит не так часто, как правило раз в 1,5 - 2 года. Упс... Это грустно. В оракеле с этим хоть и неидеально, но как-то попроще - online redefinition всякие и плюс совершенно необязательно сразу кидаться все секционированные таблички перелопачивать, можно и по одной... Кроме того, если я правильно понимаю, пользователи резервной системы ограничены только выборкой данных? Или ТераДата предлагает системные механизмы для прогона проведенных в резервной базе изменений по боевой после окончания перераспределения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2006, 15:35 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
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 значений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2006, 21:51 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Андрей ПрохоровРасскажите о других способах распаралеливания join-ов в Oracle. andrey_anonymous Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Ну где здесь 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". Если один из партишенов больше другого, то получается неравномерная нагрузка на серверы, чтобы понять как это увеличивает время выполнения запроса лучше почитать документацию, если сразу не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2006, 22:11 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Андрей ПрохоровНу где здесь Query Coordinator, где паралелизм? Матчасть не знаем, совсем Тезка, прежде чем хамить, обращаем внимание на колоночку "PQ Distrib" и вдумчиво размышляем над сутью происходящего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2006, 23:55 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
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 разделов :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2006, 00:14 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Андрей Прохоров 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 здесь перецитируйте. Итак, выяснили - можно получить "перекос данных". Но это мы выяснили еще несколько постов назад. И что же Вы ответили на просьбу оценить влияние подобного перекоса на время выполнения запроса? Вот: "получается неравномерная нагрузка на серверы, чтобы понять как это увеличивает время выполнения запроса лучше почитать документацию, если сразу не понятно". То есть опять ничего не ответили. Создается впечатление, что Вы просто сотрясаете форум неуместными цитатами и надуваете щеки, попутно обсуждая личность собеседника. Неспортивно, уважаемый. Все-таки попробуйте ответить на этот вопрос, после чего мы сможем продолжить обсуждение этого влияния в несколько ином аспекте, чего лично я уже давно жду :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2006, 01:08 |
|
||
|
Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)
|
|||
|---|---|---|---|
|
#18+
Константин Лисянский Константин, спасибо за Ваши комментарии относительно ТераДата. Я для себя вынес следующее, поправьте пожалуйста если я где-то неправ: 1) Количество разделов таблицы в ТераДата обязательно кратно количеству узлов, невозможно "вертикально" распределить вычислительные мощности в соответствии с потребностями приложений (например, днем 8 узлов операторам, 2 узла - batch, ночью наоборот). 2) Основными конкурентными преимуществами ТераДата на сегодняшний день являются относительно простой синтаксис DDL, user-friendly вывод explain plan, программно-аппаратный комплекс ByNet, значительное количество реальных инсталляций с десятками и сотями узлов. 3) Основными недостатками ТераДата являются длительные простои при переконфигурировании, практическая непригодность для смешанных oltp+dss приложений, непригодность для систем 24х7 ввиду простоя во время резервного копирования (низкий коэффициент готовности). То есть область ее применения ограничена чистым DWH. Еще хотелось бы, если возможно, узнать про возможности системы по обеспечению load balancing и application failover. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2006, 01:29 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=34088406&tid=1552808]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 160ms |

| 0 / 0 |
