Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
Сообщение от opennews (??), 29-Июн-18, 17:05
Доступен (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.dev/opennews/art.shtml?num=48878
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
Сообщение от Аноним (1), 29-Июн-18, 17:05
Нужно
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от A.Stahl (ok), 29-Июн-18, 17:17
	Что?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
	Сообщение от dkgnim (?), 29-Июн-18, 17:24
	Что нужно?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от A.Stahl (ok), 29-Июн-18, 17:37
	Ну я и спрашиваю что. Аноним знает.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	17. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+6 +/–
	Сообщение от Catwoolfii (ok), 29-Июн-18, 23:03
	нужно удалить
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от A (?), 29-Июн-18, 17:59
	... ещё добавить триггеры и встроенные процедуры.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+13 +/–
	Сообщение от Аноним (7), 29-Июн-18, 18:18
	и приделать, наконец, SQL.....
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

5. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+7 +/–
Сообщение от Аноним (5), 29-Июн-18, 17:38
Добавлена поддержка показа рекламы https://medium.com/@StephenLynx/mongodb-4-0-or-why-are-...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от пох (?), 29-Июн-18, 19:21
	прекрасно. Я давно искал повод (причину я придумаю) вынести нахрен эту дрянь со своих серверов (вот что-то в спинном мозге подсказывало - "оно - дрянь, брось!") А тут такой "coming out"... Рейзер сосьот со своими $25. Орацле лохи, до сих пор mysql даже не предлагает установить unbreakable kernel, не говоря уже об апгрейде до правильного линукса.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Релиз документо-ориентированной СУБД MongoDB 4.0"	–1 +/–
Сообщение от ляликс (?), 29-Июн-18, 19:08
встраиваемая версия есть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+10 +/–
Сообщение от Аноним (10), 29-Июн-18, 20:08
Отличная БД. MongoDB превосходно работает в паре с Node.JS (нужно будет доустановить немного NPM-пакетов). А если при этом запускать через systemd — вообще шик. Ну и запускать, естессно, на сервере, зайдя на него через ssh из великолепного GNOME, работающим под божественным Wayland (подойдет любой GTK+-based терминал, например gnome-terminal). Сам сервер лучше держать на Microsoft Azure, а работал бы он на Fedora с патчами от глубоко уважаемой команды Grsecurity. А исходники держать на GitHub, и править их из-под Microsoft Visual Studio Code или вообще средствами самого гитхаба через превосходный Google Chrome. Вот это я называю жизнь.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+4 +/–
	Сообщение от Аноним (12), 29-Июн-18, 20:14
	Хорошо, что у меня финкпад с дренажными отверстиями.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	34. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Q2W (?), 01-Июл-18, 00:41
	И на моём thинкпаде эти отверстия пригодились, когда я прочитал "финкпад" =).
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	13. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+2 +/–
	Сообщение от Аноним (13), 29-Июн-18, 20:59
	Так толсто, что аж тонко
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
	Сообщение от Вареник (?), 29-Июн-18, 21:24
	Классный стекб ))
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	16. "Релиз документо-ориентированной СУБД MongoDB 4.0"	–2 +/–
	Сообщение от IRASoldier (?), 29-Июн-18, 22:24
	Ты так всё это написал, как будто это смешно. Хотя так с этим работать можно и даже с комфортом.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	43. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Попугай Кеша (?), 02-Июл-18, 09:58
	Сильно вас прижарило на ЧМ по футболу
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
Сообщение от Аноним (11), 29-Июн-18, 20:09
ЭСКУЕЛЬ устарел, говорили они, ЭРДЭБЭМЭС не годится!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
Сообщение от Rodegast (ok), 29-Июн-18, 21:37
> Поддержка транзакций, удовлетворяющих требованиям ACID ... охватывающих несколько документов Ну это просто праздник какой то!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
	Сообщение от Аноним (20), 30-Июн-18, 08:31
	Ну опять же неполноценно... Да и в Spring оно придёт лишь через некоторое время...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	42. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 06:13
	> Ну опять же неполноценно... Да и в Spring оно придёт лишь через Это Spring-офилы то про неполноценность будут рассуждать?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

18. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+3 +/–
Сообщение от Аноним (18), 30-Июн-18, 00:59
Всегда не понимал, зачем оно нужно, если в Постгресе давно есть JSON/JSONB, которые ещё и быстрее.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Релиз документо-ориентированной СУБД MongoDB 4.0"	–2 +/–
	Сообщение от Аноним (19), 30-Июн-18, 01:51
	Как ты будешь failover на ПГ делать? А как обновлять часть документа? Или ты по каждому чиху будешь десериализовывать  весь объект, его изменять и повторять еще раз подобное? [сообщение отредактировано модератором]
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (20), 30-Июн-18, 08:34
	> Как ты будешь failover на ПГ делать? А как обновлять часть документа? > Или ты по каждому чиху будешь десериализовывать  весь объект, его > изменять и повторять еще раз подобное? Обновлением части документа как функцией монги вообще кто-нибудь пользуется? Обычно, с ней, как раз по каждому чиху и делают полную десериализацию/сериализацию. По крайней мере из Java/Spring А вообще, нормализацию данных как раз и придумали для того, чтобы избежать избыточности и обеспечить оптимальную гранулярность обновления данных. Не важно, монга это или РСУБД.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	46. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 10:26
	> Обновлением части документа как функцией монги вообще кто-нибудь пользуется? > Обычно, с ней, как раз по каждому чиху и делают полную десериализацию/сериализацию. Сам же расписался в былдокодерстве... и так у всех хейтерков Монги. Монговский 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 это всё равно не сравнить.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	22. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+3 +/–
	Сообщение от Инна Друзь (?), 30-Июн-18, 13:39
	> А как обновлять часть документа? Приучаемся читать мануалы: https://www.postgresql.org/docs/current/static/functions-jso... Можно и обновлять, и индексировать отдельные поля, и многое другое.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	81. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от анонсим (?), 04-Июл-18, 23:28
	Великолепный ответ!
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	85. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от MadeInRussia (?), 05-Июл-18, 13:59
	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.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

23. "Релиз документо-ориентированной СУБД MongoDB 4.0"	–2 +/–
Сообщение от Аноним (23), 30-Июн-18, 16:15
Используем MongoDB c версии 3.2 в нашей организации в 1000+ человек. Хотели просто попробовать, но распробовав, разработчики просто отказываются пользоваться чем-то альтернативным. При помощи атомарного обновления документа можно решать огромное число задач. Особо одаренные никак не могут понять, почему не использовать PostgreSQL с их JSONB. Вы реально не понимаете и не отличаете чем отличается нативных JSON (BSON) от просто поля с кучей данных, которое можно проиндексировать ? Да у нас столько данных летит в MongoDB, что если бы мы каждый раз вытаскивали весь документ, что-то меняли и запихивали его обратно - имели бы проблему с CPU. Если тот же PosgreSQL при использовании, может просто изнасиловать ваш storage алгоритмами работы 70 годов (), MongoDB работает очень быстро и не вообще не вызывает проблем. Они пишут на C++ и не решают руками тысячи проблем, которые PG'шники сами себе придумывают и обходят костылями. С транзакциями покроются вообще все кейсы работы и больше не услышим на всех конференциях - А почему вы не использовали PG? от секты свидетелей автоваакума.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
	Сообщение от Аноним (27), 30-Июн-18, 20:04
	А PG то почему не использовали?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	30. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (7), 30-Июн-18, 21:25
	> вы реально не понимаете и не отличаете чем отличается нативных JSON (BSON) от просто поля с кучей данных, которое можно проиндексировать ? У монги большие проблемы с индексацией вложенных массивов. Как только реально сложные структуры данных начинаются, всё сводится с тому, что надо раскладывать данные в одноуровневые записи. Никаких вложенных объектов внутри массивов. И чем это лучше таблиц PG? А в отношении работы в кластере, разве в монге проблему грязного чтения устранили? Или, может быть, устранили стабильность БД при внезапной перезагрузке сервера?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 06:00
	> У монги большие проблемы с индексацией вложенных массивов. Как только реально сложные структуры Работаю с ЕГРЮЛ, это 5-7 уровневые XMLки весом до пары мегабайт. Когда уже проблемы-то начнутся? Хвалёное быстрейшество Слонище с его JSONB кстати, на вставку имеет 200 документов в сек (в 10 раз медленнее Mongo). На этом мое знакомство с Pg закончилось. > А в отношении работы в кластере, разве в монге проблему грязного чтения устранили? withReadPreference(ReadPreference.primary() не? Причём можно гибко, где надо читаем с Primary, где не надо с Nearest. >Или, может быть, устранили стабильность БД при внезапной перезагрузке сервера? Неужели сервер с другими СУБД не перестает работать при перезагрузке питания? Вот так поворот!
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	50. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Кузя (?), 02-Июл-18, 16:07
	>> Неужели сервер с другими СУБД не перестает работать при перезагрузке питания? Вот так поворот! Вы удивитесь, но это ключевое свойство СУБД. Mongo пригодна только когда вам нужно хранить помои (вроде егрюлей всяких бесполезных). Если данные невозможно структурировать, то они, чаще всего, никому не нужны. Но это моё личное мнение.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	63. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от anonymous (??), 03-Июл-18, 14:54
	Когда попробуете ее по-настоящему использовать и поймете ее фишки вникните в ее парадигму, вы вдруг осознаете, что РСУБД вам будут нужно в 1% кейсов и то, версия 4.0 покрыла и эти возможности. Сам пользуюсь монгой достаточно давно. Раньше были проблемы, но сейчас это одна из лучших баз.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	64. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Кузя (?), 03-Июл-18, 17:43
	Пробовал 3-тью версию. Не совпадает с моим опытом. Не понравился и характер... экосистемы. Книги про Монгу совершенно не раскрывают, даже и не пытаются, её "внутренности". Если как работает Оракл, Сиквел или Слон я понимаю, то как работает Монга -- нет.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	36. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
	Сообщение от Bekka (?), 01-Июл-18, 10:48
	Разработчики отказываются, потому что им лень что-то делать. Могут только смузи пить
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	44. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Попугай Кеша (?), 02-Июл-18, 10:00
	> Разработчики отказываются, потому что им лень что-то делать. Могут только смузи пить Смузи это хорошо. Я люблю пить смузи
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

24. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
Сообщение от Аноним (23), 30-Июн-18, 16:53
Для многих кейсов перешли на MongoDB. Она нас просто спасает. Очень жаль, озлобленных людей, которые постоянно ее поносят, потому как в сегодняшнем своем состоянии она на голову выше всех остальных баз. Самое забавное - многие хейтеры даже не пытались ее использовать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+3 +/–
	Сообщение от Тож аноним (?), 30-Июн-18, 17:11
	Ты сам-то давно использовал в позах, отличных от однонодовой, сконфигурированной по-дефолту конфигурации? А? Я использовал. Для эксплуатации монга — боль. В том числе тихое повреждение данных на высоких rps смешанной нагрузки. А уж как в таких положениях смешно разваливается монговская «кластеризация»… ммм… любо дорого посмотреть. Вам, фанатикам, правда, это не интересно. Вы маркетинговыми документами обмазались и рассказали руководству, как оно будет хорошо. Страдать не вам.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	26. "Релиз документо-ориентированной СУБД MongoDB 4.0"	–1 +/–
	Сообщение от Аноним (23), 30-Июн-18, 17:48
	Покажите пожалуйста тикет на jira.mongodb.org, где описывается данная проблема и где тебе разработчики говорят - что она есть и мы ее еще не исправили? Очень смешно слышать о подобном, т.к знаю множество организаций, ее использующих и проблем ни у кого не возникало. Сейчас MongoDB это business critical во многих западных компаниях и сейчас сильно набирает популярность в России, поэтому о неспособности работы ее базовых функций слышать смешно. У нас 2000 rps в replica-sets и никаких проблем не имеем (нагрузка смешанная, очень много inserts и updates).
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от мимокрокодил_ноэтонеточно (?), 30-Июн-18, 20:09
	Не нужны тикеты, чтобы убедиться что способ кластеризации, который использует Mongo - defected by design, да и создание такого тикета в жире монги равносильно декларации "У вас там пздц с кластеризацией, ребята". Решать эту проблему, хотя прекрасно о ней осведомлены, разработчики, судя по всему, не хотят
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	29. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (27), 30-Июн-18, 20:11
	> У нас 2000 rps в replica-sets и никаких проблем не имеем Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до ротации - реплика отвалится, удачи.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	33. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (23), 30-Июн-18, 23:27
	>> У нас 2000 rps в replica-sets и никаких проблем не имеем > Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до > ротации - реплика отвалится, удачи. Если ты знаешь как работает реплика, зачем делаешь херню ? Если не знаешь, то не подходи к инструменту
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	48. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (48), 02-Июл-18, 14:14
	>>> У нас 2000 rps в replica-sets и никаких проблем не имеем >> Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до >> ротации - реплика отвалится, удачи. > Если ты знаешь как работает реплика, зачем делаешь херню ? > Если не знаешь, то не подходи к инструменту это вы утверждали что нет проблем, а не я
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	70. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Ананомизец (?), 04-Июл-18, 09:36
	>> У нас 2000 rps в replica-sets и никаких проблем не имеем > Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до > ротации - реплика отвалится, удачи. Можно просто увеличить размер оплога
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	38. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Вадик (??), 01-Июл-18, 13:25
	Поддерживаю, использовал на двух высоконагружпнных сервисах. Отличное решение для многих задач. Но деньги по понятным причинам хранили в postgres :)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	31. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (7), 30-Июн-18, 21:30
	> Для многих кейсов перешли на MongoDB. Она нас просто спасает. > Очень жаль, озлобленных людей, которые постоянно ее поносят, потому как в сегодняшнем > своем состоянии она на голову выше всех остальных баз. Что значит выше? Падает стремительнее? Монга хороша для некоторых специфичных задач. Например использовать как помойку для документов, структура которых не определена. Причём желательно, не дёргать её OLTP-нагрузкой, как и не пытаться использовать её как аналитическую СУБД. С чем можно согласиться, так это с тем, что если пишешь на Жаве, то не надо думать о DDL для инициализации структур данных. Но реально же, крайне мало кто использует бессхемность монги. Почти все работают только с жесткой структурой данных, также как с реляционкой. При этом PG, например, почти гарантирует надежность хранения данных. Монга ничего не гарантирует. И скорость у неё только потому, что по умолчанию буфер со сбросом на диск чуть ли не раз в минуту.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	32. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (23), 30-Июн-18, 23:24
	> Монга хороша для некоторых специфичных задач. Например использовать как помойку для документов, структура > которых не определена. Причём желательно, не дёргать её OLTP-нагрузкой, как и не пытаться использовать её > как аналитическую СУБД. Она прекрасно разруливает OLTP нагрузку, т.к для нее и предназначена, не говорите бред. Может быть до движка WiredTiger могли быть какие-либо проблемы, но сейчас и точно нет, что подтверждается личным опытом. Представляете, она лучше справляется с ней в отличие от того же PostgreSQL, потому что ей не нужен Vacuum, ей не нужно перестраивать индексы из-за write amplification и дальше по мелочам. OLAP нагрузку тоже держит и появляется множество инструментов, которые помогают с запросами. Вы наверное последнее что делали - запускали MapReduce, который вообще никто не использует сейчас. > При этом PG, например, почти гарантирует надежность хранения данных PosgtreSQL теряет данные, просто кукарекающие фанатики не видят и не хотят это видеть. PG это прежде всего коммерциализированное сообщество, отдельные личности которого хотят поиметь денег, т.к с начала 90х годов пытаются впарить PG во все организации, но получаться у них стало только недавно. Я не против PG, просто не нужно говорить что MongoDB это маркетинг, т.к у PG маркетинговая компания гораздо мощнее и напористее. > Монга ничего не гарантирует Ну что за бред? У Монги есть такой же WAL лог, который нужен для восстановления. Такое ощущение, что хейтерство MongoDB это такая же маркетинговая фигня от сообщества PostgreSQL, т.к эти попытки набросить просто уже набили оскомину и не поддаются никакой логики. Монга НИЧЕГО НЕ ТЕРЯЕТ, запомните это и прекратите тиражировать. Она не теряет данные ни в standalone вариант, ни в распределенном (посмотрите результаты jepsen test)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	35. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (35), 01-Июл-18, 08:25
	> Ну что за бред? У Монги есть такой же 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: не увлекайтесь фразами типа "Ну что за бред?". Для вашего лечебного заведения, может быть, это и норма общения, но не в технической среде.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	37. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (23), 01-Июл-18, 13:19
	> И сервера работают без сбоев, память всегда сбрасывается на диск Здесь все базы в одной лодке. > Грязное чтение пофиксили к началу 17-го года. Что на счёт сброса буфера? Для Release Candidate сборок, где добавлялся новый способ чтения данных, ошибки - это нормально. WAL лог был, но журналирование было отключено по умолчанию. Начиная с 3.2 версии его включили по умолчанию, поэтому на сброс буфера можно не ориентироваться. Драйвер не отдаст управление вызывающему коду, пока запись не запишется в журнал. Не понимаю, почему когда PG теряет данных и крашит БД никто так сильно не расписывает это по форумам ?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	39. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (39), 01-Июл-18, 13:49
	> Не понимаю, почему когда PG теряет данных и крашит БД никто так сильно не расписывает это по форумам ? Вероятно потому, что за PG никогда не водилось терять данные за последнюю минуту с настройками по умолчанию.... Если у вас идёт поток платёжек, а СУБД позволяет себе терять последнюю минуту, то это как-то дорого получается.... Именно так монга была настроена, как минимум, до 3-х версий. Ну и скорость работы монги с включенным синхронным режимом была даже не на один порядок ниже PG, у которого синхронный режим включен по умолчанию. Может, конечно, в 4-й версии поправили, но нужны независимые бенчмарки.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	45. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 10:14
	>последнюю минуту с настройками по умолчанию Ламеры не палятся ))) >Если у вас идёт поток платёжек, а СУБД позволяет себе терять последнюю минуту Тебя на мыло, если у тебя падающий сервер вызывает потерю данных. С любой СУБД ;) Вообще, с монгой 3.4++ надо сильно постараться, что даже падающий мастер вызвал потерю данных. А ещё и за последнюю минуту - это несусветный бред.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	47. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (7), 02-Июл-18, 10:48
	> Тебя на мыло, если у тебя падающий сервер вызывает потерю данных. С любой СУБД ;) Вообще, с монгой 3.4++ надо сильно постараться, что даже падающий мастер вызвал потерю данных. > А ещё и за последнюю минуту - это несусветный бред. Товарищ только вчера примкнул к программисткому сообществу?.... Откуда вас столько медработников взялось?....
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	51. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
	Сообщение от Кузя (?), 02-Июл-18, 16:16
	Извините, но Монга принципиально теряет данные и "выдумывает" их. В этом кроются её плюсы, как ни странно. Вы, по сути, переключаетесь, в терминах РСУБД, в режим грязного чтения. Да, это приводит к радикальному сокращению транзакционных издержек, но, опять же, нужно здраво осознавать какой ценой. Для каких-то случаев такой подход вполне приемлем. Типично, да, это помойка данных, т.е. когда заказчику нужно хранить какую-то никчёмную, но обязательную чушь, которая практически никогда не подвергается критическому анализу, а если и подвергается, то риск вскрытых в результате коллизий дёшев.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	57. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 19:40
	>теряет данные и "выдумывает" их. >режим грязного чтения ну и клоун, причём повторяешь этот бред в каждой теме.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	62. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от anonymous (??), 03-Июл-18, 14:26
	Это память у тебя теряется и выдумывается каждый раз новая
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	52. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Кузя (?), 02-Июл-18, 16:24
	> потому что ей не нужен Vacuum, ей не нужно перестраивать индексы Вас само слово Вакуум пугает? Механизмы очистки исторических данных есть во всех MVCC-СУБД. И в PG такой механизм вполне на уровне прочих. Слон не супер-субд-для-всего, но вы как-то довольно странно трактуете критерии сравнения.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	56. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 19:33
	> Вас само слово Вакуум пугает? Ну распиши тут как делать vacuum full когда 80% storage занято. Для сравнения в Монго этого делать не надо никогда. Профит...
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	58. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (7), 02-Июл-18, 20:10
	> Для сравнения в Монго этого делать не надо никогда. Профит... Всерьёз считаете, что в монге изобрели новые способы хранения индексов? И о страничной организации они ничего не слышали? Шли бы в Кнута, для начала....
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	80. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от anonymous (??), 04-Июл-18, 20:51
	>> Для сравнения в Монго этого делать не надо никогда. Профит... > Всерьёз считаете, что в монге изобрели новые способы хранения индексов? И о > страничной организации они ничего не слышали? > Шли бы в Кнута, для начала.... Почитайте, для чего нужен ваакуум для начала и поймите лучше, что вам хотят сказать
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	66. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+1 +/–
	Сообщение от Кузя (?), 03-Июл-18, 19:02
	>> Вас само слово Вакуум пугает? > Ну распиши тут как делать vacuum full когда 80% storage занято. > Для сравнения в Монго этого делать не надо никогда. Профит... Да, профит Монги в том, что у неё нет ни транзакций, ни согласованности данных по времени и это вообще не БД. Я и не спорю, если вам не нужна БД, то Монга (по крайней мере 3-ка) прекрасно подойдёт. Есть ещё Дельфин, но если всё с чем ты сталкивался это JS, то Дельфин тоже не катит -- там какой-то sql ещё нужен.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	60. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (23), 02-Июл-18, 22:56
	Только у PostgreSQL MVCC сделан так костыльно, что они уже замучались выдумывать варианты его обхода. Понимаете, в нормальных базах данных, старые кортежи от транзакций перемещаются в другую область данных и в случае отката транзакции - копируются назад. И только в PG база срет там где жрет - и вычищает старые данные только по расписанию и из-за этого таблицы так раздуваются, что становится просто стыдно. И не нужно говорить, что все базы устроены одинаково - нормальные базы изначально спроектированы адекватно, в отличие от поделки PG. Хорошо что они знают о проблеме и пытаются ее решить.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	65. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Кузя (?), 03-Июл-18, 18:00
	> Понимаете, в нормальных базах данных, старые кортежи от транзакций перемещаются в другую > область данных и в случае отката транзакции - копируются назад. И > только в PG база срет там где жрет - и вычищает > старые данные только по расписанию и из-за этого таблицы так раздуваются, > что становится просто стыдно. Понимаю я другое -- я очень хорошо знаю, как работает механизм MVCC Оракла и Сиквела (они достаточно нормальные?). Оракл вообще не хранит старые "кортежи", а хранит данные как вернуть состояние блока к исходному состоянию, в результате операции отката в Оракле крайне дорогие. В Сиквеле, в новых версиях, да, изменённые данные со всех БД сбрасываются в БД Temp. В результате сбой Temp-а приводит к развалу всех БД. К тому же, создаёт существенные накладные расходы на копирование данных (и увеличивает вероятность сбоя), которые копировать совершенно не нужно. Слон же, при адекватно настроенном автовакууме, работает куда менее накладно в результате. У Слона есть проблемы с длинными транзакциями, потому что фактически время транзакции ничем не ограничено, у него "snapshot too old" не бывает никогда. Но начиная с 10-ки есть вариант сделать очень похоже на оракл по поведению, когда слишком длительные транзакции будут просто откатываться со временем.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	69. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (23), 04-Июл-18, 01:25
	Накладно при откате ? Мы говорим про нормальную работу БД, где коммиты происходят значительно чаще чем откаты. Зачем PG нужен этот мусор? Если бы их все устраивало, они бы на каждой конфе не говорили, что хотят переписать движок и сделать его таким же как у Oracle
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	84. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Жаба (?), 05-Июл-18, 11:42
	> Накладно при откате ? > Мы говорим про нормальную работу БД, где коммиты происходят значительно чаще чем > откаты. Зачем PG нужен этот мусор? Если бы их все устраивало, > они бы на каждой конфе не говорили, что хотят переписать движок > и сделать его таким же как у Oracle О каком мусоре речь? Это, батенька, не мусор, а многоверсионность. В её самой напрашивающейся реализации -- хранить исторические данные о данных в виде самих этих... данных. В Оракле подход другой, в Оракле хранят довольно сложно устроенный код, как собрать состояние блока на любой момент в прошлом (в пределах объёма сегмента отката). Какой подход лучше -- бесполезный спор(т). Обслуживание же MVCC в Слоне тема давно уже не болезненная. Просто нужно делать автовакуум очень часто. Вот и всё. Очень-очень часто. Да и не ясно к чему о ней тут.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	53. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Кузя (?), 02-Июл-18, 16:35
	> Монга НИЧЕГО НЕ ТЕРЯЕТ, запомните это и прекратите тиражировать. Она не теряет > данные ни в standalone вариант, ни в распределенном (посмотрите результаты jepsen > test) А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления? Какие есть варианты?
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	55. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 19:32
	> А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления? Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот транзакция1 прилетела и сказала update blatable set blacol = 3 where id = 1; а параллельно прилетела транзакция2 и сказала update blatable set blacol = 13 where id = 1; обе команды выполнятся в порядке прихода, кто последний тот и папа. Что в Монго 2, что 3, что 4. Что в орацле. Что гундишь то?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	67. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Кузя (?), 03-Июл-18, 19:05
	>> А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления? > Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот > транзакция1 прилетела и сказала update blatable set blacol = 3 where > id = 1; а параллельно прилетела транзакция2 и сказала update blatable > set blacol = 13 where id = 1; > обе команды выполнятся в порядке прихода, кто последний тот и папа. > Что в Монго 2, что 3, что 4. Что в орацле. Что > гундишь то? Э, ну там, всякие разные "уровни изоляции транзакций" бывают. Но не парься, я тебя понял.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	68. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (68), 04-Июл-18, 00:11
	> Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот > транзакция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;
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	71. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 04-Июл-18, 11:28
	>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 аналитики?
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	72. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (68), 04-Июл-18, 13:10
	>>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 Ясен пень ,что можно сделать одной операцией. Это простой пример составной операции, хоть и искуственный.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	73. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Жаба (?), 04-Июл-18, 13:25
	Охохонюшка, ответ куда проще: в Монге нет транзакций )))) поэтому и нет обработки конкурентного изменения. В Монге всё валится в кучу без разбора. В Монге длительная операция может упорно что-то там изменять, а другая, начавшаяся после, но короткая, видит такие "сырые" изменения и без проблем фигачит прямо по ним. Нет никакой изоляции, потому что (вот так новость) транзакций-то нет. Поэтому нет никакой защиты от фантомов, нет никакой атомарности изменений в принципе. В 4-ке их заявляют, но, есть предположение, работать это будет так же медленно, как и работа с блобами в любой другой РСУБД -- потому что ничем от неё не отличается принципиально.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	82. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 05-Июл-18, 05:29
	>В Монге длительная операция может упорно что-то там изменять, а другая, начавшаяся после, но короткая, видит такие "сырые" изменения и без проблем фигачит прямо по ним Если это недопустимо и тем не менее происходит, то вывод ровно один: прогер ленивый олень. Тут один уже отписался, что "ну $set же никто не использует, все олени за replace" Открою страшную тайну: с труЪ СУБД + ORM фреймворк у того же самого оленя будут те же самые проблемы, он делает entity managed, чего-то там с ним долго делает, если кто-то другой дернет глобальный update, то persist() на эту entity перезапишет результаты глобального апдейта. ОКей, без ORM фреймворк эта проблема тоже никуда не делась. Если у тебя разные процессы живут своей жизнью и один делает глобальный UPDATE, то выполнятся они по очереди, но проблема перезаписи данных никуда не ушла.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	83. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Жаба (?), 05-Июл-18, 11:28
	Зависит от орм-а. Если вы о реализациях JPA, то версионность часть стандарта, так что такая ситуация менеджером обрабатывается. Тут важнее понимать, что происходит.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	74. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Жаба (?), 04-Июл-18, 13:33
	> Одиночный апдейт должен быть атомарен в любой субд Вопрос-то, видимо, не в этом. Вот есть у вас транзакция А -- очень длительная и сложная. Эта А началась в Т1. И есть тразакция В -- короткая и простая. В началась в Т2. Так уж сложилось, что подпадающие под критерии обоих транзакций данные пересекаются. Причём так, что если бы А зафиксировалась до Т2, то данные перестали бы соответствовать критериям В. Но А до Т2 не зафиксировалась, но данные уж поменяла и идёт дальше. В же видит данные на момент Т2 и они соответствуют её критериям выбора на изменение и меняет их, затем фиксируется в Т3. В Т125 наконец приходит время фиксироваться транзакции А. Но оказывается, что транзакция В, хотя и пришла после А, но данные уже поменяла и давно пофиксила. И вот тут начинается самое интересное...
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	78. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (68), 04-Июл-18, 14:36
	Ну это вааще роскомнадзор какой-то
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	54. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Кузя (?), 02-Июл-18, 16:41
	> Она прекрасно разруливает OLTP нагрузку, т.к для нее и предназначена, не говорите > бред. > Может быть до движка WiredTiger могли быть какие-либо проблемы, но сейчас и > точно нет, что подтверждается личным опытом. ... К примеру, у меня есть объект-коллекция, который содержит несколько сот миллионов одинаковых элементов. В случае схемного ORM это моделируется, и фактически хранится, двумя строками в двух отношениях. Как это будет отображено в случае Монги? Искренне интересно.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	41. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от лютый охохоня... (?), 02-Июл-18, 06:11
	> Монга хороша для некоторых специфичных задач. До 4.0 была хороша для 70-80% задач. С ACID уже стала хороша для 95% задач. Ой? > Но реально же, крайне мало кто использует бессхемность монги. Почти все > работают только с жесткой структурой данных, также как с реляционкой. Не пиши бред. BSON местами уместнее POJO (там где не надо методов). > Монга ничего не гарантирует. И скорость у неё только потому, что по умолчанию буфер > со сбросом на диск чуть ли не раз в минуту. commitIntervalMs Default: 100 or 30 (Карл, разрешенный максимум 500мс)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	76. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Жаба (?), 04-Июл-18, 14:15
	>> Монга хороша для некоторых специфичных задач. > До 4.0 была хороша для 70-80% задач. С ACID уже стала хороша > для 95% задач. Ой? Монго не хороша для любых задач, для которых не хороши документные СУБД. Т.е. если есть корреспондированные сущности, если есть композиции любого вида, если есть строгие требования к прецеденции и согласованности модели в любой момент времени. Получается -- документные СУБД непригодны ни для чего, кроме как готовой инфры для организации сериализации и не строгой репликации объектов между площадками. Ну или когда у клиента есть строго завязанный на сложившийся документооборот процесс, в котором его надёжность обеспечивается административно, а не программно.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	61. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (23), 02-Июл-18, 23:00
	> желательно, не дёргать её OLTP-нагрузкой Это PostgreSQL не нужно дергать OLTP нагрузкой, т.к у него нет Hard&Soft parse как у Oracle, т.к сложные запросы не кэшируются а разбираются заново каждый раз. Если кэш только в рамках сессии. А с учетом того, что pooling для запросов встроенного в PG нет и приходится встраивать сторонние решения в лице PgBouncer - догадайтесь, как можно что-то кешировать и задавать параметры сессии, если твой connection может достаться другому.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	75. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Жаба (?), 04-Июл-18, 14:06
	>> желательно, не дёргать её OLTP-нагрузкой > Это PostgreSQL не нужно дергать OLTP нагрузкой, т.к у него нет Hard&Soft > parse как у Oracle, т.к сложные запросы не кэшируются а разбираются > заново каждый раз. Если кэш только в рамках сессии. > А с учетом того, что pooling для запросов встроенного в PG нет > и приходится встраивать сторонние решения в лице PgBouncer - догадайтесь, как > можно что-то кешировать и задавать параметры сессии, если твой connection может > достаться другому. Всё не так драматично. В Оракле больше нет никакого хард- и софт- разбора. Анализатор сам решает, как параметризовать и кэшировать разборы. Слоне действует точно так же, только, увы, на мой взгляд, менее эффективно пока. Отсутствие разделяемых сессий в Слоне тоже не проблема: во-первых, полно сторонних решений для построения очередей, а, во-вторых, очереди вообще редко в каких решениях нужны -- чаще всего есть только один сеанс и это сеанс с сервером приложений, у которого есть свой пуллинг.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

49. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
Сообщение от ПДК (?), 02-Июл-18, 14:18
Секундочку, я наверное что-то пропустил, в MongoDB наконец-то появились нормальные транзакции или это всё та же грёбaнaя атомарность?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	59. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от Аноним (7), 02-Июл-18, 20:15
	> Секундочку, я наверное что-то пропустил, в MongoDB наконец-то появились нормальные транзакции > или это всё та же грёбaнaя атомарность? Нормальные - не появились. Судя по описанию, появились минимально возможные для последовательности операций. Видимо, тупо с полной блокировкой всего.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

77. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
Сообщение от Жаба (?), 04-Июл-18, 14:28
По-моему, некорретно называть Монго СУБД. Монго, всё же, это мета-файловая система. Функционально она ничем не лучше сочетания, скажем, работающего по верх zfs grep-а. Ну в сочетании с какой-нибудь технологией блочной репликации.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	79. "Релиз документо-ориентированной СУБД MongoDB 4.0"	+/–
	Сообщение от anonymous (??), 04-Июл-18, 20:40
	Ну что ты несешь? Сидели бы по углам и не вылазили
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема