Не использующие 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.ru/opennews/art.shtml?num=22696
отличный проект. если оно еще линейно масштабируется, то вообще супер.Единственно что не понятно, так это почему PostgreSQL (написанный на С или С++), а не Apache Derby (java)
Претензия к языку или к постгре?
Язык хорош. PostgreSQL - вообще отличная вещь.Вопрос: нафига делать сборную солянку java + C особенно если есть возможность обойтись одной java? Зоопарк языков - ИМО не лучшее решение.
java - в топку и с ним derby.
А PostgreSQL - действительно нормальная бд. Потрируется и на форточки и на маки.
Производительность С кода во много выше java.Относительно темы: Идея хороша, и данные решения имеют смысл только для узкого круга задач, т.к. на данный момент, как не крути, SQL - есть стандарт (который не везде соблюдается но тем не менее - работает). Полного перехода на новую систему можно не ждать. А вот исполнения сервером запросов поданных ему в скомпилированной форме возможно было бы интересно. т.е. 1. Делаем SQL запрос. 2. Просим СУБД вернуть компилированную форму - которую уже используем в проекте. Хотя, даже, ценность этого подхода вызывает сомнения, т.к. порядочные системы управления базами данных успешно кешируют запросы.
SQL поразительно плохо генерируется из кода. На мой взгляд, по одной этой причине надо искать альтернативу. Желательно, попроще.
Вы думаете альтернатива сама, волшебным образом будет решать проблему оптимизации ?
> SQL поразительно плохо генерируется из кода.SQL в принципе не должен генерироваться из кода. SQL и есть код. А большинство приложений имеют код на двух языках SQL + java (C#)
> SQL в принципе не должен генерироваться из кода. SQL и есть код.Приложениям надо где-то хранить данные. Индексированные данные, с которыми можно быстро проводить массивные операции. В основном это делается в реляционных базах данных, которые используют SQL.
Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.
В любом случае, SQL не рассчитан на компьютерную генерацию, но она все равно имеет место.
> Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.моя твоя не понимать.
1. select * from table where name = 'Вася' вернет 10 строк.
2. select * from table where name = 'Петя' вернет 20 строк (к примеру).но по сути это один и тот же параметризованный запрос. и генерации никакой нет.
вложенные запросы преобразуются оптимизатором в обычный join, если это возможно. Потому для СУБД первой тройки скорость запроса с подзапросом и запроса через join одинакова (хотя есть множество нюансов которые грамотный ДБА должен знать).
Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос с динамическим фильтром - но как его реализовать без динамического описания запроса (на любом языке не обязательно на SQL) мне не понятно.
>но по сути это один и тот же параметризованный запрос. и генерации никакой нет.а такой (надуманно)?
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 за пределы кода возможно лишь в единичных и очень примитивных случаях. Так что пока такой язык не появится, каждый будет делать так, как ему удобно, пусть и с костылями.
> а такой (надуманно)?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]в том то и дело, что надуманно. Как часто ван нужны такие запросы? Мне понадобилось когда писал обработку данных на СУБД. и то потому что ленив и влом было имена столбцов и таблиц переписывать - написал хранимку, а таблицу задавал параметром.
> моя твоя не понимать.
> 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 нельзя знать, что именно будет делать эта программа.
>Покажите мне, пожалуйста, как вы напишете функцию типа 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 динамически. так вопрос - вы
> знаете как это реализовать БЕЗ динамического изменения SQL?А разве я говорил, что надо бороться с динамической генерацией запросов? Наоборот, я говорю, что нужно решение, где динамическая генерация запросов проще, логичней и не создает таких проблем с производительностью.
> я написал что для первой тройки: Oracle, MS SQL server, DB2.
Это ж опеннет. Тут первая тройка, пожалуй, должная быть MySQL, PostgreSQL и SQLight. Ну или что-то в этом роде.
А еще нужнее решение где нажал на одну кнопку "сделать зашибись" и все хорошо. Реально то вы что предлагаете ? За счет чего может стать проще но при этом не тормознутее ? Дело не в том что SQL плох, а в том что ООП для него уж больно неконкретен, на устранение этой неконкретности силы и уходят. Будет менее конкретное средство, будет может и проще, но менее оптимально, будет более конкретное - соответственно наоборот. Ничего в результате не меняется, разве что просто для того чтобы поиметь альтернативу, кому что ближе тот то пользовать и будет.