RL
Это не имеет отношения к предварительной оптимизации, речь скорее про именование переменных
Size: a a a
2020 May 03
RL
Если с нуля пишется - имена переменных
RL
Если работающий код - уже оптимизация при необходимости (не предварительная)
y
Это и есть предварительная оптимизация. Вы хотите изменить какой-то один подход, в пользу другого подхода, руководствуясь одним случаем.
Да, уменьшение длинны ключа в ряде случаев может иметь положительный эффект. Но для того чтоб понять какой конкретно эффект и стоит ли в него инвестировать, нужно иметь перед глазами реальную проблему.
В общем случае изменение не будет существенным, так как проблема очень редко в размере документа. Проблемы в основном в том, что нет индекса, или слишком много индексов или слишком большая вариативность значений индекса.
Да, уменьшение длинны ключа в ряде случаев может иметь положительный эффект. Но для того чтоб понять какой конкретно эффект и стоит ли в него инвестировать, нужно иметь перед глазами реальную проблему.
В общем случае изменение не будет существенным, так как проблема очень редко в размере документа. Проблемы в основном в том, что нет индекса, или слишком много индексов или слишком большая вариативность значений индекса.
y
И попытка решить эту проблему размером документа — неэффективна.
y
Оптимизации это десятки и сотни человеко-часов. Чтоб это имело хоть какой-то экономический смысл, подобные изменения должны экономить тысячи долларов
RL
Я все ещё сомневаюсь в корректности измерений. Слишком большая разница. 15-20% ещё реально, больше — уже вызывает вопросы. Не исключаю специфики, но сомневаюсь.
Вероятно вы сравнивали существующую коллекцию, в которой могло образоваться много вакантных страниц, с новой коллекцией, в которую вы залили модифицированные данные.
Вероятно вы сравнивали существующую коллекцию, в которой могло образоваться много вакантных страниц, с новой коллекцией, в которую вы залили модифицированные данные.
N
а пример документа до и после можно?
N
куданить на пастбин
y
У вас 3 индекса в первой коллекции, 2 во второй
RL
в первой еще uniq автоматический
RL
во второй в качестве уника уже имеющееся поле
y
Второй момент: для корректного сравнения размера необходимо сделать дамп обеих коллекций и восстановить их с новыми именами или дропнуть и создать по новой
y
И сравнивать можно только в том случае если схемы вообще не менялись. Если схема поменялась или подменялся порядок ключей, то сравнение уже не будет корректным.
RL
документы в этих коллекциях служат как статичные данные, не подразумевающие никаких правок
RL
оригинальный
https://hastebin.com/gizubowujo.json
https://hastebin.com/gizubowujo.json
RL
модифицированный
https://hastebin.com/duhutudidu.json
https://hastebin.com/duhutudidu.json
RL
справедливости ради, 2 общих поля в документе были убраны и плюс один из массивов обьектов стал массивом массивов
RL
плюс пара дат из строк переведены в таймштамп
RL
нисколько не претендую на истину и совсем не хочу советовать кому либо, что либо.
предлагаю к этому относиться просто как к интересному факту.
и мой кейс был весьма специфичный и это не коммерческий проект.
в нормальном продакшене я в целом соглашусь с коллегой - овчинка выделки скорее всего не будет стоить.
предлагаю к этому относиться просто как к интересному факту.
и мой кейс был весьма специфичный и это не коммерческий проект.
в нормальном продакшене я в целом соглашусь с коллегой - овчинка выделки скорее всего не будет стоить.