Да, эта версия определенно годна для продакшна (конечно, ждем 1.6.1). Монго прекрасна, начинаю копаться в джаваскрипт-эмуляторе мап-редьюс, ибо это самое узкое место в данный момент.

Боженька, зачем ты сделал модным эти документ-ориентированные СУБД? Я же страдаю, разве ты не видишь? Ладно, если их уничтожить уже нельзя, то пожалуйста, лиши возможности модниц принимать решение об их использовании!

А есть альтернативы ?

Оно уже стало поддерживать базу данных более 2,5 ГБ на 32-х битах?

PS. У нас есть и CouchDB в продакшене. Шардинг и мэп-редьюс там давно.

Там, где я вынужден использовать Cassandra наиболее логичным решением была бы РСУБД.

это научилось уже mapreduce в несколько потоков или все так же однопоточное?

MongoDB 1.6.0

В Mandriva 2010, Ubuntu 10.10, Debian 6.0 Testing пока лежит MongoDB 1.4.4.

В Gentoo 1.5.5 лежит.

Выглядит заманчиво. Особенно радует наличие java биндингов. На досуге надо будет попробовать посмотреть.

Поподробнее про шардинг в couchdb можно?

Нету его из коробки, только сторонняя приблуда couchdb-lounge и она сырая еще очень сильно.

А в ней можно замутить из всего CAP только C(A|B) чтобы консистенция была?

Это чудо не собирается на big-endian платформах, и по словам авторов не будет.

1.5.x - это dev. 1.4.x - stable.

> документо-ориентированная система управления базами данных

Объясните дураку, что же это такое? Куда это можно присунуть, и где этого наоборот использовать не стоит?

картина мира восстановленна. ура!

Что за НЁХ?

Да, да, поддерживаю! Что это такое?

кто нибудь пробовал полнотекст прикрутить на основе multikeys и что юзал для стемминга в этом случае?

Для полнотекстового поиска надо использовать специальные инструменты, а не пытаться натянуть его на систему хранения. Ничем хорошим это, обычно, не заканчивается.

> Боженька, зачем ты сделал модным эти документ-ориентированные СУБД?

Присоединяюсь к молитвам.
«Вразуми начальников и дилетантов, да обойдёт их стороной искушение применять молоток вместо отвёртки, ибо не есть сие благо».

>кто нибудь пробовал полнотекст прикрутить на основе multikeys

Ну, я планирую прикрутить Sphinx. Там, вроде, ничего сложного.

...

Меня больше интересует как бы для распределённой базы придумать единые 32-х битные уникальные ID. Чтобы можно было на разных машинах писать и не иметь коллизий.

ораклокопец настает.

>«Вразуми начальников и дилетантов, да обойдёт их стороной искушение применять молоток вместо отвёртки, ибо не есть сие благо».

Появился семигранный гаечный ключ для завинчивания специфических, но не редко встречающихся семигранных гаек. Но народ плачет и молится, матерясь на семигранные ключи и предпочитает завинчивать гайки по старинке - плоскогубцами.

>Чтобы можно было на разных машинах писать и не иметь коллизий.

Не знаю специфику задачи, а решение наподобии выдачи айпишников по маске (маска ограничевает диапазон) не подойдет?

У меня ситуация ровно наоборот: используется DB2 со странной схемой данных и монструозными селектами там, где идеально подошла бы, например, MongoDB. Это проблема не технологии, а менеджмента и архитектуры.

>специфических, но не редко встречающихся семигранных гаек.

Ну так расскажите нам скорее что это такие за семигранные гайки.

>Меня больше интересует как бы для распределённой базы придумать единые 32-х битные уникальные ID. Чтобы можно было на разных машинах писать и не иметь коллизий.

отдать n-бит из этого идентификатора под номер ноды?

> Для полнотекстового поиска надо использовать специальные инструменты, а не пытаться натянуть его на систему хранения. Ничем хорошим это, обычно, не заканчивается.

Эээ, а как же оное в PostgreSQL?

>Не знаю специфику задачи

Да есть желание попробовать сделать распределённый форум. Типа, если одна машина откажет, с другой бы чтобы работало.

а решение наподобии выдачи айпишников по маске (маска ограничевает диапазон) не подойдет?

Да, мысль. Надо подумать.

>Ну так расскажите нам скорее что это такие за семигранные гайки.

Есть такие. Там, где не требуется транзакционная целостность, но где важны скорость и масштабируемость. Или быстрые модификации структуры.

>Эээ, а как же оное в PostgreSQL?

Я даже в mysql не использую fulltext. Тормозной он и неудобный. В то время, как sphinx среди двух миллионов сообщений на 4Гб находит результат за десятые и сотые доли секунды.

>но где важны скорость и масштабируемость

А где бы солидных тестов найти? А то после каждого теста, показывающего хорошее преимущество NoSQL шло жесткое разоблачение.

>А где бы солидных тестов найти?

Как реализую что-нибудь солидное - будет и солидный тест. Пока же хватает и поверхностных оценок для того, чтобы делать выводы о применимости:

http://www.linux.org.ru/jump-message.jsp?msgid=5111473&cid=5131669
http://www.linux.org.ru/jump-message.jsp?msgid=5139765&cid=5151850

Меня больше интересует как бы для распределённой базы придумать единые 32-х битные уникальные ID

Если нод две, то тупо чет/нечет подойдет :)

используется DB2 со странной схемой данных и монструозными селектами

Кхе. И как вы монстроузные селекты собираетесь описывать понятием key/value? Кхе-кхе

Я даже в mysql не использую fulltext.

А зря. В отличии от mySQL в PostgreSQL ребята подошли с головой к данной проблеме. Очень толково сделали полнотекстовый поиск. Читать здесь:
http://rus-linux.net/lib.php?name=/MyLDP/subd/pgfts.html
http://www.sai.msu.su/~megera/postgres/talks/fts_pgsql_intro.html#ftsperf

Эээ, а как же оное в PostgreSQL?

Я даже в mysql не использую fulltext.

А вы попробуйте, вдруг понравится (я не про MySQL очевидно :) - нашли с чем сравнивать) http://www.postgresql.org/docs/8.4/static/textsearch.html

Ну и тут: http://www.linux.org.ru/search.jsp?q=%D0%9F%D0%BE%D0%BB%D0%BD%D0%BE%D1%82%D0%...

В третьей ссылке KRoN73 в 2007 году уже объясняли почему в MySQL поиск плох, а в PostgtreSQL нет.

> зачем ты сделал модным эти документ-ориентированные СУБД?

как зачем? в них кукисы хранить удобно

Эээ, а как же оное в PostgreSQL?

Пробежал глазами по доке — очень богатый и гибкий функционал. Удивился. Как раз то исключение из правила. Когда можно вмешаться в парсинг документов, определить свои веса для ключей (например модели товаров должны иметь наивысший приоритет).

Еще две бд назовешь с аналогичным по мощности фуллтекстовым поиском?

>>«Вразуми начальников и дилетантов, да обойдёт их стороной искушение применять молоток вместо отвёртки, ибо не есть сие благо».

Появился семигранный гаечный ключ для завинчивания специфических, но
не редко встречающихся семигранных гаек. Но народ плачет и молится,
матерясь на семигранные ключи и предпочитает завинчивать гайки по
старинке - плоскогубцами.

скорее проблема в том, что вместо применения старинных, проверенных, и ничуть не уступающих по качеству 6-и гранных гаек, быдло-топ-менеджеры дадут команду использовать 7-и гранные. просто потому что так «красифше-наX» и «солиднее-мля»...

о том что-б этого не было и моляцца)

>о том что-б этого не было и моляцца)

У кого голова не плечах есть, тем молиться смысла нет :) Они итак решат, какие тут гайки лучше подойдут. А кто сам решить не может - тому и молитвы не помогут...

Для полнотекстового поиска надо использовать специальные инструменты, а не пытаться натянуть его на систему хранения.

поверь я с полнотекстом очень и очень сильно и плотно дружу в разных его инкарнациях и тут есть возможность его также прикрутить, что и собираюсь делать, интересно было - пробовал кто либо или нет.

> У кого голова не плечах есть, тем молиться смысла нет :) Они итак решат, какие тут гайки лучше подойдут. А кто сам решить не может

Понты такие понты.

Ну, я планирую прикрутить Sphinx. Там, вроде, ничего сложного.

ага - я люсену :) (индекс часто и сильно меняется)

а стеминг? стандартный? я вот собираюсь от aot подтянуть напосмотреть

Эээ, а как же оное в PostgreSQL

pg'шный fts более чем унулое овно, юзабельное в простейших случаях

>У кого голова не плечах есть, тем молиться смысла нет :) Они итак решат, какие тут гайки лучше подойдут. А кто сам решить не может - тому и молитвы не помогут...

это бы конечно наверное так. но типичный «топ» в российских территориях - тварь практически неуправляемая, не прогнозируемая и не вменяемая. думать он часто не умеет, или думает о своем. его можно только приманить деньгами, а про суть вещей он судит по «солидности» презентации.

и нам, как техническим специалистам российских компаний, часто остается только молиться. потому что иного пути повлиять на ситуацию и решение топа - часто нет ))))

часто даже «документ на рецензирование», спускают как «уже утвержденный». А в нем такой бред сивой кАбылы написан, шопипец ))) вы думаете тут можно сделать что-то иное кроме как молиться?))) тогда вам редко повезло с компанией)

>а стеминг? стандартный?

Ну да. И для поиска хватает, даже если юзеру и выскочит лишняя ссылка - переживёт, и для системных нужд, например, при автоматическом связывании материалов - всё равно часто потом более жёсткая проверка идёт и модераторы/редакторы в итоге всё равно должны поработать.

>это бы конечно наверное так. но типичный «топ» в российских территориях - тварь практически неуправляемая

Ну так можно же тупо держаться от таких подальше :)

жёсткая проверка идёт и модераторы/редакторы в итоге всё равно должны поработать

повезло :)))