| |
| 2.6, A (?), 17:59, 29/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
... ещё добавить триггеры и встроенные процедуры.
| | |
|
| |
| 2.9, пох (?), 19:21, 29/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
прекрасно. Я давно искал повод (причину я придумаю) вынести нахрен эту дрянь со своих серверов (вот что-то в спинном мозге подсказывало - "оно - дрянь, брось!")
А тут такой "coming out"... Рейзер сосьот со своими $25. Орацле лохи, до сих пор mysql даже не предлагает установить unbreakable kernel, не говоря уже об апгрейде до правильного линукса.
| | |
|
| 1.10, Аноним (10), 20:08, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– | |
Отличная БД. MongoDB превосходно работает в паре с Node.JS (нужно будет доустановить немного NPM-пакетов). А если при этом запускать через systemd — вообще шик. Ну и запускать, естессно, на сервере, зайдя на него через ssh из великолепного GNOME, работающим под божественным Wayland (подойдет любой GTK+-based терминал, например gnome-terminal). Сам сервер лучше держать на Microsoft Azure, а работал бы он на Fedora с патчами от глубоко уважаемой команды Grsecurity. А исходники держать на GitHub, и править их из-под Microsoft Visual Studio Code или вообще средствами самого гитхаба через превосходный Google Chrome.
Вот это я называю жизнь.
| | |
| |
| |
| 3.34, Q2W (?), 00:41, 01/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
 И на моём thинкпаде эти отверстия пригодились, когда я прочитал "финкпад" =).
| | |
|
| 2.16, IRASoldier (?), 22:24, 29/06/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ты так всё это написал, как будто это смешно. Хотя так с этим работать можно и даже с комфортом.
| | |
|
| 1.15, Rodegast (ok), 21:37, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 > Поддержка транзакций, удовлетворяющих требованиям ACID ... охватывающих несколько документов
Ну это просто праздник какой то!
| | |
| |
| 2.20, Аноним (20), 08:31, 30/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну опять же неполноценно... Да и в Spring оно придёт лишь через некоторое время...
| | |
| |
| 3.42, лютый охохоня... (?), 06:13, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну опять же неполноценно... Да и в Spring оно придёт лишь через
Это Spring-офилы то про неполноценность будут рассуждать?
| | |
|
|
| 1.18, Аноним (18), 00:59, 30/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Всегда не понимал, зачем оно нужно, если в Постгресе давно есть JSON/JSONB, которые ещё и быстрее.
| | |
| |
| 2.19, Аноним (19), 01:51, 30/06/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
Как ты будешь failover на ПГ делать? А как обновлять часть документа? Или ты по каждому чиху будешь десериализовывать весь объект, его изменять и повторять еще раз подобное?
[сообщение отредактировано модератором]
| | |
| |
| 3.21, Аноним (20), 08:34, 30/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Как ты будешь failover на ПГ делать? А как обновлять часть документа?
> Или ты по каждому чиху будешь десериализовывать весь объект, его
> изменять и повторять еще раз подобное?
Обновлением части документа как функцией монги вообще кто-нибудь пользуется? Обычно, с ней, как раз по каждому чиху и делают полную десериализацию/сериализацию. По крайней мере из Java/Spring
А вообще, нормализацию данных как раз и придумали для того, чтобы избежать избыточности и обеспечить оптимальную гранулярность обновления данных. Не важно, монга это или РСУБД.
| | |
| |
| 4.46, лютый охохоня... (?), 10:26, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Обновлением части документа как функцией монги вообще кто-нибудь пользуется?
> Обычно, с ней, как раз по каждому чиху и делают полную десериализацию/сериализацию.
Сам же расписался в былдокодерстве... и так у всех хейтерков Монги.
Монговский 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 это всё равно не сравнить.
| | |
|
|
|
| 1.23, Аноним (23), 16:15, 30/06/2018 [ответить] [﹢﹢﹢] [ · · · ] | –2 +/– | Используем MongoDB c версии 3 2 в нашей организации в 1000 человек Хотели прос... большой текст свёрнут, показать | | |
| |
| 2.30, Аноним (7), 21:25, 30/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> вы реально не понимаете и не отличаете чем отличается нативных JSON (BSON) от просто поля с кучей данных, которое можно проиндексировать ?
У монги большие проблемы с индексацией вложенных массивов. Как только реально сложные структуры данных начинаются, всё сводится с тому, что надо раскладывать данные в одноуровневые записи. Никаких вложенных объектов внутри массивов. И чем это лучше таблиц PG?
А в отношении работы в кластере, разве в монге проблему грязного чтения устранили? Или, может быть, устранили стабильность БД при внезапной перезагрузке сервера?
| | |
| |
| 3.40, лютый охохоня... (?), 06:00, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> У монги большие проблемы с индексацией вложенных массивов. Как только реально сложные структуры
Работаю с ЕГРЮЛ, это 5-7 уровневые XMLки весом до пары мегабайт. Когда уже проблемы-то начнутся?
Хвалёное быстрейшество Слонище с его JSONB кстати, на вставку имеет 200 документов в сек (в 10 раз медленнее Mongo). На этом мое знакомство с Pg закончилось.
> А в отношении работы в кластере, разве в монге проблему грязного чтения устранили?
withReadPreference(ReadPreference.primary()
не? Причём можно гибко, где надо читаем с Primary, где не надо с Nearest.
>Или, может быть, устранили стабильность БД при внезапной перезагрузке сервера?
Неужели сервер с другими СУБД не перестает работать при перезагрузке питания? Вот так поворот!
| | |
| |
| 4.50, Кузя (?), 16:07, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>> Неужели сервер с другими СУБД не перестает работать при перезагрузке питания? Вот так поворот!
Вы удивитесь, но это ключевое свойство СУБД.
Mongo пригодна только когда вам нужно хранить помои (вроде егрюлей всяких бесполезных). Если данные невозможно структурировать, то они, чаще всего, никому не нужны. Но это моё личное мнение.
| | |
| |
| 5.63, anonymous (??), 14:54, 03/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Когда попробуете ее по-настоящему использовать и поймете ее фишки вникните в ее парадигму, вы вдруг осознаете, что РСУБД вам будут нужно в 1% кейсов и то, версия 4.0 покрыла и эти возможности.
Сам пользуюсь монгой достаточно давно. Раньше были проблемы, но сейчас это одна из лучших баз.
| | |
| |
| 6.64, Кузя (?), 17:43, 03/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Пробовал 3-тью версию. Не совпадает с моим опытом. Не понравился и характер... экосистемы. Книги про Монгу совершенно не раскрывают, даже и не пытаются, её "внутренности". Если как работает Оракл, Сиквел или Слон я понимаю, то как работает Монга -- нет.
| | |
|
|
|
|
| 2.36, Bekka (?), 10:48, 01/07/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Разработчики отказываются, потому что им лень что-то делать. Могут только смузи пить
| | |
| |
| 3.44, Попугай Кеша (?), 10:00, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Разработчики отказываются, потому что им лень что-то делать. Могут только смузи пить
Смузи это хорошо. Я люблю пить смузи
| | |
|
|
| 1.24, Аноним (23), 16:53, 30/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Для многих кейсов перешли на MongoDB. Она нас просто спасает.
Очень жаль, озлобленных людей, которые постоянно ее поносят, потому как в сегодняшнем своем состоянии она на голову выше всех остальных баз.
Самое забавное - многие хейтеры даже не пытались ее использовать.
| | |
| |
| 2.25, Тож аноним (?), 17:11, 30/06/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ты сам-то давно использовал в позах, отличных от однонодовой, сконфигурированной по-дефолту конфигурации?
А?
Я использовал. Для эксплуатации монга — боль. В том числе тихое повреждение данных на высоких rps смешанной нагрузки. А уж как в таких положениях смешно разваливается монговская «кластеризация»… ммм… любо дорого посмотреть.
Вам, фанатикам, правда, это не интересно. Вы маркетинговыми документами обмазались и рассказали руководству, как оно будет хорошо. Страдать не вам.
| | |
| |
| 3.26, Аноним (23), 17:48, 30/06/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Покажите пожалуйста тикет на jira.mongodb.org, где описывается данная проблема и где
тебе разработчики говорят - что она есть и мы ее еще не исправили?
Очень смешно слышать о подобном, т.к знаю множество организаций, ее использующих и проблем ни у кого не возникало. Сейчас MongoDB это business critical во многих западных компаниях и сейчас сильно набирает популярность в России, поэтому о неспособности работы ее базовых функций слышать смешно.
У нас 2000 rps в replica-sets и никаких проблем не имеем (нагрузка смешанная, очень много inserts и updates).
| | |
| |
| 4.28, мимокрокодил_ноэтонеточно (?), 20:09, 30/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Не нужны тикеты, чтобы убедиться что способ кластеризации, который использует Mongo - defected by design, да и создание такого тикета в жире монги равносильно декларации "У вас там пздц с кластеризацией, ребята". Решать эту проблему, хотя прекрасно о ней осведомлены, разработчики, судя по всему, не хотят
| | |
| 4.29, Аноним (27), 20:11, 30/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> У нас 2000 rps в replica-sets и никаких проблем не имеем
Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до ротации - реплика отвалится, удачи.
| | |
| |
| 5.33, Аноним (23), 23:27, 30/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> У нас 2000 rps в replica-sets и никаких проблем не имеем
> Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до
> ротации - реплика отвалится, удачи.
Если ты знаешь как работает реплика, зачем делаешь херню ?
Если не знаешь, то не подходи к инструменту
| | |
| |
| 6.48, Аноним (48), 14:14, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
>>> У нас 2000 rps в replica-sets и никаких проблем не имеем
>> Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до
>> ротации - реплика отвалится, удачи.
> Если ты знаешь как работает реплика, зачем делаешь херню ?
> Если не знаешь, то не подходи к инструменту
это вы утверждали что нет проблем, а не я
| | |
|
| 5.70, Ананомизец (?), 09:36, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> У нас 2000 rps в replica-sets и никаких проблем не имеем
> Создай капед колекцию нагруженную и попробуй реплику новую поднять, не успеешь до
> ротации - реплика отвалится, удачи.
Можно просто увеличить размер оплога
| | |
|
| 4.38, Вадик (??), 13:25, 01/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Поддерживаю, использовал на двух высоконагружпнных сервисах. Отличное решение для многих задач. Но деньги по понятным причинам хранили в postgres :)
| | |
|
|
| 2.31, Аноним (7), 21:30, 30/06/2018 [^] [^^] [^^^] [ответить] | +/– | Что значит выше Падает стремительнее Монга хороша для некоторых специфичных за... большой текст свёрнут, показать | | |
| |
| 3.32, Аноним (23), 23:24, 30/06/2018 [^] [^^] [^^^] [ответить] | +/– | Она прекрасно разруливает OLTP нагрузку, т к для нее и предназначена, не говорит... большой текст свёрнут, показать | | |
| |
| 4.35, Аноним (35), 08:25, 01/07/2018 [^] [^^] [^^^] [ответить] | +/– | Ок И сервера работают без сбоев, память всегда сбрасывается на диск Уваж... большой текст свёрнут, показать | | |
| |
| 5.37, Аноним (23), 13:19, 01/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> И сервера работают без сбоев, память всегда сбрасывается на диск
Здесь все базы в одной лодке.
> Грязное чтение пофиксили к началу 17-го года. Что на счёт сброса буфера?
Для Release Candidate сборок, где добавлялся новый способ чтения данных, ошибки - это нормально.
WAL лог был, но журналирование было отключено по умолчанию. Начиная с 3.2 версии его включили по умолчанию, поэтому на сброс буфера можно не ориентироваться. Драйвер не отдаст управление вызывающему коду, пока запись не запишется в журнал.
Не понимаю, почему когда PG теряет данных и крашит БД никто так сильно не расписывает это по форумам ?
| | |
| |
| 6.39, Аноним (39), 13:49, 01/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Не понимаю, почему когда PG теряет данных и крашит БД никто так сильно не расписывает это по форумам ?
Вероятно потому, что за PG никогда не водилось терять данные за последнюю минуту с настройками по умолчанию.... Если у вас идёт поток платёжек, а СУБД позволяет себе терять последнюю минуту, то это как-то дорого получается.... Именно так монга была настроена, как минимум, до 3-х версий.
Ну и скорость работы монги с включенным синхронным режимом была даже не на один порядок ниже PG, у которого синхронный режим включен по умолчанию. Может, конечно, в 4-й версии поправили, но нужны независимые бенчмарки.
| | |
| |
| 7.45, лютый охохоня... (?), 10:14, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>последнюю минуту с настройками по умолчанию
Ламеры не палятся )))
>Если у вас идёт поток платёжек, а СУБД позволяет себе терять последнюю минуту
Тебя на мыло, если у тебя падающий сервер вызывает потерю данных. С любой СУБД ;)
Вообще, с монгой 3.4++ надо сильно постараться, что даже падающий мастер вызвал потерю данных.
А ещё и за последнюю минуту - это несусветный бред.
| | |
|
|
|
| 4.51, Кузя (?), 16:16, 02/07/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Извините, но Монга принципиально теряет данные и "выдумывает" их. В этом кроются её плюсы, как ни странно. Вы, по сути, переключаетесь, в терминах РСУБД, в режим грязного чтения. Да, это приводит к радикальному сокращению транзакционных издержек, но, опять же, нужно здраво осознавать какой ценой. Для каких-то случаев такой подход вполне приемлем. Типично, да, это помойка данных, т.е. когда заказчику нужно хранить какую-то никчёмную, но обязательную чушь, которая практически никогда не подвергается критическому анализу, а если и подвергается, то риск вскрытых в результате коллизий дёшев.
| | |
| |
| 5.57, лютый охохоня... (?), 19:40, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
>теряет данные и "выдумывает" их.
>режим грязного чтения
ну и клоун, причём повторяешь этот бред в каждой теме.
| | |
|
| 4.52, Кузя (?), 16:24, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> потому что ей не нужен Vacuum, ей не нужно перестраивать индексы
Вас само слово Вакуум пугает? Механизмы очистки исторических данных есть во всех MVCC-СУБД. И в PG такой механизм вполне на уровне прочих. Слон не супер-субд-для-всего, но вы как-то довольно странно трактуете критерии сравнения.
| | |
| |
| 5.56, лютый охохоня... (?), 19:33, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Вас само слово Вакуум пугает?
Ну распиши тут как делать vacuum full когда 80% storage занято.
Для сравнения в Монго этого делать не надо никогда. Профит...
| | |
| |
| 6.58, Аноним (7), 20:10, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Для сравнения в Монго этого делать не надо никогда. Профит...
Всерьёз считаете, что в монге изобрели новые способы хранения индексов? И о страничной организации они ничего не слышали?
Шли бы в Кнута, для начала....
| | |
| |
| 7.80, anonymous (??), 20:51, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> Для сравнения в Монго этого делать не надо никогда. Профит...
> Всерьёз считаете, что в монге изобрели новые способы хранения индексов? И о
> страничной организации они ничего не слышали?
> Шли бы в Кнута, для начала....
Почитайте, для чего нужен ваакуум для начала и поймите лучше, что вам хотят сказать
| | |
|
| 6.66, Кузя (?), 19:02, 03/07/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Вас само слово Вакуум пугает?
> Ну распиши тут как делать vacuum full когда 80% storage занято.
> Для сравнения в Монго этого делать не надо никогда. Профит...
Да, профит Монги в том, что у неё нет ни транзакций, ни согласованности данных по времени и это вообще не БД. Я и не спорю, если вам не нужна БД, то Монга (по крайней мере 3-ка) прекрасно подойдёт. Есть ещё Дельфин, но если всё с чем ты сталкивался это JS, то Дельфин тоже не катит -- там какой-то sql ещё нужен.
| | |
|
| 5.60, Аноним (23), 22:56, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Только у PostgreSQL MVCC сделан так костыльно, что они уже замучались выдумывать варианты его обхода.
Понимаете, в нормальных базах данных, старые кортежи от транзакций перемещаются в другую область данных и в случае отката транзакции - копируются назад. И только в PG база срет там где жрет - и вычищает старые данные только по расписанию и из-за этого таблицы так раздуваются, что становится просто стыдно.
И не нужно говорить, что все базы устроены одинаково - нормальные базы изначально спроектированы адекватно, в отличие от поделки PG.
Хорошо что они знают о проблеме и пытаются ее решить.
| | |
| |
| 6.65, Кузя (?), 18:00, 03/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Понимаете, в нормальных базах данных, старые кортежи от транзакций перемещаются в другую
> область данных и в случае отката транзакции - копируются назад. И
> только в PG база срет там где жрет - и вычищает
> старые данные только по расписанию и из-за этого таблицы так раздуваются,
> что становится просто стыдно.
Понимаю я другое -- я очень хорошо знаю, как работает механизм MVCC Оракла и Сиквела (они достаточно нормальные?). Оракл вообще не хранит старые "кортежи", а хранит данные как вернуть состояние блока к исходному состоянию, в результате операции отката в Оракле крайне дорогие. В Сиквеле, в новых версиях, да, изменённые данные со всех БД сбрасываются в БД Temp. В результате сбой Temp-а приводит к развалу всех БД. К тому же, создаёт существенные накладные расходы на копирование данных (и увеличивает вероятность сбоя), которые копировать совершенно не нужно. Слон же, при адекватно настроенном автовакууме, работает куда менее накладно в результате. У Слона есть проблемы с длинными транзакциями, потому что фактически время транзакции ничем не ограничено, у него "snapshot too old" не бывает никогда. Но начиная с 10-ки есть вариант сделать очень похоже на оракл по поведению, когда слишком длительные транзакции будут просто откатываться со временем.
| | |
| |
| 7.69, Аноним (23), 01:25, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Накладно при откате ?
Мы говорим про нормальную работу БД, где коммиты происходят значительно чаще чем откаты. Зачем PG нужен этот мусор? Если бы их все устраивало, они бы на каждой конфе не говорили, что хотят переписать движок и сделать его таким же как у Oracle
| | |
| |
| 8.84, Жаба (?), 11:42, 05/07/2018 [^] [^^] [^^^] [ответить] | +/– | О каком мусоре речь Это, батенька, не мусор, а многоверсионность В её самой на... текст свёрнут, показать | | |
|
|
|
|
| 4.53, Кузя (?), 16:35, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Монга НИЧЕГО НЕ ТЕРЯЕТ, запомните это и прекратите тиражировать. Она не теряет
> данные ни в standalone вариант, ни в распределенном (посмотрите результаты jepsen
> test)
А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления? Какие есть варианты?
| | |
| |
| 5.55, лютый охохоня... (?), 19:32, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления?
Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот транзакция1 прилетела и сказала update blatable set blacol = 3 where id = 1; а параллельно прилетела транзакция2 и сказала update blatable set blacol = 13 where id = 1;
обе команды выполнятся в порядке прихода, кто последний тот и папа.
Что в Монго 2, что 3, что 4. Что в орацле. Что гундишь то?
| | |
| |
| 6.67, Кузя (?), 19:05, 03/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> А вы не могли бы описать, что делает Монга 4 в случае конкурентного обновления?
> Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот
> транзакция1 прилетела и сказала update blatable set blacol = 3 where
> id = 1; а параллельно прилетела транзакция2 и сказала update blatable
> set blacol = 13 where id = 1;
> обе команды выполнятся в порядке прихода, кто последний тот и папа.
> Что в Монго 2, что 3, что 4. Что в орацле. Что
> гундишь то?
Э, ну там, всякие разные "уровни изоляции транзакций" бывают. Но не парься, я тебя понял.
| | |
| 6.68, Аноним (68), 00:11, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Кузя лучше расскажи, как волшебный РСУБД защищает от конкурентного обновления? Ну вот
> транзакция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;
| | |
| |
| 7.71, лютый охохоня... (?), 11:28, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>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 аналитики?
| | |
| |
| 8.72, Аноним (68), 13:10, 04/07/2018 [^] [^^] [^^^] [ответить] | +/– | Ясен пень ,что можно сделать одной операцией Это простой пример составной опера... текст свёрнут, показать | | |
| 8.73, Жаба (?), 13:25, 04/07/2018 [^] [^^] [^^^] [ответить] | +/– | Охохонюшка, ответ куда проще в Монге нет транзакций поэтому и нет обработк... текст свёрнут, показать | | |
| |
| |
| 10.83, Жаба (?), 11:28, 05/07/2018 [^] [^^] [^^^] [ответить] | +/– | Зависит от орм-а Если вы о реализациях JPA, то версионность часть стандарта, та... текст свёрнут, показать | | |
|
|
|
| 7.74, Жаба (?), 13:33, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Одиночный апдейт должен быть атомарен в любой субд
Вопрос-то, видимо, не в этом. Вот есть у вас транзакция А -- очень длительная и сложная. Эта А началась в Т1. И есть тразакция В -- короткая и простая. В началась в Т2. Так уж сложилось, что подпадающие под критерии обоих транзакций данные пересекаются. Причём так, что если бы А зафиксировалась до Т2, то данные перестали бы соответствовать критериям В. Но А до Т2 не зафиксировалась, но данные уж поменяла и идёт дальше. В же видит данные на момент Т2 и они соответствуют её критериям выбора на изменение и меняет их, затем фиксируется в Т3. В Т125 наконец приходит время фиксироваться транзакции А. Но оказывается, что транзакция В, хотя и пришла после А, но данные уже поменяла и давно пофиксила. И вот тут начинается самое интересное...
| | |
|
|
|
| 4.54, Кузя (?), 16:41, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Она прекрасно разруливает OLTP нагрузку, т.к для нее и предназначена, не говорите
> бред.
> Может быть до движка WiredTiger могли быть какие-либо проблемы, но сейчас и
> точно нет, что подтверждается личным опытом.
... К примеру, у меня есть объект-коллекция, который содержит несколько сот миллионов одинаковых элементов. В случае схемного ORM это моделируется, и фактически хранится, двумя строками в двух отношениях. Как это будет отображено в случае Монги? Искренне интересно.
| | |
|
| 3.41, лютый охохоня... (?), 06:11, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Монга хороша для некоторых специфичных задач.
До 4.0 была хороша для 70-80% задач. С ACID уже стала хороша для 95% задач. Ой?
> Но реально же, крайне мало кто использует бессхемность монги. Почти все
> работают только с жесткой структурой данных, также как с реляционкой.
Не пиши бред. BSON местами уместнее POJO (там где не надо методов).
> Монга ничего не гарантирует. И скорость у неё только потому, что по умолчанию буфер
> со сбросом на диск чуть ли не раз в минуту.
commitIntervalMs Default: 100 or 30
(Карл, разрешенный максимум 500мс)
| | |
| |
| 4.76, Жаба (?), 14:15, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> Монга хороша для некоторых специфичных задач.
> До 4.0 была хороша для 70-80% задач. С ACID уже стала хороша
> для 95% задач. Ой?
Монго не хороша для любых задач, для которых не хороши документные СУБД. Т.е. если есть корреспондированные сущности, если есть композиции любого вида, если есть строгие требования к прецеденции и согласованности модели в любой момент времени. Получается -- документные СУБД непригодны ни для чего, кроме как готовой инфры для организации сериализации и не строгой репликации объектов между площадками. Ну или когда у клиента есть строго завязанный на сложившийся документооборот процесс, в котором его надёжность обеспечивается административно, а не программно.
| | |
|
| 3.61, Аноним (23), 23:00, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> желательно, не дёргать её OLTP-нагрузкой
Это PostgreSQL не нужно дергать OLTP нагрузкой, т.к у него нет Hard&Soft parse как у Oracle, т.к сложные запросы не кэшируются а разбираются заново каждый раз. Если кэш только в рамках сессии.
А с учетом того, что pooling для запросов встроенного в PG нет и приходится встраивать сторонние решения в лице PgBouncer - догадайтесь, как можно что-то кешировать и задавать параметры сессии, если твой connection может достаться другому.
| | |
| |
| 4.75, Жаба (?), 14:06, 04/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> желательно, не дёргать её OLTP-нагрузкой
> Это PostgreSQL не нужно дергать OLTP нагрузкой, т.к у него нет Hard&Soft
> parse как у Oracle, т.к сложные запросы не кэшируются а разбираются
> заново каждый раз. Если кэш только в рамках сессии.
> А с учетом того, что pooling для запросов встроенного в PG нет
> и приходится встраивать сторонние решения в лице PgBouncer - догадайтесь, как
> можно что-то кешировать и задавать параметры сессии, если твой connection может
> достаться другому.
Всё не так драматично. В Оракле больше нет никакого хард- и софт- разбора. Анализатор сам решает, как параметризовать и кэшировать разборы. Слоне действует точно так же, только, увы, на мой взгляд, менее эффективно пока.
Отсутствие разделяемых сессий в Слоне тоже не проблема: во-первых, полно сторонних решений для построения очередей, а, во-вторых, очереди вообще редко в каких решениях нужны -- чаще всего есть только один сеанс и это сеанс с сервером приложений, у которого есть свой пуллинг.
| | |
|
|
|
| 1.49, ПДК (?), 14:18, 02/07/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Секундочку, я наверное что-то пропустил, в MongoDB наконец-то появились нормальные транзакции или это всё та же грёбaнaя атомарность?
| | |
| |
| 2.59, Аноним (7), 20:15, 02/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Секундочку, я наверное что-то пропустил, в MongoDB наконец-то появились нормальные транзакции
> или это всё та же грёбaнaя атомарность?
Нормальные - не появились. Судя по описанию, появились минимально возможные для последовательности операций. Видимо, тупо с полной блокировкой всего.
| | |
|
| 1.77, Жаба (?), 14:28, 04/07/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
По-моему, некорретно называть Монго СУБД. Монго, всё же, это мета-файловая система. Функционально она ничем не лучше сочетания, скажем, работающего по верх zfs grep-а. Ну в сочетании с какой-нибудь технологией блочной репликации.
| | |
|
