yopp
такого рода r&d само по себе не самое дешёвое удовольствие
yopp
tl;dr: чем будет меньше неструктуированных данных, тем лучше
yopp
декомпозиция неструктуированных данных в тот-же gridfs тоже неплохая идея
yopp
всё что можно хранить в binary, хранить в binary, включая хешсуммы
yopp
дедупликация is a must
Andrey
Может оказаться что дешевле - покупать сторонний сервис с этими данными, пусть и с худшим качеством.
yopp
плюс я думаю что если начать нормализировать ваши данные, тоже можно существенно экономить
yopp
yopp
с высокой долей вероятности на пару порядков
Andrey
Andrey
Качество правда страдает
Andrey
Но...
yopp
если есть сторонние сервисы, то всего есть смысл купить, начать эксплуатировать, а потом понять чего не хватает и сколько ценности добавят капексы
yopp
потому что у in-house на таких объёмах годовой бюджет будет семизначный
yopp
и жуткие цифры капесков
yopp
сомневаюсь что первый год будет стоить меньше миллиона
yopp
если даже на порядок объём сократить, это 60гб в сутки, а это 20Тб, если у сервиса SLA даже две девятки, это хранить как минимум 40Тб, а лучше 60Тб, плюс запас, т.е. яб сотку закладывал
20Тб на одну ноду очень сложно положить, реально ну 4Тб. это 25 нод, плюс ещё три на конфиг сервер.
Ноду собирать на commodity потому что и так 3x redundancy. Ryzen 9 3900x $450, Мать на x570 c kvm $500, 128Gb RAM (w/o ECC) $550, 2 × 2Tb SSD $700, 2x850W PSU + реле $250 баксов, две сетевые 10G карты $300, видяха на случай если надо в железку смотреть ну ещё $50, 2U шасси для ATX матерери 200$ = $3000
ну тоесть с hot-standby ЗИПом 10% это ну пусть 32 ноды. Ну пусть ноду c установкой можно уложить в 3500, для круглого счёта $120k, ещё $20к накинем на коммутацию внутри/межу стоек. если ставить in-house, то разложить в три кабинета это ещё $6k если уже есть своя серверная с 32kW, плюс 250 МВт*ч даже пусть по 20 центов это ещё $56k + ~$21k на отвод 100k тепла + $20k на rooftop кондей. итого ~$100k без учёта полосы
если colocation, то $30к на стойки, $160к на 32kW. итого $190 без учёта полосы
итого ещё ничо делать не начали, а уже ~150k капесков и $100-200k опексов)
yopp
т.е минимум $2.5k в год за 1Tb
yopp
это без аммортизации
yopp
с амортизацией в 2 года до нулевого остатка это ~$4k
yopp
ой, нет $3.3k
yopp
зависимость от данных без цены рук будет плюс минус линейная
yopp
можно умножить на два и будет реальная цена
yopp
~$0.5 в месяц за гиг
yopp
более-менее тёплых данных, если индексов не больше 3% (оч сложно)
yopp
если нужны горячие данные, то умножаем на четыре
yopp
хотя, тредриппер 1500, 512gb памяти 3500, получится ~$7k
yopp
на два тогда
yopp
хотя, тредриппер 1500, 512gb памяти 3500, получится ~$7k
А, тредриппер не выйдер, эпик нужен, но там разницы нет особо, 7552 ну 1600 стоит, мать 700, зато не нужны сетевые карты и видяхи, итого теж $7k. ну и раз сетевух нет, можно и в 1U наверное уместить. но эт ни на что особ не повляает. шкафы на фоне всего остального копьё стоят
Anonymous
Всем привет. Подскажите плз, как удалить дерево документов одним махом. Начиная с родительского и удалить его детей, потом детей детей и так далее. Можно как то сделать? Буду благодарен и за ссылки
Anonymous
Daniil
Anonymous
Daniil
Ну тогда просто .deleteMany({ rootParentId })
Anonymous
Anonymous
Ну тогда просто .deleteMany({ rootParentId })
Но всё-таки этого мало). Я забыл сказать что у родителя может быть массив детей, а у детей массив ещё одних детей, и так вниз по цепочке глубиной около 4 - 5 этажей. Если юзать только deleteMany, то нужно всеравно циклом перебирать, чтоб до детей в глубине добраться
Daniil
Daniil
тогда можно будет удалять любые части дерева
Anonymous
Правильное название - Каскадное удаление
Anonymous
Смотрю, в прехуках можно сделать
Daniil
Тогда deleteMany сработает без проблем
Daniil
Если нужно с разных участков дерева удалять в глубину все дочерние элементы, то более общий вариант, как я выше написал
Anonymous
Спасибо
Ardasher
всем привет, я новичок в монге и вообще в NoSql, нужно вытаскивать юзеров по uuid. Думаю вместо _id(ObjectId) заюать UUID для этого нужно в валидации прописать тип string?
"_id": {
"bsonType": "string",
description: "must be a string and is required"
},
и надо будет uuid у клиента(базы) генерировать? и вообще может лучше _id не трогать и просто создать новое required поле uuid?
yopp
Ardasher
yopp
96. uuid4 не 128, там доступная энтропия 122
Ardasher
у меня задача состоит в том чтобы выдать пару access/refresh токенов по guid думаю тут и размер важен, для этой цели можно использовать objectId?
yopp
это секретные токены?
Ardasher
ага
yopp
нет смысла использовать guid/objectid, заведите отдельный аттрибут и складывайте туда случайные 128 или 256 бит
yopp
главное источник энтропии хороший выбрать
yopp
objectid псевдослучайный
yopp
но он возрастающий, его перебирать проще, потому что там очень маленькая случайная часть энтропии
yopp
так-то и 64 бита будет достаточно, если у вас веб-сервис
Ardasher
ну по стандарту же должно быть 128
yopp
FISP?
Ardasher
хз, тут прочёл https://ru.wikipedia.org/wiki/GUID
yopp
guid это просто соглашение об индентификаторах
yopp
задача которую решает guid это проблема коллизии идентификаторов, а не реквизитов доступа
Andrey
yopp
если у вас кроме токена есть какой-то признак, например логин или ещё что-то, то вобщем-то 64 бита за глаза, потому шанса подобрать при наличии тротлинга для большого числа попыток — нет, даже без тротлинга всё равно нет :)
yopp
если это единственный признак, то да, можно 128 сделать
Ardasher
ок, спасибо всем за помощь
Devperk
Всем привет.
Подскажите плз как организовать a/b тестирование, если хранить в mongo счетчики по A/B выдаче
Например при такой схеме теста
{
"name":"test_v1",
"label_A": "var_1",
"label_B": "var_2",
"type": "type1",
"active": true,
"counter_A": 5,
"counter_B": 7,
"start_exp": {
"$date": "1999-12-31T21:00:00.000Z"
},
"end_exp": {
"$date": "1999-12-31T21:00:00.000Z"
}
}
Размеры экспериментов небольшие по количеству пользователей, поэтому хотелось бы сразу выдавать 50/50% label_A/label_B.
Если действовать по алгоритму
1. find_one({test by name})
2. update( {test by id}, inc{counter_A} )
то изменения счетчика не атомарны.
Подскажите может кто делал, как атомарно считать и изменить счетчик в mongo?
Eugen
Привет всем, ребят, сделал Агрегатор но он выводит количество зарегистрированных в конкретные дни, а промежуточные когда никто не регался не показывает ( а надо ),
Вот выводит
[
[
"2020-10-15",
18
],
[
"2020-10-25",
4
],
[
"2020-10-26",
11
]
]
Подскажите как сделать что бы был показывало все дни ( с нулем если никто не регистрировался)
group = {
_id: {
year: { $year: "$createdAt" },
month: { $month: "$createdAt" },
day: { $dayOfMonth: "$createdAt" }
},
count: { $sum: 1 },
}
Nick
Привет всем, ребят, сделал Агрегатор но он выводит количество зарегистрированных в конкретные дни, а промежуточные когда никто не регался не показывает ( а надо ),
Вот выводит
[
[
"2020-10-15",
18
],
[
"2020-10-25",
4
],
[
"2020-10-26",
11
]
]
Подскажите как сделать что бы был показывало все дни ( с нулем если никто не регистрировался)
group = {
_id: {
year: { $year: "$createdAt" },
month: { $month: "$createdAt" },
day: { $dayOfMonth: "$createdAt" }
},
count: { $sum: 1 },
}
добавить потом в коде своег оприложения
Nick
Всем привет.
Подскажите плз как организовать a/b тестирование, если хранить в mongo счетчики по A/B выдаче
Например при такой схеме теста
{
"name":"test_v1",
"label_A": "var_1",
"label_B": "var_2",
"type": "type1",
"active": true,
"counter_A": 5,
"counter_B": 7,
"start_exp": {
"$date": "1999-12-31T21:00:00.000Z"
},
"end_exp": {
"$date": "1999-12-31T21:00:00.000Z"
}
}
Размеры экспериментов небольшие по количеству пользователей, поэтому хотелось бы сразу выдавать 50/50% label_A/label_B.
Если действовать по алгоритму
1. find_one({test by name})
2. update( {test by id}, inc{counter_A} )
то изменения счетчика не атомарны.
Подскажите может кто делал, как атомарно считать и изменить счетчик в mongo?
изменения счетчика через $inc атомарны
Devperk
изменения счетчика через $inc атомарны
знаю, но мне ведь вначале надо получить документ с содержанием счетчиков по тесту, сравнить счетчики, и после этого изменить счетчик.
Получить и изменить можно одним действием, а вот чтобы сравнить, для сохранения соотношения 50/50 приходится на два обращения к БД разбивать
Nick
Nick
не мудрите, делайте проще
Devperk
направьте на более простой вариант, пожалуйста)
Nick
Всем привет.
Подскажите плз как организовать a/b тестирование, если хранить в mongo счетчики по A/B выдаче
Например при такой схеме теста
{
"name":"test_v1",
"label_A": "var_1",
"label_B": "var_2",
"type": "type1",
"active": true,
"counter_A": 5,
"counter_B": 7,
"start_exp": {
"$date": "1999-12-31T21:00:00.000Z"
},
"end_exp": {
"$date": "1999-12-31T21:00:00.000Z"
}
}
Размеры экспериментов небольшие по количеству пользователей, поэтому хотелось бы сразу выдавать 50/50% label_A/label_B.
Если действовать по алгоритму
1. find_one({test by name})
2. update( {test by id}, inc{counter_A} )
то изменения счетчика не атомарны.
Подскажите может кто делал, как атомарно считать и изменить счетчик в mongo?
вообще правильно сделать процентажи по лейблам и выбирать вариант по рендому