Знаком, хотя лично не работал. В кратце - это open-source реализация гугловских алгоритмов MapAndReduce и BidTable. Сверху написаны технологии HBase, Lucene, Hype, Pig и т.д. По отзывам довольно громоздкая система, применимая только в случае обработки больших файлов с большой скоростью и выявления в них паттернов. Обычно ее используют компании, занимающие поисками в интернете и каталогизацией и обработкой найденного.
Для простой Non-SQL базы данных я бы использовал Cassandra или ЖЖ-шный open-source Memcached.
Спасибо. Посмотрю. Нам надо попытаться использовать существующие технологии для балансировки и распределения довольно многочисленных работ по распознаванию речи. Так сказать, оптимизировать этот процесс в туче (или как это по-русски будет?).
Выбор технологии будет зависеть от объема данных для каждой задачи (например, если нужно хранить большие документы, то лучше MongoDb/CouchDB, а если маленькие key/value, то Cassandra), от языка программирования (вы же не хотите все переписывать), от того, что вам нужно делать быстро (Cassandra быстрее работает для writes, Hadoop/Hbase для reads), от того, нужна ли вам статистическая обработка (Hadoop и Cassandra могут работать с Lucene) и еще кучи параметров. В интеренете много статей по этому поводу. Но тренд сейчас в сторону Cassandra/MongoDb и подобное, а не Hadoop.
Да, нормально. Главное, отделить мух от котлет. Котлеты - это мапредьюс и бигтейбл; мухи - это мучительные api и проблемы инсталляции. Их надо демонстративно игнорировать.
Кстати, если есть выбор, то советую монго. Мапредьюс тоже делает, а внутри вместо неонки джаваскрипт. Обожаю!
ну, рулез то оно рулез, но с hadoop сравнение странное. Потому как hadoop это distributed filesystem, а mongodb - document-oriented database. В огороде бузина, а в Киеве дядька. Хотя да, Map-reduce присутствует и там и там.
Это general-purpose distributed filesystem. Нынче очень модно на него чего-нить сверху нацепить, hbase какой-нить, а потом удивляться "ой, так это-ж Cassandra получилась!" Стоит ли оно того и нужно ли под него строиться очень зависит от конкретной задачи. Огород пропалывать, например, неудобно.
Задача -- распределять большое количество jobs между компутерами в оптимизированном виде. Конкретнее -- работ по распознаванию речи. Вот приходит много запросов, а их надо быстро и грамотно разбросать по серверам, желательно при этом -- минимизируя необходимость перезагрузки языковых моделей.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
branchandroot
no subject
Date: 2011-04-26 12:32 am (UTC)Для простой Non-SQL базы данных я бы использовал Cassandra или ЖЖ-шный open-source Memcached.
no subject
Date: 2011-04-26 01:09 pm (UTC)no subject
Date: 2011-04-26 01:36 pm (UTC)Для большинства вещей Cassandra более перепективная и легкая технология. Посмотри у них на странице, какие компани используют ее для своего cloud.
no subject
Date: 2011-04-26 02:01 pm (UTC)no subject
Date: 2011-04-26 02:09 pm (UTC)Выбор технологии будет зависеть от объема данных для каждой задачи (например, если нужно хранить большие документы, то лучше MongoDb/CouchDB, а если маленькие key/value, то Cassandra), от языка программирования (вы же не хотите все переписывать), от того, что вам нужно делать быстро (Cassandra быстрее работает для writes, Hadoop/Hbase для reads), от того, нужна ли вам статистическая обработка (Hadoop и Cassandra могут работать с Lucene) и еще кучи параметров. В интеренете много статей по этому поводу. Но тренд сейчас в сторону Cassandra/MongoDb и подобное, а не Hadoop.
no subject
Date: 2011-04-26 01:37 pm (UTC)no subject
Date: 2011-04-26 02:34 am (UTC)Кстати, если есть выбор, то советую монго. Мапредьюс тоже делает, а внутри вместо неонки джаваскрипт. Обожаю!
no subject
Date: 2011-04-26 01:10 pm (UTC)no subject
Date: 2011-04-26 11:07 pm (UTC)no subject
Date: 2011-04-28 06:04 am (UTC)no subject
Date: 2011-04-28 11:59 am (UTC)cool:)
Date: 2011-04-27 02:12 am (UTC)no subject
Date: 2011-04-28 06:07 am (UTC)Стоит ли оно того и нужно ли под него строиться очень зависит от конкретной задачи. Огород пропалывать, например, неудобно.
no subject
Date: 2011-04-28 12:05 pm (UTC)no subject
Date: 2011-05-10 10:18 pm (UTC)