LINUX.ORG.RU

Релиз MongoDB 2.2.0

 , ,


0

3

Компания 10gen объявила о выпуске NoSQL базы данных MongoDB версии 2.2.0.

Среди наиболее важных изменений разработчики выделили следующие:

  • Появление Aggregation Framework, оптимизирующего обработку больших массивов данных без необходимости применения технологии map-reduce. Также в командной строке mongo теперь доступен метод-помощник db.collection.aggregate();
  • Введение TTL-коллекций, использующих специальные индексы для проверки данных на актуальность в соответствии с указанным временем жизни (что удобно, например, для хранения логов и подобной информации). При использовании таких коллекций создается дополнительный фоновый процесс для реализации соответсвующей проверки;
  • Улучшения в механизме параллелизации, а также дополнительные инструменты командной строки для мониторинга текущих параллельных операций;
  • Добавлена поддержка географически распределенных и горизонатльно масштабированных систем;
  • Улучнения в системе авторизации клиентов (новая версия не совместима при работе в кластере вместе с MongoDB 2.0);
  • А также многое другое.

Список всех исправленных ошибок в багтрекере

>>> Список изменений

★★★★★

Проверено: maxcom ()

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

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

x_hash
()

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

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

anonymous
()

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

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

real_maverick ★★★
()

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

boo32
()
Ответ на: комментарий от anonymous

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

VladimirMalyk ★★★★★
()
Ответ на: комментарий от anonymous

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

x_hash
()

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

Проверено: maxcom

kelyar ★★★★★
()
Ответ на: комментарий от boo32

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от boo32

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

dimonb
()
Ответ на: комментарий от I-Love-Microsoft

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

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

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

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

rtvd ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

boo32
()
Ответ на: комментарий от tailgunner

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

boo32
()
Ответ на: комментарий от boo32

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

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

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

hobbit ★★★★★
()
Ответ на: комментарий от boo32

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от boo32

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от boo32

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

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

tensai_cirno ★★★★★
()
Ответ на: комментарий от hobbit

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

boo32
()
Ответ на: комментарий от boo32

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

renya ★★★★★
()
Ответ на: комментарий от tailgunner

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

boo32
()
Ответ на: комментарий от boo32

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

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

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

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

tailgunner ★★★★★
()

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

SI ★★☆☆
()
Ответ на: комментарий от boo32

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

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

yyk ★★★★★
()
Ответ на: комментарий от boo32

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

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

hobbit ★★★★★
()
Ответ на: комментарий от tailgunner

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

Дейт?

hobbit ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

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

x_hash
()
Ответ на: комментарий от yyk

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

boo32
()
Ответ на: комментарий от I-Love-Microsoft

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от boo32

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

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

Nagwal ★★★★
()
Ответ на: комментарий от boo32

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

yyk ★★★★★
()
Ответ на: комментарий от hobbit

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

hunger
()
Ответ на: комментарий от hobbit

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

boo32
()
Ответ на: комментарий от tailgunner

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

hunger
()
Ответ на: комментарий от tailgunner

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

boo32
()
Ответ на: комментарий от hobbit

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

tensai_cirno ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

x_hash
()
Ответ на: комментарий от hunger

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

facepalm.jpg

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

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

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.