URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 57142
[ Назад ]

Исходное сообщение
"Создан гибрид SQL-Hadoop"

Отправлено opennews , 23-Июл-09 10:30 
Не использующие SQL системы обработки данных, такие как Hadoop и MapReduce, могут быть очень дешевыми и прекрасно масштабироваться. Тем не менее, по скорости написания запросов и простоте использования они проигрывают традиционным реляционным базам данных. И вот, ученые из Йельского университета (Yale University), кажется, сумели взять лучшее от обеих концепций: они создали (http://news.idg.no/cw/art.cfm?id=9D2C109A-1A64-6A71-CE90BD44...) гибридную систему, отличающуюся высокой производительностью и практически неограниченной масштабируемостью.

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

URL: http://tech.slashdot.org/story/09/07/21/1747241/Researchers-...
Новость: http://www.opennet.me/opennews/art.shtml?num=22696


Содержание

Сообщения в этом обсуждении
"Создан гибрид SQL-Hadoop"
Отправлено uZver , 23-Июл-09 10:30 
отличный проект. если оно еще линейно масштабируется, то вообще супер.

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


"Создан гибрид SQL-Hadoop"
Отправлено deepwalker , 23-Июл-09 11:58 
Претензия к языку или к постгре?

"Создан гибрид SQL-Hadoop"
Отправлено uZver , 23-Июл-09 14:06 
Язык хорош. PostgreSQL - вообще отличная вещь.

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


"Создан гибрид SQL-Hadoop"
Отправлено vbv , 23-Июл-09 11:59 
java - в топку и с ним derby.
А PostgreSQL - действительно нормальная бд. Потрируется и на форточки и на маки.
Производительность С кода во много выше java.

Относительно темы: Идея хороша, и данные решения имеют смысл только для узкого круга задач, т.к. на данный момент, как не крути, SQL - есть стандарт (который не везде соблюдается но тем не менее - работает). Полного перехода на новую систему можно не ждать. А вот исполнения сервером запросов поданных ему в скомпилированной форме возможно было бы интересно. т.е. 1. Делаем SQL запрос. 2. Просим СУБД вернуть компилированную форму - которую уже используем в проекте. Хотя, даже, ценность этого подхода вызывает сомнения, т.к. порядочные системы управления базами данных успешно кешируют запросы.


"Создан гибрид SQL-Hadoop"
Отправлено Gambler , 24-Июл-09 00:34 
SQL поразительно плохо генерируется из кода. На мой взгляд, по одной этой причине надо искать альтернативу. Желательно, попроще.

"Создан гибрид SQL-Hadoop"
Отправлено Аноним , 24-Июл-09 10:51 
Вы думаете альтернатива сама, волшебным образом будет решать проблему оптимизации ?

"Создан гибрид SQL-Hadoop"
Отправлено uZver , 24-Июл-09 11:06 
> SQL поразительно плохо генерируется из кода.

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


"Создан гибрид SQL-Hadoop"
Отправлено Gambler , 24-Июл-09 20:17 
> SQL в принципе не должен генерироваться из кода. SQL и есть код.

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

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

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


"Создан гибрид SQL-Hadoop"
Отправлено uZver , 25-Июл-09 11:08 
> Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.

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

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

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

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

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


"Создан гибрид SQL-Hadoop"
Отправлено pro100master , 25-Июл-09 11:55 
>но по сути это один и тот же параметризованный запрос. и генерации никакой нет.

а такой (надуманно)?
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 за пределы кода возможно лишь в единичных и очень примитивных случаях. Так что пока такой язык не появится, каждый будет делать так, как ему удобно, пусть и с костылями.


"Создан гибрид SQL-Hadoop"
Отправлено uZver , 26-Июл-09 11:21 
> а такой (надуманно)?

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-Hadoop"
Отправлено Gambler , 25-Июл-09 19:09 
> моя твоя не понимать.
> 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-qu.../

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

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


"Создан гибрид SQL-Hadoop"
Отправлено uZver , 26-Июл-09 11:26 
>Покажите мне, пожалуйста, как вы напишете функцию типа selectBy(fildName, fieldValue) без генерации
>кода.

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

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

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

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


"Создан гибрид SQL-Hadoop"
Отправлено Gambler , 26-Июл-09 20:38 
> хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы
> знаете как это реализовать БЕЗ динамического изменения SQL?

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

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

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


"Создан гибрид SQL-Hadoop"
Отправлено Аноним , 27-Июл-09 15:22 
А еще нужнее решение где нажал на одну кнопку "сделать зашибись" и все хорошо. Реально то вы что предлагаете ? За счет чего может стать проще но при этом не тормознутее ? Дело не в том что SQL плох, а в том что ООП для него уж больно неконкретен, на устранение этой неконкретности силы и уходят. Будет менее конкретное средство, будет может и проще, но менее оптимально, будет более конкретное - соответственно наоборот. Ничего в результате не меняется, разве что просто для того чтобы поиметь альтернативу, кому что ближе тот то пользовать и будет.