Вообще табличные хранилища приучили инженеров фатальной вещи — идущим подряд номерам. Идущие подряд номера это безумно дорого, сложно и практически никогда не решает никакой задачи кроме псевдо-эстетической. Если вам необходимо реализовать жесткую сквозную нумерацию, то скорее всего у вас какая-то очень большая проблема в архитектуре связей между данными. Не представляю даже, сколько процентов мирового ВВП тратится на никому не нужные циферки.

Но ведь нет ничего лучше для суррогатного ключа

Я имел ввиду что интегрируемся с существующим бизнесом %) Он бумажный.

Первичка?

Но ведь нет ничего лучше для суррогатного ключа

128 случайных бит хватит всем

Первичка?

Управление электросетями....

Управление электросетями....

Попробуйте переосмыслить почему это три разные коллекции. Вероятно сквозная нумерация не просто так возникла

Попробуйте переосмыслить почему это три разные коллекции. Вероятно сквозная нумерация не просто так возникла

Коллекции разные, потому что сущности разные в них хранятся. Накой им нумерация - потому что так было они это хотят чтобы мы повторили.

128 случайных бит хватит всем

Если это не шутка, то если индекс кластерный, то при случайном значении (равно как при использовании гуидов) вставка данных будет весьма болезненной процедурой, отжирающей проценты мирового ВВП и далее по тексту

Если это не шутка, то если индекс кластерный, то при случайном значении (равно как при использовании гуидов) вставка данных будет весьма болезненной процедурой, отжирающей проценты мирового ВВП и далее по тексту

Не будет

Дереву вообще без разницы это ваши цифры

Не будет

Практика показывает обратное

Практика показывает обратное

Даже математика с вами не согласна. Для хранения 10 значений хоть 64 хоть 1024 битных потребуется одинаковое количество узлов того же btree. Разница будет только в размере, которая на фоне размера транзакции в память и количеству циклов которые будет тупить процессор пока одупляется память вообще никогда не будет видна. Да и SIMD уже изобрели 128 бит это всего в два раза больше бит чем сегодняшние 64 бита. В принципе и 64 случайных бита тоже сойдёт, если там пав сотен значений в час генерируется.

ObjectId вон 96 бит

Даже математика с вами не согласна. Для хранения 10 значений хоть 64 хоть 1024 битных потребуется одинаковое количество узлов того же btree. Разница будет только в размере, которая на фоне размера транзакции в память и количеству циклов которые будет тупить процессор пока одупляется память вообще никогда не будет видна. Да и SIMD уже изобрели 128 бит это всего в два раза больше бит чем сегодняшние 64 бита. В принципе и 64 случайных бита тоже сойдёт, если там пав сотен значений в час генерируется.

А точно мы говорим об одном и том же? О кластерном индексе, да? Который надо перестаивать при вставке значения "в середину"

А точно мы говорим об одном и том же? О кластерном индексе, да? Который надо перестаивать при вставке значения "в середину"

Не представляю что «кластерный индекс» в этом контексте может значить.

И второй вопрос - а какие такие гигантские накладные расходы несёт автоинкремент?

Синхронизация состояния

Не представляю что «кластерный индекс» в этом контексте может значить.

Ок, мой косяк кластеризованный

Синхронизация состояния

Копейки Мы же не из базы вычитываем последнюю вставленную строку, а где-то храним это число

Копейки Мы же не из базы вычитываем последнюю вставленную строку, а где-то храним это число

Вот и попробуйте организовать совместный доступ и изменение этого числа хотяб между двумя тредами. А потом попробуйте тоже самое повторить между 10 сетевыми узлами

Ок, мой косяк кластеризованный

Я все равно не знаю что это значит. Беглый гуглеж показывает документацию к mssql

Вот и попробуйте организовать совместный доступ и изменение этого числа хотяб между двумя тредами. А потом попробуйте тоже самое повторить между 10 сетевыми узлами

Это же (в общем) примитивная задача. Вставка и так в монопольном режиме будет происходить

Это же (в общем) примитивная задача. Вставка и так в монопольном режиме будет происходить

Ну вот и вы будете ждать на всех 9 узлах, пока десятый отваливается по таймауту

Чисто чтоб коснуться верхушки проблемы, попробуйте 2 phase commit хотяб разок реализоват

Я все равно не знаю что это значит. Беглый гуглеж показывает документацию к mssql

Я думаю в документации mssql хорошо описано что это такое. Полезно почитать чтобы знать, это один из ключевых моментов, который обязательно надо учитывать при проектировании рсубд

Ну вот и вы будете ждать на всех 9 узлах, пока десятый отваливается по таймауту

Так ждать же в любом случае надо. Например, уникальный индекс есть в таблице. Мы по любому при вставке пачки данных будем делать это по очереди

Так ждать же в любом случае надо. Например, уникальный индекс есть в таблице. Мы по любому при вставке пачки данных будем делать это по очереди

Да. Вы будете два раза

Да. Вы будете два раза

Зачем два, когда это можно сделать в одной блокировке?

Я думаю в документации mssql хорошо описано что это такое. Полезно почитать чтобы знать, это один из ключевых моментов, который обязательно надо учитывать при проектировании рсубд

Не вижу для себя ценности в настоящий момент. Мне гораздо важнее теория за CRDT прочими OT типами. Просто потому что у меня перед глазами прототип распределённого хранилища для ультрагафа. и я стадию со счетчиками уже прошёл и это ОЧЕНЬ сложно. Casual tree проще

Зачем два, когда это можно сделать в одной блокировке?

Еще раз предлагаю проверить свою гипотезу на 10 сетевых узлах, два из которых на разных концах планеты и один за китайским файрволлом

Не вижу для себя ценности в настоящий момент. Мне гораздо важнее теория за CRDT прочими OT типами. Просто потому что у меня перед глазами прототип распределённого хранилища для ультрагафа. и я стадию со счетчиками уже прошёл и это ОЧЕНЬ сложно. Casual tree проще

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

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

Так объясните, раз уж это такой фундаментальный вопрос

Так объясните, раз уж это такой фундаментальный вопрос

Мне то это зачем? Да и вряд ли я смогу без усилий сделать это лучше, чем msdn, или где там вы ссылку находили

Мне то это зачем? Да и вряд ли я смогу без усилий сделать это лучше, чем msdn, или где там вы ссылку находили

Очень странно что вы в качестве аргумента против случайных значений привели в пример организацию b-tree, смысл которой хранить записи упорядоченными на нижнем уровне. Но самое странное что индекс то вообще не требует перестройки в случае неупорядоченной вставки, хватает page split: The commonly held belief that with a clustered index the rows are always stored physically on the disk in the same order as the index key is false Instead a page split occurs. ... Each page at the leaf level of both clustered and non clustered indexes has the address (File:Page) of the next and previous page in logical key order. These pages need not be either contiguous or in key order. e.g. the linked page chain might be 1:2000 <-> 1:157 <-> 1:7053 When a page split happens a new page is allocated from anywhere in the filegroup (from either a mixed extent, for small tables, or a non empty uniform extent belonging to that object or a newly allocated uniform extent). This might not even be in the same file if the file group contains more than one.

Очень странно что вы в качестве аргумента против случайных значений привели в пример организацию b-tree, смысл которой хранить записи упорядоченными на нижнем уровне. Но самое странное что индекс то вообще не требует перестройки в случае неупорядоченной вставки, хватает page split: The commonly held belief that with a clustered index the rows are always stored physically on the disk in the same order as the index key is false Instead a page split occurs. ... Each page at the leaf level of both clustered and non clustered indexes has the address (File:Page) of the next and previous page in logical key order. These pages need not be either contiguous or in key order. e.g. the linked page chain might be 1:2000 <-> 1:157 <-> 1:7053 When a page split happens a new page is allocated from anywhere in the filegroup (from either a mixed extent, for small tables, or a non empty uniform extent belonging to that object or a newly allocated uniform extent). This might not even be in the same file if the file group contains more than one.

Я вообще не думал, что суррогатный ключ всерьёз предлагают делать случайным. Мне казалось, что это прикол такой

Я вообще не думал, что суррогатный ключ всерьёз предлагают делать случайным. Мне казалось, что это прикол такой

Потому что вы не понимаете сложности синхронизации состояний и параллельного доступа. В монге именно для простоты используется псевдослучайный ObjectId как первичный ключ (не знаю что такое «суррогатный», мне mssql терминология далека)

Потому что вы не понимаете сложности синхронизации состояний и параллельного доступа. В монге именно для простоты используется псевдослучайный ObjectId как первичный ключ (не знаю что такое «суррогатный», мне mssql терминология далека)

Куда уж мне Суррогатный ключ - понятие из теории рбд. Mssql тут не пр чём Базовое, в общем-то, понятие Upd: рбд = реляционных баз данных

Куда уж мне Суррогатный ключ - понятие из теории рбд. Mssql тут не пр чём Базовое, в общем-то, понятие Upd: рбд = реляционных баз данных

Вы ошиблись группой, словарным запасом меряются в @ru_dba ;)

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

Так может и термины не особо нужны.

Вот это жопа

Спам

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

Ваше утверждение про clustered index — ложь

Ваше утверждение про clustered index — ложь

Какое именно? Что использование гуидов или случайных значений в случае кластеризованного индекса вредно?

Какое именно? Что использование гуидов или случайных значений в случае кластеризованного индекса вредно?

«вредно» до этого звучало как «надо перестраивать при вставке в середину». Что в реальности не требует никаких перестроек, а обходится делением ноды с записями, потому что это всё ещё b-tree. И ещё раз подчеркну — обсуждаемая структура придумана для хранения /упорядоченных/ данных, что было актуально в когда ничего кроме вращающихся болванок по которым елозит мантийная головка, не придумали и была задача минимизировать random seeks при /упорядоченном чтении/. Да, даже с твердотельной памятью такая компоновка поможет сократить число транзакции при /упорядоченном/ чтении, но это уже не даст такого выигрыша во времени как с нжмд. Конечно эта структура будет не самым эффективным способом хранить неупорядоченные данные. Но это не единственная структура: обычное b-tree без требований к порядку ака «некластреизованный индекс» будет себя примерно одинаково вести и при упорядоченной вставке и при случайной вставке. Но нет, вы продолжаете упорно настаивать что так как эта конкретная структура, которая создана для упорядоченных данных, будет менее эффективна на неупорядоченных данных, то значит неупорядоченные данные менее эффективны. 🤷🏻‍♂️ Солюсь из дальнейшей дискуссии, если оппонент не готов слышать не совпадающию с его позицию, это тупо непродуктивно, а повторять одно и тоже несколько раз, не несёт образовательной пользы сообществу.

интересно было бы ознакомиться со статистикой на тему какой объём данных хранится на каких носителях а то, конечно, хорошо рассуждать о том, что скорость физического доступа к данным уже не так низка, как раньше, и можно смело выдумывать абы какие структуры для хранения информации на физических носителях но скорее всего на практике эта скорость всё ещё та же проблема, что и раньше дальнейшие рассуждения я как-то не смог осилить, потому что там явное искажение моих слов и приписывание мне того, что я не говорил (вы продолжаете упорно настаивать ... неупорядоченные данные менее эффективны - конечно же ничего такого не было)

Привет, подскажите пожалуйста, как в aggregate занулить не нужные поля?

Ребят, подскажите пожалуйста. Есть полученный с запроса массив из объектов. Нужно в документ вставить или обновить записи в поле (типом массив из объектов)

Привет, подскажите пожалуйста, как в aggregate занулить не нужные поля?

https://docs.mongodb.com/manual/reference/operator/aggregation/project

Ребят, подскажите пожалуйста. Есть полученный с запроса массив из объектов. Нужно в документ вставить или обновить записи в поле (типом массив из объектов)

https://docs.mongodb.com/manual/tutorial/update-documents/

https://docs.mongodb.com/manual/tutorial/update-documents/

и? У меня есть массив из объектов: [{ a: 1, b: 1, result: 'a'}, { a: 2, b: 2, result: 'b'}, { a: 3, b: 3, result: 'g'}] Есть документ: { foo: 'bar', list: [{ a: 1, b: 1, result: 'e'}, { a: 2, b: 2, result: 'f'}] } Нужно в поле list либо вставить недостающие элементы либо обновить существующие. Когда я пытаюсь сделать это через bulkWrite из updateOne действий, то у меня появляется ошибка: The positional operator did not find the match needed from the query Действие выглядит примерно так: updateOne: { filter: { '_id': myId, 'list.a': item.a, 'list.b': item.b }, update: { $set: { 'list.$.result': item.result } }, upsert: true }

Если использовать $set, то обновляется только то, что есть. upsert почему-то при это варианте не работает model.updateOne({ _id: myId }, { $set: { 'list': myList }}, { upsert: true })

Я так понял, что такую логику за одно действие в базу сделать нельзя? Нужно сначала вызвать $set, затем база вернёт то, что изменилось и если количество изменённых элементов не совпало, то добавлять недостающие элементы? Или есть менее костыльные варианты?

$addToSet

$addToSet

$addToSet не изменяет существующие элементы

Все. Решил проблему. Часть которая отвечает за добавление или обновление элементов перенёс на js

А, вам ещё и обновить надо. В этом случае проще на каждую операцию по запросу или считать дельту состояния на клиенте и по конкретным индексам массива делать $set

Все. Решил проблему. Часть которая отвечает за добавление или обновление элементов перенёс на js

Да, так проще если есть возможность

Сделайте оптимистичную блокировку

Например по updatedAt

Да, так проще если есть возможность

Я использую Mongoose. Оказывается Mongoose помогает правильно формировать запросы, если например значения уже повторяются, то не добавлять в запрос и т.д.

Да, по-моему оно умеет само считать дельты объектов. Убедитесь что оно ещё делает условие по какому-то полю, например по updatedAt, чтоб не было ситуации когда вы перезаписываете чужие изменения.

Да, по-моему оно умеет само считать дельты объектов. Убедитесь что оно ещё делает условие по какому-то полю, например по updatedAt, чтоб не было ситуации когда вы перезаписываете чужие изменения.

Ну я фильтрую по _id. Думаю этого достаточно?

@dd_bb приветствую, вопрос есть ли способ произвести фильтрацию входных данных с помощью монги ? например по какому-то полю есть список строк из которых нужно исключить те, что уже имеются в коллекции?

искать то что присутствует и потом вычетать сеты самое очевидное решение, но может есть какое-то решение которое вернет из базы именно уже то, что отфильтровано?

Ну я фильтрую по _id. Думаю этого достаточно?

Нет. Нужно условие которое не выполнится когда ваши изменения попробуют применится к документу в который уже внесли изменения. В mongoose по-моему было поле __v которое инкрементируется с каждым обновлением. Если оно автоматом добавляется в запрос этого хватит

искать то что присутствует и потом вычетать сеты самое очевидное решение, но может есть какое-то решение которое вернет из базы именно уже то, что отфильтровано?

Вы можете делать операции над множествами прямо в монге: https://docs.mongodb.com/v3.2/reference/operator/aggregation-set/

Вопрос только о каком количестве элементов речь

Вопрос только о каком количестве элементов речь

например 1к записей на входе, против записей из базы около 6М

Нет. Нужно условие которое не выполнится когда ваши изменения попробуют применится к документу в который уже внесли изменения. В mongoose по-моему было поле __v которое инкрементируется с каждым обновлением. Если оно автоматом добавляется в запрос этого хватит

Не совсем понимаю для чего это

Вопрос только о каком количестве элементов речь

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

почему монгуз bulkWrite __v не пишет?

Доброго времени суток! Можно ли задавать здесь вопросы по pymongo? Или лучше в другом месте?

Мне с ним помогли здесь)

Ну тогда я тоже спрошу) Хочу зафетчить большое количество документов (желательно >500к, в идеале – >37млн) паймонгой. Около 20к доков и ~двух минут ловлю CursorNotFound: cursor id 100500 not found , даже с no_cursor_timeout=True Забираю вот так:    con = pymongo.MongoClient(MONGODB_HOST, MONGODB_PORT, username=USERNAME, password=PASSWORD)     psp = con.get_database(MONGODB_DATABASE)     events = psp.events.find({ # мой запрос            }           ,no_cursor_timeout=True, batch_size=10) Это я что-то делаю не так или сервер игнорирует no_cursor_timeout ?

< 20к документов берет нормально

Подскажите, плз, почему может не создаваться индекс? В приложении всё ок проходит, а индекса так и нет. С соседними коллекциями всё работает нормально

Ну тогда я тоже спрошу) Хочу зафетчить большое количество документов (желательно >500к, в идеале – >37млн) паймонгой. Около 20к доков и ~двух минут ловлю CursorNotFound: cursor id 100500 not found , даже с no_cursor_timeout=True Забираю вот так:    con = pymongo.MongoClient(MONGODB_HOST, MONGODB_PORT, username=USERNAME, password=PASSWORD)     psp = con.get_database(MONGODB_DATABASE)     events = psp.events.find({ # мой запрос            }           ,no_cursor_timeout=True, batch_size=10) Это я что-то делаю не так или сервер игнорирует no_cursor_timeout ?

У меня такая же проблема. Частично решается первой ссылкой в гуугле про batch_size. Пробовал отладить, но не прокатило. Вычислил только то, что если стучаться напрямую в мастер, то работает. Мне было не критично пока, потому решил так. Но, видимо, второй раунд с этой проблемой у меня ещё будет...

У меня такая же проблема. Частично решается первой ссылкой в гуугле про batch_size. Пробовал отладить, но не прокатило. Вычислил только то, что если стучаться напрямую в мастер, то работает. Мне было не критично пока, потому решил так. Но, видимо, второй раунд с этой проблемой у меня ещё будет...

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

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

Ну вот у меня сработал маленький батч и чтение с мастера (примари преверред).