Не нужен.

Ну и проходите мимо.

Ура, наконец-то он вышел.

Радует появление Aggregation Framework и то, что теперь при записи лочится база (на ноде), а не вся нода (обещали, что блокировки на уровне коллекций сделать будет теперь совсем просто). Из недоделок остался последний boost 1.50 (насколько я понял, он не поддерживается, нужно работать с 1.49 - обещают исправить к 2.3.0). Зато поддерживается последний glibc 2.16. В общем mongo активно развивается, многое уже работает, остальное в процессе добавления.

Насколько знаю, это свободный аналог СУБД Cache'?

Под какими дистрами работает и есть ли графические механизмы установки и возможна ли конвертация баз Cache?

тестил rc1 и rc2 - великолепно, наконец то более вменяемый writelock (к сожалению полностью от него не избавились)

/me начинает гонять тесты по нагрузке и шардингу для выкатки в продакшен

стремно же, лучше обождать месяцок

Именно этой СУБД я обязан избавлению от SQL головного мозга, навязываемого человечеству оракулом с незапамятных времён. Теперь SQL уехал туда, где ему и положено быть - на серверы отчётов и OLAP.

А почему решили уйти от map-reduce?

там map-reduce функции на js, теперь вместо них на типовых задачах можно пользовать сишечные из агрегейшнфреймворка

От него не уходили. Map/reduce это более общий способ решения более широкого круга задач и там используется JavaScript, а Aggregation - это типа group by и встроенного в саму СУБД (работает без JavaScript).

соответсвующей
горизонатльно
Улучнения

Проверено: maxcom

я в БД как свинья в апельсинах :) вот думаю что бы такого хорошего и простого заюзать, а MongoDB относительно других подобных как? честно, хочется NoSQL (а это я так понимаю просто база со своим, возможно более простым, API и CLI?)

хочу освоить какую-нибудь БД, а то стыдно - здоровенная детина, а не работал с БД (ну разве чуть чуть из Qt)

люто плюсую. Еще полностью не избавлены, но вектор уже выбран.

посмотри еще на Redis

я в БД как свинья в апельсинах :) вот думаю что бы такого хорошего и простого заюзать, а MongoDB относительно других подобных как? честно, хочется NoSQL (а это я так понимаю просто база со своим, возможно более простым, API и CLI?)

Неправильно понимаешь. NoSQL это buzzword. За ним стоит в первую очередь элементарное желание впарить продукт под видом экзотики.

Что до технической стороны, то вне зависимости от того, что за NoSQL тебе предлагают, как правило речь идёт о нереляционной СУБД. Т.е. это вещь более фундаментальная чем какой-то другой API. И две NoSQL СУБД могут быть похожи приблизительно также как шимпанзе и баобаб.

Реляционки имеют дело с таблицами и связями между ними (плюс кое-какие дополнительные штучки). Другие виды СУБД могут работать с графами, хеш-таблицами, разряжёнными матрицами, и т.д.

Выбор NoSQL-СУБД нужно осуществлять исходя из задачи. Скажем, для организации очереди или кеширования скорее подойдёт key-value, типа Redis. Но Mongo (документо-ориентированная СУБД), в общем, будет хорошим выбором для изучения в качестве подходящей под большинство задач современных информационных систем (скажем, социальную сеть на ней базировать будет отличным вариантом). Вообще, она практически идеальна для веба (удобно квантовать данные, один документ - одна страница). Начинай с неё, не прогадаешь :).

SQL головного мозга, навязываемого человечеству оракулом с незапамятных времён

facepalm.mkv (4.7G)

Вы, видимо, не читали журналов типа «Компьютер» или «Монитор» за год эдак 89-ый? Или не догадываетесь, кто такой Oracle? Или как мне расшифровать ваш глубокомысленный комментарий?

я обязан избавлению от SQL головного мозга, навязываемого человечеству оракулом с незапамятных времён

Хм, вроде, в DB2 SQL был задолго до оракула, если не путаю?

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

спасибо :) начну с неё :) а то я реально как свинья в апельсинах в области БД, хотя знаю что они очень разные внутри и для принципиально разных задач...

Когда они выкинут mmap и глобальный лок на всю базу при записи, тогда и посмотрим.

Вы, видимо, не читали журналов типа «Компьютер» или «Монитор» за год эдак 89-ый?

Блин, я сейчас зарыдаю. Ты бы еще «Мурзилку» вспомнил.

Для протокола: первая (известная мне) книга, посвященная _исключительно_ SQL, «Руководство по реляционной СУБД DB2», в СССР была опубликована в 1988 (а в США - в 1984). Это не говоря о System R, дизайн которой был тщательно описан еще в 70-е.

Mongo (документо-ориентированная СУБД)
скажем, социальную сеть на ней базировать будет отличным вариантом

Лолшто? Каким образом монго заточена под работы с графами?

Я не говорил, что SQL придумал Oracle, но во многом именно агрессивный маркетинг Oracle принёс SQL в массы (и это хоть и распространённое, но мнение, потому не претендую на единственно верную трактовку истории). А вот как раз в нужности SQL как «унифицированном средстве для извлечения данных из очень разных БД» и усомнилось современное сообщество разработчиков, и пока это сомнение даёт положительные результаты в развитии принципов построения информационных систем.

Хорошо, спасибо за комментарий. А что можешь посоветовать для изучения? Думаю, что I-Love-Microsoft будет тоже полезно ;)

Ты, кажется, соревнуешься со мной в знакомстве с как можно более старой РСУБД? Или как твой тезис относится к моему комментарию?

Лолшто? Каким образом монго заточена под работы с графами?

Ты, кажется, соревнуешься со мной в знакомстве с как можно более старой РСУБД?

Тебе кажется.

как твой тезис относится к моему комментарию?

Опровергает его.

использовал для подсчета онлайн статистики некоторое время. Из-за детских ошибок ( в частности из-за group by max 20000 ) и из-за жуткого потребления памяти/диска отказался в пользу redis. Серверам сразу полегчало :)

в нужности SQL как «унифицированном средстве для извлечения данных из очень разных БД» и усомнилось современное сообщество разработчиков

конечно, впарить SQL-продукт хомячкам очень трудно - нихера не понимают. А вот что попроще - расходится как горячие пирожки!..

Разве?

А вот как раз в нужности SQL как «унифицированном средстве для извлечения данных из очень разных БД» и усомнилось современное сообщество разработчиков, и пока это сомнение даёт положительные результаты в развитии принципов построения информационных систем.

(Написал длительную филиппику в адрес современного сообщества разработчиков, потом стёр.) Ладно... SQL и основанные на нём API позволяют масштабировать программы по используемым СУБД - от SQLite до того же Oracle в зависимости от серьёзности проекта. Для NoSQL подобный гибкий механизм существует?

Для протокола: первая (известная мне) книга, посвященная _исключительно_ SQL, «Руководство по реляционной СУБД DB2», в СССР была опубликована в 1988 (а в США - в 1984).

Дейт?

Да.

Для NoSQL подобный гибкий механизм существует?

Но каждому ли проекту необходимо ездить туда сюда по масштабам?

я в БД как свинья в апельсинах :)

На сайте mongo написано, что это такое, чем отличается от SQL, и для каких задач оно подходит лучше (без фанатизма, с анализом как плюсов так и минусов каждого решения).

http://www.mongodb.org/display/DOCS/About

Чаще как раз наоборот, NoSQL-СУБД потребуют от разработчика разобраться в её архитектуре, прежде чем использовать (ибо поверх нет SQL, скрывающего особенности реализации). А вот адепты SQL, порою, версионник от блокировочника отличить не могут.

Разве?

Да. До середины 90-х Oracle был всего лишь одним из многих. DB2, Informix, Sybase... даже в галимом FoxPro 2 (1991) был SQL.

Но каждому ли проекту необходимо ездить туда сюда по масштабам?

Лучше спроси: «Каждому ли проекту необходима масштабируемость, которой кичится NoSQL вообще и MongoDB в частности?».

А вот как раз в нужности SQL как «унифицированном средстве для извлечения данных из очень разных БД» и усомнилось современное сообщество разработчиков

Сообщество разработчиков усомнилось не в sql, а в acid, который не дает базы горизонтально масштабировать. Иначе не прикручивали бы к каждой второй nosql базе очередной QL.

зачем сравнивать «адептов» с разработчиками? :\ Очень надеюсь, что демагогия «выродилась» неосознанно...

Как раз SQL масштабируется хреново... ну вернее либо дорого (Оракл) либо дешево и сердито (руцями, путем выбрасывания основных фич СУБД и оствлением голых таблиц в Мускуле). А вот все носкльные решение идут изначально заточеные на масшатбирование, туже Касандру например, без кластера в сотню нод использовать смысла нет. Тоесть это изначально закладываетсяч в архитектуру, а все остальные фичи идут уже в дополнение, при чем в разных базюльках эти плюшки очень даже разные

Как раз этот вид масштабирования оказался менее востребован (да и иллюзорен, по-сути - если программа прозрачно SQLite и Oracle, то Oracle превращается в дорогостоящий SQLite), чем масштабирование горизонтальное (основа философии веба).

Не каждому. Но многим.

Ты дурачок?

Сто пудов не каждому. Но и сложность СКЛ нужна тоже не каждому. Если мне налобать нужно простенький сайтец с базюлькой без сложных связей и выборок, то не проще ли выбрать туже Монго, котороя позволяет намного проще промапить данные на ту же джаву, пыхыпы, любой другой язык?

Хорошо, я принимаю и вашу точку зрения. Однако моё мнение об Oracle как одном из основных «виновников» продвижения SQL не изменилось.

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

Лучше спроси: «Каждому ли проекту необходима масштабируемость, которой кичится NoSQL вообще и MongoDB в частности?».

Разумеется, если проект никогда не вырастет до стадии, когда одна выделенная машина с базой уже не справляется, то пользы от масштабирования, которая легко дается на NoSQL базах такой проект не получит. Но кроме масштабирования у Mongo есть еще и гибкость (отсутствие схемы, например). Тут еще в ответ можно спросить, а каждому ли проекту нужна реляционность?

Вообще смысла великого спорить кто круче слон или кит (SQL или NoSQL) нет почти никогда. Они для разных почти не перекрывающихся областей задач и у каждого решения есть как свои преимущества, так и недостатки.

сложность СКЛ

facepalm.jpg

Если мне налобать нужно простенький сайтец с базюлькой без сложных связей и выборок, то не проще ли выбрать туже Монго

NoSQL головного мозга детектед.