The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Создан гибрид SQL-Hadoop

23.07.2009 10:00

Не использующие SQL системы обработки данных, такие как Hadoop и MapReduce, могут быть очень дешевыми и прекрасно масштабироваться. Тем не менее, по скорости написания запросов и простоте использования они проигрывают традиционным реляционным базам данных. И вот, ученые из Йельского университета (Yale University), кажется, сумели взять лучшее от обеих концепций: они создали гибридную систему, отличающуюся высокой производительностью и практически неограниченной масштабируемостью.

HadoopDB анонсировал в своем блоге профессор Йельского университета Daniel J. Abadi. Система собрана из нескольких opensource компонентов, включающих PostgreSQL, Apache Hadoop и модуль сортировки Hive. Она принимает запросы, написанные как в формате MapReduce, так и в традиционной SQL форме. Обработка запросов осуществляется частично движком Hadoop, и частично некоторым числом экземпляров PostgreSQL, объединенных в shared-nothing кластер.

Исходные тексты новой системы обработки данных доступны под лицензией APL 2.0. Решение на базе HadoopDB должно понравится сторонникам движения 'NoSQL', ратующим за отказ от использования структурированного языка запросов. Корпоративные потребители, ищущие недорогую масштабируемую альтернативу своим проприетарным решениям на базе Oracle Database, IBM DB2 или MSSQL, могут тоже обратить внимание на этот проект.

  1. Главная ссылка к новости (http://tech.slashdot.org/story...)
Автор новости: blkdog
Тип: К сведению
Ключевые слова: SQL, Hadoop
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, uZver (??), 10:30, 23/07/2009 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    отличный проект. если оно еще линейно масштабируется, то вообще супер.

    Единственно что не понятно, так это почему PostgreSQL (написанный на С или С++), а не Apache Derby (java)

     
     
  • 2.3, deepwalker (??), 11:58, 23/07/2009 [^] [ответить]    [к модератору]
  • +/
    Претензия к языку или к постгре?
     
     
  • 3.6, uZver (??), 14:06, 23/07/2009 [^] [ответить]    [к модератору]
  • +2 +/
    Язык хорош. PostgreSQL - вообще отличная вещь.

    Вопрос: нафига делать сборную солянку java + C особенно если есть возможность обойтись одной java? Зоопарк языков - ИМО не лучшее решение.

     
  • 2.4, vbv (??), 11:59, 23/07/2009 [^] [ответить]     [к модератору]
  • –6 +/
    java - в топку и с ним derby А PostgreSQL - действительно нормальная бд Потрир... весь текст скрыт [показать]
     
  • 1.9, Gambler (ok), 00:34, 24/07/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    SQL поразительно плохо генерируется из кода. На мой взгляд, по одной этой причине надо искать альтернативу. Желательно, попроще.
     
     
  • 2.11, Аноним (-), 10:51, 24/07/2009 [^] [ответить]    [к модератору]  
  • +/
    Вы думаете альтернатива сама, волшебным образом будет решать проблему оптимизации ?
     
  • 2.12, uZver (??), 11:06, 24/07/2009 [^] [ответить]    [к модератору]  
  • +/
    > SQL поразительно плохо генерируется из кода.

    SQL в принципе не должен генерироваться из кода. SQL и есть код. А большинство приложений имеют код на двух языках SQL + java (C#)

     
     
  • 3.13, Gambler (ok), 20:17, 24/07/2009 [^] [ответить]    [к модератору]  
  • +/
    > SQL в принципе не должен генерироваться из кода. SQL и есть код.

    Приложениям надо где-то хранить данные. Индексированные данные, с которыми можно быстро проводить массивные операции. В основном это делается в реляционных базах данных, которые используют SQL.

    Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.

    В любом случае, SQL не рассчитан на компьютерную генерацию, но она все равно имеет место.

     
     
  • 4.14, uZver (??), 11:08, 25/07/2009 [^] [ответить]    [к модератору]  
  • +/
    > Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.

    моя твоя не понимать.

    1. select * from table where name = 'Вася' вернет 10 строк.
    2. select * from table where name = 'Петя' вернет 20 строк (к примеру).

    но по сути это один и тот же параметризованный запрос. и генерации никакой нет.

    вложенные запросы преобразуются оптимизатором в обычный join, если это возможно. Потому для СУБД первой тройки скорость запроса с подзапросом и запроса через join одинакова (хотя есть множество нюансов которые грамотный ДБА должен знать).

    Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос с динамическим фильтром - но как его реализовать без динамического описания запроса (на любом языке не обязательно на SQL) мне не понятно.

     
     
  • 5.15, pro100master (ok), 11:55, 25/07/2009 [^] [ответить]    [к модератору]  
  • +/
    >но по сути это один и тот же параметризованный запрос. и генерации никакой нет.

    а такой (надуманно)?
    select
      a1.a as a1,
      a2.a as a2,
      a3.a as a3,
    ...
      aN.a as aN,
    from xxx x where x.fignja>1
    left join test1 a1 on a1.a=1
    ...
    где N [1..X]

    >Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос
    >с динамическим фильтром - но как его реализовать без динамического описания
    >запроса (на любом языке не обязательно на SQL) мне не понятно.
    >

    люди уже с самого начала реляционных баз курят эту проблему. Они говорят, что идеальный ORM без интеграции самого SQL в язык невозможен. А вынести SQL за пределы кода возможно лишь в единичных и очень примитивных случаях. Так что пока такой язык не появится, каждый будет делать так, как ему удобно, пусть и с костылями.

     
     
  • 6.17, uZver (??), 11:21, 26/07/2009 [^] [ответить]    [к модератору]  
  • +/
    > а такой (надуманно)?

    select
      a1.a as a1,
      a2.a as a2,
      a3.a as a3,
    ...
      aN.a as aN,
    from xxx x where x.fignja>1
    left join test1 a1 on a1.a=1
    ...
    где N [1..X]

    в том то и дело, что надуманно. Как часто ван нужны такие запросы? Мне понадобилось когда писал обработку данных на СУБД. и то потому что ленив и влом было имена столбцов и таблиц переписывать - написал хранимку, а таблицу задавал параметром.

     
  • 5.16, Gambler (ok), 19:09, 25/07/2009 [^] [ответить]    [к модератору]  
  • +/
    > моя твоя не понимать.
    > 1. select * from table where name = 'Вася' вернет 10 строк.
    > 2. select * from table where name = 'Петя' вернет 20 строк (к примеру).

    Покажите мне, пожалуйста, как вы напишете функцию типа selectBy(fildName, fieldValue) без генерации кода.

    >вложенные запросы преобразуются оптимизатором в обычный join

    http://www.selikoff.net/blog/2008/12/10/memo-avoid-nested-queries-in-mysql-at

    > хотя есть множество нюансов которые грамотный ДБА должен знать

    Причем тут DBA? Речь идет про запросы, например, из ORM. Логика определяется вешней программой, и на время написания ORM нельзя знать, что именно будет делать эта программа.

     
     
  • 6.18, uZver (??), 11:26, 26/07/2009 [^] [ответить]    [к модератору]  
  • +/
    >Покажите мне, пожалуйста, как вы напишете функцию типа selectBy(fildName, fieldValue) без генерации
    >кода.

    criteria.add(Expression.eq(fieldName,fieldValue));

    хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы знаете как это реализовать БЕЗ динамического изменения SQL?

    >
    >>вложенные запросы преобразуются оптимизатором в обычный join
    >
    >http://www.selikoff.net/blog/2008/12/10/memo-avoid-nested-queries-in-mysql-at

    я написал что для первой тройки: Oracle, MS SQL server, DB2.

     
     
  • 7.19, Gambler (ok), 20:38, 26/07/2009 [^] [ответить]    [к модератору]  
  • +/
    > хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы
    > знаете как это реализовать БЕЗ динамического изменения SQL?

    А разве я говорил, что надо бороться с динамической генерацией запросов? Наоборот, я говорю, что нужно решение, где динамическая генерация запросов проще, логичней и не создает таких проблем с производительностью.

    > я написал что для первой тройки: Oracle, MS SQL server, DB2.

    Это ж опеннет. Тут первая тройка, пожалуй, должная быть MySQL, PostgreSQL и SQLight. Ну или что-то в этом роде.

     
     
  • 8.20, Аноним (-), 15:22, 27/07/2009 [^] [ответить]     [к модератору]  
  • +/
    А еще нужнее решение где нажал на одну кнопку сделать зашибись и все хорошо Р... весь текст скрыт [показать]
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру
    Hosting by Ihor