forum.opennet.ru - "Создан гибрид SQL-Hadoop" (15)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

Форумы Разговоры, обсуждение новостей (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Создан гибрид SQL-Hadoop"		+/–
Сообщение от opennews (??) on 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-... Новость: https://www.opennet.ru/opennews/art.shtml?num=22696
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Создан гибрид SQL-Hadoop, uZver, 10:30 , 23-Июл-09, (1)

Создан гибрид SQL-Hadoop, deepwalker, 11:58 , 23-Июл-09, (3)

Создан гибрид SQL-Hadoop, uZver, 14:06 , 23-Июл-09, (6) +2

Создан гибрид SQL-Hadoop, vbv, 11:59 , 23-Июл-09, (4) –6

Создан гибрид SQL-Hadoop, Gambler, 00:34 , 24-Июл-09, (9) +1

Создан гибрид SQL-Hadoop, Аноним, 10:51 , 24-Июл-09, (11)
Создан гибрид SQL-Hadoop, uZver, 11:06 , 24-Июл-09, (12)

Создан гибрид SQL-Hadoop, Gambler, 20:17 , 24-Июл-09, (13)

Создан гибрид SQL-Hadoop, uZver, 11:08 , 25-Июл-09, (14)

Создан гибрид SQL-Hadoop, pro100master, 11:55 , 25-Июл-09, (15)

Создан гибрид SQL-Hadoop, uZver, 11:21 , 26-Июл-09, (17)

Создан гибрид SQL-Hadoop, Gambler, 19:09 , 25-Июл-09, (16)

Создан гибрид SQL-Hadoop, uZver, 11:26 , 26-Июл-09, (18)

Создан гибрид SQL-Hadoop, Gambler, 20:38 , 26-Июл-09, (19)

Создан гибрид SQL-Hadoop, Аноним, 15:22 , 27-Июл-09, (20)

Сообщения по теме [Сортировка по времени | RSS]

1. "Создан гибрид SQL-Hadoop" +/–

Сообщение от uZver (??) on 23-Июл-09, 10:30

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Создан гибрид SQL-Hadoop" +/–

Сообщение от deepwalker (??) on 23-Июл-09, 11:58

Претензия к языку или к постгре?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Создан гибрид SQL-Hadoop" +2 +/–

Сообщение от uZver (??) on 23-Июл-09, 14:06

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Создан гибрид SQL-Hadoop" –6 +/–

Сообщение от vbv (??) on 23-Июл-09, 11:59

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Создан гибрид SQL-Hadoop" +1 +/–

Сообщение от Gambler (ok) on 24-Июл-09, 00:34

SQL поразительно плохо генерируется из кода. На мой взгляд, по одной этой причине надо искать альтернативу. Желательно, попроще.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Создан гибрид SQL-Hadoop" +/–

Сообщение от Аноним (??) on 24-Июл-09, 10:51

Вы думаете альтернатива сама, волшебным образом будет решать проблему оптимизации ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Создан гибрид SQL-Hadoop" +/–

Сообщение от uZver (??) on 24-Июл-09, 11:06

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Создан гибрид SQL-Hadoop" +/–

Сообщение от Gambler (ok) on 24-Июл-09, 20:17

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Создан гибрид SQL-Hadoop" +/–

Сообщение от uZver (??) on 25-Июл-09, 11:08

> Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.
моя твоя не понимать.
1. select * from table where name = 'Вася' вернет 10 строк.
2. select * from table where name = 'Петя' вернет 20 строк (к примеру).
но по сути это один и тот же параметризованный запрос. и генерации никакой нет.
вложенные запросы преобразуются оптимизатором в обычный join, если это возможно. Потому для СУБД первой тройки скорость запроса с подзапросом и запроса через join одинакова (хотя есть множество нюансов которые грамотный ДБА должен знать).
Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос с динамическим фильтром - но как его реализовать без динамического описания запроса (на любом языке не обязательно на SQL) мне не понятно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Создан гибрид SQL-Hadoop" +/–

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Создан гибрид SQL-Hadoop" +/–

Сообщение от uZver (??) on 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]
в том то и дело, что надуманно. Как часто ван нужны такие запросы? Мне понадобилось когда писал обработку данных на СУБД. и то потому что ленив и влом было имена столбцов и таблиц переписывать - написал хранимку, а таблицу задавал параметром.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Создан гибрид SQL-Hadoop" +/–

Сообщение от Gambler (ok) on 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 нельзя знать, что именно будет делать эта программа.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Создан гибрид SQL-Hadoop" +/–

Сообщение от uZver (??) on 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.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Создан гибрид SQL-Hadoop" +/–

Сообщение от Gambler (ok) on 26-Июл-09, 20:38

> хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы
> знаете как это реализовать БЕЗ динамического изменения SQL?
А разве я говорил, что надо бороться с динамической генерацией запросов? Наоборот, я говорю, что нужно решение, где динамическая генерация запросов проще, логичней и не создает таких проблем с производительностью.
> я написал что для первой тройки: Oracle, MS SQL server, DB2.
Это ж опеннет. Тут первая тройка, пожалуй, должная быть MySQL, PostgreSQL и SQLight. Ну или что-то в этом роде.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Создан гибрид SQL-Hadoop" +/–

Сообщение от Аноним (??) on 27-Июл-09, 15:22

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Создан гибрид SQL-Hadoop"		+/–
Сообщение от uZver (??) on 23-Июл-09, 10:30
отличный проект. если оно еще линейно масштабируется, то вообще супер. Единственно что не понятно, так это почему PostgreSQL (написанный на С или С++), а не Apache Derby (java)
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от deepwalker (??) on 23-Июл-09, 11:58
	Претензия к языку или к постгре?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Создан гибрид SQL-Hadoop"		+2 +/–
	Сообщение от uZver (??) on 23-Июл-09, 14:06
	Язык хорош. PostgreSQL - вообще отличная вещь. Вопрос: нафига делать сборную солянку java + C особенно если есть возможность обойтись одной java? Зоопарк языков - ИМО не лучшее решение.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Создан гибрид SQL-Hadoop"		–6 +/–
	Сообщение от vbv (??) on 23-Июл-09, 11:59
	java - в топку и с ним derby. А PostgreSQL - действительно нормальная бд. Потрируется и на форточки и на маки. Производительность С кода во много выше java. Относительно темы: Идея хороша, и данные решения имеют смысл только для узкого круга задач, т.к. на данный момент, как не крути, SQL - есть стандарт (который не везде соблюдается но тем не менее - работает). Полного перехода на новую систему можно не ждать. А вот исполнения сервером запросов поданных ему в скомпилированной форме возможно было бы интересно. т.е. 1. Делаем SQL запрос. 2. Просим СУБД вернуть компилированную форму - которую уже используем в проекте. Хотя, даже, ценность этого подхода вызывает сомнения, т.к. порядочные системы управления базами данных успешно кешируют запросы.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

9. "Создан гибрид SQL-Hadoop"		+1 +/–
Сообщение от Gambler (ok) on 24-Июл-09, 00:34
SQL поразительно плохо генерируется из кода. На мой взгляд, по одной этой причине надо искать альтернативу. Желательно, попроще.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от Аноним (??) on 24-Июл-09, 10:51
	Вы думаете альтернатива сама, волшебным образом будет решать проблему оптимизации ?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от uZver (??) on 24-Июл-09, 11:06
	> SQL поразительно плохо генерируется из кода. SQL в принципе не должен генерироваться из кода. SQL и есть код. А большинство приложений имеют код на двух языках SQL + java (C#)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от Gambler (ok) on 24-Июл-09, 20:17
	> SQL в принципе не должен генерироваться из кода. SQL и есть код. Приложениям надо где-то хранить данные. Индексированные данные, с которыми можно быстро проводить массивные операции. В основном это делается в реляционных базах данных, которые используют SQL. Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью. В любом случае, SQL не рассчитан на компьютерную генерацию, но она все равно имеет место.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от uZver (??) on 25-Июл-09, 11:08
	> Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью. моя твоя не понимать. 1. select * from table where name = 'Вася' вернет 10 строк. 2. select * from table where name = 'Петя' вернет 20 строк (к примеру). но по сути это один и тот же параметризованный запрос. и генерации никакой нет. вложенные запросы преобразуются оптимизатором в обычный join, если это возможно. Потому для СУБД первой тройки скорость запроса с подзапросом и запроса через join одинакова (хотя есть множество нюансов которые грамотный ДБА должен знать). Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос с динамическим фильтром - но как его реализовать без динамического описания запроса (на любом языке не обязательно на SQL) мне не понятно.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от pro100master (ok) on 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 за пределы кода возможно лишь в единичных и очень примитивных случаях. Так что пока такой язык не появится, каждый будет делать так, как ему удобно, пусть и с костылями.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от uZver (??) on 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] в том то и дело, что надуманно. Как часто ван нужны такие запросы? Мне понадобилось когда писал обработку данных на СУБД. и то потому что ленив и влом было имена столбцов и таблиц переписывать - написал хранимку, а таблицу задавал параметром.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от Gambler (ok) on 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 нельзя знать, что именно будет делать эта программа.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от uZver (??) on 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.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Создан гибрид SQL-Hadoop"		+/–
	Сообщение от Gambler (ok) on 26-Июл-09, 20:38
	> хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы > знаете как это реализовать БЕЗ динамического изменения SQL? А разве я говорил, что надо бороться с динамической генерацией запросов? Наоборот, я говорю, что нужно решение, где динамическая генерация запросов проще, логичней и не создает таких проблем с производительностью. > я написал что для первой тройки: Oracle, MS SQL server, DB2. Это ж опеннет. Тут первая тройка, пожалуй, должная быть MySQL, PostgreSQL и SQLight. Ну или что-то в этом роде.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


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