Доступен (https://www.mongodb.com/blog/post/mongodb-multi-document-aci...) стабильный выпуск документо-ориентированной СУБД MongoDB 4.0 (https://www.mongodb.com/mongodb-4.0), которая занимает нишу между быстрыми и масштабируемыми системами, оперирующими данными в формате ключ/значение, и реляционными СУБД, функциональными и удобными в формировании запросов. Код MongoDB написан на языке C++ и распространяется (https://github.com/mongodb/mongo/) в рамках лицензии AGPLv3. Сборки MongoDB 4.0 сформированы (https://www.mongodb.org/downloads#community) для Linux, Windows и macOS.
MongoDB поддерживает хранение документов в JSON-подобном формате, имеет достаточно гибкий язык для формирования запросов, может создавать индексы для различных хранимых атрибутов, эффективно обеспечивает хранение больших бинарных объектов, поддерживает журналирование операций по изменению и добавлению данных в БД, может работать в соответствии с парадигмой Map/Reduce, поддерживает репликацию и построение отказоустойчивых конфигураций.В MongoDB имеются встроенные средства по обеспечению шардинга (распределение набора данных по серверам на основе определенного ключа), комбинируя который репликацией данных можно построить горизонтально масштабируемый кластер хранения, в котором отсутствует единая точка отказа (сбой любого узла не сказывается на работе БД), поддерживается автоматическое восстановление после сбоя и перенос нагрузки с вышедшего из строя узла. Расширение кластера или преобразование одного сервера в кластер производится без остановки работы БД простым добавлением новых машин.
Особенности (http://docs.mongodb.org/manual/release-notes/4.0/) нового (https://www.mongodb.com/mongodb-4.0) выпуска:
- Поддержка транзакций, удовлетворяющих требованиям ACID (атомарность, согласованность, изолированность, надежность) при обработке запросов, охватывающих несколько документов (многодокументные транзакции (https://docs.mongodb.com/manual/core/transactions/)). В контексте одного докумнта ACID-транзакции в MongoDB поддерживались изначально, но обеспечение изоляции на уровне нескольких документов было одним из наиболее часто высказываемых пользователями пожеланий. При помощи механизма изоляции на базе снапшотов (https://docs.mongodb.com/manual/reference/read-concern-snaps...) внутри транзакции теперь предоставляется целостное представление всех данных и возможность отката всех изменений в случае отмены транзакции, независимо от того сколько документов было вовлечено.
После модификации документа внутри транзакции для него выставляется блокировка операций записи (не влияет на чтение) до завершения транзакции или истечения таймаута (по умолчанию транзакция не может длиться более 60 секунд). До заврршения транзакции все внесённые в рамках транзакции изменения остаются невидимы для других запросов, в момент подтверждения транзакции изменения применяются атомарно. Синтаксис транзакций повторяет операции в реляционных СУБД - открытие транзакции (startTransaction) с последующим её подтверждением (commitTransaction) или сбросом (abortTransaction). В настоящее время многодокументные транзакции применимы только на уровне одного набора реплицированных данных (Replica Set), но в выпуске MongoDB 4.2 планируется обеспечить работу транзакций на уровне кластера MongoDB;
- Добавлены (https://docs.mongodb.com/manual/reference/operator/aggregati.../) новые агрегатные операторы для преобразования типов данных на стороне СУБД: универсальный оператор $convert для конвертации в любой указанный тип и привязанные к конкретным типам операторы $toBool, $toDate, $toDecimal, $toDouble, $toInt, $toLong,
$toObjectId и $toString;- Добавлены (https://docs.mongodb.com/manual/reference/operator/aggregati...) новые строковые операторы для вырезания пробелов или определённых символов вначале или в конце строки: $ltrim, $rtrim и
$trim;- В агрегатный оператор $dateFromString (https://docs.mongodb.com/manual/reference/operator/aggregati...) добавлена возможность определения формата разбора даты;
- Добавлена поддержка аутентификации SCRAM-SHA-256 (https://docs.mongodb.com/manual/core/security-scram/#authent...) на базе хэша SHA-256 (ранее предоставлялся SCRAM-SHA-1 на базе SHA-1) для организации более безопасного доступа по паролю. Поддержка устаревшего механизма аутентификации MONGODB-CR прекращена. По умолчанию отключена поддержка TLS 1.0 (для создания шифрованного канала связи требуется TLS 1.1+);
- Для интеграции с системами мониторинга добавлены новые привилегии
checkFreeMonitoringStatus и setFreeMonitoring (https://docs.mongodb.com/manual/administration/free-monitoring/);- Движок хранения MMAPv1 (https://docs.mongodb.com/manual/core/mmapv1/#storage-mmapv1) объявлен устаревшим и будет удалён в одном из следующих выпусков. Пользователям движка MMAPv1 (оригинальный движок MongoDB на базе отзеркаленных в память файлов) рекомендуется перейти (https://docs.mongodb.com/manual/tutorial/change-standalone-w.../) на движок WiredTiger (https://docs.mongodb.com/manual/core/wiredtiger/), который применяется по умолчанию, начиная с выпуска MongoDB 3.2;
- Прекращена поддержка репликации в режиме Master-Slave и протокола реплицирования данных pv0, вместо которых следует использовать (https://docs.mongodb.com/manual/core/master-slave/#convert-m...) набор реплик (Replica Set) и протокол pv1 (https://docs.mongodb.com/manual/reference/replica-configurat...);
- Встроенный JavaScript-движок обновлён до выпуска MozJS 45.9.0. По умолчанию в JavaScript-движке отключён JIT-компилятор;- Обновлены драйверы (https://docs.mongodb.com/ecosystem/drivers/) к MongoDB, совместимость с MongoDB 4.0 обеспечена в выпусках драйверов Java 3.8.0, Python 3.7.0, C 1.11.0,
C# 2.7, Node 3.1.0, Ruby 2.6.0, Perl 2.0.0, PHPC 1.5.0 и Scala 2.4.0;- Обеспечена интеграция с инструментарием оркестровки контейнеров Kubernetes для автоматизации развёртывания и поддержания сервисов с MongoDB в кластере Kubernetes.
URL: https://www.mongodb.com/blog/post/mongodb-multi-document-aci...
Новость: https://www.opennet.me/opennews/art.shtml?num=48878
Нужно
Что?
Что нужно?
Ну я и спрашиваю что. Аноним знает.
нужно удалить
... ещё добавить триггеры и встроенные процедуры.
и приделать, наконец, SQL.....
Добавлена поддержка показа рекламы https://medium.com/@StephenLynx/mongodb-4-0-or-why-are-...
прекрасно. Я давно искал повод (причину я придумаю) вынести нахрен эту дрянь со своих серверов (вот что-то в спинном мозге подсказывало - "оно - дрянь, брось!")А тут такой "coming out"... Рейзер сосьот со своими $25. Орацле лохи, до сих пор mysql даже не предлагает установить unbreakable kernel, не говоря уже об апгрейде до правильного линукса.
встраиваемая версия есть?
Отличная БД. MongoDB превосходно работает в паре с Node.JS (нужно будет доустановить немного NPM-пакетов). А если при этом запускать через systemd — вообще шик. Ну и запускать, естессно, на сервере, зайдя на него через ssh из великолепного GNOME, работающим под божественным Wayland (подойдет любой GTK+-based терминал, например gnome-terminal). Сам сервер лучше держать на Microsoft Azure, а работал бы он на Fedora с патчами от глубоко уважаемой команды Grsecurity. А исходники держать на GitHub, и править их из-под Microsoft Visual Studio Code или вообще средствами самого гитхаба через превосходный Google Chrome.Вот это я называю жизнь.
Хорошо, что у меня финкпад с дренажными отверстиями.
И на моём thинкпаде эти отверстия пригодились, когда я прочитал "финкпад" =).
Так толсто, что аж тонко
Классный стекб ))
Ты так всё это написал, как будто это смешно. Хотя так с этим работать можно и даже с комфортом.
Сильно вас прижарило на ЧМ по футболу
ЭСКУЕЛЬ устарел, говорили они, ЭРДЭБЭМЭС не годится!
> Поддержка транзакций, удовлетворяющих требованиям ACID ... охватывающих несколько документовНу это просто праздник какой то!
Ну опять же неполноценно... Да и в Spring оно придёт лишь через некоторое время...
> Ну опять же неполноценно... Да и в Spring оно придёт лишь черезЭто Spring-офилы то про неполноценность будут рассуждать?
Всегда не понимал, зачем оно нужно, если в Постгресе давно есть JSON/JSONB, которые ещё и быстрее.
Как ты будешь failover на ПГ делать? А как обновлять часть документа? Или ты по каждому чиху будешь десериализовывать весь объект, его изменять и повторять еще раз подобное?[сообщение отредактировано модератором]
> Как ты будешь failover на ПГ делать? А как обновлять часть документа?
> Или ты по каждому чиху будешь десериализовывать весь объект, его
> изменять и повторять еще раз подобное?Обновлением части документа как функцией монги вообще кто-нибудь пользуется? Обычно, с ней, как раз по каждому чиху и делают полную десериализацию/сериализацию. По крайней мере из Java/Spring
А вообще, нормализацию данных как раз и придумали для того, чтобы избежать избыточности и обеспечить оптимальную гранулярность обновления данных. Не важно, монга это или РСУБД.
> Обновлением части документа как функцией монги вообще кто-нибудь пользуется?
> Обычно, с ней, как раз по каждому чиху и делают полную десериализацию/сериализацию.Сам же расписался в былдокодерстве... и так у всех хейтерков Монги.
Монговский BSON в большинстве случаев позволяет полноценно работать без DTO, сразу на Document-ах.
Так не осилил?collection.updateOne(eq("id", id), Updates.pull("val", bla));
collection.updateOne(eq("id", id), Updates.set("val", bla));
collection.updateOne(eq("id", id), Updates.Updates.addToSet("val", bla));На большой вложенности приходится написать немного оберток, но за скорость надо платить.
С голым JDBC это всё равно не сравнить.
> А как обновлять часть документа?Приучаемся читать мануалы: https://www.postgresql.org/docs/current/static/functions-jso...
Можно и обновлять, и индексировать отдельные поля, и многое другое.
Великолепный ответ!
Postgres очень дорого и хрупко горизонтально масштабируется. И при этом вообще не эластичный (когда нужно без downtime с минимальным ручным вмешательством добавить или убавить несколько штук или десятков узлов) нифига.Такие системы как Mongo, Ignite, Cassandra предназначены для ситуаций, где нужно быстро и дешево горизонтально масштабироваться в высоконагруженной OLTP-системе, при необходимости оперативно доставлять и убирать узлы, обеспечивая эластичное масштабирование.
Так, например, Netflix в свое время тестировал Cassandra на кластерах до 288 узлов: https://medium.com/netflix-techblog/benchmarking-cassandra-s...
И даже делал утилиту для автоматического масштабирования:
https://medium.com/netflix-techblog/scryer-netflixs-predicti...
https://medium.com/netflix-techblog/scryer-netflixs-predicti...Ignite имеет кластеры на 2 000 узлов: https://www.gridgain.com/resources/videos/choosing-the-right...
MongoDB имеет кластеры с более чем 1 000 узлов: https://www.mongodb.com/mongodb-scale
Это OLTP и HTAP-базы, ориентированные на интенсивную нагрузку на запись и чтение.
Postgres в его кластеризуемых вариантах, например, GreenPlum, ориентирован, скорее на неспешный OLAP, на котором он будет, несомненно, на голову и корпус лучше вышеописанных решений из-за обильной поддержки SQL.
Используем MongoDB c версии 3.2 в нашей организации в 1000+ человек.
Хотели просто попробовать, но распробовав, разработчики просто отказываются пользоваться чем-то альтернативным.
При помощи атомарного обновления документа можно решать огромное число задач.Особо одаренные никак не могут понять, почему не использовать PostgreSQL с их JSONB. Вы реально не понимаете и не отличаете чем отличается нативных JSON (BSON) от просто поля с кучей данных, которое можно проиндексировать ?
Да у нас столько данных летит в MongoDB, что если бы мы каждый раз вытаскивали весь документ, что-то меняли и запихивали его обратно - имели бы проблему с CPU.Если тот же PosgreSQL при использовании, может просто изнасиловать ваш storage алгоритмами работы 70 годов (), MongoDB работает очень быстро и не вообще не вызывает проблем.
Они пишут на C++ и не решают руками тысячи проблем, которые PG'шники сами себе придумывают и обходят костылями.С транзакциями покроются вообще все кейсы работы и больше не услышим на всех конференциях - А почему вы не использовали PG? от секты свидетелей автоваакума.
А PG то почему не использовали?
> вы реально не понимаете и не отличаете чем отличается нативных JSON (BSON) от просто поля с кучей данных, которое можно проиндексировать ?У монги большие проблемы с индексацией вложенных массивов. Как только реально сложные структуры данных начинаются, всё сводится с тому, что надо раскладывать данные в одноуровневые записи. Никаких вложенных объектов внутри массивов. И чем это лучше таблиц PG?
А в отношении работы в кластере, разве в монге проблему грязного чтения устранили? Или, может быть, устранили стабильность БД при внезапной перезагрузке сервера?
> У монги большие проблемы с индексацией вложенных массивов. Как только реально сложные структурыРаботаю с ЕГРЮЛ, это 5-7 уровневые XMLки весом до пары мегабайт. Когда уже проблемы-то начнутся?
Хвалёное быстрейшество Слонище с его JSONB кстати, на вставку имеет 200 документов в сек (в 10 раз медленнее Mongo). На этом мое знакомство с Pg закончилось.
> А в отношении работы в кластере, разве в монге проблему грязного чтения устранили?
withReadPreference(ReadPreference.primary()
не? Причём можно гибко, где надо читаем с Primary, где не надо с Nearest.>Или, может быть, устранили стабильность БД при внезапной перезагрузке сервера?
Неужели сервер с другими СУБД не перестает работать при перезагрузке питания? Вот так поворот!
>> Неужели сервер с другими СУБД не перестает работать при перезагрузке питания? Вот так поворот!Вы удивитесь, но это ключевое свойство СУБД.
Mongo пригодна только когда вам нужно хранить помои (вроде егрюлей всяких бесполезных). Если данные невозможно структурировать, то они, чаще всего, никому не нужны. Но это моё личное мнение.
Когда попробуете ее по-настоящему использовать и поймете ее фишки вникните в ее парадигму, вы вдруг осознаете, что РСУБД вам будут нужно в 1% кейсов и то, версия 4.0 покрыла и эти возможности.
Сам пользуюсь монгой достаточно давно. Раньше были проблемы, но сейчас это одна из лучших баз.
Пробовал 3-тью версию. Не совпадает с моим опытом. Не понравился и характер... экосистемы. Книги про Монгу совершенно не раскрывают, даже и не пытаются, её "внутренности". Если как работает Оракл, Сиквел или Слон я понимаю, то как работает Монга -- нет.
Разработчики отказываются, потому что им лень что-то делать. Могут только смузи пить
> Разработчики отказываются, потому что им лень что-то делать. Могут только смузи питьСмузи это хорошо. Я люблю пить смузи
Для многих кейсов перешли на MongoDB. Она нас просто спасает.
Очень жаль, озлобленных людей, которые постоянно ее поносят, потому как в сегодняшнем своем состоянии она на голову выше всех остальных баз.
Самое забавное - многие хейтеры даже не пытались ее использовать.
Ты сам-то давно использовал в позах, отличных от однонодовой, сконфигурированной по-дефолту конфигурации?
А?
Я использовал. Для эксплуатации монга — боль. В том числе тихое повреждение данных на высоких rps смешанной нагрузки. А уж как в таких положениях смешно разваливается монговская «кластеризация»… ммм… любо дорого посмотреть.Вам, фанатикам, правда, это не интересно. Вы маркетинговыми документами обмазались и рассказали руководству, как оно будет хорошо. Страдать не вам.
Покажите пожалуйста тикет на jira.mongodb.org, где описывается данная проблема и где
тебе разработчики говорят - что она есть и мы ее еще не исправили?
Очень смешно слышать о подобном, т.к знаю множество организаций, ее использующих и проблем ни у кого не возникало. Сейчас MongoDB это business critical во многих западных компаниях и сейчас сильно набирает популярность в России, поэтому о неспособности работы ее базовых функций слышать смешно.У нас 2000 rps в replica-sets и никаких проблем не имеем (нагрузка смешанная, очень много inserts и updates).
Не нужны тикеты, чтобы убедиться что способ кластеризации, который использует Mongo - defected by design, да и создание такого тикета в жире монги равносильно декларации "У вас там пздц с кластеризацией, ребята". Решать эту проблему, хотя прекрасно о ней осведомлены, разработчики, судя по всему, не хотят
> У нас 2000 rps в replica-sets и никаких проблем не имеемСоздай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до ротации - реплика отвалится, удачи.
>> У нас 2000 rps в replica-sets и никаких проблем не имеем
> Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до
> ротации - реплика отвалится, удачи.Если ты знаешь как работает реплика, зачем делаешь херню ?
Если не знаешь, то не подходи к инструменту
>>> У нас 2000 rps в replica-sets и никаких проблем не имеем
>> Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до
>> ротации - реплика отвалится, удачи.
> Если ты знаешь как работает реплика, зачем делаешь херню ?
> Если не знаешь, то не подходи к инструментуэто вы утверждали что нет проблем, а не я
>> У нас 2000 rps в replica-sets и никаких проблем не имеем
> Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до
> ротации - реплика отвалится, удачи.Можно просто увеличить размер оплога
Поддерживаю, использовал на двух высоконагружпнных сервисах. Отличное решение для многих задач. Но деньги по понятным причинам хранили в postgres :)
> Для многих кейсов перешли на MongoDB. Она нас просто спасает.
> Очень жаль, озлобленных людей, которые постоянно ее поносят, потому как в сегодняшнем
> своем состоянии она на голову выше всех остальных баз.Что значит выше? Падает стремительнее?
Монга хороша для некоторых специфичных задач. Например использовать как помойку для документов, структура которых не определена. Причём желательно, не дёргать её OLTP-нагрузкой, как и не пытаться использовать её как аналитическую СУБД.
С чем можно согласиться, так это с тем, что если пишешь на Жаве, то не надо думать о DDL для инициализации структур данных. Но реально же, крайне мало кто использует бессхемность монги. Почти все работают только с жесткой структурой данных, также как с реляционкой. При этом PG, например, почти гарантирует надежность хранения данных. Монга ничего не гарантирует. И скорость у неё только потому, что по умолчанию буфер со сбросом на диск чуть ли не раз в минуту.
> Монга хороша для некоторых специфичных задач. Например использовать как помойку для документов, структура > которых не определена. Причём желательно, не дёргать её OLTP-нагрузкой, как и не пытаться использовать её > как аналитическую СУБД.Она прекрасно разруливает OLTP нагрузку, т.к для нее и предназначена, не говорите бред.
Может быть до движка WiredTiger могли быть какие-либо проблемы, но сейчас и точно нет, что подтверждается личным опытом.
Представляете, она лучше справляется с ней в отличие от того же PostgreSQL, потому что ей не нужен Vacuum, ей не нужно перестраивать индексы из-за write amplification и дальше по мелочам.
OLAP нагрузку тоже держит и появляется множество инструментов, которые помогают с запросами. Вы наверное последнее что делали - запускали MapReduce, который вообще никто не использует сейчас.> При этом PG, например, почти гарантирует надежность хранения данных
PosgtreSQL теряет данные, просто кукарекающие фанатики не видят и не хотят это видеть. PG это прежде всего коммерциализированное сообщество, отдельные личности которого хотят поиметь денег, т.к с начала 90х годов пытаются впарить PG во все организации, но получаться у них стало только недавно.
Я не против PG, просто не нужно говорить что MongoDB это маркетинг, т.к у PG маркетинговая компания гораздо мощнее и напористее.> Монга ничего не гарантирует
Ну что за бред? У Монги есть такой же WAL лог, который нужен для восстановления.
Такое ощущение, что хейтерство MongoDB это такая же маркетинговая фигня от сообщества PostgreSQL, т.к эти попытки набросить просто уже набили оскомину и не поддаются никакой логики.
Монга НИЧЕГО НЕ ТЕРЯЕТ, запомните это и прекратите тиражировать. Она не теряет данные ни в standalone вариант, ни в распределенном (посмотрите результаты jepsen test)
> Ну что за бред? У Монги есть такой же WAL лог, который нужен для восстановления.
> Такое ощущение, что хейтерство MongoDB это такая же маркетинговая фигня от сообщества PostgreSQL, т.к эти попытки набросить просто уже набили оскомину и не поддаются никакой логики.
> Монга НИЧЕГО НЕ ТЕРЯЕТ, запомните это и прекратите тиражировать. Она не теряет данные ни в standalone вариант, ни в распределенном (посмотрите результаты jepsen test)Ок... И сервера работают без сбоев, память всегда сбрасывается на диск..... Уважаемый, в последний раз тесты, однозначно показывающие проблемы надёжности монги, включая отсутствие сброса буфера в "есть такой же WAL лог" и грязное чтение, видел года 3 назад. Проблема в том, что для того, чтобы поверить в стабильность монги сейчас, нужны реальные бенчмарки, которые это ДОКАЗЫВАЮТ. Надо доказывать, что она справилась с проблемами. Причём для демонстрации нагрузки вполне можно использовать семейства TPC.
> (посмотрите результаты jepsen test)
Version Lost updates Dirty Reads Stale Reads
3.4.0-rc3 Allowed (v1 bugs) Kinda Kinda
3.4.0-rc4 Allowed (v1 bugs) Kinda Kinda
3.4.0 Prevented Prevented Prevented
----------------------------------------------------------
ok... Грязное чтение пофиксили к началу 17-го года. Что на счёт сброса буфера?....
PS: не увлекайтесь фразами типа "Ну что за бред?". Для вашего лечебного заведения, может быть, это и норма общения, но не в технической среде.
> И сервера работают без сбоев, память всегда сбрасывается на дискЗдесь все базы в одной лодке.
> Грязное чтение пофиксили к началу 17-го года. Что на счёт сброса буфера?
Для Release Candidate сборок, где добавлялся новый способ чтения данных, ошибки - это нормально.
WAL лог был, но журналирование было отключено по умолчанию. Начиная с 3.2 версии его включили по умолчанию, поэтому на сброс буфера можно не ориентироваться. Драйвер не отдаст управление вызывающему коду, пока запись не запишется в журнал.
Не понимаю, почему когда PG теряет данных и крашит БД никто так сильно не расписывает это по форумам ?
> Не понимаю, почему когда PG теряет данных и крашит БД никто так сильно не расписывает это по форумам ?Вероятно потому, что за PG никогда не водилось терять данные за последнюю минуту с настройками по умолчанию.... Если у вас идёт поток платёжек, а СУБД позволяет себе терять последнюю минуту, то это как-то дорого получается.... Именно так монга была настроена, как минимум, до 3-х версий.
Ну и скорость работы монги с включенным синхронным режимом была даже не на один порядок ниже PG, у которого синхронный режим включен по умолчанию. Может, конечно, в 4-й версии поправили, но нужны независимые бенчмарки.
>последнюю минуту с настройками по умолчаниюЛамеры не палятся )))
>Если у вас идёт поток платёжек, а СУБД позволяет себе терять последнюю минуту
Тебя на мыло, если у тебя падающий сервер вызывает потерю данных. С любой СУБД ;)
Вообще, с монгой 3.4++ надо сильно постараться, что даже падающий мастер вызвал потерю данных.А ещё и за последнюю минуту - это несусветный бред.
> Тебя на мыло, если у тебя падающий сервер вызывает потерю данных. С любой СУБД ;) Вообще, с монгой 3.4++ надо сильно постараться, что даже падающий мастер вызвал потерю данных.
> А ещё и за последнюю минуту - это несусветный бред.Товарищ только вчера примкнул к программисткому сообществу?.... Откуда вас столько медработников взялось?....
Извините, но Монга принципиально теряет данные и "выдумывает" их. В этом кроются её плюсы, как ни странно. Вы, по сути, переключаетесь, в терминах РСУБД, в режим грязного чтения. Да, это приводит к радикальному сокращению транзакционных издержек, но, опять же, нужно здраво осознавать какой ценой. Для каких-то случаев такой подход вполне приемлем. Типично, да, это помойка данных, т.е. когда заказчику нужно хранить какую-то никчёмную, но обязательную чушь, которая практически никогда не подвергается критическому анализу, а если и подвергается, то риск вскрытых в результате коллизий дёшев.
>теряет данные и "выдумывает" их.
>режим грязного чтенияну и клоун, причём повторяешь этот бред в каждой теме.
Это память у тебя теряется и выдумывается каждый раз новая
> потому что ей не нужен Vacuum, ей не нужно перестраивать индексыВас само слово Вакуум пугает? Механизмы очистки исторических данных есть во всех MVCC-СУБД. И в PG такой механизм вполне на уровне прочих. Слон не супер-субд-для-всего, но вы как-то довольно странно трактуете критерии сравнения.
> Вас само слово Вакуум пугает?Ну распиши тут как делать vacuum full когда 80% storage занято.
Для сравнения в Монго этого делать не надо никогда. Профит...
> Для сравнения в Монго этого делать не надо никогда. Профит...Всерьёз считаете, что в монге изобрели новые способы хранения индексов? И о страничной организации они ничего не слышали?
Шли бы в Кнута, для начала....
>> Для сравнения в Монго этого делать не надо никогда. Профит...
> Всерьёз считаете, что в монге изобрели новые способы хранения индексов? И о
> страничной организации они ничего не слышали?
> Шли бы в Кнута, для начала....Почитайте, для чего нужен ваакуум для начала и поймите лучше, что вам хотят сказать
>> Вас само слово Вакуум пугает?
> Ну распиши тут как делать vacuum full когда 80% storage занято.
> Для сравнения в Монго этого делать не надо никогда. Профит...Да, профит Монги в том, что у неё нет ни транзакций, ни согласованности данных по времени и это вообще не БД. Я и не спорю, если вам не нужна БД, то Монга (по крайней мере 3-ка) прекрасно подойдёт. Есть ещё Дельфин, но если всё с чем ты сталкивался это JS, то Дельфин тоже не катит -- там какой-то sql ещё нужен.
Только у PostgreSQL MVCC сделан так костыльно, что они уже замучались выдумывать варианты его обхода.
Понимаете, в нормальных базах данных, старые кортежи от транзакций перемещаются в другую область данных и в случае отката транзакции - копируются назад. И только в PG база срет там где жрет - и вычищает старые данные только по расписанию и из-за этого таблицы так раздуваются, что становится просто стыдно.И не нужно говорить, что все базы устроены одинаково - нормальные базы изначально спроектированы адекватно, в отличие от поделки PG.
Хорошо что они знают о проблеме и пытаются ее решить.
> Понимаете, в нормальных базах данных, старые кортежи от транзакций перемещаются в другую
> область данных и в случае отката транзакции - копируются назад. И
> только в PG база срет там где жрет - и вычищает
> старые данные только по расписанию и из-за этого таблицы так раздуваются,
> что становится просто стыдно.Понимаю я другое -- я очень хорошо знаю, как работает механизм MVCC Оракла и Сиквела (они достаточно нормальные?). Оракл вообще не хранит старые "кортежи", а хранит данные как вернуть состояние блока к исходному состоянию, в результате операции отката в Оракле крайне дорогие. В Сиквеле, в новых версиях, да, изменённые данные со всех БД сбрасываются в БД Temp. В результате сбой Temp-а приводит к развалу всех БД. К тому же, создаёт существенные накладные расходы на копирование данных (и увеличивает вероятность сбоя), которые копировать совершенно не нужно. Слон же, при адекватно настроенном автовакууме, работает куда менее накладно в результате. У Слона есть проблемы с длинными транзакциями, потому что фактически время транзакции ничем не ограничено, у него "snapshot too old" не бывает никогда. Но начиная с 10-ки есть вариант сделать очень похоже на оракл по поведению, когда слишком длительные транзакции будут просто откатываться со временем.
Накладно при откате ?
Мы говорим про нормальную работу БД, где коммиты происходят значительно чаще чем откаты. Зачем PG нужен этот мусор? Если бы их все устраивало, они бы на каждой конфе не говорили, что хотят переписать движок и сделать его таким же как у Oracle
> Накладно при откате ?
> Мы говорим про нормальную работу БД, где коммиты происходят значительно чаще чем
> откаты. Зачем PG нужен этот мусор? Если бы их все устраивало,
> они бы на каждой конфе не говорили, что хотят переписать движок
> и сделать его таким же как у OracleО каком мусоре речь? Это, батенька, не мусор, а многоверсионность. В её самой напрашивающейся реализации -- хранить исторические данные о данных в виде самих этих... данных. В Оракле подход другой, в Оракле хранят довольно сложно устроенный код, как собрать состояние блока на любой момент в прошлом (в пределах объёма сегмента отката). Какой подход лучше -- бесполезный спор(т).
Обслуживание же MVCC в Слоне тема давно уже не болезненная. Просто нужно делать автовакуум очень часто. Вот и всё. Очень-очень часто. Да и не ясно к чему о ней тут.
> Монга НИЧЕГО НЕ ТЕРЯЕТ, запомните это и прекратите тиражировать. Она не теряет
> данные ни в standalone вариант, ни в распределенном (посмотрите результаты jepsen
> test)А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления? Какие есть варианты?
> А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления?Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот транзакция1 прилетела и сказала update blatable set blacol = 3 where id = 1; а параллельно прилетела транзакция2 и сказала update blatable set blacol = 13 where id = 1;
обе команды выполнятся в порядке прихода, кто последний тот и папа.
Что в Монго 2, что 3, что 4. Что в орацле. Что гундишь то?
>> А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления?
> Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот
> транзакция1 прилетела и сказала update blatable set blacol = 3 where
> id = 1; а параллельно прилетела транзакция2 и сказала update blatable
> set blacol = 13 where id = 1;
> обе команды выполнятся в порядке прихода, кто последний тот и папа.
> Что в Монго 2, что 3, что 4. Что в орацле. Что
> гундишь то?Э, ну там, всякие разные "уровни изоляции транзакций" бывают. Но не парься, я тебя понял.
> Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот
> транзакция1 прилетела и сказала update blatable set blacol = 3 where
> id = 1; а параллельно прилетела транзакция2 и сказала update blatable
> set blacol = 13 where id = 1;
> обе команды выполнятся в порядке прихода, кто последний тот и папа.Одиночный апдейт должен быть атомарен в любой субд, так что пример неподходящий. Лучше такой пример
Select num into :n where id=1;
:n:=:n+1;
Update set num=:n where id=1;
>Select num into :n where id=1; :n:=:n+1; Update set num=:n where id=1;Извиняюсь, это что за индусятина? В SQL это делается одной операцией update bla
set num = num + 1 where id = 1Ну и в монго это всю жисть было атомарной операцией
db.bla.update({id:1},{ $inc: { num: 1} })
И причём тут две конкурентные транзакции, за что конкурируете, господа SQL аналитики?
>>Select num into :n where id=1; :n:=:n+1; Update set num=:n where id=1;
> Извиняюсь, это что за индусятина? В SQL это делается одной операцией update
> bla
> set num = num + 1 where id = 1Ясен пень ,что можно сделать одной операцией. Это простой пример составной операции, хоть и искуственный.
Охохонюшка, ответ куда проще: в Монге нет транзакций )))) поэтому и нет обработки конкурентного изменения. В Монге всё валится в кучу без разбора. В Монге длительная операция может упорно что-то там изменять, а другая, начавшаяся после, но короткая, видит такие "сырые" изменения и без проблем фигачит прямо по ним. Нет никакой изоляции, потому что (вот так новость) транзакций-то нет. Поэтому нет никакой защиты от фантомов, нет никакой атомарности изменений в принципе. В 4-ке их заявляют, но, есть предположение, работать это будет так же медленно, как и работа с блобами в любой другой РСУБД -- потому что ничем от неё не отличается принципиально.
>В Монге длительная операция может упорно что-то там изменять, а другая, начавшаяся после, но короткая, видит такие "сырые" изменения и без проблем фигачит прямо по нимЕсли это недопустимо и тем не менее происходит, то вывод ровно один: прогер ленивый олень.
Тут один уже отписался, что "ну $set же никто не использует, все олени за replace"Открою страшную тайну: с труЪ СУБД + ORM фреймворк у того же самого оленя будут те же самые проблемы, он делает entity managed, чего-то там с ним долго делает, если кто-то другой дернет глобальный update, то persist() на эту entity перезапишет результаты глобального апдейта.
ОКей, без ORM фреймворк эта проблема тоже никуда не делась. Если у тебя разные процессы живут своей жизнью и один делает глобальный UPDATE, то выполнятся они по очереди, но проблема перезаписи данных никуда не ушла.
Зависит от орм-а. Если вы о реализациях JPA, то версионность часть стандарта, так что такая ситуация менеджером обрабатывается. Тут важнее понимать, что происходит.
> Одиночный апдейт должен быть атомарен в любой субдВопрос-то, видимо, не в этом. Вот есть у вас транзакция А -- очень длительная и сложная. Эта А началась в Т1. И есть тразакция В -- короткая и простая. В началась в Т2. Так уж сложилось, что подпадающие под критерии обоих транзакций данные пересекаются. Причём так, что если бы А зафиксировалась до Т2, то данные перестали бы соответствовать критериям В. Но А до Т2 не зафиксировалась, но данные уж поменяла и идёт дальше. В же видит данные на момент Т2 и они соответствуют её критериям выбора на изменение и меняет их, затем фиксируется в Т3. В Т125 наконец приходит время фиксироваться транзакции А. Но оказывается, что транзакция В, хотя и пришла после А, но данные уже поменяла и давно пофиксила. И вот тут начинается самое интересное...
Ну это вааще роскомнадзор какой-то
> Она прекрасно разруливает OLTP нагрузку, т.к для нее и предназначена, не говорите
> бред.
> Может быть до движка WiredTiger могли быть какие-либо проблемы, но сейчас и
> точно нет, что подтверждается личным опытом.... К примеру, у меня есть объект-коллекция, который содержит несколько сот миллионов одинаковых элементов. В случае схемного ORM это моделируется, и фактически хранится, двумя строками в двух отношениях. Как это будет отображено в случае Монги? Искренне интересно.
> Монга хороша для некоторых специфичных задач.До 4.0 была хороша для 70-80% задач. С ACID уже стала хороша для 95% задач. Ой?
> Но реально же, крайне мало кто использует бессхемность монги. Почти все
> работают только с жесткой структурой данных, также как с реляционкой.Не пиши бред. BSON местами уместнее POJO (там где не надо методов).
> Монга ничего не гарантирует. И скорость у неё только потому, что по умолчанию буфер
> со сбросом на диск чуть ли не раз в минуту.commitIntervalMs Default: 100 or 30
(Карл, разрешенный максимум 500мс)
>> Монга хороша для некоторых специфичных задач.
> До 4.0 была хороша для 70-80% задач. С ACID уже стала хороша
> для 95% задач. Ой?Монго не хороша для любых задач, для которых не хороши документные СУБД. Т.е. если есть корреспондированные сущности, если есть композиции любого вида, если есть строгие требования к прецеденции и согласованности модели в любой момент времени. Получается -- документные СУБД непригодны ни для чего, кроме как готовой инфры для организации сериализации и не строгой репликации объектов между площадками. Ну или когда у клиента есть строго завязанный на сложившийся документооборот процесс, в котором его надёжность обеспечивается административно, а не программно.
> желательно, не дёргать её OLTP-нагрузкойЭто PostgreSQL не нужно дергать OLTP нагрузкой, т.к у него нет Hard&Soft parse как у Oracle, т.к сложные запросы не кэшируются а разбираются заново каждый раз. Если кэш только в рамках сессии.
А с учетом того, что pooling для запросов встроенного в PG нет и приходится встраивать сторонние решения в лице PgBouncer - догадайтесь, как можно что-то кешировать и задавать параметры сессии, если твой connection может достаться другому.
>> желательно, не дёргать её OLTP-нагрузкой
> Это PostgreSQL не нужно дергать OLTP нагрузкой, т.к у него нет Hard&Soft
> parse как у Oracle, т.к сложные запросы не кэшируются а разбираются
> заново каждый раз. Если кэш только в рамках сессии.
> А с учетом того, что pooling для запросов встроенного в PG нет
> и приходится встраивать сторонние решения в лице PgBouncer - догадайтесь, как
> можно что-то кешировать и задавать параметры сессии, если твой connection может
> достаться другому.Всё не так драматично. В Оракле больше нет никакого хард- и софт- разбора. Анализатор сам решает, как параметризовать и кэшировать разборы. Слоне действует точно так же, только, увы, на мой взгляд, менее эффективно пока.
Отсутствие разделяемых сессий в Слоне тоже не проблема: во-первых, полно сторонних решений для построения очередей, а, во-вторых, очереди вообще редко в каких решениях нужны -- чаще всего есть только один сеанс и это сеанс с сервером приложений, у которого есть свой пуллинг.
Секундочку, я наверное что-то пропустил, в MongoDB наконец-то появились нормальные транзакции или это всё та же грёбaнaя атомарность?
> Секундочку, я наверное что-то пропустил, в MongoDB наконец-то появились нормальные транзакции
> или это всё та же грёбaнaя атомарность?Нормальные - не появились. Судя по описанию, появились минимально возможные для последовательности операций. Видимо, тупо с полной блокировкой всего.
По-моему, некорретно называть Монго СУБД. Монго, всё же, это мета-файловая система. Функционально она ничем не лучше сочетания, скажем, работающего по верх zfs grep-а. Ну в сочетании с какой-нибудь технологией блочной репликации.
Ну что ты несешь? Сидели бы по углам и не вылазили