Я слышал, что большие размеры партии на самом деле не дают каких-либо дополнительных характеристикЧто такое оптимальный счетчик количества предметов с помощью метода InsertBatch в драйвере mongodb C#?
Какой оптимальный?
Если вы вызываете «Вставить», чтобы вставлять документы по одному, для каждого документа есть круговое путешествие по сети. Если вы вызываете InsertBatch, чтобы вставлять документы в пакеты, для каждой партии вместо каждого документа требуется круговое путешествие по сети. InsertBatch более эффективен, чем Insert, потому что он уменьшает количество сетевых поездок.
Предположим, вам нужно вставить 1,000,000 документов, можно проанализировать количество сетевых обходов для различных пакетных размеров:
Итак, вы видите, что даже размер партии размером до 10 уже устранил 90% сетевых обходов, а размер партии 100 удалил 99% сетевых обходов.
Это несколько упрощенный анализ, поскольку он игнорирует тот факт, что по мере увеличения размеров партии размеры сообщений, но более или менее точные.
не думаю, что есть оптимальный размер партии. Я бы сказал, что более крупные партии более эффективны, но после того, как у вас будет 10-100 документов на каждую партию, будут небольшие улучшения производительности с большими партиями.
Нет ссылки на то, где вы его слышали? Хм, я бы обычно говорил все, что вписывалось в пространство размером 16 мегабайт (макс.)? – Sammaye
Я открыл проблему в jira, и это было упомянуто в комментариях https://jira.mongodb.org/browse/CSHARP-725 – Serdar
Хорошо, я думаю, что я понимаю, вы за одну вызывающую пакетную вставку с размером документа более 16 мг , что Роберт говорит также о том, что помощь крупным партиям зависит от того, насколько чисты ваши данные, если он постоянно возвращается клиенту из-за ошибок, тогда будет более эффективным выполнение меньших партий (как он говорит еще раз). Что касается оптимальной суммы здесь: хм, может быть, 100 в партии? – Sammaye