The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Создан гибрид 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-...
Новость: http://www.opennet.me/opennews/art.shtml?num=22696

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

 Оглавление

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


1. "Создан гибрид SQL-Hadoop"  +/
Сообщение от uZver (??) on 23-Июл-09, 10:30 
отличный проект. если оно еще линейно масштабируется, то вообще супер.

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

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

3. "Создан гибрид SQL-Hadoop"  +/
Сообщение от deepwalker email(??) 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ообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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