LINUX.ORG.RU

MongoDB 1.6.0

 , , ,


0

1

MongoDB — документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++.

Шардинг

Шардинг готов для использования в производстве, давая возможность масштабировать MongoDB горизонтально. При необходимости единственный экземпляр mongod может быть преобразован в распределённый кластер с нулевым временем простоя.

Replica Sets

Replica sets — новый метод репликации, который предоставляет возможность автоматически переключаться среди участников кластера.

Replica pairs объявлен устаревшим; использующим данный функционал рекомендуется перейти на использование replica sets.

Другие улучшения

  • Опция w (и wtimeout) форсирует запись на n серверов до успешного завершения операции (особенно хорошо работает с replica sets)
  • $or-запросы
  • Улучшенная многопоточность
  • $slice-оператор для возвращения части массива (подмассива)
  • 64 индекса на каждую коллекцию (в 1.4 было 40)
  • 64-битные целые могут быть представлены в командной оболочке посредством NumberLong
  • Команда findAndModify теперь поддерживает upserts (аналог SQL MERGE). Также теперь позволяется указывать поле, которое должно быть получено
  • $showDiskLoc — опция для отображения местонахождения документа на диске
  • Поддержка IPv6 и доменных сокетов UNIX
  • C++ клиент отделён от бинарного пакета

>>> Подробности

★★

Проверено: catap ()
Последнее исправление: MuZHiK-2 (всего исправлений: 2)

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

Значит блокировка все-же есть

Нету там блокировки. Попытка записать документ с не той версией сразу дает исключение. И клиент должен сам разрулить конфликт.

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

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

Я так понимаю спор чисто терминологический, так как я считаю версионность одним из способов реализации транзакций.

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

Ты утверждаешь, что

Скачать, обновить, записать обратно - а за это время второй поток обновил адрес... Вот и рэйс

Я так не утверждаю. Я утверждаю, что если еcть два процесса, которые конкурируют за общий ресурс в данном случае за доступ к объекту JSON, то блокировка на изменение JSON объекта неизбежна в том или ином виде. Даже в мультиверсионной БД имеется блокировка на время включения свежей версии. Если есть блокировка и есть поддержка транзакций, возможен deadlock.

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

> Даже в мультиверсионной БД имеется блокировка на время включения свежей версии. Если есть блокировка и есть поддержка транзакций, возможен deadlock.

В данном случае дедлока быть не может, потому что блокирующий код не лезет ни в какие больше ресурсы, то есть не может возникнуть цикл локов. Ну если реализовано все правильно конечно.

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

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

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

Практика говорит об обратном. Таких БД пока-что не встречал.

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

> Действительно вопрос терминологический. Можно конечно и не считать заблокированной запись, которую нельзя изменить до тех пор, пока она не будет разблокирована другим процессом. Так?

Ну мы ведь не о таких локах говорили, да и вообще непонятно как там все в глубине реализовано, может там один вызов compare-and-swap стоит, для смены указателя на новый документ?

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

Ну мы ведь не о таких локах говорили

Такие локи в сложном приложении способны привести к deadlock.
Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

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

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

> Такие локи в сложном приложении способны привести к deadlock.

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

Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

Смешалось все в кучу, понятие SQL/NoSQL ортогонально транзакциям..

А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно. Транзакций пока нет, разграничения прав доступа тоже нет. Ссылочной целостности нет.

Как элементарно перевести средства с одного счёта на другой без транзакций?

В berkeleydb например есть транзакции.

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

> Такие локи не могут привести к дедлокам, почему я обьяснил выше. В каких СУБД c поддержкой транзакций принципиально отсутствуют дедлоки? Клиентсткие приложения работающие с такими СУБД не будут подвержены дедлокам?

Смешалось все в кучу, понятие SQL/NoSQL ортогонально транзакциям..

Действительно транзакции можно реализовать и в NoSQL СУБД. И таковые реализованы.

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

В couchdb целостность базы данных обеспечивается исключительно на уровне отдельных записей (но не на уровне связей между ними);
Нет транзакций

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

> лиентсткие приложения работающие с такими СУБД не будут подвержены дедлокам?

Сколько раз мне еще повторить слово «нет»? ;-)

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

Сколько раз мне еще повторить слово «нет»? ;-)

Не верю! Дайте мне примеров! :-) Дайте хотя-бы ссылку.

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

MVCC реализовано в Firebird. Это первая СУБД c MVCC. Дедлок в ней возможен. В каких СУБД с поддержкой транзакций это не так?

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

>В couchdb целостность базы данных обеспечивается исключительно на уровне отдельных записей

Какой смысл ты вкладываешь в термин «запись» в контексте couchdb?

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

> MVCC реализовано в Firebird. Это первая СУБД c MVCC. Дедлок в ней возможен. В каких СУБД с поддержкой транзакций это не так?

Те ДБ о которых ты говоришь, они с write lock-ом. А в couchdb write lock-a к примеру нету.

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

В couchdb транзакций нет. Я утверждаю, что если в СУБД есть поддержка транзакций, то возможны дедлоки. Добавьте в couchdb транзакции и получите возможность дедлока.

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

Просвещаю. «запись» в контексте couchdb это JSON-подобный документ, моделью которого является дерево (ориентированный граф);

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

В одиной коллекции документов предметную область не выразишь.
(Как генеалогическое древо в документную СУБД уложить?)
Как только в рамках одной транзакции появляются взаимосвязанные документы возникают дедлоки.

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

Т.е. получаем возможность появления дедлоков.

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

>В couchdb целостность базы данных обеспечивается исключительно на уровне отдельных записей

«запись» в контексте couchdb это JSON-подобный документ, моделью которого является дерево (ориентированный граф);

В РСУБД целостность базы данных обеспечивается исключительно на уровне отдельных документов.

«документ» в контексте РСУБД это SQL-подобный текст, моделью которого является [неразборчиво]

//fixed

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

В РСУБД целостность базы данных обеспечивается исключительно на уровне отдельных документов.

Неверно. Скорее целостность на уровне кортежей.

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

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

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

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

>да, былинный опыт

Ты что-то перепутал, там нет слова «резюме»

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

>Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

в одном предложении сразу две ветряные мельницы.

Кто сказал, что _только_ использование NO-SQL СУБД, решает проблему deadlock? Да nosql вообще в целях своих не решал именно эту проблему. Просто упростили схему работы, убрали бОльшую часть транзакций (основной источник дедлоков) и подняли производительность базы и поэтому большинство дедлоков ушло. Не более того.

и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

А преимущество как раз значительное, вероятность появления дедлоков снижена на порядки.

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

> убрали бОльшую часть транзакций
В Mongodb есть транзакции?
Их там нет. Есть атомарность отдельного объекта коллекции и все.


А преимущество как раз значительное, вероятность появления дедлоков снижена на порядки.

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

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

> Как только в рамках одной транзакции появляются взаимосвязанные документы возникают дедлоки.

ITT носкулисты не могут понять эту простую истину.

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

>А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно.

1) Утверждение за весь NO-SQL, а претензии к конкретной реализации. Это неверно.

Транзакций пока нет,

Транзакции на уровне БД не обязательны.

разграничения прав доступа тоже нет.

и как же это большинтво финансовых систем использует для всех один логин к базе?

Ссылочной целостности нет.

которую опять таки обычно отключают в пользу триггеров.

Как элементарно перевести средства с одного счёта на другой без транзакций?

Версиями, метками в объектах, через очередь заданий.

А, теперь понял, трехзвенки до вас так и недошли?

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

>> убрали бОльшую часть транзакций

В Mongodb есть транзакции?

Их там нет. Есть атомарность отдельного объекта коллекции и все.

Читать: «убрали бОльшую часть необходимости в транзакциях»

Отсутствие транзакций не тянет на преимущество, скорее наоборот.

отсутсвие необходимости в транзакциях тянет на преимущество.

От дедлоков помогает грамотное проектирование структуры БД и логики обработки данных.

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

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

> Да, именно репликации. Какие БД позволяют симметрично реплицироваться? Чтобы работа с каждой шла автономно и реплицировалась на другую?

MS SQL. подозреваю что орацл и дб2 тоже умеют.

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

и как же это большинтво финансовых систем использует для всех один логин к базе?

Идиоты админы?

Транзакции на уровне БД не обязательны.

Обязательны

которую опять таки обычно отключают в пользу триггеров.

Не понял. Ссылочную целотность надобно отключать? Ccылочная целостность реализуют триггерами? Но как её реализовать, (ссылочную целостность) если атомарна работа только с одним объектом коллекции?

Как элементарно перевести средства с одного счёта на другой без транзакций?

Версиями, метками в объектах, через очередь заданий. т.е. реализуем транзакции самостоятельно? Зачем, если эту возможность можно заложить в СУБД?

Итого: 1. транзакции необходимы в СУБД 2. пока в Mongodb их нет 3. когда они появятся скорость обновлений данных упадет

По-прежнему нет ссылочной целостности. Та зачем тогда NOSQL. Может лучше расширить реляционную модель и добавить возможность хранения индексированных документов в строках таблиц?

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

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

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

А, теперь понял, трехзвенки до вас так и недошли?

трёхзвенка отменяет удобство использования транзакций без извращений с метками?

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

>> и как же это большинтво финансовых систем использует для всех один логин к базе?

Идиоты админы?

Скорее разработчики.

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

>MVCC в couchdb замечательно с этим справляется без локов.

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

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

>>Все бы хорошо, если бы не было так плохо: описанный пример (как и весь nosql) не позволяет делать атомарный update

не понял, мы в новости про монго или где?

http://www.mongodb.org/display/DOCS/Updating#Updating-update%28%29

update() replaces the document matching criteria entirely with objNew.

А атомарное обновление делается на стороне сервера, где он лочит весь объект, вычитывает его в буфер, обновляет и записывает обратно. Тот же read-modify-write, но только для одной копии, а что там с репликами? А что с репликами, если сервер с одной из копий был недоступен?

Распределенного атомарного апдейта там нет.

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

Анонимус доказал, что ему носиквел не нужен. Молодец.

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

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

>трёхзвенка отменяет удобство использования транзакций без извращений с метками?

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

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

>Как элементарно перевести средства с одного счёта на другой без транзакций?

Попробую:

{«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

вот, пожалуй, самое очевидное, что приходит в голову.

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

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

Смысла намного больше когда функционал транзакций реализован на уровне СУБД

Хотя трехзвенку я упомянул в первую очередь в связи с логином и уровнями доступа к БД.

У вас в трехзвенке сервер приложений единственным незашифрованным паролем с СУБД коннектится?

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

>Вопрос в том, что новые технологии обычно появляются тогда, когда старые подводят. И носиквел тому не исключение.

Ну, насчет «подводят», это все-таки lor_mode, а вот то, что всякие «ораклы» всовывают туда, где им не место — это да. Любой задристаный сайтик ведь должен быть непременно ЪНтырпрайез-SQL92, хранить картинки в файлах? фи, что за дикость и ниасиляция блобов?!

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

>> {«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Где первый и второй номер счёта?

что значит «первый и второй номер счёта»?

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

> что значит «первый и второй номер счёта»?

Номер счета, с которого деньги ушли, и номер счета, на который они пришли.

Еще интересно знать, что в данном случае является «документом» - счет или акт перевода денег?

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

>> {«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Где первый и второй номер счёта?

ок, специально для смущенных латиницей повторяю:

{«тип»:«проводка», «Дата»:«09.08.2010» «Дебет»:«50» «Кредит»:«51» «Сумма»:«100»}

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