Во-первых, есть такая штука как Exadata storage expansion.
Так а за счет чего будет прирост прозиодительности? все будет упираться в сеть между числогрызом и хранилкой!
Оракл вполне разумно параллелит запросы, поэтому не будет передавать все с сервера на сервер при параллельном запросе таком как count(*) from big_table.
С сервера на сервер не будет. Но хранилка у Оракла одна, и нужно считать с этой хранилки, и потом передать в RAC, вы хоть до бесконечности увеличивайте число нодов в Раке, и количество Exadata storage, все равно все упрется в 40 Гбит в сек.
>Будут переданы только готовые агрегаты от каждого parallel slave
Вот это не совсем понял. Вы хотите сказать, что уже на хранилке(storage sell) будет сделан count(*), без передачи на числогрыз? Я слышал про такое, но даже если это так, это чисто мистечковая задача, а если запрос вида
select c1, sum(*) from t1 group by c1, этот запрос тоже посчитается на хранилке? где про это можно почитать?
>Кроме того вы не учитываете, что в Exadata и SuperCluster сторадж селлы «умные».
Да вы правы, я сравнивал больше архитектуру, а не фичи, коих у Экзадаты в 100 раз больше чем у Терадаты. Но фичи иногда не работают, а грубая сила Терадаты стабильна.
>И вы нарочно не используете в сравнении возможности Oracle 12.1.0.2?
Не в курсе, что вышел 12.1.0.2, в 12.1.0.1 вроде ничего такого нет. Какие фичи в 12.1.0.2 могли повлиять на выводы моей статьи?
Ок, посмотрю, только у меня не OLTP. OLTP это транзакции и 50% запись, 50% чтения. У меня 90 на 10 и не нужна транзакции, но и грязное чтение тоже не желательно!
Аа, вот с этого и нужно было начинать =)
Если не секрет, если данные не в кэше, а на винте, сколько потребуется времени на запрос в 1 мегабайт? Или где про это можно почитать?
Spark — это вычислительный фреймворк, а не хранилище. Если у вас запрос на 10Гб, то они элементарно помещаются целиком в память и обрабатываются максимально эффективно. Кроме того, Spark оперирует над ленивыми коллекциями, так что к важдый конкретный момент времени на воркерах может вообще обрабатываться всего одна строчка данных.
Понимаете, это все не то, мне не нужен in-memory. Мне нужен быстрый MPP, которые без оперативной памяти может за секунды ответить на запрос. Пока я вижу только Терадату, остальные все очень медленные. MapReduce Хадупа ужасно тормозной. Где Терадата ответить на запрос за мили секунды, Хадуп будет отвечать 15-20 секунд.
Проблема Хадупа как я вижу, это реализация MapReduce, он жутко проигрывает механизму Запрос-ПланЗапроса-выполение Терадате
>что BIGINT в каком-то случае это значение факта, а в каком-то идентификатор измерения,
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
Я так и не понял, по какому признаку были распределены данные по нодам?
>Но ведь не все 300Тб одновременно и за 3 секунды?
Нет конечно. Может быть и 10 гигабайт за 3 секунды, но скорее всего меньше. Скорей всего будут применяться агрегаты, индексы, партиции, желательно ручная сегментация. Вообщем я ищу MPP, но с функциями почти классической СУБД, разве что джоинов там будет мало. Архитектура базы будет звездочка или снежинка.
Поддержка SQL явный плюс.
Если честно, я что-то сомневаюсь, что MapReduce может обеспечить быстрый отклик.
Так же большой проблемой я считаю жестко заданый размер блока в 64 мегабайта, это слишком много, у Оракла максиму 32 килобайта. Т.е. что бы считать одну строчку нужно считать целых 64 мегабайта.
Идеальную систему я вообще вижу очень гибкой, и что бы можно быть и realtime нагрузки давать, и если нужно выполнять ресурсоемкие задачи с десятками терабайт.
Почитал про Spark. Он in-memory, а у меня 300 терабайт, я же не будут строить класстер с 300 теребайтамии оперативки?
А вот Impala может и подойдет. Как я понял там не MapReduce, но все поверх той же HDFS.
Я ищу MPP, но для realtime. У нас дашборды на Oracle BI, на одном дашборде около 10 графиков и таблиц. Необходимо чтобы страница грузилась за 3 секунды. Hadoop классический не подходит, т.к. batch обработка медленная и вродебы Hadoop не держит больше 10 параллельных запросов.
HBase я тоже сомневаюсь что подойдет.
Так же нужно, чтобы обрабатывал базу в 300 Тб.
Чтобы могли работать одновременно 100 пользователей, в будущем больше.
Как я понял Cloudera имеет те же проблемы что и классический Hadoop?
В частности не realtime нагрузка.
Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Как я понял Cloudera решает только проблему merge данных за счет больших требований к памяти?
>что BIGINT в каком-то случае это значение факта, а в каком-то идентификатор измерения,
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
На сколько я понял Hive это чисто движок преобразующий SQL в MapReduce и он не вмешивается в формат хранения и тем более в распределения данных.
Но вот в Вики говорят, что в Hive есть фича создавать индексы. Значит создает какие-то свои системные данные.
HBase на сколько я понимаю, имеет свой формат хранения. И имеет партиционирование, которое
называется регион. Думаю Flurry тоже имеет, что-то подобное.
Я думаю если еще не создали, то создадут какой ни будь плагинчик для управления распределением данных по нодам.
Я пока еще не до конца понял возможности и ограничения Хадупа.
Я всегда думал, что Hive поверх HBase, но вы говорите, что поверх HDFS. Или Hive может быть и поверх HBase?
Как я понял Hive транслирует свой язык sql-like в код MapReduce процедур.
Вообще MapReduce программирование как-то меняется в зависимости от использования HDFS или HBase?
Как я понял в HDFS нет аналогов партиционирования? Например у нас лежит таблица в 1 триллион записей. А нужно прочитать только последний месяц. То Мариться будет весь 1 триллион, уже после редюсится до 1 месяца?
Я тут подумал.
Кто-то собирает Хадуп на большом количестве слабых серверов, кто-то малом количестве мощных. Думаю, если есть редкие или даже частые задачи по соединению таблиц, то лучше использовать малое количество мощных серверов. Чтобы можно было перелить driven-table на один мощный сервак и соединить.
Спасибо за информацию! Теперь можно расставить градацию.
У Оракла проблем с джоином нет, пока хватает памяти, но желательно партиционировать.
У Терадаты проблем тоже в принципе нет, но очень желательно правильно распределить партиции и данные по нодам, иначе начнется очень интенсивный сетевой обмен.
У Хадупа с джоином не очень.
Остается теперь узнать отличие реализации HDFS от HBase на Хадупе. Вы не в курсе?
А что делать, если данные связанные и в запросе нужно соединить 2 таблицы, например, каждая по 1 триллиону записей. В Терадате я бы их распределил по ключу соединения и еще партиционировал бы по ключу. Тогда Терадата бы все поняла, и положила только связанные партиции на каждый нод. Тогда при запросе данные бы вычислались только внутри каждой ноды. Каждая нода бы знала, что все данные есть локально.
А в Hadoop что получается? Каждый из 100 нодов хранит по 10 миллионов строк таблицы. Первую таблицу можно оставить как есть, никуда не пересылая данные по сети. Но что делать со второй? Придется на каждый нод тянуть все 1 триллион записей, что соединить.
Я правильно понял?
Нужно узнать, как Hadoop распределяет данные по нодам. Я уверен, что есть способ на это повлиять. Возможно это температурное распределение, т.е. данные двигаются, если Хадуп понял, что мало Data-local map tasks?
Я могу сказать, как это делается в Терадате. Допустим есть 2 абсолютно разных запросы. Одно распределение данных для них не подоходит, либо производительность одного будет просидать, либо второго. Делают обычно исходную таблицу распределенную оптимально для запроса 1, и табличный индекс, по сути копия таблицу распределенную оптимально для запроса 2. Как оптимизировать в этом случае Hadoop?
Так всё-таки речь о скорости или об удобстве?
Главное в статье скорость, но и про удобство тоже можно рассказать. Это влияет на стоимость разработки.
Вы мне предлагаете так же поговорить про абстрактную систему в вакууме с неизвестными задачами и посчитать для неё затраты электроэнергии? :) Ну уж нет, спасибо
Давайте договоримся о конкретике. Рассчитайте стоимость кластера, способного считывать в многопоточном режиме (т.е. винты должны быть серверные с большим числом головок) 25 и 35 Гб/с с дисков. В Hadoop можно узнать сколько и за какой времы каждый нод считал данных с диска?
Так а за счет чего будет прирост прозиодительности? все будет упираться в сеть между числогрызом и хранилкой!
С сервера на сервер не будет. Но хранилка у Оракла одна, и нужно считать с этой хранилки, и потом передать в RAC, вы хоть до бесконечности увеличивайте число нодов в Раке, и количество Exadata storage, все равно все упрется в 40 Гбит в сек.
>Будут переданы только готовые агрегаты от каждого parallel slave
Вот это не совсем понял. Вы хотите сказать, что уже на хранилке(storage sell) будет сделан count(*), без передачи на числогрыз? Я слышал про такое, но даже если это так, это чисто мистечковая задача, а если запрос вида
select c1, sum(*) from t1 group by c1, этот запрос тоже посчитается на хранилке? где про это можно почитать?
>Кроме того вы не учитываете, что в Exadata и SuperCluster сторадж селлы «умные».
Да вы правы, я сравнивал больше архитектуру, а не фичи, коих у Экзадаты в 100 раз больше чем у Терадаты. Но фичи иногда не работают, а грубая сила Терадаты стабильна.
>И вы нарочно не используете в сравнении возможности Oracle 12.1.0.2?
Не в курсе, что вышел 12.1.0.2, в 12.1.0.1 вроде ничего такого нет. Какие фичи в 12.1.0.2 могли повлиять на выводы моей статьи?
Если не секрет, если данные не в кэше, а на винте, сколько потребуется времени на запрос в 1 мегабайт? Или где про это можно почитать?
Понимаете, это все не то, мне не нужен in-memory. Мне нужен быстрый MPP, которые без оперативной памяти может за секунды ответить на запрос. Пока я вижу только Терадату, остальные все очень медленные. MapReduce Хадупа ужасно тормозной. Где Терадата ответить на запрос за мили секунды, Хадуп будет отвечать 15-20 секунд.
Проблема Хадупа как я вижу, это реализация MapReduce, он жутко проигрывает механизму Запрос-ПланЗапроса-выполение Терадате
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
Я так и не понял, по какому признаку были распределены данные по нодам?
Нет конечно. Может быть и 10 гигабайт за 3 секунды, но скорее всего меньше. Скорей всего будут применяться агрегаты, индексы, партиции, желательно ручная сегментация. Вообщем я ищу MPP, но с функциями почти классической СУБД, разве что джоинов там будет мало. Архитектура базы будет звездочка или снежинка.
Поддержка SQL явный плюс.
Если честно, я что-то сомневаюсь, что MapReduce может обеспечить быстрый отклик.
Так же большой проблемой я считаю жестко заданый размер блока в 64 мегабайта, это слишком много, у Оракла максиму 32 килобайта. Т.е. что бы считать одну строчку нужно считать целых 64 мегабайта.
Идеальную систему я вообще вижу очень гибкой, и что бы можно быть и realtime нагрузки давать, и если нужно выполнять ресурсоемкие задачи с десятками терабайт.
Почитал про Spark. Он in-memory, а у меня 300 терабайт, я же не будут строить класстер с 300 теребайтамии оперативки?
А вот Impala может и подойдет. Как я понял там не MapReduce, но все поверх той же HDFS.
Я ищу MPP, но для realtime. У нас дашборды на Oracle BI, на одном дашборде около 10 графиков и таблиц. Необходимо чтобы страница грузилась за 3 секунды. Hadoop классический не подходит, т.к. batch обработка медленная и вродебы Hadoop не держит больше 10 параллельных запросов.
HBase я тоже сомневаюсь что подойдет.
Так же нужно, чтобы обрабатывал базу в 300 Тб.
Чтобы могли работать одновременно 100 пользователей, в будущем больше.
В частности не realtime нагрузка.
Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Как я понял Cloudera решает только проблему merge данных за счет больших требований к памяти?
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
На сколько я понял Hive это чисто движок преобразующий SQL в MapReduce и он не вмешивается в формат хранения и тем более в распределения данных.
Но вот в Вики говорят, что в Hive есть фича создавать индексы. Значит создает какие-то свои системные данные.
HBase на сколько я понимаю, имеет свой формат хранения. И имеет партиционирование, которое
называется регион. Думаю Flurry тоже имеет, что-то подобное.
Я думаю если еще не создали, то создадут какой ни будь плагинчик для управления распределением данных по нодам.
Отличий встроенного Oracle OLAP от Essbase если честно не знаю. Все используют Essbase обычно
Я всегда думал, что Hive поверх HBase, но вы говорите, что поверх HDFS. Или Hive может быть и поверх HBase?
Как я понял Hive транслирует свой язык sql-like в код MapReduce процедур.
Вообще MapReduce программирование как-то меняется в зависимости от использования HDFS или HBase?
Как я понял в HDFS нет аналогов партиционирования? Например у нас лежит таблица в 1 триллион записей. А нужно прочитать только последний месяц. То Мариться будет весь 1 триллион, уже после редюсится до 1 месяца?
Кто-то собирает Хадуп на большом количестве слабых серверов, кто-то малом количестве мощных. Думаю, если есть редкие или даже частые задачи по соединению таблиц, то лучше использовать малое количество мощных серверов. Чтобы можно было перелить driven-table на один мощный сервак и соединить.
У Оракла проблем с джоином нет, пока хватает памяти, но желательно партиционировать.
У Терадаты проблем тоже в принципе нет, но очень желательно правильно распределить партиции и данные по нодам, иначе начнется очень интенсивный сетевой обмен.
У Хадупа с джоином не очень.
Остается теперь узнать отличие реализации HDFS от HBase на Хадупе. Вы не в курсе?
А в Hadoop что получается? Каждый из 100 нодов хранит по 10 миллионов строк таблицы. Первую таблицу можно оставить как есть, никуда не пересылая данные по сети. Но что делать со второй? Придется на каждый нод тянуть все 1 триллион записей, что соединить.
Я правильно понял?
Я могу сказать, как это делается в Терадате. Допустим есть 2 абсолютно разных запросы. Одно распределение данных для них не подоходит, либо производительность одного будет просидать, либо второго. Делают обычно исходную таблицу распределенную оптимально для запроса 1, и табличный индекс, по сути копия таблицу распределенную оптимально для запроса 2. Как оптимизировать в этом случае Hadoop?
Главное в статье скорость, но и про удобство тоже можно рассказать. Это влияет на стоимость разработки.
Давайте договоримся о конкретике. Рассчитайте стоимость кластера, способного считывать в многопоточном режиме (т.е. винты должны быть серверные с большим числом головок) 25 и 35 Гб/с с дисков. В Hadoop можно узнать сколько и за какой времы каждый нод считал данных с диска?