yopp
такого рода r&d само по себе не самое дешёвое удовольствие
yopp
tl;dr: чем будет меньше неструктуированных данных, тем лучше
yopp
декомпозиция неструктуированных данных в тот-же gridfs тоже неплохая идея
yopp
всё что можно хранить в binary, хранить в binary, включая хешсуммы
yopp
дедупликация is a must
Andrey
такого рода r&d само по себе не самое дешёвое удовольствие
Да вы правы. Моя задача подготовить обоснование с приблизительными цифрами. Объем данных, железо, вход-выход данных, штат и так далее.
Andrey
Может оказаться что дешевле - покупать сторонний сервис с этими данными, пусть и с худшим качеством.
yopp
плюс я думаю что если начать нормализировать ваши данные, тоже можно существенно экономить
yopp
с высокой долей вероятности на пару порядков
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
Всем привет. Подскажите плз, как удалить дерево документов одним махом. Начиная с родительского и удалить его детей, потом детей детей и так далее. Можно как то сделать? Буду благодарен и за ссылки
Daniil
Ну тогда просто .deleteMany({ rootParentId })
Anonymous
Ну тогда просто .deleteMany({ rootParentId })
Но всё-таки этого мало). Я забыл сказать что у родителя может быть массив детей, а у детей массив ещё одних детей, и так вниз по цепочке глубиной около 4 - 5 этажей. Если юзать только deleteMany, то нужно всеравно циклом перебирать, чтоб до детей в глубине добраться
Daniil
Но всё-таки этого мало). Я забыл сказать что у родителя может быть массив детей, а у детей массив ещё одних детей, и так вниз по цепочке глубиной около 4 - 5 этажей. Если юзать только deleteMany, то нужно всеравно циклом перебирать, чтоб до детей в глубине добраться
я имел ввиду, что у каждого документа в дереве (на любом уровне вложенности от родителя) будет идентификатор родителя соответственно можно расширить этот кейс на массив идентификаторов всех родителей вплоть до корневого у каждого документа
Daniil
тогда можно будет удалять любые части дерева
Anonymous
тогда можно будет удалять любые части дерева
А можно как то удалить глубоких детей, которые связаны одним корнем в самом верху?
Anonymous
Правильное название - Каскадное удаление
Anonymous
Смотрю, в прехуках можно сделать
Daniil
А можно как то удалить глубоких детей, которые связаны одним корнем в самом верху?
Если нужно удалить только тупо все дерево, то проще всего хранить root id у каждого элемента дерева
Daniil
Тогда deleteMany сработает без проблем
Daniil
Если нужно с разных участков дерева удалять в глубину все дочерние элементы, то более общий вариант, как я выше написал
Anonymous
Если нужно удалить только тупо все дерево, то проще всего хранить root id у каждого элемента дерева
А тьфу, у меня же рут id с одним и тем же ключём идёт во всех документах, вообще проблем нет тогда, это я туплю
Anonymous
Спасибо
Ardasher
всем привет, я новичок в монге и вообще в NoSql, нужно вытаскивать юзеров по uuid. Думаю вместо _id(ObjectId) заюать UUID для этого нужно в валидации прописать тип string? "_id": { "bsonType": "string", description: "must be a string and is required" }, и надо будет uuid у клиента(базы) генерировать? и вообще может лучше _id не трогать и просто создать новое required поле uuid?
Ardasher
objectid вобщем-то тот-же uuid4
он тоже 128 битов весит?
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 это проблема коллизии идентификаторов, а не реквизитов доступа
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 }, }
Eugen
добавить потом в коде своег оприложения
То-есть те промежутки только через код добавить ? через Монго не сделать ?
Nick
То-есть те промежутки только через код добавить ? через Монго не сделать ?
да, только через код, а еще лучше там где выводите эту инфомарцию сразу сделать возможность работы с пропусками
Devperk
изменения счетчика через $inc атомарны
знаю, но мне ведь вначале надо получить документ с содержанием счетчиков по тесту, сравнить счетчики, и после этого изменить счетчик. Получить и изменить можно одним действием, а вот чтобы сравнить, для сохранения соотношения 50/50 приходится на два обращения к БД разбивать
Nick
не мудрите, делайте проще
Devperk
направьте на более простой вариант, пожалуйста)
Devperk
вообще правильно сделать процентажи по лейблам и выбирать вариант по рендому
это второй вариант который у меня пока в голове 0.5 random на каждый вариант. И ребалансировка весами для rand функции раз в час