и по ключу шардирования все-таки. Правильно ли я понимаю, если совсем просто:
date или _id - запись идет все время на один шард из-за монотонно возрастающего ключа
client_id - запись на все шарды
с client_id это работает только если у тебя вставка таким образом, что вставка вся с разными client_id
yopp
Alexey
ну каждый документ имеет конечно разные client_id
Alexey
То есть свой, соответственно клиенту
Alexey
а имеет ли смысл хешировать этот клиент ид? т. к. это строка
yopp
если он меньше 512 байт (или сколько там сейчас), то не имеет смысла
yopp
у тебя уже даныне есть?
Alexey
да
yopp
ну вот возьми собери себе тестовый стол
yopp
и на нём проверь все свои гипотезы
yopp
эх
yopp
https://yopp.in/13pL
yopp
вот так хуёво работает балансер :(
yopp
убийцей mms
yopp
(на самом деле я там забыл сортировочку по min/max, правильный heat map вот такой https://yopp.in/13qO)
yopp
но зато видно как чанки бьются
Anonymous
Мне тоже нравится.
Aleksey
Фоновый интерес
Alexey
Warm/hot это шарды по свежести данных?
yopp
по скорости стороджа
yopp
hot local ssd, warm сетевая хрень с 300 iops
Denis
тёпленький ))
Denis
видимо чуть тёпленький если там 300иопс )
Oleg
ребят привет
Oleg
подскажите тут мне передали парочку баз
Oleg
и вот пришел момент заресторивать
Oleg
дамп пищется с ключами —gzip —archive
Oleg
в итоге на выходе получается один data файл, а не папка dump
Oleg
как проще всего заресторить из этого файла базу?
Oleg
mngbck_2017-04-26: data
Oleg
привет! я уже разобрался с этим форматом)
Oleg
спасибо
yopp
общее правило: как бекапили, так и ресторим
yopp
в смысле набор опций
Oleg
да, так и получилось)
Diman
Всем привет. Кто нибудь сталкивался с подобным: http://stackoverflow.com/questions/41328480/mongodb-command-compact-is-not-working
yopp
Всем привет. Кто нибудь сталкивался с подобным: http://stackoverflow.com/questions/41328480/mongodb-command-compact-is-not-working
ну ты всегда можешь сделать дамп, удалить коллекцию и влить дамп обратно
yopp
но вообще покажи полную стату по коллекции, stats("indexDetails"). если у тебя WT то надо посмотреть есть ли свободные страницы. если есть, то repair должен по идее работать, но никто никогда этого не гарантировал
yopp
afair оно вообще должно это делать: перезаливать коллекцию по сути
yopp
ну и да, версию монги ты нигде не указал
yopp
shame on you
Diman
но вообще покажи полную стату по коллекции, stats("indexDetails"). если у тебя WT то надо посмотреть есть ли свободные страницы. если есть, то repair должен по идее работать, но никто никогда этого не гарантировал
https://gist.github.com/krabradosty/37730bb3ca00cced9225087e92b5c2af
yopp
интересно
yopp
попробуй сделать дамп с коллекции и посмотреть сколько весит дамп
Diman
Сейсчас не имею возможности. За идею спасибо.
yopp
ещё можно попробовать обновит ьмонгу
yopp
последняя стабильная 3.2.12
yopp
можешь глянуть в ченджлоге, может быть уже даже нашли и починили
Cap
Какие недостатки и подводные камни при использовании MongoDB, с которыми вы столкнулись ?
yopp
Cap
Чтоб понять откуда ждать беды)
Dmitrii
Cap
Это я уже заметил)
У меня сетевая игра, мобильная, пошаговая сессионка, база на монгодб
Cap
Позволила более удобно организовать хранение данных, dto объекты мапятся в базу напрямую со всеми вложенными структурами
Cap
Предупреждён значит вооружён
Евгений
Подскажите, ObjectID генерится на клиенте, верно? значит у драйвера должна быть возможность получить ObjectID до вставки записи, верно я понимаю?
Sergey
Можно генерировать его явно при вставке
CC-BY-SA-4.0/Docker-ce30.0
И отлавливать кей дупликейшн
Евгений
в разных статьях говорится что вариантов ключа так много что коллизия настолько маловероятна что кей дупликейшн практически исключен. теоретическое 6*10^57 выглядит убедительно... а что вы думаете?
Евгений
после mysql и autoincrement непривычно
Sergey
Энивей, обработку ошибок, естественно, делать стоит. Но не ради именно кей дупликейшн, а вообще.
Евгений
ну это конечно! спасибо!
CC-BY-SA-4.0/Docker-ce30.0
Для некоторых сущностей
Sergey
UUID?
CC-BY-SA-4.0/Docker-ce30.0
Нет.
CC-BY-SA-4.0/Docker-ce30.0
Как id амазоновских сущностей
Sergey
Никогда не работал с амазоном
yopp
в разных статьях говорится что вариантов ключа так много что коллизия настолько маловероятна что кей дупликейшн практически исключен. теоретическое 6*10^57 выглядит убедительно... а что вы думаете?
Мы думаем что на _id и так unique есть, так что даже если ты выиграешь в коллизионную лотерею, нет повода для беспокойства. Кроме вложенных документов, но там тоже можно сделать свой уникальный индекс.
А все другие способы проверки уникальности без linearizable смысла не имеют.
Denis
☝️
Nick
Начал задумывать о шардинге и словил такую мысль прошу поправить, если где-то ошибся:
если у меня по некоторым шардинг ключам будет намного больше документов чем по другим и когда-нибудь при росте бд в одном из чанков будут только доки конкретного ключа то:
1. остальные чанки будут уплотнены, т.е. содержать доки по нескольким шард ключам
2. собственно размер чанка ограничивает суммарный размер доков по одному шард ключу (в пределе 1Гб) и если планируется хранить больше для одного шард ключа, то нужно придумывать другой
yopp
везде ошибся
yopp
чанки по гигабайту не надо делать
yopp
индекс который собирает много документов в одном ключе тоже не надо делать