Comments 36
Я запутался. Все критерии перемешаны (железо, сеть, олап/олтп...), без отрисовки графов отследить логику рассуждений невозможно.
Раз уж это сравнение, то хорошо бы его структурировать.
Раз уж это сравнение, то хорошо бы его структурировать.
Согласен. Нужно более структурировать статью, но и в таком виде будет полезна, учитывая что автор использует реальные данные и наверное трудно их представить в табличном виде.
Да, есть такое. Про сеть я начал рассуждать, что бы показать слабость архитектуры Оракл, почему она чисто теоретически не справится с Петабайтами.
Может сделаете сравнение систем по каждому пункту отдельно? Это может стать хорошей точкой для обсуждения. Тема ведь довольно интересная, а людей которые имеют представление о всех трех хранилищах очень мало.
Довольно сложно сравнить, да и простое сравнение ничего не даст. Я думаю по этому вы и не найдете в сети заголовка подобного этой теме.
Опишите критерии по каким сравнивать?
Опишите критерии по каким сравнивать?
Брр, какое-то сумбурное у вас сравнение. К тому же, многие высказывания либо запутаны, либо неверны. Вот, например:
Не ручаюсь за Teradata, но на Hadoop-е распределением занимается сама файловая система — HDFS. Вручную управлять распределением данных не только бессмысленно, но ещё и крайне вредно.
Или вот:
Если речь идёт о резервном копировании, то в Hadoop по умолчанию стоит репликация на три ноды. Мы как-то случайно грохнули половину серверов, при этом потерялось всего 3% данных.
С Teradata не работал, но если сравнивать Oracle и Hadoop, то я бы сказал, что в первую очередь надо смотреть на задачи. Если данные часто меняются, то Hadoop со свистом пролетает — операция update в большинстве случаев тупо не поддерживается. Если надо параллельно обрабатывать терабайты данных, то Oracle со своим ETL подходом уходит в сторону. Поэтому сравнение производительности на основе скорости дисков не имеет смысла — ну подняли вы 25Гб за секунду, а передавать их по сети на App сервер и обрабатывать то всё ещё нужно. А кластер Hadoop-а сразу работает и как хранилище, и как обработчик (при этом вы сами выбираете конфигурацию по дискам/памяти/процессорам). И по той же причине при оценке электроэнергии нужно рассматривать сразу всю систему, а не только хранилище данных.
Так же упомяну общий недостаток Teradata и Hadoop. Это необходимость как-то распределить данные по нодам.
Не ручаюсь за Teradata, но на Hadoop-е распределением занимается сама файловая система — HDFS. Вручную управлять распределением данных не только бессмысленно, но ещё и крайне вредно.
Или вот:
Hadoop, получается, очень невыгоден по электроэнергии, и это еще без учета того, что у Exadata все с двойным резервированием.
Если речь идёт о резервном копировании, то в Hadoop по умолчанию стоит репликация на три ноды. Мы как-то случайно грохнули половину серверов, при этом потерялось всего 3% данных.
С Teradata не работал, но если сравнивать Oracle и Hadoop, то я бы сказал, что в первую очередь надо смотреть на задачи. Если данные часто меняются, то Hadoop со свистом пролетает — операция update в большинстве случаев тупо не поддерживается. Если надо параллельно обрабатывать терабайты данных, то Oracle со своим ETL подходом уходит в сторону. Поэтому сравнение производительности на основе скорости дисков не имеет смысла — ну подняли вы 25Гб за секунду, а передавать их по сети на App сервер и обрабатывать то всё ещё нужно. А кластер Hadoop-а сразу работает и как хранилище, и как обработчик (при этом вы сами выбираете конфигурацию по дискам/памяти/процессорам). И по той же причине при оценке электроэнергии нужно рассматривать сразу всю систему, а не только хранилище данных.
Брр, какое-то сумбурное у вас сравнение. К тому же, многие высказывания либо запутаны, либо неверны. Вот, например:
Так же упомяну общий недостаток Teradata и Hadoop. Это необходимость как-то распределить данные по нодам.
Все сложнее. В Терадата только ручное распределение, и это правильно. Если неправильно распределить, то вы проиграете Ораклу. Это и есть недостаток Терадаты, что требуется думать о том, о чем не нужно думать в Оракле в принципе.
На счет HDFS вы правы, там нельзя распределять данные по нодам, и это плохо или я не совсем понимаю модель MapReduce.
Расскажу на примере фейла DB2:
Смысл в том, что каждая из 1000 нод обрабатывает только свои данные, тем самым минимизируется сетевой трафик. А если данные для обработки нужно пересылать он нода к ноду, как например в DB2, то это плохо. Поэтому DB2 и загнулась на больших данных.
Смысл в том, что бы минимизировать сетевой трафик. Если Hadoop, сам правильно умеет распределять данные, а потом с помощью MapReduce распараллелить все так, что бы каждый нод обрабатывал только свои локальный данные, то я прислоняюсь перед Hadoop. Но я сомневаюсь, что он сможет так сделать. Если уж Терадата и Оракл и DB2 не смогли.
Я думаю если использовать не HDFS, а HBase, то там можно по ключу, например региону распределить данные или еще как и использовать это в MapReduce.
>Если надо параллельно обрабатывать терабайты данных, то Oracle со своим ETL подходом уходит в сторону
Hadoop будет быстрее за счет отсутствия ACID, а в Оракле есть Undo and Redo logs. Которые существенно замедляют работу, но позволяют не беспокоиться о то, что данные могут и читать и изменяться параллельно 10 процессов. Оракл — это удобство!
>ну подняли вы 25Гб за секунду
Это не скорость чтения с винта, это скорость обработки данных согласно пресрелизу Оракла. Получается count(*) по таблице в 100 Гб должна занимать 4 секунды. Но я лично не проверял.
>А кластер Hadoop-а сразу работает и как хранилище, и как обработчик
Так же и Терадата, у них нет разделения на числогрыз и хранилку.
>И по той же причине при оценке электроэнергии нужно рассматривать сразу всю систем
Ок, жду от вас статьи об этом =)
Смысл в том, что бы минимизировать сетевой трафик. Если Hadoop, сам правильно умеет распределять данные, а потом с помощью MapReduce распараллелить все так, что бы каждый нод обрабатывал только свои локальный данные, то я прислоняюсь перед Hadoop. Но я сомневаюсь, что он сможет так сделать. Если уж Терадата и Оракл и DB2 не смогли.
Сейчас для интереса посмотрел выполнение трёх случайных задач на JobTracker, получил такую статистику:
Launched map tasks: 50, 49, 46
Launched reduce tasks: 9, 1, 15
Data-local map tasks: 41, 42, 37
Rack-local map tasks: 9, 7, 9
Т.е. больше 80% map-тасков выполнились локально, остальные — внутри одной стойки. MR-задания были сформированы Hive-ом, поэтому есть подозрение, что часть нелокальных map-ов связана с параллельной записью результатов на диск — обычно локальность даже выше. В целом, репликация каждого блока на 3 ноды и большое количество процессоров на каждой машине позволяет почти избежать передачи данных по сети при параллельной обработке. Oracle, DB2, etc., как я уже говорил, делались для других задач, и сравнивать что смогли и не смогли сделать в разных системах нет смысла.
Hadoop будет быстрее за счет отсутствия ACID, а в Оракле есть Undo and Redo logs. Которые существенно замедляют работу, но позволяют не беспокоиться о то, что данные могут и читать и изменяться параллельно 10 процессов. Оракл — это удобство!
Так всё-таки речь о скорости или об удобстве?
Это не скорость чтения с винта, это скорость обработки данных согласно пресрелизу Оракла. Получается count(*) по таблице в 100 Гб должна занимать 4 секунды. Но я лично не проверял.
Вы данные для чего храните? Для того, чтобы count по ним гонять? Если мы говорим про всеми любимый BigData, то это в первую очередь логи событий, аналитические данные. Часть аналитики можно сделать через PL/SQL — тогда, если оптимизатор Оракла окажется достаточно умным, а запросы не слишком сложными — база данных сможет сохранить значительную часть локальности, и всё отработает быстро. В остальных случаях вам придётся передавать ваши 25Гб/с на сервер(а) приложений, где из них сделают что-нибудь полезное и засунут обратно в базу.
>И по той же причине при оценке электроэнергии нужно рассматривать сразу всю систем
Ок, жду от вас статьи об этом =)
Вы мне предлагаете так же поговорить про абстрактную систему в вакууме с неизвестными задачами и посчитать для неё затраты электроэнергии? :) Ну уж нет, спасибо.
Нужно узнать, как Hadoop распределяет данные по нодам. Я уверен, что есть способ на это повлиять. Возможно это температурное распределение, т.е. данные двигаются, если Хадуп понял, что мало Data-local map tasks?
Я могу сказать, как это делается в Терадате. Допустим есть 2 абсолютно разных запросы. Одно распределение данных для них не подоходит, либо производительность одного будет просидать, либо второго. Делают обычно исходную таблицу распределенную оптимально для запроса 1, и табличный индекс, по сути копия таблицу распределенную оптимально для запроса 2. Как оптимизировать в этом случае Hadoop?
Главное в статье скорость, но и про удобство тоже можно рассказать. Это влияет на стоимость разработки.
Давайте договоримся о конкретике. Рассчитайте стоимость кластера, способного считывать в многопоточном режиме (т.е. винты должны быть серверные с большим числом головок) 25 и 35 Гб/с с дисков. В Hadoop можно узнать сколько и за какой времы каждый нод считал данных с диска?
Я могу сказать, как это делается в Терадате. Допустим есть 2 абсолютно разных запросы. Одно распределение данных для них не подоходит, либо производительность одного будет просидать, либо второго. Делают обычно исходную таблицу распределенную оптимально для запроса 1, и табличный индекс, по сути копия таблицу распределенную оптимально для запроса 2. Как оптимизировать в этом случае Hadoop?
Так всё-таки речь о скорости или об удобстве?
Главное в статье скорость, но и про удобство тоже можно рассказать. Это влияет на стоимость разработки.
Вы мне предлагаете так же поговорить про абстрактную систему в вакууме с неизвестными задачами и посчитать для неё затраты электроэнергии? :) Ну уж нет, спасибо
Давайте договоримся о конкретике. Рассчитайте стоимость кластера, способного считывать в многопоточном режиме (т.е. винты должны быть серверные с большим числом головок) 25 и 35 Гб/с с дисков. В Hadoop можно узнать сколько и за какой времы каждый нод считал данных с диска?
Нужно узнать, как Hadoop распределяет данные по нодам. Я уверен, что есть способ на это повлиять. Возможно это температурное распределение, т.е. данные двигаются, если Хадуп понял, что мало Data-local map tasks?
При стандартной репликации на 3 ноды одна реплика считается главной (в неё первую пишут), вторая размещается в той же стойке, третья копируется в другую стойку на случай падения первой. Узнать, где находятся блоки, можно — HDFS API предоставляет эту возможность как MapReduce, так и любым другим сервисам. Повлиять на размещение не переписывая аллокатор нельзя.
Я могу сказать, как это делается в Терадате. Допустим есть 2 абсолютно разных запросы. Одно распределение данных для них не подоходит, либо производительность одного будет просидать, либо второго. Делают обычно исходную таблицу распределенную оптимально для запроса 1, и табличный индекс, по сути копия таблицу распределенную оптимально для запроса 2. Как оптимизировать в этом случае Hadoop?
Давайте я вам расскажу, как работает HDFS. HDFS в целом похожа на любую другую файловую систему, только больше. Вместо файловой таблицы там целый сервер — т.н. Namenode, а блоки, в которых хранится информация, занимают ни много ни мало 64Мб. Размещаются эти блоки на так называемых DataNode-ах (один DataNode на одну машину) и реплицируются 3 раза так, как я описал выше. Все эти параметры можно кастомизировать, но суть не в этом.
Рядом с DataNode-ами ставятся вычислительные узлы. Для обычного MapReduce — это TaskTrackers, для Impala или Spark — это соответсвующие воркеры. И где-нибудь ставится главный управляющий узел, назовём его мастером. Мастер знает, сколько и где у него есть вычислительных ресурсов (свободных ядер и памяти), а также умеет узнавать у HDFS расположение блоков данных и их реплик.
Теперь представьте, что пользователь захотел посчитать, сколько строк в большом файле. Для этого нужно посчитать строки в каждом блоке и сложить результаты. Вторая часть тривиальна, первая может быть сделана независимо для каждого блока. Мастер собирает список блоков и их реплик и начинает смотреть, есть ли у него свободные ядра на нодах с нужными блоками. Есть ядро — вычисляем, нет — смотрим на реплику этого блока. Данные будут передаваться по сети только если ни для одной реплики не нашлось свободного локального ядра.
Вопрос: как повлияет ручное размещение блоков по машинам? Да никак. HDFS гомогенна, равно как и вычислительные ресурсы. Блоки любого файла равномерно распределены по машинам, и каждая машина имеет примерно одинаковое количество слотов для вычислений.
Для более сложных вычислений схема сложнее, и эффективная организация вычислений — более сложная задача. Но физическое размещение данных на производительность мало влияет.
Главное в статье скорость, но и про удобство тоже можно рассказать. Это влияет на стоимость разработки.
Если удобство, то опять же: для какой задачи. Вы снова и снова пытаетесь подмять под одну гребёнку всё подряд. Если я работаю с логом событий, то мне и даром не сдались Undo и Redo — данные у меня всё равно не меняются.
Давайте договоримся о конкретике. Рассчитайте стоимость кластера, способного считывать в многопоточном режиме (т.е. винты должны быть серверные с большим числом головок) 25 и 35 Гб/с с дисков.
Ну вот опять вы за старое. С данными вы собираетесь что-нибудь делать, или просто хотите с диска их прочитать и забыть? Если всё-таки сделать, то берите в расчёт скорость передачи по сети и скорость обработки, а также стоимость железа и энергопотребление сервера приложений. А без списка задач, объёма данных, средств разработки и индивидуальных цен, предложенных вендорами этот разговор очень далёк от конкретики.
А что делать, если данные связанные и в запросе нужно соединить 2 таблицы, например, каждая по 1 триллиону записей. В Терадате я бы их распределил по ключу соединения и еще партиционировал бы по ключу. Тогда Терадата бы все поняла, и положила только связанные партиции на каждый нод. Тогда при запросе данные бы вычислались только внутри каждой ноды. Каждая нода бы знала, что все данные есть локально.
А в Hadoop что получается? Каждый из 100 нодов хранит по 10 миллионов строк таблицы. Первую таблицу можно оставить как есть, никуда не пересылая данные по сети. Но что делать со второй? Придется на каждый нод тянуть все 1 триллион записей, что соединить.
Я правильно понял?
А в Hadoop что получается? Каждый из 100 нодов хранит по 10 миллионов строк таблицы. Первую таблицу можно оставить как есть, никуда не пересылая данные по сети. Но что делать со второй? Придется на каждый нод тянуть все 1 триллион записей, что соединить.
Я правильно понял?
Правильным подходом в этом случае будет держать обе таблицы в виде одной денормализованной. join на Хадупе — это вообще тяжёлая операция, и не столько из-за размещения данных, сколько из-за общей ориентации на последовательную обработку пакетных данных, в то время как join-like операции опираются на произвольный доступ к отдельным записям. По факту, в задачах, специфичных для Hadoop, объединенние таблиц (особенно двух больших) встречается очень редко. А для неспецифичных для Хадупа задач его использовать и не надо :) Как я и сказал в самом начале, нужно смотреть на задачу.
Спасибо за информацию! Теперь можно расставить градацию.
У Оракла проблем с джоином нет, пока хватает памяти, но желательно партиционировать.
У Терадаты проблем тоже в принципе нет, но очень желательно правильно распределить партиции и данные по нодам, иначе начнется очень интенсивный сетевой обмен.
У Хадупа с джоином не очень.
Остается теперь узнать отличие реализации HDFS от HBase на Хадупе. Вы не в курсе?
У Оракла проблем с джоином нет, пока хватает памяти, но желательно партиционировать.
У Терадаты проблем тоже в принципе нет, но очень желательно правильно распределить партиции и данные по нодам, иначе начнется очень интенсивный сетевой обмен.
У Хадупа с джоином не очень.
Остается теперь узнать отличие реализации HDFS от HBase на Хадупе. Вы не в курсе?
Я тут подумал.
Кто-то собирает Хадуп на большом количестве слабых серверов, кто-то малом количестве мощных. Думаю, если есть редкие или даже частые задачи по соединению таблиц, то лучше использовать малое количество мощных серверов. Чтобы можно было перелить driven-table на один мощный сервак и соединить.
Кто-то собирает Хадуп на большом количестве слабых серверов, кто-то малом количестве мощных. Думаю, если есть редкие или даже частые задачи по соединению таблиц, то лучше использовать малое количество мощных серверов. Чтобы можно было перелить driven-table на один мощный сервак и соединить.
Остается теперь узнать отличие реализации HDFS от HBase на Хадупе. Вы не в курсе?
Это неправильный вопрос. HDFS — это основа основ, главная фича Hadoop-а. Поверх неё можно запускать несколько «баз данных» с более или менее привычным/удобным интерфейсом, в частности Hive и HBase. Hive — попытка реализовать SQL поверх HDFS. Hive работает с пакетными данными, поэтому хорошо подходит для всякой аналитики, отчётов и пр. HBase, с другой стороны, ориентирована на работу в реальном времени. Она поддерживает быстрое чтение (и даже изменение) отдельных записей, но это не делает её полноценной RDBMS — модель данных совсем другая. В итоге, все три — Hive, HBase и классические RDBMS — используются для разных целей, и сравнивать их на одних задачах всё равно что сравнивать по силе кита и слона.
Кто-то собирает Хадуп на большом количестве слабых серверов, кто-то малом количестве мощных. Думаю, если есть редкие или даже частые задачи по соединению таблиц, то лучше использовать малое количество мощных серверов.
В этом случае лучше использовать Vertica или Oracle, или что вам больше по душе. У Хадупа есть вполне конкретная модель работы, и пытаться её переделывать — всё равно, что пытаться забивать гвозди сапогом: что-нибудь да получится, но потом ноги на каждом шагу болеть будут. При малом количестве мощных серверов увеличивается вероятность неравномерного распределения блоков для какой-то конкретной задачи, соответсвенно, ухудшается распараллеливание. Падение одного мощного сервера гораздо тяжелее для системы в целом, чем падение нескольких более слабых, но в разное время. Да и вообще, практически ни один инструмент из экосистемы Hadoop не заточен под работу на нескольких мощных серверах, а рассчитывает именно на большой кластер commodity hardware.
Я пока еще не до конца понял возможности и ограничения Хадупа.
Я всегда думал, что Hive поверх HBase, но вы говорите, что поверх HDFS. Или Hive может быть и поверх HBase?
Как я понял Hive транслирует свой язык sql-like в код MapReduce процедур.
Вообще MapReduce программирование как-то меняется в зависимости от использования HDFS или HBase?
Как я понял в HDFS нет аналогов партиционирования? Например у нас лежит таблица в 1 триллион записей. А нужно прочитать только последний месяц. То Мариться будет весь 1 триллион, уже после редюсится до 1 месяца?
Я всегда думал, что Hive поверх HBase, но вы говорите, что поверх HDFS. Или Hive может быть и поверх HBase?
Как я понял Hive транслирует свой язык sql-like в код MapReduce процедур.
Вообще MapReduce программирование как-то меняется в зависимости от использования HDFS или HBase?
Как я понял в HDFS нет аналогов партиционирования? Например у нас лежит таблица в 1 триллион записей. А нужно прочитать только последний месяц. То Мариться будет весь 1 триллион, уже после редюсится до 1 месяца?
Я всегда думал, что Hive поверх HBase, но вы говорите, что поверх HDFS. Или Hive может быть и поверх HBase?
Изначально было так: Hadoop = HDFS + MapReduce. HDFS — файловая система, MapReduce — инструмент для эффективного использования этой файловой системы. Hive, HBase, Pig, Oozie, Flume, Impala, Mahout и т.д. — все были построены поверх HDFS (даже если сейчас могут работать и без неё). Делать Hive поверх HBase — это всё равно что делать MongoDB поверх MySQL — технически можно, но это уже чёрный пояс по извращениям.
Как я понял в HDFS нет аналогов партиционирования? Например у нас лежит таблица в 1 триллион записей. А нужно прочитать только последний месяц. То Мариться будет весь 1 триллион, уже после редюсится до 1 месяца?
Партиционирование — это фича базы данных, а не файловой системы. И Hive, и Impala, и, вероятно, другие SQL-движки поддерживают концепцию партиционирования. Обычно это реализуется просто через директории на диске. Например, если у вас данные за два года, а вы работаете только с последними, то можно создать партиции по полю dt, которые на диске будут храниться как-то так:
/data/mytable/dt=2014-01-01/actualdata.dat
/data/mytable/dt=2014-01-02/actualdata.dat
/data/mytable/dt=2014-01-03/actualdata.dat
...
Если вам нужно обработать только последний месяц, то сканироваться будут только файлы, лежащие в соответсвующих директориях.
Спасибо!
На сколько я понял Hive это чисто движок преобразующий SQL в MapReduce и он не вмешивается в формат хранения и тем более в распределения данных.
Но вот в Вики говорят, что в Hive есть фича создавать индексы. Значит создает какие-то свои системные данные.
HBase на сколько я понимаю, имеет свой формат хранения. И имеет партиционирование, которое
называется регион. Думаю Flurry тоже имеет, что-то подобное.
Я думаю если еще не создали, то создадут какой ни будь плагинчик для управления распределением данных по нодам.
На сколько я понял Hive это чисто движок преобразующий SQL в MapReduce и он не вмешивается в формат хранения и тем более в распределения данных.
Но вот в Вики говорят, что в Hive есть фича создавать индексы. Значит создает какие-то свои системные данные.
HBase на сколько я понимаю, имеет свой формат хранения. И имеет партиционирование, которое
называется регион. Думаю Flurry тоже имеет, что-то подобное.
Я думаю если еще не создали, то создадут какой ни будь плагинчик для управления распределением данных по нодам.
На сколько я понял Hive это чисто движок преобразующий SQL в MapReduce и он не вмешивается в формат хранения и тем более в распределения данных.
Представьте себе обычную односерверную СУБД. У неё есть SQL парсер, оптимизатор и интерпретатор/транслятор в нативные команды. У неё также есть информация о таблицах, колонках, индексах, путях к данным на файловой системе и т.д. Эта СУБД взаимодействует с файловой системой через API и мало на что может повлиять на низком уровне. Эксплуатировать какие-нибудь особенности системы может, но диктовать ей, где разместить очередной файл вряд ли будет.
Hive — такая же «обычная» СУБД, только вместо локальной файловой системы у него HDFS, а вместо нативных комманд — MapReduce. Есть определённые особенности, связанные с распределённостью, но в целом идеи одни и те же.
Я думаю если еще не создали, то создадут какой ни будь плагинчик для управления распределением данных по нодам.
Вы упускаете суть. Как только вы начинаете управлять размещением блоков, вы теряете все преимущества HDFS. Если очень хочется, то лучше сразу отказываться от распределённой файловой системой и хэндлить всё вручную, но failover, репликацию и прочие радости распределённых хранилищ вам придётся делать самому.
Преимущество гомогенного размещения а-ля HDFS ещё и в том, что кластер очень легко расширяется новыми машинами. Если партиционировать по ключу, то перепатиционирование сразу превращается в ад.
Расскажу на примере фейла DB2:
Смысл в том, что каждая из 1000 нод обрабатывает только свои данные, тем самым минимизируется сетевой трафик. А если данные для обработки нужно пересылать он нода к ноду, как например в DB2, то это плохо. Поэтому DB2 и загнулась на больших данных.
А можно поподробнее, про какую конфигурацию кластера DB2 идет речь? Database Partitioning Feature или pureScale? Про «загнулась» тоже интересны подробности.
Добавили бы в сравнение еще Vertica,Yota например внедрила у себя и вроде все хорошо. На предыдущей работе, дба долго выбирал из нескольких систем включая терадату, остановились на вертике все же.
В будущем сделаю) Еще есть Greenplum, в Тинькове вроде внедрили или вот вот внедрят.
Ну и Hana тогда уже обозрите SAP'овскую, раз пошло такое дело)
Я подброшу ещё одно интересное решение с похожими задачами — SAP (Sybase) IQ.
>> Создание MapReduce процедур как правило трудоемкое занятие.
можно решить при помощи таких инструментов как BigQuery
см white paper
можно решить при помощи таких инструментов как BigQuery
см white paper
В этом надо разбираться, попробую на досуге. Хотя в Хадупе есть Хайв, чем он хуже BigQuery?
я не знаю, что такое hive, но вот на so пишут, что его (hive) должны переработать под dremel архитектуру stackoverflow.com/questions/6607552/what-is-googles-dremel-how-is-it-different-from-mapreduce
Ответ датирован 2011-м годом ;) Hive 0.13 работает на Apache Tez, что вроде как даёт ускорение в 50-100 раз и позволяет делать нормальные интерактивные запросы.
прикольно! у меня подозрение, что big query все равно быстрее (т.к. он не основан на MR), но сил проверять нет =(
если я правильно понимаю, OS аналог dremel это drill: www.quora.com/Dremel/What-are-usage-scenarios-for-Apache-Drill
опять же если я правильно понял вот эту презентацию www.slideshare.net/HiveData/apache-drilltalk-thehive
то drill по скорости наравне с impala, а hive+tez немного отстают
если я правильно понимаю, OS аналог dremel это drill: www.quora.com/Dremel/What-are-usage-scenarios-for-Apache-Drill
опять же если я правильно понял вот эту презентацию www.slideshare.net/HiveData/apache-drilltalk-thehive
то drill по скорости наравне с impala, а hive+tez немного отстают
Я вас прошу :) Каждый разработчик всегда пиарит свою разработку. Если вы смотрите презентацию от Cloudera, то самой быстрой будет Impala, если от Hortonworks — то, очевидно, Hive on Tez и т.д.
Также надо понимать, что MapReduce — это и название идеи, и название двух фреймворков — от Google и от Hadoop. Сама идея MR очень мощная: всё, что можно распараллелить, сделать параллельно, а потом собрать результаты и сделать то, что не параллелится. Добавьте пару примитивов таких как mapPartition (применить функцию ко всем данным на одной машине, аналогично методу combine в классическом MR) и получится вообще отличный вычислительный аппарат. Медленными могут быть имплементации этого аппарата. Например, классический MapReduce в Hadoop жутко тормозной из-за того, что на каждом шагу сбрасывает данные на диск. Но другие реализации могут этого и не делать, и, соответсвенно, выполнять длинные пайплайны гораздо быстрее.
Также надо понимать, что MapReduce — это и название идеи, и название двух фреймворков — от Google и от Hadoop. Сама идея MR очень мощная: всё, что можно распараллелить, сделать параллельно, а потом собрать результаты и сделать то, что не параллелится. Добавьте пару примитивов таких как mapPartition (применить функцию ко всем данным на одной машине, аналогично методу combine в классическом MR) и получится вообще отличный вычислительный аппарат. Медленными могут быть имплементации этого аппарата. Например, классический MapReduce в Hadoop жутко тормозной из-за того, что на каждом шагу сбрасывает данные на диск. Но другие реализации могут этого и не делать, и, соответсвенно, выполнять длинные пайплайны гораздо быстрее.
А Вы про какой сорт оракла размышляли? про
Oracle DB
Oracle DB + olap options
Oracle (Hyperion) Essbase?
Все они по разному работают…
Oracle DB
Oracle DB + olap options
Oracle (Hyperion) Essbase?
Все они по разному работают…
Параллелить Exadata не особо выгодно. Дисковое пространство то одно на всех! А если объединить дисковое пространство 2-х стоек (позволяется ли это Exadata — не знаю?), то все упрется в производительность сети 40Гигабит между стойками. Вернее, стойка 1 будет иметь быстрый и широкий доступ к своим винтам, но медленный к винтам стойки 2, и наоборот.
Во-первых, есть такая штука как Exadata storage expansion.
Во-вторых, Оракл вполне разумно параллелит запросы, поэтому не будет передавать все с сервера на сервер при параллельном запросе таком как count(*) from big_table. Будут переданы только готовые агрегаты от каждого parallel slave. Вообще оптимизатор Оракла — это отдельная песня: до сих пор иногда удивляюсь когда гляжу на то, что понапишут разрабы и как прекрасно оракл с этим справляется.
Кроме того вы не учитываете, что в Exadata и SuperCluster сторадж селлы «умные».
И вы нарочно не используете в сравнении возможности Oracle 12.1.0.2?
Во-первых, есть такая штука как 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 могли повлиять на выводы моей статьи?
Sign up to leave a comment.
Oracle vs Teradata vs Hadoop