_ilchpl_
Всем привет, безопасно ли по _id получать пост из базы данных на фронтенде, при условии, что_id поста будет в строке браузера как путь к посту. Например: posts/:_id и тд?
Anton
Здравствуйте! Скажите, где в монголии (желательно улан-батор) банкомат поддерживающий карты МИР?
Igor
Здравствуйте! Скажите, где в монголии (желательно улан-батор) банкомат поддерживающий карты МИР?
Эт конечно не про freebsd на канале с аниме, но тоже не плохо )
Нуриддин
Здравствуйте! Скажите, где в монголии (желательно улан-батор) банкомат поддерживающий карты МИР?
Пока самый интригующий вопрос в этой группе)
Viktor
Привестствую всех, недавно начал изучать монгу для своего проекта и столкнулся с проблемой. Все документы в базе можно представить с помощью схем ниже мне надо искать документы у которых поля в определённом аргументе (который находится можно сказать во вложенном списке по схеме) равны опр значению
Viktor
from pydantic import BaseModel
from typing import Union, List, Optional
from beanie import Document
class Language(BaseModel):
    ru: str
    en: str
class KeyValue(BaseModel):
    type: str
    key: Optional[str] = ""
    args: dict
    lines: Language
class DictElement(BaseModel):
    type: str
    key: Optional[KeyValue] = ""
    value: Optional[KeyValue] = ""
class Formatted(BaseModel):
    value: Language
    nameColor: Optional[str] = ""
    valueColor: Optional[str] = ""
class NumericElement(BaseModel):
    type: str
    name: Optional[Union[str, KeyValue]] = ""
    value: Optional[Union[float, int, str]] = ""
    formatted: Optional[Union[str, Formatted]] = ""
class Text(BaseModel):
    type: str
    text: Optional[str] = ""
class RangeElement(BaseModel):
    type: str
    name: Optional[KeyValue] = ""
    min_value: Optional[Union[float, int, str]] = 0
    max_value: Optional[Union[float, int, str]] = 0
    formatted: Optional[Union[str, Formatted]] = ""
class TextElement(BaseModel):
    type: str
    title: Optional[Text] = ""
    text: Optional[Union[str, KeyValue]] = ""
class ListElement(BaseModel):
    type: str
    title: Optional[Union[str, Text]] = ""
    elements: Optional[List[Union[DictElement, NumericElement, TextElement, RangeElement]]] = []
class InfoBlock(BaseModel):
    type: Optional[str] = ""
    title: Optional[Union[str, Text]] = ""
    elements: Optional[List[Union[DictElement, NumericElement, ListElement, TextElement, RangeElement]]] = []
class Status(BaseModel):
    state: str
class Item(Document):
    item_id : str
    category: str
    name: KeyValue
    color: str
    status: Status
    infoBlocks: List[InfoBlock]
Viktor
Сейчас для поиска применял Beanie
Артем
Всем привет. Сорян за нубский вопрос, но. Если запрос на изменение данных в довольно большой коллекции, отправленный с клиента, отвалится по тайм-ауту. Команда выполнится до конца или прервется?
Nick
Всем привет. Сорян за нубский вопрос, но. Если запрос на изменение данных в довольно большой коллекции, отправленный с клиента, отвалится по тайм-ауту. Команда выполнится до конца или прервется?
Смотря какая ошибка, если это таймаут соединения то выполнение апдейта продолжится
Nick
Привестствую всех, недавно начал изучать монгу для своего проекта и столкнулся с проблемой. Все документы в базе можно представить с помощью схем ниже мне надо искать документы у которых поля в определённом аргументе (который находится можно сказать во вложенном списке по схеме) равны опр значению
Не понятно какой запрос хочется выполнить и что найти
Viktor
Не понятно какой запрос хочется выполнить и что найти
Для начала надо новую проблему решить). У меня монга по какой то причине дропает все бд через время. При том непонятно через какое время, стоит в контейнере и даже при перезапуске контейнера все нормально.
Артем
Смотря какая ошибка, если это таймаут соединения то выполнение апдейта продолжится
Да, речь именно про таймаут клиента, т.к. размер коллекции очень большой и нужно внести изменения по критерию выборки в несколько тысяч документов. Спасибо!
Igor
Для начала надо новую проблему решить). У меня монга по какой то причине дропает все бд через время. При том непонятно через какое время, стоит в контейнере и даже при перезапуске контейнера все нормально.
Где-то у тебя скрипт который пересоздает колекцию )
Viktor
Где-то у тебя скрипт который пересоздает колекцию )
Так бд пропадает через некоторое время, даже пробовал перезапускать контейнер и если делать это сразу то ничего не пропадает
Viktor
А просто когда сижу через mongosh она берёт и пропадает 😅
Сотрудник 236
А просто когда сижу через mongosh она берёт и пропадает 😅
mongosh может запускать крипты на старте
Сотрудник 236
Если linux, то в домашней директории ищи .mongoshrc.js
Асель
Запоздало: скорее всего нужно у одной ноды ещё и priority: 0 выставить, так как в вашем случае количество нод-кандидатов чётное и при потере линка возникает ситуация когда обе стороны не знают где находится большинство, так как обе стороны могут выбрать себе новую primary ноду
спасибо за ответ! не укала сразу в описании, но в резервном цоде у всех нод priority:0, в итоге нод кандидатов 3 штуки, и все в основном цоде
Andry
Подскажите пожалуйста есть такая проблема - я строю aggregate groupby и отвечает достаточно долго
Andry
{
"explainVersion" : "1",
"stages" : [
{
"$cursor" : {
"queryPlanner" : {
"namespace" : "WMS.InventSum",
"indexFilterSet" : false,
"parsedQuery" : {
"InventDim.WarehouseId" : {
"$eq" : "S097"
}
},
"queryHash" : "0F93E5F6",
"planCacheKey" : "552CC6CA",
"maxIndexedOrSolutionsReached" : false,
"maxIndexedAndSolutionsReached" : false,
"maxScansToExplodeReached" : false,
"winningPlan" : {
"stage" : "PROJECTION_DEFAULT",
"transformBy" : {
"AvailPhysical" : 1.0,
"InventDim.WarehouseId" : 1.0,
"PhysicalInventory" : 1.0,
"ProductId" : 1.0,
"_id" : 0.0
},
"inputStage" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"InventDim.WarehouseId" : 1.0
},
"indexName" : "WarehouseId",
"isMultiKey" : false,
"multiKeyPaths" : {
"InventDim.WarehouseId" : [
]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2.0,
"direction" : "forward",
"indexBounds" : {
"InventDim.WarehouseId" : [
"[\"S097\", \"S097\"]"
]
}
}
}
},
"rejectedPlans" : [
Andry
]
}
}
},
{
"$group" : {
"_id" : {
"ProductId" : "$ProductId",
"WarehouseId" : "$InventDim.WarehouseId"
},
"AvailPhysical" : {
"$sum" : "$AvailPhysical"
},
"PhysicalInventory" : {
"$sum" : "$PhysicalInventory"
}
}
}
],
"serverInfo" : {
"host" : "33c4907823e2",
"port" : 27017.0,
"version" : "5.0.27",
"gitVersion" : "49571988f1fea870e803f71a3ef8417173f3fbb1"
},
"serverParameters" : {
"internalQueryFacetBufferSizeBytes" : 104857600.0,
"internalQueryFacetMaxOutputDocSizeBytes" : 104857600.0,
"internalLookupStageIntermediateDocumentMaxSizeBytes" : 104857600.0,
"internalDocumentSourceGroupMaxMemoryBytes" : 104857600.0,
"internalQueryMaxBlockingSortMemoryUsageBytes" : 104857600.0,
"internalQueryProhibitBlockingMergeOnMongoS" : 0.0,
"internalQueryMaxAddToSetBytes" : 104857600.0,
"internalDocumentSourceSetWindowFieldsMaxMemoryBytes" : 104857600.0
},
"command" : {
"aggregate" : "InventSum",
"pipeline" : [
{
"$match" : {
"InventDim.WarehouseId" : "S097"
}
},
{
"$group" : {
"_id" : {
"ProductId" : "$ProductId",
"WarehouseId" : "$InventDim.WarehouseId"
},
"AvailPhysical" : {
"$sum" : "$AvailPhysical"
},
"PhysicalInventory" : {
"$sum" : "$PhysicalInventory"
}
}
}
],
"explain" : true,
"cursor" : {
},
"lsid" : {
"id" : UUID("f3a4953a-af72-4dbc-b79d-ce3af9ad0d59")
},
"$db" : "WMS"
},
"ok" : 1.0
}
Andry
Почему он не хочет использовать покрывающий индекс и можно ли заставить его использовать покрывающий индекс?
Andry
"$group" : {
"_id" : {
"ProductId" : "$ProductId",
"WarehouseId" : "$InventDim.WarehouseId"
},
"AvailPhysical" : {
"$sum" : "$AvailPhysical"
},
"PhysicalInventory" : {
"$sum" : "$PhysicalInventory"
}
Andry
на эти все поля у меня есть покрывающий индекс
Nick
Почему он не хочет использовать покрывающий индекс и можно ли заставить его использовать покрывающий индекс?
группировка не использует покрывающие индексы. Поэтому выбирается индекс только под match стейдж, а там самый лучший индекс как раз и выбран
Andry
группировка не использует покрывающие индексы. Поэтому выбирается индекс только под match стейдж, а там самый лучший индекс как раз и выбран
А что можно сделать чтобы быстро искать?
Andry
Эластик сбоку прикручивать?
Andry
мне надо чтобы 200 ms было
Andry
в целом эквивалентно на самом деле
Andry
там все под текущий фильтр попадают
Артем
Может это доступ к полю объекта такой долгий..?
Потому что у меня похожие запросы на большом объеме отрабатываются за сотни мс
Andry
Может это доступ к полю объекта такой долгий..?
Потому что у меня похожие запросы на большом объеме отрабатываются за сотни мс
Не знаю - вот эксплейн выше(( не тащит что то
Andry
я из Студии3T запрос запукаю
Andry
db.getCollection("InventSum").explain().aggregate([{ "$match" : { "InventDim.WarehouseId" : "S097" } },
{ "$group" : { "_id" : { "ProductId" : "$ProductId", "WarehouseId" : "$InventDim.WarehouseId" },
"AvailPhysical" : { "$sum" : "$AvailPhysical" }, "PhysicalInventory" : { "$sum" : "$PhysicalInventory" } } }])
Nick
db.getCollection("InventSum").explain().aggregate([{ "$match" : { "InventDim.WarehouseId" : "S097" } },
{ "$group" : { "_id" : { "ProductId" : "$ProductId", "WarehouseId" : "$InventDim.WarehouseId" },
"AvailPhysical" : { "$sum" : "$AvailPhysical" }, "PhysicalInventory" : { "$sum" : "$PhysicalInventory" } } }])
сделайте с explain("executionStats") и на https://pastila.nl
Andry
понял щас
Andry
https://pastila.nl/?003a5a01/ceb9cf61919f530754ffe47e38b44cb3#tUUBlPv8QiQKy6BTkbSnsA==
Viktar
Для 5 млн записей группировка работает норм за 6 сек
Andry
Для 5 млн записей группировка работает норм за 6 сек
ее как то покрывающий индекс можно заставить использовать?
Andry
Может тогда через оплог куда то в другую базу просинхронить?
Andry
Чтобы перфоманс получить
Andry
Мне просто совсем не норм((( даже близко
Nick
https://pastila.nl/?003a5a01/ceb9cf61919f530754ffe47e38b44cb3#tUUBlPv8QiQKy6BTkbSnsA==
тут
1) выборка идет всех данных, планировщик почемуто не делает колскан и считает что надо юзать индекс
2) как следствие для каждой записи полученной из индекса идет чтение дока и его разбор
конкретно тут можно убрать $match секцию и поулчить просто колскан для линейного чтения вместо рендом акссеса
Andry
тут
1) выборка идет всех данных, планировщик почемуто не делает колскан и считает что надо юзать индекс
2) как следствие для каждой записи полученной из индекса идет чтение дока и его разбор
конкретно тут можно убрать $match секцию и поулчить просто колскан для линейного чтения вместо рендом акссеса
это я понимаю, но вопрос в том как ускорить это
Andry
на монге
Nick
это я понимаю, но вопрос в том как ускорить это
вот так и ускорять, избавиться/кменьшить рендом акссес на диск либо давать больше ресурсов
Nick
это я понимаю, но вопрос в том как ускорить это
ну и предагрегаты конечно же в соседней коллекции
Andry
да маленький 254 мегабайта
Viktar
Percona попробуйте. Она все данные в памяти хранит
Viktar
Но честно я бы посоветовал пересмотреть подход
Andry
Но честно я бы посоветовал пересмотреть подход
да мне отчеты надо строить быстро - как тут что пересмотреть?
Andry
еще неплохо было бы обновиться, скорее всего в новых версиях планировщик хотя бы распознает что селективность индекса нулевая в данном случае
интеерсное предложение - минутку попробую
Viktar
Возможно вы можете делать предагрегации
Viktar
еще неплохо было бы обновиться, скорее всего в новых версиях планировщик хотя бы распознает что селективность индекса нулевая в данном случае
Сомневаюсь. Я и на 7 сталкивался, что использует индекс, там где он не нужен
Nick
Сомневаюсь. Я и на 7 сталкивался, что использует индекс, там где он не нужен
увы но это нормально для монги
Viktar
да маленький 254 мегабайта
А сколько времени у вас занимает время скопировать файл коллекции. Это даст вам примерное мин время IO операций со всей коллекцией.
Viktar
Это скорость, а я про время
Артем
А сколько времени у вас занимает время скопировать файл коллекции. Это даст вам примерное мин время IO операций со всей коллекцией.
Копия файла более дорогая операция, чем посчитать сумму же)
Nick
это я понимаю, но вопрос в том как ускорить это
есть еще параметр internalQueryPlannerGenerateCoveredWholeIndexScans, который говорит планировщику использовать индексы вместо колскана. Он на уровне сервера выставляется и как следствие может аффектить другие запросы, которые например бы быстрее выполнились по колскану
включать в рантайме через
db.adminCommand({setParameter: 1,"internalQueryPlannerGenerateCoveredWholeIndexScans": true});
сбрасывается после ребута монги. Чтоб не сбрасывалось в конфиг файл надо указывать
Viktar
есть еще параметр internalQueryPlannerGenerateCoveredWholeIndexScans, который говорит планировщику использовать индексы вместо колскана. Он на уровне сервера выставляется и как следствие может аффектить другие запросы, которые например бы быстрее выполнились по колскану
включать в рантайме через
db.adminCommand({setParameter: 1,"internalQueryPlannerGenerateCoveredWholeIndexScans": true});
сбрасывается после ребута монги. Чтоб не сбрасывалось в конфиг файл надо указывать
Очень не рекомендую. Вам нужно будет отслеживать все запросы
Nick
Очень не рекомендую. Вам нужно будет отслеживать все запросы
ага, очень специфичное решение чтоб его просто лепить
Andry
Не помогает он
Andry
то есть прироста не дало
Viktar
Покажите експлейн
Andry
https://pastila.nl/?0017e270/933d68cf2e7598b8af07940687bd74a5#FuBAvQXocoVQOaWRYz6eMw==
Viktar
Используется ваш индекс для группировки