Старый
вот предположим есть кластер, 256 гб оперативы его общее кол-во, размер базы 3+ тб, запросы разные, например вывести список товаров прошедших через юзера в компании за пол года, или вообще весь, а так же целиком у компании
Старый
где до 30 юзеров
Старый
сколько такие запросы потребуют iops при выполнении в сравнении с выше перечисленными бд
yopp
:)))))))))
yopp
Случайное число от 0 до «сколько вытянет сторадж»
Старый
Случайное число от 0 до «сколько вытянет сторадж»
вот тут то и оно, что базе одновременно ещё есть хранимые xml до разбора приложением
yopp
Но в целом, в худшем случае, по числу страниц которые необходимо просмотреть для поиска по индексу и потом ещё по числу страниц для чтения документов.
Aleksey
и еще учесть фрагментацию файловой системы, и тип схд
Aleksey
и длинну кабелей до схд. и качество лунного света.
yopp
Нормальные стораджи блоком пишут
Старый
и еще учесть фрагментацию файловой системы, и тип схд
вот потому и думаю, как рассказать одному из партнёров, что их наёбывает подрядная организация
yopp
Так что фрагментация не должна ролять
Старый
будут netapp+iscsi как мне известно
yopp
Потому что не будет последовательного чтения в худшем случае
Старый
его и не будет
Старый
так и так
Aleksey
оценка iops для базы при выполнеии запроса... хм.
yopp
Смешно, соглашусь.
Aleksey
даже не знаю слышал ли я более странное предложение
Старый
оценка iops для базы при выполнеии запроса... хм.
у меня есть запросы к mssql которые фактически кладут базу
Aleksey
у всех есть такие запросы.
yopp
С таким подходом ты насчитаешь чушь полную
yopp
Потому что ты пытаешься определить размер абстрактного коня в абстрактной системе координат
Старый
😂 а ещё у меня многие кодеры потребовали им поченить select count * у кассандры и аэроспайка
yopp
Даже не коня, а его абстрактной проекции
yopp
Так не из этого исходить надо
yopp
Модели нужно строить
yopp
Взять срез реальных данных, гигов 100, залить в монгу и исследовать данные
yopp
Взять целевые параметры, типа числа потребителей, количества и типа запросов
yopp
Взять пиковые параметры, запас
Aleksey
не. всё фигня. требуй all flash на 40Tb
yopp
Пфф
Aleksey
это под journal
yopp
NVMe
Aleksey
под данные еще 2 стойки
Старый
Взять срез реальных данных, гигов 100, залить в монгу и исследовать данные
нет ещё данных, к тому же все данные должны быть подписаны разными ключами и конторами из списка их больше 16 тысяч
yopp
Пиздец
yopp
К абстрактной архитектуре ещё а добавок.
Aleksey
о
Aleksey
я видел ответ на этот вопрос
Старый
😂
Aleksey
не. у меня гдето было тз на эту тему
Aleksey
"Время выполнения запросов зависит от параметров, не поддающихся надежной оценке на стадии проектирования"
Aleksey
вот. и нахуй послал. и еще раз вернутся!
Aleksey
чудо а не фраза
Igor
А может кто-то подсказать (не так давно с монгой работаю, еще не освоился) - есть запрос, который возвращает грубо говоря {elements:[{...}, {...}, {...}]}, в то время как мне нужно - [{...},}{...},{...}]. Как это можно сделать?
yopp
На клиенте выкусить
Igor
На клиенте выкусить
Серьезно, больше никак? То есть монга не позволяет устранять излишние вложенности?
yopp
Можно через AF сделать, но я смысла не вижу.
yopp
См
yopp
Тьфу блин. Короче смотри там на выбор от projection до redact
yopp
Aggregation framework
yopp
Но лучше либо избавиться от лишнего подокумента, либо кроить на клиенте
Igor
Еще один вопрос - мне выдается частенько маппером всякая херня по типу { "$numberInt" : "1" }, { "$numberLong" : "1" } и прочее такое. Можно ли как-то заставить монгу проглатывать и выплевывать адекватные примитивы, или это со стороны фреймворка проблема?
yopp
Со стороны фреймворка
yopp
Bson бинарный же
yopp
То что ты показываешь это расширенная json нотация bson
Igor
То что ты показываешь это расширенная json нотация bson
Просто странно, учитывая то, что загоняю я определенно Json, такое видеть.
yopp
Весь протокол и обработка внутри базы в bson. То что ты показываешь это проблема десермализации скорее всего
yopp
Bson бинарный формат, там тип задаётся 8 битами
Max
@dd_bb привет! А подскажи, плиз.
в лог монги активно пишутся строки типа
2017-10-27T06:17:25.916-0700 I COMMAND [conn26413] query dev_0.subid_cr_info query: { subscription_id: "59c777e14e8fb4f2ff8b45cd", subid_name: "subid1", clicks: { $gte: 100 } } planSummary: IXSCAN { subscription_id: 1, subid_name: 1, clicks: 1 } cursorid:307732170309 ntoreturn:0 ntoskip:0 keysExamined:101 docsExamined:101 numYields:6 nreturned:101 reslen:15921 locks:{ Global: { acquireCount: { r: 14 } }, Database: { acquireCount: { r: 7 } }, Collection: { acquireCount: { r: 7 } } } 105ms
оно зачем это говорит? это какой-то лог долгих-кривых запросов, которые стОит передать девелоперам?
Max
там в конце везде сколько-то ms, похоже на медленные запросы.
так?
Alexander
ну вон 105 мс у тебя запрос выполняется
стоит оптимизировать
yopp
Типа того.
yopp
Там нечего судя по всему оптимизировать. На 101 лукап ключа 101 документ.
yopp
Можно лимит приподнять
yopp
Сколько qps?
Max
оно медленно изза диска, 100%
Max
сек
yopp
Памяти добавьте значит
Max
qps монгостатом же можно посмотреть?
yopp
Да
Max
1.2k ins
3k query
3.5k update
500 getmore
500 command
наверное это оно :)