Привет На гитхабе видел несколько схем такого типа const mongoose = require('mongoose') var Schema = mongoose.Schema; const userSchema = new Schema({ chat_id: { type: Number, index: true, unique: true, required: true }, first_name: { type: String, required: true }, last_name: String, username: String, }, { timestamps: true }) const User = mongoose.model("User", userSchema) module.exports = User Но я всё время получаю ошибку The 2nd parameter to `mongoose.model()` should be a ' + 'schema or a POJO Подскажите, пожалуйста, что я делаю не так

единственный вопрос к { timestamps: true }

спасибо, чекну

если я индексацию по createdAt не давал и в aggregate в конце приписал sort by createdAt (чтоб он вразброс не давал) он не будет есть память для сортировки?

ребят, по умолчанию mongoose по createdAt сортирует же да?

если я индексацию по createdAt не давал и в aggregate в конце приписал sort by createdAt (чтоб он вразброс не давал) он не будет есть память для сортировки?

Привнт всем, в монго 4 как я понял не подерживается --source, как можно настроить реплекацыю без реплика сетов на мастере?

Какой самый эффективный способ получить последние n элементов коллекции?

Какой самый эффективный способ получить последние n элементов коллекции?

Да я уже решил все делать на клиенте, коллекции максимум могут быть 100 элементов и сами объекты небольшие

Привет! Разбираюсь с тем как устроен bson, насколько я понял ключи хранятся как есть, просто строкой. Также в монге документы хранятся в виде валидных bson. Возник вопрос почему ключи не кодируются, для экономии места, времени на сравнение и т.п.? Кажется что поскольку ключи в документах примерно одинаковые обычно, то это может давать большой оверхед, так ли это?

Привет! Разбираюсь с тем как устроен bson, насколько я понял ключи хранятся как есть, просто строкой. Также в монге документы хранятся в виде валидных bson. Возник вопрос почему ключи не кодируются, для экономии места, времени на сравнение и т.п.? Кажется что поскольку ключи в документах примерно одинаковые обычно, то это может давать большой оверхед, так ли это?

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

Все эти оптимизации не имеют смысла, так как в 98% случаев даже snappy нивелирует все нюансы

Все эти оптимизации не имеют смысла, так как в 98% случаев даже snappy нивелирует все нюансы

Так вот, смысл все таки есть, проверялось на реальном примере и уменьшилась коллекция в два раза, путем сокращения ключей до 3-4 символов без особой потери читаемости.

Так же пример кейса где это может быть важно - бесплатные 500мб на атласе.

К - Категоричность

Второй момент, разница в два раза вызывает вопросы Или это какой-то специфический случай или ошибка дизайна эксперимента

К тому же надо еще вспомнить про оперативную память и ее размер, если вдруг захочется держать весь датасет в памяти

Докинем еще размер на передачу по сети

Я не понимаю причем здесь время разработчика

Там тоже компрессия есть

И плюс кейс когда что то пишется с нуля - имеет смысл держать в голове этот факт при проектировании схем документов

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

Я все ещё сомневаюсь в корректности измерений. Слишком большая разница. 15-20% ещё реально, больше — уже вызывает вопросы. Не исключаю специфики, но сомневаюсь. Вероятно вы сравнивали существующую коллекцию, в которой могло образоваться много вакантных страниц, с новой коллекцией, в которую вы залили модифицированные данные.

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