MongoDB 1.6.0

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

Технический специалист, если его чего-то не устраивает, может легко сменить топа. Если, конечно, он специалист, а не «програмист на компьютере»

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

в чем они заключаются в данном случае?

Видимо, человеку кажется, что если другой рассуждает о влиянии разума на свободу выбора - то это только понты :)

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

Что-то вроде LORа? Что значит простейшие случаи?

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

кластеризация не Ъ

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

Эээ, а оно надо? Достаточно одного :)

>кластеризация не Ъ

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

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

в чем они заключаются в данном случае?

В том, что приходит заказчик и говорит: «Вот работа, вот деньги, но сделать на NoSQL, патамушта модно». Так вот, если кто-то говорит, что пошлет заказчика только из-за NoSQL - этот кто-то понтуется.

>Так вот, если кто-то говорит, что пошлет заказчика только из-за NoSQL - этот кто-то понтуется.

Я - посылал, когда заказчик хотел откровенной фигни и не был вменяем, чтобы понять контраргументы. Обычно связываться с невменяемыми заказчиками - себе дороже. Не зависимо от того, чего они там захотят использовать. Тем более, что через пару дней они могут захотеть уже совсем другого и тебе придётся или переделывать, или снова его посылать.

Так что - никаких понтов. Суровый прагматизм.

А вот у меня как раз ситуация, когда заказчик вполне вменяем (да и вообще хороший человек), но хочет кассандру.

>А вот у меня как раз ситуация, когда заказчик вполне вменяем (да и вообще хороший человек), но хочет кассандру.

Если он вменяем и Кассандра не подходит в случае проекта, то тебе не составит труда аргументированно объяснить его минусы такого решения и плюсы альтернативного.

>> Так вот, если кто-то говорит, что пошлет заказчика только из-за NoSQL - этот кто-то понтуется.

Я - посылал, когда заказчик хотел откровенной фигни и не был вменяем

Ты увидел невменяемость там, где ее нет.

Бывает так, что недостатки всплывают посреди проекта в каком-то частном случае, когда уже поздно что-то менять. Всего предвидеть невозможно, тем более, что у меня это был первый крупный проект с использованием NoSQL.

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

Тогда это уже не наш случай «искушения применить молоток вместо отвёртки». Если в начале проекта неизвестны возможные последствия, то самодурством начальства тут, как бы, не пахнет. Риск есть риск.

Ты увидел невменяемость там, где ее нет.

А ты что, в курсе подробностей?

>Ты увидел невменяемость там, где ее нет.

У тебя libastral глючит. Настрой получше.

>> Ты увидел невменяемость там, где ее нет.

А ты что, в курсе подробностей?

Вообще-то это я придумал ситуацию %) (на основе опыта, конечно).

>> Ты увидел невменяемость там, где ее нет.

У тебя libastral глючит.

У меня его нет, а вот у тебя он и правда глючит.

>У меня его нет

А, так ты данные для оценок из /dev/random берёшь? Ну, тогда понятно.

У тебя libastral глючит.

У меня его нет

А, так ты данные для оценок из /dev/random берёшь?

А что, у тебя вариантов только два - libastral.so и /dev/urandom? %)

Возвращаясь к теме.

Кто-нибудь может дать сравнение MongoDB с couchDB? Кратенько. Можно субъективно.

>Вообще-то это я придумал ситуацию

Уа-ау-у!!! Да ты прям Лев Толстой! В твоем выдуманном мире неадекватных заказчиков не бывает?

Кстати поддержу Крона, неадекватов надо сразу слать ВЖгГ, работать с ними слишком накладно. В реальном мире, по крайней мере, так.

Я и не про самодурство говорил. Просто изначальная мотивация применить Кассандру была связана с тем, что это модно, а не с тем, что РСУБД не справилась бы. А я не возражал, т. к. не мог предвидеть всех последствий.

Раз уж у тебя опыт есть. Скажи - как там со скоростью обновления данных? По сравнению с SQL?

Если не секрет, может поделиться проблемами с использованием кассандры?

> Я и не про самодурство говорил. Просто изначальная мотивация применить Кассандру была связана с тем, что это модно

А что плохого в использовании новых (современных, «модных») инструментов?

я не возражал, т. к. не мог предвидеть всех последствий.

Ну так твой косяк. Рассказать, что плохого в неспособности оценить пригодность инструмента для задачи?

Не секрет. Много чего надо делать вручную, например:

• Контроль целостности. Нет способа сказать, что является обязательным.
• Преобразование типов. Cassandra оперирует массивами байт. Конвертация их в строки, даты, числа --- целиком наша забота. Здесь, правда, очень помогли неявные преобразования из Scala.
• Нужно было быстро осуществлять выборку SuperColumn-ов, отсортированных по 2-м Column-ам, содержащимся в них. Пришлось делать что-то типа обратного индекса вручную.

В общем, все эти задачи скучны, я бы предпочёл переложить их на СУБД, а мне пришлось писать код для их выполнения. Кстати, если заказчик разрешит, то я опубликую Scala-либу для Cassandra под WTFPL на http://bitbucket.org. Она позволяет решать эти задачи автоматом.

>Рассказать, что плохого в неспособности оценить пригодность инструмента для задачи?

Мир был бы идеален, если бы можно было предвидеть все последствия принятых решений.

Для Mongo:

Нет способа сказать, что является обязательным.

Это лучше вообще лучше делать на этапе компиляции с правильной поддержкой языка :)

Преобразование типов.

с этим все нормально.

выборку SuperColumn-ов

не знаю что это

отсортированных по 2-м Column-ам

это запросто

Это лучше вообще лучше делать на этапе компиляции с правильной поддержкой языка

А если кто-то обратится неправильной программой к ваше БД. Тогда как?
Будем искать виновника?

>А если кто-то обратится неправильной программой к ваше БД

А сфигали кто-то «неправильной» программой вообще что-то с БД делать будет?

>А что, у тебя вариантов только два - libastral.so и /dev/urandom? %)

Да нет. Ещё всякие date|md5sum возможны. Короче, оценки типа ППП.

>Кто-нибудь может дать сравнение MongoDB с couchDB? Кратенько. Можно субъективно.

Сам не сравнивал, но по отзывам, если совсем коротко, то MongoDB быстрее, CouchDB надёжнее.

>Раз уж у тебя опыт есть. Скажи - как там со скоростью обновления данных? По сравнению с SQL?

Опыта нет, есть очень грубые тесты. Т.е. не тесты даже, а оценки. В один поток в миллионых размеров таблицы данные вставляет в 10 раз быстрее, чем в MySQL/MyISAM. В несколько потоков не тестировал.

Собственно, у сабжа и заявлена особенно высокая скорость именно на обновлении. На чтении в целом производительность в MySQL сравнима.

>А если кто-то обратится неправильной программой к ваше БД. Тогда как?

А если «неправильная программа» из SQL-базы удалит не те значения? :)

>по отзывам, если совсем коротко, то MongoDB быстрее, CouchDB надёжнее.

Да я тоже пока только «палочкой потыкиваю».

Что мне в CouchDB понравилось, это JSON,REST и работа под вендой (сам, правда, не пробовал)

>Что мне в CouchDB понравилось, это JSON,REST и работа под вендой

Поскольку я пользуюсь готовыми либами, то мне без разницы :) Я в MongoDB просто скармливаю JSON-массив, который библиотека уже сама преобразует в BSON и отдаст базе, скрывая для меня и наличие или отсутствие REST.

...

Кстати, в пользу MongoDB ещё официальный биндинг (PECL) на PHP :) - http://ru2.php.net/mongodb/

Я так понял ты форум на ней держишь. База накрывалась у тебя?

Не-не. Форум у меня на MySQL. Я пока только оцениваю возможность перевода на MongoDB.

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

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

>все эти nosql годны только

Именно. Для шурупов есть отвёртка, для гвоздей - молоток.

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

>не требуется для бизнеса.

Смотря для какого. Посмотри http://www.mongodb.org/display/DOCS/Production+Deployments - это все бизнес-клиенты. Да, большинство из них аля-социальные сети и форму. Но во-первых не только. Во-вторых это тоже бизнес.

> во-первых не только

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

Правильно. Шурупы можно забивать молотком. (И это даже лучше, чем завинчивать гвозди отвёрткой.)

>_только_ для того, без чего бизнес совершенно спокойно может существовать

4.2 невнимательно смотрели. Там есть примеры аналитики на MongoDB.

>Кстати, в пользу MongoDB ещё официальный биндинг (PECL) на PHP :)

Это, скорее, недостаток :)

Если серьезно, то у меня пхп используется для <? include $file ?> и вычисления $file. Так что, от пхп можно вообще отказаться. В данном случае.

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

суть не в SQL/noSQL, суть в заказчиках неадекватах. если вы работаете без разбора - мне вас жаль.

>Технический специалист, если его чего-то не устраивает, может легко сменить топа. Если, конечно, он специалист, а не «програмист на компьютере»

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

К сожалению, проблемы с топами иногда возникают после подписания договора. И часто эти проблемы возникают не из-за тебя, а из-за косяков РП.

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

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

Вот от избавления такого геморроя, и только остается молиться. )))) ну это к тому, про то, с чего мы тут начали разговаривать.

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

Что за чушь и рабовладельческий строй? Конечно может. А если он, как ты говоришь, вменяемый человек — сделает это как можно быстрее.

И, если тебя так волнует нравственный аспект, подумай вот о чем: ведь тебя пригласили за твои профессиональные навыки. Проявляя неадекватность, работодатель фактически отвергает тебя как специалиста. То есть, в этом случае, у тебя не остается никаких моральных обязательств.

Давайте разделять 2 области. Личный зачет бойцов одиночек, и командная работа над большими проектами.

А зачем?

В большом проекте есть договор, есть проект, есть твой участок работ

В любом проекте точно так же.

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

Об этом и речь. Ты, как специалист, совершенно не интересуешь работодателя.

Нельзя в данной ситуации взять и уйти. Просто потому что ты подписался на заданный участок.

Как подписался, так и отписался. Долой рабство.

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

Значит ли это, что ты не профессионал, а обычный «программист на компьютере»?

>Вот от избавления такого геморроя, и только остается молиться. )))) ну это к тому, про то, с чего мы тут начали разговариват

А надо не молится, а расти как специалист.