Nick
и вы будете поулччать ошибки на вставках
Alexey
ну и да, привязка к инкрементам это плохая архитектура
Alexey
удалите юзера - будет дырка
Alexey
многопоток - будет дублирование, а если поле уникальное - ошибка
Anonymous
Вопрос по поводу _id в моделях.
Столкнулся с ситуацией, когда автогенерируемый _id вообще никак не будет использоваться и идет фактически мертвым грузом. Например, для модели "Товар", у которого в реальном мире уже есть аналог _id, чаще всего какое-то число, типа условного 5254, которое в рамках магазина чаще всего уникально. _id по умолчанию конечно тоже уникален, но 12-значный буквенно-циферный код товара в реальном мире какое-то извращение. Соответственно возникает вопрос, есть смысл тогда генерить этот самый код товара и его передвать в качестве _id ? Или все же лучше для mongo оставить в покое его _id и вводить дополнительное поле code?
Aleksandr
Возвращаясь к моему вопросу про колбэки, это нормальный выход из ситуации или костыль дикий?
const user = new userProfile({
id: '',
name: newUserData.data.name,
twitter: '',
vk: '',
fb: newUserData.data.id
});
userProfile.countDocuments((err, res) => {
if(err) throw err;
user.id = res + 1
console.log(user)
})
Alexey
Возвращаясь к моему вопросу про колбэки, это нормальный выход из ситуации или костыль дикий?
const user = new userProfile({
id: '',
name: newUserData.data.name,
twitter: '',
vk: '',
fb: newUserData.data.id
});
userProfile.countDocuments((err, res) => {
if(err) throw err;
user.id = res + 1
console.log(user)
})
дикий, юзай preSave хук, если уж прижало
Alexey
в схеме можно задать функцию которая будет генерировать id
Alexey
но надо понимать суть асинхронности, могут быть коллизии
Alexey
_id:{type:String, default:function(){return ...}}
Alexey
эта функция синхронная, соответсвенно никаких запросов к базе тут не получится сделать
Anonymous
Ну т.е. в целом это нормальная практика свой тип _id использовать?
Alexey
я не могу найти этому оправдание
Alexey
лучше засунуть ещё один id
Alexey
и доп индекс по нему
Alexey
просто в реальности вы можете получить кучу странностей, которые потом замучаетесь разгребать
Alexey
_id он потому и с _ начинается, что это внутренний идентификатор
Alexey
он не для показа пользователям
Anonymous
лучше засунуть ещё один id
ну вот собственно у меня в этом и вопрос, как делать лучше - переписывать дефолтный _id, либо вводить дополнительное свое поле. best practices, как говорится.
Alexey
если у вас терабайты данных в коллекции, то лишнее поле может давать нагрузку на сеть и место
Alexey
если у вас всего 100 метров база, то используйте доп параметр
Anonymous
Просто опять же, требование к коду товара такое же как и к _id, оно должно быть уникальным. Т.е. в любом случае будет дополнительная проверка перед вставкой и отлавливание ошибок.
Alexey
индекс по _id всегда есть, в случае с доп параметром его так же надо добавлять
Alexey
опять же - память и сторадж
Alexey
да, доп валидация на уникальность
Alexey
какой размер базы? сколько доков?
Alexey
у нас бывает десятки тысяч вставок в секунду - пожалели о вводе такого доп id
Alexey
так как доп индекс влияет на скорость инсертов, доп валидация так же
Anonymous
Вопрос интересует в целом, безотносительно к конкретной реализации бд.
В общем тогда буду ориентироваться исходя из требований. Спасибо, буду думать.
Nariman
Всем привет это правильный query
db.getCollection('Test').find({"time": { $lt: "20190400000000000" }}).count()
несмотря на то что time это string ?
Alex
Nariman
time в стринге хранить не очень нормально.
Я хотел удалить старые данные
И вот как я это сделал (Может кому пригодиться)
db.getCollection('Test').deleteMany({"time": { $lt: "20181201000000000" }})
Потом
db.runCommand( { compact : 'Test' } )
Alex
Я хотел удалить старые данные
И вот как я это сделал (Может кому пригодиться)
db.getCollection('Test').deleteMany({"time": { $lt: "20181201000000000" }})
Потом
db.runCommand( { compact : 'Test' } )
часто сталкиваюсь, когда хранится только в int или в UTCDateTime
Nick
Я хотел удалить старые данные
И вот как я это сделал (Может кому пригодиться)
db.getCollection('Test').deleteMany({"time": { $lt: "20181201000000000" }})
Потом
db.runCommand( { compact : 'Test' } )
Компакт вешает лок на базу, в которой находится коллекция, поэтому ее бездумное использование остановит все запросы пока компакт не закончится. При этом пользы от компакта практически не будет, если удаляется мало данных
Anonymous
почему нету переподключения?
const client = new MongoClient(url, {
useNewUrlParser: true,
autoReconnect: true,
reconnectTries: 60,
reconnectInterval: 1000,
});
Anonymous
монга не запущена. ожидаю повторных попыток подключния, но тихо
Anonymous
mongodb просто глоток свежего воздуха после реляционных бд
Roman
Господа помогите с репликой
имеем сервер с монгой 4.0.10 с данными, работал standalone,
решил сделать реплику, мои шаги:
1. на рабочем сервере в конфиг добавлено:
security:
authorization: enabled
keyFile: /var/lib/mongodb/mongo-keyfile
#operationProfiling:
replication:
replSetName: rs0
2. на вотором сервере поднимаем чистую монгу
security:
keyFile: /var/lib/mongodb/mongo-keyfile
#operationProfiling:
replication:
replSetName: rs0
3. на первом сервере
говорим
rs.initiate();
rs.add( { host: "mongo-backup-01:27017", priority: 0, votes: 0, hidden: true } );
4. rs.status()
для второго сервера
{
"_id" : 1,
"name" : "mongo-backup-01:27017",
"health" : 1,
"state" : 0,
"stateStr" : "STARTUP",
"uptime" : 383,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2019-07-03T12:26:28.658Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : NumberLong(18),
"lastHeartbeatMessage" : "",
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"configVersion" : -2
}
статус: STARTUP
что я делаю не так?
на первом сервере авторизация включена
на втором нет, может с этим связано?
Сапсибо, что дочитали :)
Roman
keyfile совпадают
yopp
почему нету переподключения?
const client = new MongoClient(url, {
useNewUrlParser: true,
autoReconnect: true,
reconnectTries: 60,
reconnectInterval: 1000,
});
проверьте что ваш драйвер в принципе в это умеет, а если умеет что это не требует какой-то особой конфигурации
Roman
да, попробуйте включить аутентификацию на обоих нодах и проверьте что keyfile совпадают
логин и пароли должны быть одинаковыми?
yopp
какие логины пароли?
yopp
на втором сервере у вас должен быть пустой dbpath
yopp
если мне память не изменяет, то rbac через оплог синхронизиуется. а значит когда вы добавили пользователей в праймари, они разъедутся по всем остальным нодам
Roman
понял, спасибо, пробую
yopp
yopp
заводить ещё один индетификатор ради красоты не имеет смысла
Josh
клиентам выдавать как-то надо красоту, поэтому практически всегда грохаю _id за ненадобностью, вот так вот
Roman
yopp
Roman
да, попробуйте включить аутентификацию на обоих нодах и проверьте что keyfile совпадают
на втором сервере вот такая ситуация
Roman
rs.status();
{
"ok" : 0,
"errmsg" : "no replset config has been received",
"code" : 94,
"codeName" : "NotYetInitialized"
}
Roman
{
"_id" : 1,
"name" : "mongo-backup-01:27017",
"health" : 1,
"state" : 0,
"stateStr" : "STARTUP",
"uptime" : 215,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2019-07-03T13:11:22.771Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : NumberLong(18),
"lastHeartbeatMessage" : "",
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"configVersion" : -2
}
Josh
не надо
Что не надо то? Целостность кода товара/услуги/предмета/этс нужна, но пользоваться километровой строкой неудобно
yopp
Что не надо то? Целостность кода товара/услуги/предмета/этс нужна, но пользоваться километровой строкой неудобно
что такое «целостность» и что такое «удобство»?
Roman
вот весь
yopp
удобство инкрементальных номеров — заблуждение
Roman
{
"set" : "rs0",
"date" : ISODate("2019-07-03T13:11:24.264Z"),
"myState" : 1,
"term" : NumberLong(1),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1562159481, 1),
"t" : NumberLong(1)
},
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1562159481, 1),
"t" : NumberLong(1)
},
"appliedOpTime" : {
"ts" : Timestamp(1562159481, 1),
"t" : NumberLong(1)
},
"durableOpTime" : {
"ts" : Timestamp(1562159481, 1),
"t" : NumberLong(1)
}
},
"lastStableCheckpointTimestamp" : Timestamp(1562159451, 1),
"members" : [
{
"_id" : 0,
"name" : "IP:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 3146,
"optime" : {
"ts" : Timestamp(1562159481, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2019-07-03T13:11:21Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1562156367, 2),
"electionDate" : ISODate("2019-07-03T12:19:27Z"),
"configVersion" : 2,
"self" : true,
"lastHeartbeatMessage" : ""
},
{
"_id" : 1,
"name" : "mongo-backup-01:27017",
"health" : 1,
"state" : 0,
"stateStr" : "STARTUP",
"uptime" : 215,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2019-07-03T13:11:22.771Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : NumberLong(18),
"lastHeartbeatMessage" : "",
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"configVersion" : -2
}
],
"ok" : 1,
"operationTime" : Timestamp(1562159481, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1562159481, 1),
"signature" : {
"hash" : BinData(0,"+Fj2rLCNS7dWy4CpclbJrCm6V28="),
"keyId" : NumberLong("6709090695648378881")
}
}
}
Roman
а.... блин :)
Roman
2019-07-03T16:14:28.620+0300 W NETWORK [replexec-1] getaddrinfo("mongo-backup-01") failed: Name or service not known
Josh
что такое «целостность» и что такое «удобство»?
назовите код товара?
6e7t0j9s09tyj0695h6fg4h8fgg37d8sd88fu1
это удобство
блоть, у нас таких товаров два, вам 6e7t0j9s09tyj0695h6fg4h8fgg37d8sd88fu1, который с g8e2f782f872 или fh738273f872g? Уточните
это целостность
yopp
назовите код товара?
6e7t0j9s09tyj0695h6fg4h8fgg37d8sd88fu1
это удобство
блоть, у нас таких товаров два, вам 6e7t0j9s09tyj0695h6fg4h8fgg37d8sd88fu1, который с g8e2f782f872 или fh738273f872g? Уточните
это целостность
метрики покажите, сколько раз у вас в пользователи используют какой-то там код для поиска товаров
Josh
я 3 символа использую для идентификации событий, хватает на месяц, лучшие id, 10/10
Rustam
Надо отличать sku от _id.
Josh
да
yopp
я 3 символа использую для идентификации событий, хватает на месяц, лучшие id, 10/10
вы занимаетесь бесполезной работой которая вероятнее всего не решает ни единой проблемы бизнеса
Josh
yopp
нет метрики, нет проблемы
Josh
цель вопроса от челика была как раз в этом, в каком-нть общепите аля макдак крутятся заказы очереди инкрементно и все довольны, всем нравится
yopp
у вас нет метрики, значит у вас нет проблемы, а значит вы могли бы потратить своё рабочее время на решение проблем бизнеса. я сомневаюсь что идентификаторы хоть как-то влияют на прибыльность вашего бизнеса или вообще оказывают хоть какое-то влияние
Roman
Привет!
Подскажите, пожалуйста, в каком случае лучше использовать
.find({})
а в каком
.find({}, {'atr1': 1, 'atr2': 1})
yopp
Привет!
Подскажите, пожалуйста, в каком случае лучше использовать
.find({})
а в каком
.find({}, {'atr1': 1, 'atr2': 1})
привет! в 95% случаев проекции не нужны, 4% приходятся на covered query и ещё 1% процент на ситуации когда у вас возник реальный затык в передаче больших документов по сети, при условии что используется буквально пара полей