Физик-ядерщик
Хелоу друзья
Физик-ядерщик
Ускоряет ли поиск более детально описанный поисковый запрос, в котором указано несколько полей вместо одного?
Aleksey
Ускоряет ли поиск более детально описанный поисковый запрос, в котором указано несколько полей вместо одного?
Если эти поля проиндексированы - то да
Андрей
Кто-то может подсказать, почему не работает лдап авторизация?
"ctx":"conn19","msg":"Authentication failed","attr":{"mechanism":"PLAIN","principalName":"","authenti
cationDatabase":"$external","client":"127.0.0.1:50508","result":"OperationFailed: SASL step did not complete: (no mechanism available)"}}
На хосте с саслом порядок, авторизация на лдапе консольно происходит. В конфиге СУБД есть setParameter:
saslauthdPath: /var/run/saslauthd/mux
authenticationMechanisms: PLAIN,SCRAM-SHA-1,SCRAM-SHA-256
Denis
Господа подскажите, насколько длянна названия поля влияет на размер базы? у меня 300 млн документов. имеет ли смысл делать котроткие названия полей, что бы выйграть на размере базы?
Я так храню. Пишу на го, там тэги структур bson, так что называется B а что C не забуду. Плюс смотрел hiload доклад от чувака из joom вроде, он топил за такой вариант, что мол весят и данные и индексы меньше
Даже не особо страдаю когда документы в базе смотрю, обычно по значению поля уже понятно что это
Denis
В моем случае есть. У меня массовый апдейт раз в три месяца. Потом только чтение. И чем больше размер базы тем больше стоимость владения. Через год по моим подсчётам будет 2 Тб база. Так что я бьюсь за каждый гигабайт
compact можно делать с какой то периодичностью. Если бывает что куча доков удаляется
Viktar
compact можно делать с какой то периодичностью. Если бывает что куча доков удаляется
Так и делаем. У нас апдейты. Ничего не удаляем
Denis
Так и делаем. У нас апдейты. Ничего не удаляем
На таймсериес бд переезжать уже поздно я так понял? )
Клик например. Он норм жмет. Но если вы храните что то типа логов, транзакций (только инсерты). Говоришь апдейты, смотря какие, мб и таймсериес тоже не то
Viktar
Да. И стоимость переезда довольно большая получится
yopp
Если документы небольшие, то разница не существенная из-за компрессии
yopp
Похоже на правду, да
yopp
Особенно если вы zstd используете
Viktar
Именно его и использую
yopp
У snappy результат может быть лучше
yopp
В смысле что короткие поля будут давать больше выигрыша
Viktar
Я понял. Но проиграю на компрессии
yopp
Да
yopp
В зависимости от содержимого документа, можно попробовать какие-то хитрости
yopp
Например собирать документы в бакеты
yopp
Так чтоб минимизировать дублирующиеся поля
yopp
Если есть какие-то поля с низкой энтропией — нормализовать их
Viktar
У меня приоритет по скорости чтения. Документы в 98% случаев достаются по ид. Поэтому делали макс денормализовано
yopp
Не видя примеров документов и статистики по полям, сложно что-то предложить :)
Denis
Особенно если вы zstd используете
Почитал в блоге монги. А почему они не сделали zstd дефолтным, а оставили snappy. Хотя сами пишут что zstd всем лучше
yopp
yopp
Но учитывая что основное бутылочное горлышко это любое IO, даже поход в кеш это долго, не говоря уже о памяти, то я даже не знаю есть ли смысл на CPU cost обращать внимание
Viktar
Не видя примеров документов и статистики по полям, сложно что-то предложить :)
Документы каталога. Люди и их атрибуты, адреса, телефоны, соседи, кредиты и т.п. банковская сфера
Viktar
zstd дало нам перформанс по ИО на 27%, по СПЮ прирост был в 44%. Для нас это увеличило скорость приложения на 31%
yopp
Viktar
И второй момент, что читаем и пишем на один диск.
yopp
Детали в том, что тупо много документов и они довольно большие. ~100кб
Перехетрить энтропийное кодирование можно только статистическим анализом
yopp
И переносом части данных в клиента
Viktar
И у нас ещё тупо идёт bulk updateOne.
yopp
Я так понимаю что борьба идёт не за запись, а за чтение
Viktar
В проде за чтение, в стейджинге за запись.
Viktar
Процессим в общем случае 450-500 млн документов.
Denis
В проде за чтение, в стейджинге за запись.
За чтение можно попробовать делать covered query где возможно
Viktar
Сейчас сделали для процессинга 20 нод для чтения.
Viktar
За чтение можно попробовать делать covered query где возможно
В моем случае, не имеет смысла. Читается документ целиком и целиком используется
Denis
Тогда поможет только переписать бэк на го. Если уже на го то на раст
Denis
🐺
db.zips.update({city:"HUDSON"},{$set:{"pop":pop+5}})
🐺
подскажите как мне обновить значение pop + 5
🐺
как взять старое значение и прибавить ?
Roman Khonichev
$inc
Viktar
подскажите, можно ли ускорить агрегацию
"command": {
"aggregate": "addressCatalog",
"pipeline": [
{
"$geoNear": {
"near": {
"type": "Point",
"coordinates": [
-81.214015,
33.984846
]
},
"distanceField": "dist.calculated",
"maxDistance": 200,
"query": {},
"includeLocs": "dist.location",
"spherical": true
}
},
{
"$limit": 5
}
],
"cursor": {},
"lsid": {
"id": {
"$uuid": "7b630c0b-5ec0-4adb-962a-96fcb23eedf2"
}
},
"$db": "catalog",
"$readPreference": {
"mode": "primaryPreferred"
}
},
смысл найти ближлежащие обекты
размер коллекции 111 млн записей
"storage": {
"data": {
"bytesRead": 2351827895,
"timeReadingMicros": 25295139
}
𝚂𝚑𝚞𝚔𝚑𝚊
как популяризировать(populate) при получении, сохранении и возвращении документа и тд
𝚂𝚑𝚞𝚔𝚑𝚊
сейчас у меня просто повторяющийся код
Post.post(“save”, function () {...})
и вот так 3 раза и меняется только значение “save”
𝚂𝚑𝚞𝚔𝚑𝚊
можно это как-то сократить?
Sergey Bedritsky
господа, нужна оплачиваемая помощь с несколькими муторными аггрегациями. куда обратится?
Sergey Bedritsky
может у кого-то есть час-два времени?
Антон
у меня с фронта приходит объект json с фильтром для монги. и если в фильтре не только строка или число, а еще ObjectID, то проблема - json преобразует ее в строку... есть какие то адекватные варианты передачи id в json? чтобы на бэке не парсить этот json
Bogdan
Всем привет!
Ребят подскажите пожалуйста как через Sequilize сделать запрос такого вида?
SELECT * FROM users WHERE date_1 >= (date_2 + '2 day') OR date_1 is null;
Делаю вот так, но ерроры кидает
await Users.findAll({
where: {
activated_at: { [Op.lte]: lastActivatedAt },
date_2: {
[Op.or]: {
[Op.gte]: sequilize.col('date_1') + '2 days' ,
[Op.eq]: null,
},
},
Максим
Максим
по нему сразу поиск должен был делаться
Жсон это строка, если его не парсить то ничего особо с ним не сделаешь. И искать по нему не получится. Так что не понятно в чём вопрос.
Антон
ну как не получится? там есть тип строка и число. это поля нормально ищутся. а вот когда objectid, то он конвертится в строку и монго об этом не знает конечно
Максим
Sergey Bedritsky
Sergey Bedritsky
при этом таких документов миллионы. это плохая идея?
Viktar
Сделал индекс на коллекции
{
"v" : 2,
"key" : {
"cityId" : 1,
"loc_mdb" : "2dsphere"
},
"name" : "cityId_1_loc_mdb_2dsphere",
"background" : true,
"2dsphereIndexVersion" : 3
}
но он почему то не работает с моей агрегацией
db.addressCatalog.aggregate([
{
$geoNear: {
near: { type: "Point", coordinates: [-149.914791, 61.133738 ] },
distanceField: "dist.calculated",
maxDistance: 2,
query: { cityId: xxxxxxxx },
includeLocs: "dist.location",
spherical: true
}
}
])
Получаю вот такую ошибку
{'ok': 0.0, 'errmsg': 'error processing query: ns=catalog.addressCatalogTree: GEONEAR field=loc_mdb maxdist=200 isNearSphere=1\nSort: {}\nProj: {}\nCollation: { locale: "simple" }\n planner returned error :: caused by :: unable to find index for $geoNear query', 'code': 291, 'codeName': 'NoQueryExecutionPlans'}
Viktar
"loc_mdb" : [
-149.914791,
61.133738
]
Вот по этому полю сделан гео индекс
Viktar
а можно пример, не совсем вас понял? я брал за основу
https://docs.mongodb.com/manual/reference/operator/aggregation/geoNear/
Viktar
db.places.aggregate([
{
$geoNear: {
near: { type: "Point", coordinates: [ -73.99279 , 40.719296 ] },
distanceField: "dist.calculated",
maxDistance: 2,
query: { category: "Parks" },
includeLocs: "dist.location",
spherical: true
}
}
])
yopp
а можно пример, не совсем вас понял? я брал за основу
https://docs.mongodb.com/manual/reference/operator/aggregation/geoNear/
У вас в query внутри $geoNear указано только поле cityId
yopp
Вероятно вам нужно указать key: loc_mdb
Viktar
так тоже пробывал, та же ошибка
Viktar
но самое интересное, что с не с композитным индексом работает
Viktar
у меня до этого был простой геоиндекс, и с ним запрос отрабатывал, просто он довольно медленный, решил отсекать по городу ещё но что то не получилось
yopp
А индекс точно создался уже?
Viktar
как проверить наверняка?
Viktar
> db.addressCatalog.createIndex({ cityId:1, loc_mdb : "2dsphere" }, {background:true})
{
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 3,
"numIndexesAfter" : 4,
"ok" : 1
}
Viktar
теоритически создался