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

kost-bebix (05.08.2010 23:56:30)

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

Zenom (06.08.2010 0:17:09)

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

Jetty (06.08.2010 0:26:42)

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

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

pythonist (06.08.2010 1:05:26)

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

Zenom (06.08.2010 1:18:45)

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

JFreeM (06.08.2010 1:20:55)

> MongoDB 1.6.0

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

lystor (06.08.2010 1:23:42)

В Gentoo 1.5.5 лежит.

keeper_b (06.08.2010 1:27:41)

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

drakmail (06.08.2010 2:02:26)

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

catap (06.08.2010 2:03:36)

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

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

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

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

Aesthete (06.08.2010 8:18:14)

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

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

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

catap (06.08.2010 10:02:58)

Что за НЁХ?

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

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

real_maverick (06.08.2010 10:50:45)

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

baverman (06.08.2010 11:30:27)

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

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

matumba (06.08.2010 11:32:11)

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

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

...

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

KRoN73 (06.08.2010 11:37:00)

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

AVL2 (06.08.2010 11:38:04)

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

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

KRoN73 (06.08.2010 11:38:34)

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

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

theos (06.08.2010 11:43:19)

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

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

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

theos (06.08.2010 11:44:19)

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

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

AVL2 (06.08.2010 11:50:51)

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

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

Evgueni (06.08.2010 11:51:59)

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

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

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

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

KRoN73 (06.08.2010 11:54:20)

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

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

KRoN73 (06.08.2010 11:55:59)

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

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

KRoN73 (06.08.2010 11:57:04)

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

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

theos (06.08.2010 11:59:06)

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

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

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

KRoN73 (06.08.2010 12:03:26)

> Меня больше интересует как бы для распределённой базы придумать единые 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

Evgueni (06.08.2010 12:29:05)

Ну и тут: 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 нет.

Evgueni (06.08.2010 12:35:18)

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

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

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

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

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

baverman (06.08.2010 13:06:40)

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

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

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

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

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

KRoN73 (06.08.2010 15:06:45)

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

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

real_maverick (06.08.2010 15:16:27)

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

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

tailgunner (06.08.2010 15:17:43)

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

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

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

real_maverick (06.08.2010 15:19:05)

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

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

real_maverick (06.08.2010 15:20:34)

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

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

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

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

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

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

KRoN73 (06.08.2010 15:35:22)

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

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

KRoN73 (06.08.2010 15:35:54)

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

повезло :)))

real_maverick (06.08.2010 15:38:51)