Oracle vs Teradata vs Hadoop

Эта статья нацелена на Большие и Очень большие Хранилища Данных, но для ровной картины в классификации немного упомянуты и маленькие.

Статья написана для специалистов, которые ценят главный критерий работы с базами данными — скорость. Речь пойдет о системах, нацеленных на грубый full scan (ораклисты уже напряглись, а терадатовцы радуются).

Давайте рассмотрим, под какой объем данных и работ лучше всего подходит Oracle или Hadoop/NoSQL.

1) На малых объемах выгоднее использовать NoSQL без Hadoop, если вам жалко 900$ на Oracle SE One. Главная его выгода — это цена, базы NoSQL, как правило, бесплатны. Малый объем данных подразумевает небольшую сложность модели и разработки в БД.

2) На средних и больших объемах у Oracle есть большие преимущества перед Teradata и Hadoop. Его главные достоинства:
1. Очень большая зрелость технологии и продукта, число внедрений по сравнению с Hadoop.
3. Очень богатый набор технологий, что существенно облегчает и убыстряет разработку по сравнению со всеми.
3. Подозреваю, что Oracle дешевле в эксплуатации, чем Hadoop, из-за стоимости аренды серверной и электроэнергии.
4. Цена по сравнению с Teradata. Если не покупать Exadata, а собрать свой сервер, думаю, разница в цене не будет огромной по сравнению с Hadoop.

У Oracle хорошая масштабируемость, но есть и узкое место, это подсистема хранения, она одна на все числогрызы. Так что до определенного предела Oracle показывает одну из лучших скорость обработки данных.

Самые быстрые самосборочные массивы хранения, что я видел, обеспечивают 18 Гб/c (хотя, уверен, что есть и больше). Exadata Full Rack обеспечивает за счет кастомных прошивок всего Hardware and Software 25 Гб/c.

Однако часто бывает, что производительности full scan в Оракле не хватает.

Расскажу на примере. В 2007-м году в Билайне в одну таблицу падало 170 млн записей в день, это все звонки по всей России. Анализировать, а выражаясь на сленге базаданщиков, бегать, по такой таблицы нереально, никакой производительности винчестеров не хватит. В таких случаях применяют оптимизацию, создают на основе такой таблицы фактов несколько больших агрегатов по 4 млн записей в день. А на основе этих больших агрегатов создают уже множество более мелких агрегатов под конкретные задачи/отчеты. Такая рода оптимизация может быть сделана и на Oracle, и на Teradata, и на Hadoop.

У данной системы есть 3 недостатка:
1. Если бизнес-пользователям требуется новое поле, которого нет в агрегатах, то процесс разработки, то есть его добавления — очень долгий.
Необходимо протягивать поле через все агрегаты.
2. Не все Ad-hoc отчеты на такой системы возможны. А они потому Ad-hoc, что требуется отчет здесь и сейчас, небольшой и простой, и это либо убытки для компании, либо ответ на вопрос уже устарел и не нужен.
3. Очень сложный ETL.

Вот для решения двух данных недостаток и можно применить Hadoop или Teradata.

3) На сверх больших объемах можно использовать Hadoop.
Плюсов у данной технологии 2:
1. Практически бесконечная линейная масштабируемость. Можно обеспечить 25, 125, 1000 Гигабайт в секунду.
2. Цена, все бесплатно. Кроме железа, конечно.

Недостаток:
1. Создание MapReduce процедур как правило трудоемкое занятие. Так что Ad-hoc запросы не будут так просты, как в SQL.

Я не сравнивал производительность Oracle и Hadoop на одном железе, но, думаю, Hadoop уступит Oracle существенно. Если учитывать только скорость винтов, то Exadata выдает 25Гб/c, обычный офисный диск 7.2К 100 Мб/c, получается, потребуется 250 обычных компьютеров. Обычный компьютер стоит 20 тыс рублей. Потребляет 200 ват. Exadata 7600 Ват. Hadoop, получается, очень невыгоден по электроэнергии, и это еще без учета того, что у Exadata все с двойным резервированием.

4) Сверх большие объемы на Teradata.
Teradata намного лучше справляется с грубым методом работы с данными, таким как full scan. У Teradata идеология shared-nothing и она очень похожа на Hadoop/NoSQL. Данные лежат на множестве серверов, каждый сервер обрабатывает свою часть сам. Но у Teradata есть существенный недостаток — довольно бедный инструментарий. На нем неудобно работать. По сравнению с Oracle не такой зрелый продукт. Цена, полный шкаф Teradata и Exadata Full Rack стоят примерно одинакого, $5 млн.

Так же упомяну общий недостаток Teradata и Hadoop. Это необходимость как-то распределить данные по нодам. Это может быть или натуральные ключ, т.е. бизнес ключ, либо сурогатный. Время тут уже не подойдет, это не партиционирование. Нужно, чтобы будущие данные ложились равномерно по всем нодам. Регион, например, для Билайна, плохой атрибут, Москва занимает 30%. Либо какой-то суррогатный или хэш-ключ.

Преимуществ Teradata в том, что у ней, по сути, тройное партицирование, а у Oracle двойное. При наличии в одной партиции 170 млн строк это оказывается очень полезным, если разбить эти 170 млн еще на 85 подподпартиций по регионам, а на Teradata еще и на 30 нодов, то конечный массив данных можно считать очень быстро.

Предел Teradata:
Teradata за счет технологии shared-nothing и сети BYNET V5 может масштабироваться до 2048 нод, по 76ТБ (10K) на ноду, итого 234PB. А одна стойка Exadata — это всего 672Тб(15К) или 200ТБ(7.2К). Параллелить Exadata не особо выгодно. Дисковое пространство то одно на всех! А если объединить дисковое пространство 2-х стоек (позволяется ли это Exadata — не знаю?), то все упрется в производительность сети 40Гигабит между стойками. Вернее, стойка 1 будет иметь быстрый и широкий доступ к своим винтам, но медленный к винтам стойки 2, и наоборот.

Нужно еще учитывать, что у Teradata и Exadata есть поколоночное, гибридное сжатия. До 4-6 раз сжатие в среднем. Хотя в NoSQL базах оно тоже есть, но возможно не такое эффективное, как в таких монстрах, в разработку которые ушло очень много денег.

Для полноты картины еще стоит упомянуть, что:
У Oracle 2 уровня кэша, оперативная память и SSD Flash Cards.
У Teradata 1 уровень — память, но зато есть ноу-хау — температурное хранилище.
Из-за 2 уровня кэша и отсутствия MPP Exadata намного лучше подходит для OLTP нагрузки.

Вывод: Если у вас нет нерегламентированных запросов, все запросы заранее известны и данных не больше 600ТB, то берите Oracle — очень удобно работать. Если больше, то берите Терадата или Hadoop.
Если у вас данных больше 100Тб и очень много нерегламентированных запросов, берите Teradata или Hadoop.

P.S. Хотел добавить в статью связку Oracle + Lustre, но понял, что она ничего нового Oracle не добавляет, все опять упирается в производительность 40 гигабитной сети.
Share post

Similar posts

Comments 36

    +8
    Я запутался. Все критерии перемешаны (железо, сеть, олап/олтп...), без отрисовки графов отследить логику рассуждений невозможно.
    Раз уж это сравнение, то хорошо бы его структурировать.
      0
      Согласен. Нужно более структурировать статью, но и в таком виде будет полезна, учитывая что автор использует реальные данные и наверное трудно их представить в табличном виде.
        0
        Да, есть такое. Про сеть я начал рассуждать, что бы показать слабость архитектуры Оракл, почему она чисто теоретически не справится с Петабайтами.
          0
          Может сделаете сравнение систем по каждому пункту отдельно? Это может стать хорошей точкой для обсуждения. Тема ведь довольно интересная, а людей которые имеют представление о всех трех хранилищах очень мало.
            0
            Довольно сложно сравнить, да и простое сравнение ничего не даст. Я думаю по этому вы и не найдете в сети заголовка подобного этой теме.

            Опишите критерии по каким сравнивать?
              0
              Возможность и пределы масштабирования (горизонтального), какие характеристики ухудшаются в ходе масштабирования. Сравнение олап и олтп систем в зависимости от объемов данных. Я понимаю, что все специфично в каждом конкретном случае, но хотя бы ключевые моменты, на которые стоит обращать внимание.
                0
                Ок, постараюсь добавить.

                На счет OLTP я просто упомянул одним словом, и не планирую детализировать.
        +4
        Брр, какое-то сумбурное у вас сравнение. К тому же, многие высказывания либо запутаны, либо неверны. Вот, например:
        Так же упомяну общий недостаток Teradata и Hadoop. Это необходимость как-то распределить данные по нодам.

        Не ручаюсь за Teradata, но на Hadoop-е распределением занимается сама файловая система — HDFS. Вручную управлять распределением данных не только бессмысленно, но ещё и крайне вредно.
        Или вот:
        Hadoop, получается, очень невыгоден по электроэнергии, и это еще без учета того, что у Exadata все с двойным резервированием.

        Если речь идёт о резервном копировании, то в Hadoop по умолчанию стоит репликация на три ноды. Мы как-то случайно грохнули половину серверов, при этом потерялось всего 3% данных.

        С Teradata не работал, но если сравнивать Oracle и Hadoop, то я бы сказал, что в первую очередь надо смотреть на задачи. Если данные часто меняются, то Hadoop со свистом пролетает — операция update в большинстве случаев тупо не поддерживается. Если надо параллельно обрабатывать терабайты данных, то Oracle со своим ETL подходом уходит в сторону. Поэтому сравнение производительности на основе скорости дисков не имеет смысла — ну подняли вы 25Гб за секунду, а передавать их по сети на App сервер и обрабатывать то всё ещё нужно. А кластер Hadoop-а сразу работает и как хранилище, и как обработчик (при этом вы сами выбираете конфигурацию по дискам/памяти/процессорам). И по той же причине при оценке электроэнергии нужно рассматривать сразу всю систему, а не только хранилище данных.
          0
          Брр, какое-то сумбурное у вас сравнение. К тому же, многие высказывания либо запутаны, либо неверны. Вот, например:
          Так же упомяну общий недостаток 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-а сразу работает и как хранилище, и как обработчик
          Так же и Терадата, у них нет разделения на числогрыз и хранилку.

          >И по той же причине при оценке электроэнергии нужно рассматривать сразу всю систем
          Ок, жду от вас статьи об этом =)
            +1
            Смысл в том, что бы минимизировать сетевой трафик. Если 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Гб/с на сервер(а) приложений, где из них сделают что-нибудь полезное и засунут обратно в базу.

            >И по той же причине при оценке электроэнергии нужно рассматривать сразу всю систем
            Ок, жду от вас статьи об этом =)

            Вы мне предлагаете так же поговорить про абстрактную систему в вакууме с неизвестными задачами и посчитать для неё затраты электроэнергии? :) Ну уж нет, спасибо.
              0
              Нужно узнать, как Hadoop распределяет данные по нодам. Я уверен, что есть способ на это повлиять. Возможно это температурное распределение, т.е. данные двигаются, если Хадуп понял, что мало Data-local map tasks?
              Я могу сказать, как это делается в Терадате. Допустим есть 2 абсолютно разных запросы. Одно распределение данных для них не подоходит, либо производительность одного будет просидать, либо второго. Делают обычно исходную таблицу распределенную оптимально для запроса 1, и табличный индекс, по сути копия таблицу распределенную оптимально для запроса 2. Как оптимизировать в этом случае Hadoop?

              Так всё-таки речь о скорости или об удобстве?

              Главное в статье скорость, но и про удобство тоже можно рассказать. Это влияет на стоимость разработки.

              Вы мне предлагаете так же поговорить про абстрактную систему в вакууме с неизвестными задачами и посчитать для неё затраты электроэнергии? :) Ну уж нет, спасибо

              Давайте договоримся о конкретике. Рассчитайте стоимость кластера, способного считывать в многопоточном режиме (т.е. винты должны быть серверные с большим числом головок) 25 и 35 Гб/с с дисков. В Hadoop можно узнать сколько и за какой времы каждый нод считал данных с диска?
                0
                Нужно узнать, как 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 Гб/с с дисков.

                Ну вот опять вы за старое. С данными вы собираетесь что-нибудь делать, или просто хотите с диска их прочитать и забыть? Если всё-таки сделать, то берите в расчёт скорость передачи по сети и скорость обработки, а также стоимость железа и энергопотребление сервера приложений. А без списка задач, объёма данных, средств разработки и индивидуальных цен, предложенных вендорами этот разговор очень далёк от конкретики.
                  0
                  А что делать, если данные связанные и в запросе нужно соединить 2 таблицы, например, каждая по 1 триллиону записей. В Терадате я бы их распределил по ключу соединения и еще партиционировал бы по ключу. Тогда Терадата бы все поняла, и положила только связанные партиции на каждый нод. Тогда при запросе данные бы вычислались только внутри каждой ноды. Каждая нода бы знала, что все данные есть локально.
                  А в Hadoop что получается? Каждый из 100 нодов хранит по 10 миллионов строк таблицы. Первую таблицу можно оставить как есть, никуда не пересылая данные по сети. Но что делать со второй? Придется на каждый нод тянуть все 1 триллион записей, что соединить.
                  Я правильно понял?
                    0
                    Правильным подходом в этом случае будет держать обе таблицы в виде одной денормализованной. join на Хадупе — это вообще тяжёлая операция, и не столько из-за размещения данных, сколько из-за общей ориентации на последовательную обработку пакетных данных, в то время как join-like операции опираются на произвольный доступ к отдельным записям. По факту, в задачах, специфичных для Hadoop, объединенние таблиц (особенно двух больших) встречается очень редко. А для неспецифичных для Хадупа задач его использовать и не надо :) Как я и сказал в самом начале, нужно смотреть на задачу.
                      0
                      Спасибо за информацию! Теперь можно расставить градацию.
                      У Оракла проблем с джоином нет, пока хватает памяти, но желательно партиционировать.
                      У Терадаты проблем тоже в принципе нет, но очень желательно правильно распределить партиции и данные по нодам, иначе начнется очень интенсивный сетевой обмен.
                      У Хадупа с джоином не очень.

                      Остается теперь узнать отличие реализации HDFS от HBase на Хадупе. Вы не в курсе?
                        0
                        Я тут подумал.
                        Кто-то собирает Хадуп на большом количестве слабых серверов, кто-то малом количестве мощных. Думаю, если есть редкие или даже частые задачи по соединению таблиц, то лучше использовать малое количество мощных серверов. Чтобы можно было перелить driven-table на один мощный сервак и соединить.
                          0
                          Остается теперь узнать отличие реализации HDFS от HBase на Хадупе. Вы не в курсе?

                          Это неправильный вопрос. HDFS — это основа основ, главная фича Hadoop-а. Поверх неё можно запускать несколько «баз данных» с более или менее привычным/удобным интерфейсом, в частности Hive и HBase. Hive — попытка реализовать SQL поверх HDFS. Hive работает с пакетными данными, поэтому хорошо подходит для всякой аналитики, отчётов и пр. HBase, с другой стороны, ориентирована на работу в реальном времени. Она поддерживает быстрое чтение (и даже изменение) отдельных записей, но это не делает её полноценной RDBMS — модель данных совсем другая. В итоге, все три — Hive, HBase и классические RDBMS — используются для разных целей, и сравнивать их на одних задачах всё равно что сравнивать по силе кита и слона.

                          Кто-то собирает Хадуп на большом количестве слабых серверов, кто-то малом количестве мощных. Думаю, если есть редкие или даже частые задачи по соединению таблиц, то лучше использовать малое количество мощных серверов.

                          В этом случае лучше использовать Vertica или Oracle, или что вам больше по душе. У Хадупа есть вполне конкретная модель работы, и пытаться её переделывать — всё равно, что пытаться забивать гвозди сапогом: что-нибудь да получится, но потом ноги на каждом шагу болеть будут. При малом количестве мощных серверов увеличивается вероятность неравномерного распределения блоков для какой-то конкретной задачи, соответсвенно, ухудшается распараллеливание. Падение одного мощного сервера гораздо тяжелее для системы в целом, чем падение нескольких более слабых, но в разное время. Да и вообще, практически ни один инструмент из экосистемы Hadoop не заточен под работу на нескольких мощных серверах, а рассчитывает именно на большой кластер commodity hardware.
                            0
                            Я пока еще не до конца понял возможности и ограничения Хадупа.

                            Я всегда думал, что Hive поверх HBase, но вы говорите, что поверх HDFS. Или Hive может быть и поверх HBase?
                            Как я понял Hive транслирует свой язык sql-like в код MapReduce процедур.
                            Вообще MapReduce программирование как-то меняется в зависимости от использования HDFS или HBase?

                            Как я понял в HDFS нет аналогов партиционирования? Например у нас лежит таблица в 1 триллион записей. А нужно прочитать только последний месяц. То Мариться будет весь 1 триллион, уже после редюсится до 1 месяца?
                              0
                              Я всегда думал, что 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
                              ...
                              


                              Если вам нужно обработать только последний месяц, то сканироваться будут только файлы, лежащие в соответсвующих директориях.
                                0
                                Спасибо!

                                На сколько я понял Hive это чисто движок преобразующий SQL в MapReduce и он не вмешивается в формат хранения и тем более в распределения данных.
                                Но вот в Вики говорят, что в Hive есть фича создавать индексы. Значит создает какие-то свои системные данные.

                                HBase на сколько я понимаю, имеет свой формат хранения. И имеет партиционирование, которое
                                называется регион. Думаю Flurry тоже имеет, что-то подобное.

                                Я думаю если еще не создали, то создадут какой ни будь плагинчик для управления распределением данных по нодам.
                                  0
                                  На сколько я понял Hive это чисто движок преобразующий SQL в MapReduce и он не вмешивается в формат хранения и тем более в распределения данных.

                                  Представьте себе обычную односерверную СУБД. У неё есть SQL парсер, оптимизатор и интерпретатор/транслятор в нативные команды. У неё также есть информация о таблицах, колонках, индексах, путях к данным на файловой системе и т.д. Эта СУБД взаимодействует с файловой системой через API и мало на что может повлиять на низком уровне. Эксплуатировать какие-нибудь особенности системы может, но диктовать ей, где разместить очередной файл вряд ли будет.
                                  Hive — такая же «обычная» СУБД, только вместо локальной файловой системы у него HDFS, а вместо нативных комманд — MapReduce. Есть определённые особенности, связанные с распределённостью, но в целом идеи одни и те же.

                                  Я думаю если еще не создали, то создадут какой ни будь плагинчик для управления распределением данных по нодам.

                                  Вы упускаете суть. Как только вы начинаете управлять размещением блоков, вы теряете все преимущества HDFS. Если очень хочется, то лучше сразу отказываться от распределённой файловой системой и хэндлить всё вручную, но failover, репликацию и прочие радости распределённых хранилищ вам придётся делать самому.
                                  Преимущество гомогенного размещения а-ля HDFS ещё и в том, что кластер очень легко расширяется новыми машинами. Если партиционировать по ключу, то перепатиционирование сразу превращается в ад.
                0
                Расскажу на примере фейла DB2:
                Смысл в том, что каждая из 1000 нод обрабатывает только свои данные, тем самым минимизируется сетевой трафик. А если данные для обработки нужно пересылать он нода к ноду, как например в DB2, то это плохо. Поэтому DB2 и загнулась на больших данных.

                А можно поподробнее, про какую конфигурацию кластера DB2 идет речь? Database Partitioning Feature или pureScale? Про «загнулась» тоже интересны подробности.
              0
              Добавили бы в сравнение еще Vertica,Yota например внедрила у себя и вроде все хорошо. На предыдущей работе, дба долго выбирал из нескольких систем включая терадату, остановились на вертике все же.
                0
                В будущем сделаю) Еще есть Greenplum, в Тинькове вроде внедрили или вот вот внедрят.
                  +1
                  Ну и Hana тогда уже обозрите SAP'овскую, раз пошло такое дело)
                    0
                    Я подброшу ещё одно интересное решение с похожими задачами — SAP (Sybase) IQ.
                0
                >> Создание MapReduce процедур как правило трудоемкое занятие.
                можно решить при помощи таких инструментов как BigQuery
                см white paper
                  0
                  В этом надо разбираться, попробую на досуге. Хотя в Хадупе есть Хайв, чем он хуже BigQuery?
                    0
                    я не знаю, что такое hive, но вот на so пишут, что его (hive) должны переработать под dremel архитектуру stackoverflow.com/questions/6607552/what-is-googles-dremel-how-is-it-different-from-mapreduce
                      0
                      Ответ датирован 2011-м годом ;) Hive 0.13 работает на Apache Tez, что вроде как даёт ускорение в 50-100 раз и позволяет делать нормальные интерактивные запросы.
                        0
                        прикольно! у меня подозрение, что 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 немного отстают
                          0
                          Я вас прошу :) Каждый разработчик всегда пиарит свою разработку. Если вы смотрите презентацию от Cloudera, то самой быстрой будет Impala, если от Hortonworks — то, очевидно, Hive on Tez и т.д.

                          Также надо понимать, что MapReduce — это и название идеи, и название двух фреймворков — от Google и от Hadoop. Сама идея MR очень мощная: всё, что можно распараллелить, сделать параллельно, а потом собрать результаты и сделать то, что не параллелится. Добавьте пару примитивов таких как mapPartition (применить функцию ко всем данным на одной машине, аналогично методу combine в классическом MR) и получится вообще отличный вычислительный аппарат. Медленными могут быть имплементации этого аппарата. Например, классический MapReduce в Hadoop жутко тормозной из-за того, что на каждом шагу сбрасывает данные на диск. Но другие реализации могут этого и не делать, и, соответсвенно, выполнять длинные пайплайны гораздо быстрее.
                  0
                  А Вы про какой сорт оракла размышляли? про
                  Oracle DB
                  Oracle DB + olap options
                  Oracle (Hyperion) Essbase?
                  Все они по разному работают…
                    0
                    Статья про Oracle DB.

                    Отличий встроенного Oracle OLAP от Essbase если честно не знаю. Все используют Essbase обычно
                    0
                    Параллелить Exadata не особо выгодно. Дисковое пространство то одно на всех! А если объединить дисковое пространство 2-х стоек (позволяется ли это Exadata — не знаю?), то все упрется в производительность сети 40Гигабит между стойками. Вернее, стойка 1 будет иметь быстрый и широкий доступ к своим винтам, но медленный к винтам стойки 2, и наоборот.

                    Во-первых, есть такая штука как Exadata storage expansion.
                    Во-вторых, Оракл вполне разумно параллелит запросы, поэтому не будет передавать все с сервера на сервер при параллельном запросе таком как count(*) from big_table. Будут переданы только готовые агрегаты от каждого parallel slave. Вообще оптимизатор Оракла — это отдельная песня: до сих пор иногда удивляюсь когда гляжу на то, что понапишут разрабы и как прекрасно оракл с этим справляется.
                    Кроме того вы не учитываете, что в Exadata и SuperCluster сторадж селлы «умные».
                    И вы нарочно не используете в сравнении возможности Oracle 12.1.0.2?
                      0
                      Во-первых, есть такая штука как 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 могли повлиять на выводы моей статьи?

                    Only users with full accounts can post comments. Log in, please.