В чём фишка монго? В быстром развёртывании, простой масштабируемости

и то и то

Это и было перечисление основных плюсов

В неё можно быстро писать Иногда предметная область плохо или неудобно раскладывается на рсубд Иногда вал изменений такой, что структура просто мешает

Монга обеспечивает быструю запись благодаря тому, что пишет в память, и по возможности дампует на диск. При высокой нагрузке это может привести к потере данных, отсутствие ACID, обещают полноценные завезти, но пока их нет 🤷‍♀️

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

Не нужно быть гуглом, чтобы закончилась память на vds )) крашнется года с монгой, данные потеряны

Емнип, это (память/дамп) настраиваемо во всех бд, и пишет монга быстро не по этому

Каким образом закончится память у сервера с монгой? У неё же лимиты есть.

Хороший вопрос, почему монго может выходить за лимиты, но это к авторам сабжа

Как при прочих равных можно на тестах выдавать больше wps, кроме как откладывая флаш и игнорируя acid?

Там может не быть прочих равных. Могут быть совершенно разные устройства хранилища, механизмы индексации. В монге, например, нет автоинкремента и айдишник похож на гуид (внешне, на самом деле там структура docs.mongodb.com/manual/reference/method/ObjectId/) - уже операции получения pk совершенно разные

Внезапно в постгре может тоже не быть автоинкремента и есть uuid, но это не отвечает на вопрос, который относится к вашему посту выше - какие образом добиться большего writes per second не пропуская флаш данных на диск и не забив на acid?

А разве монга удовлетворяет Acid?

C версии 4.2 удовлетворяет, есть транзакции.

но чтобы работало надо кластер подрубать и настраивать

Ну вот может с версии 4.2 монго стала заметно медленнее :D При использовании транзакций, конечно

Да, но по дефолту readconcern выставлен как local )) если сконфигурить транзакции как в постгре, производительность заметно снизится

Ты можешь даже в одной бд с одинаковыми настройками получить совершенно разную скорость записи. Самый простой пример, который приходит в голову - в mssql по умолчанию кластеризованный pk. Если ты в качестве pk выберешь гуид, а не автоинкремент, просадка на запись будет весьма заметной (по крайней мере на hdd, не знаю точно будет ли она заметна на ssd) То есть иногда достаточно просто сменить тип поля чтобы при прочих равных различия в скорости были заметны

В вашем примере разница в скорости составит 30-50% а в статьях топящих за монгу часто приводят разницу в 1-2 раза по записи, но не раскрывают, за счёт чего это достигается

Не уверен на счёт 30-50% Откуда такие цифры? При неудачном раскладе - большая таблица, новые записи всегда попадают в первый кластер - каждое добавление в таблицу будет вызывать переписывание всех кластеров Ну и про статьи со сравнениями я ничего не говорил. Не понимаю почему ты мне задаёшь вопрос о них

Ок, за счёт чего монга помечает записи как записанные быстрее mysql например?

Это какой-то общий вопрос, поэтому я вправе дать на него общий ответ, тогда: за счёт того, что в монге запись будет идти в одну коллекцию, а в рсубд в несколько (я обобщил запись до сохранения сущности, в случае рсубд разбитой на несколько таблиц)

Что за первый кластер и по какой причине новые записи должны попадать в него, если int и guid будут добавлять записи в конец списка?

В вашем примере одна таблица, соответственно сравнение идет именно с ней, а не с набором таблиц

Ты разобрался в том, что такое кластеризованный индекс? Гуид в общем случае будет попадать в случайный кластер. В худшем, в первый, что приведёт к перемещению всех данных таблицы на диске

Нет, в моём примере одной сущности в монге соответствует несколько таблиц в рсубд 😁

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

О каком случае идет речь? NewId или секвеншал? И какая версия БД? Потому что в старых версиях uuid не соответствовал спеке, и действительно могли быть проблемы с перестройкой индекса, но с 2014 там уже пофиксили, у нас проблем с ней не было

Хм, откуда ты тогда взял 30-50%, о которых писал выше? Речь идёт о кластеризованном индексе в mssql (не уверен, что он есть в постгрес) Он не располагается отдельно, а хранится вместе с данными. Или даже так - данные хранятся в соответствии с этим индексом В случае с автоинкрементом всё просто - его значения идут по возрастанию, поэтому при добавлении записи мы дописываем её в конец файла В случае с гуидом для сохранения сортировки по нему мы в общем случае вынуждены вставить запись куда-то между имеющимися. Вставка приводит к тому, что мы должны "подвинуть" все записи за ним. Вот и получается что в худшем случае мы при каждом добавлении будет "двигать" все записи в таблице

uuid является числом в base62, могу ошибаться, но часть последовательности кодируется по времени, поэтому каждый новый uuid в числовом значении будет больше предыдущего, поэтому и возникает фрагментация, поскольку числовые значения не идут друг за другом, а с большим разрывом, но в результате они последовательны, поэтому не возникнет ситуации, когда новое значение нужно воткнуть в начало таблицы или середину

Я не знаю формата гуида, но точно знаю что на практике ситуации возникают, использование гуида для pk в mssql это известный антипаттерн

А в чем причина антипаттерна? Какие аргументы?

Я там выше расписывал: кластеризованный индекс, вставка в середину, перемещение всех записей

Но там же есть ответ о том, что значения возрастают

Но они не возрастают

Из первой ссылки про этот тему: NEWSEQUENTIALID() дает те же уникальные идентификаторы, только каждое новое значение этой функции больше предыдущего, при этом идентификатор остается «глобально уникальным». Т.е., видимо, как минимум на уровне СУБД проблема решаемая из коробки

https://rclayton.silvrback.com/do-you-really-need-a-uuid-guid

Ну значит с его использованием ок, а если как-то иначе генерить гуиды - не ок

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

Давай уберём ветку обсуждения особенности генерации гуидов и вернёмся к изначальному вопросу про разницу в wps. Представь что айди генерится в коде, и это гарантированно уникальное случайное (сферическое) целое (в вакууме) Так понятнее будет пример того, что даже в одной бд на одной и той же машине с одними и теми же настройками wps может быть очень разный, и зависеть даже не от типа вставляемого значения, а просто от самого значения?

Разница при этом не будет отличаться в разы

Разница будет тем больше, чем больше таблица. И в плохих случаях она может дойти и до 2х, и больше. Представь, что тебе несколько Гб данных надо переразбить на блоки и физически переместить на диске. Это в плохом случае. А в хорошем - просто дописать, без перелопачивания всех остальных данных Но вообще кроме тебя никто не говорил про разы. Кажется это твои личные претензии, что кто-то где-то когда-то (но вряд ли в этом чате) заявлял что монга быстрее в разы

Почему вы сначала предлагаете отойти от особенностей реализации гуида и приводите абстрактный пример, а потом в качестве аргумента вновь приводите особенности имплементации конкретной БД?

Ты забыл изначальный вопрос, возможно? Ты спрашивал как можно получить разницу на wps t.me/nodejs_ru/690089 Я хотел показать, что её можно получить даже в одной СУБД. Показал?

Перечитайте пожалуйста вопрос, как получить больший wps. А вы рассказали, как используя неподходящий для задачи guid столкнулись с проблемами

Ну так а чем тебе не подходит пример с правильным/неправильным выбором pk? Твои рассуждения я понял как "у всех примерно одинаковая скорость". Но на самом деле бывают отклонения. В данном случае - в результате ошибки проектирования, но этот пример я привёл как самый простой, где можно показать разницу. А так - у СУБД, например, разные индексы, и стоимость добавления записи тоже может быть разной Это не вызывает вопросов?