| |
| 2.9, ra (??), 05:37, 13/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Они купят себе какую-нибудь контору и делов-то. Девелоперов потом почикают, названием сменят - все как обычно.
| | |
|
| 1.6, uZver (??), 22:40, 12/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
SQoop - утопия. Не получится заменить SQL-БД на распределенные. максимум это применение для некритичных данных - типа обработка веба и постороение поискового индекса.
| | |
| |
| 2.7, Щекн Итрч (ok), 23:54, 12/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>SQoop - утопия. Не получится заменить SQL-БД на распределенные. максимум это применение
>для некритичных данных - типа обработка веба и постороение поискового индекса.
>
Получится :)
"типа обработка веба" - "некритичные" данные??? :)
А вебморда к петабайтному OLAPу - тоже "некритична" в таком случае? Вместе с базой?
| | |
| |
| 3.8, uZver (??), 01:23, 13/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>SQoop - утопия. Не получится заменить SQL-БД на распределенные. максимум это применение
>>для некритичных данных - типа обработка веба и постороение поискового индекса.
>>
>
>Получится :)
В общем тут ты прав :)
>"типа обработка веба" - "некритичные" данные??? :)
Зависит от задач. Google поисковик не критичен к потере (не учете) одной страницы в индексе. А бух. учет и управление складом - критичны. Наверное правильнее сказать, что есть задачи которые можно решить без транзакций. И те которые нет. OLAP - можно сделать на Hadoop, а городить поверх MapReduce OLTP - это сразу диагноз.
>А вебморда к петабайтному OLAPу - тоже "некритична" в таком случае? Вместе
>с базой?
OLAP не критичен к транзакциям. Чаще всего OLAP вообще через ETL делают - какие нафиг транзакции. А вот OLTP смогут нормально работать поверх SQL.
Утопия в том, что Hadoop нужен только пока hardware не позволяет реализовать эту обработку на РСУБД. Раньше 1Gb было много для СУБД. А сейчас легко до 10-20Gb одной оперативы + огромные винты - можно намного бОльшие задачи решить на СУБД. В итоге по мере технического прогресса РСУБД будут вытеснять другие подходы ввиду простоты и универсальности.
PS будут оставаться микро-области где применяются специальные системы хранения и обработки, но РСУБД как были на уровне охвата 90% задач так и останутся. Может даже отъедят еще 5% от Массово-параллельных систем (топа Hadoop)
| | |
| |
| 4.11, Щекн Итрч (ok), 00:03, 14/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>>SQoop - утопия. Не получится заменить SQL-БД на распределенные. максимум это применение
>>>для некритичных данных - типа обработка веба и постороение поискового индекса.
>>>
>>
>>Получится :)
>
>В общем тут ты прав :)
Ну, а критики мапредуса правы, конечно же, в том, что стоимость его развертывания втрое превышает стоимость всего их бизнеса, обеих почек на продажу и бабушкиной квартиры :)
И вместо того, чтобы этот факт признать и подчеркнуть - "утопией" обзываются!
Пойду, гляну в словаре, что это за слово такое, "утопия"... Явно что-то нехорошее... :)
| | |
| 4.12, pro100master (ok), 10:37, 14/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Зависит от задач. Google поисковик не критичен к потере (не учете) одной страницы в индексе
особенно, если это страница майкрософт дот ком при запросе майкрософт уиндовс :)))
Google как раз заботится о своих данных.
| | |
| |
| 5.13, uZver (??), 11:35, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Зависит от задач. Google поисковик не критичен к потере (не учете) одной страницы в индексе
> особенно, если это страница майкрософт дот ком при запросе майкрософт уиндовс :)))
Google как раз заботится о своих данных.
проблема не в "заботе о данных", а в транзакционной консистентности. Как этого добиться на основе MapReduce?
| | |
| |
| 6.14, Аноним (-), 11:43, 15/06/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
да вы хоть читали что такое MapReduce, чтобы о транзакционной целостности говорить?! MapReduce - это всего лишь способ обработки данных, при котором обаботка происходит в два этапа - разбитие данных на пары ключ/значение и их агрегация. Способ хранения никак не оговаривается. Просто в Yahoo для хранения используют файловую систему HDFS и базу HBase, которая поверх этой фс работает. Все три компонента и составляют дистрибутив Hadoop. Так вот в HBase есть поддержка транзакций, но не по стандарту SQL, как мы к этому привыкли. А целостность достигается за счет использования HDFS с избытоной репликацией.
| | |
| |
| 7.15, uZver (??), 13:43, 16/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>да вы хоть читали что такое MapReduce, чтобы о транзакционной целостности говорить?!
Да, читал и даже тестировал :)
>MapReduce - это всего лишь способ обработки данных, при котором обаботка
>происходит в два этапа - разбитие данных на пары ключ/значение и
>их агрегация.
В принципе да, только делать MR поверх одной СУБД - потеря скорости, даже по отношению к хранимкам. Преимущество MR достигается на параллельной работе с ЛОКАЛЬНЫМ (для каждого нода) данными.
> Способ хранения никак не оговаривается.
Да, но без HDFS или другой распределенной ФС MR будет медленнее PL/SQL.
> Просто в Yahoo для
>хранения используют файловую систему HDFS и базу HBase, которая поверх этой
>фс работает. Все три компонента и составляют дистрибутив Hadoop. Так вот
>в HBase есть поддержка транзакций, но не по стандарту SQL, как
>мы к этому привыкли.
А по какому стандарту идет поддержка транзакций в HBase? Сколько я не читал ни разу не видел записи о том, что HBase имеет поддержку транзакций.
Специально зашел к гуглу - у них тоже ни разу не значится Big Table как транзакционная система. Только fault-tolerance.
> А целостность достигается за счет использования HDFS
>с избытоной репликацией.
Тут опять ошибка. HDFS обеспечивает файловую целостность. А мне нужна целостность данных, т.е. целостность между данными внутри файла(ов). К примеру это гарантия что внешний ключ ВСЕГДА указывает на существующую запись. И т.п. репликация HDFS никаким образом не спасет от нарушения логической целостности внутри файла данных.
| | |
|
|
|
|
|
|
|
