потому что вроде как до этого не особо хранили

потому что вроде как до этого не особо хранили

если не ошибаюсь там у WT настройка internalcache size указыввает как раз на хранение сжатых данных в кеше

ну ты можешь проехать курсором по коллекции и посмотреть сколько памяти оно сожрёт :)

ну ты можешь проехать курсором по коллекции и посмотреть сколько памяти оно сожрёт :)

я ошибся, внутри разжатые, и советуют как раз занижать настройку, чтобы в системфайлкеш вмещались сжатые данные.

видимо с чем то попутал)

так что тебе надо под этот сет 126 гигов памяти ;)

если он весь горячий

зачем ?

пусть разюимает на ходу и жрет цпу

слушайте, а как в монгу положить блоб в поле?

а из питона как? )

нет ) точнее, только начал. вопрос вообщем простой: если я bytes кладу в поле - всё ок будет?

нет ) точнее, только начал. вопрос вообщем простой: если я bytes кладу в поле - всё ок будет?

Да, во всяком случае в pymongo 3.x, предыдущие я не щупал

Хеша?

не не не

там совсем не хеш

зачем?

The 12-byte ObjectId value consists of: a 4-byte value representing the seconds since the Unix epoch, a 3-byte machine identifier, a 2-byte process id, and a 3-byte counter, starting with a random value.

лучше создай отдельный id и все

иначе перебирать будут

а чем принципиально именно целочисленный id?

ваще ходить по id это плохая идея

нужно генерировать рандомные токены

не привязанные к тому как база данных их назначет

потому что всем пофиг что в URL

и перебирать не будут

так например можно случайно раскрыть какие-то свои показатели

oid в монге раскроет пид и время создания записи

что может быть угрозой безопасности в некоторых случаях

Дамп бд

Например если pid == 1, значит твоя субд работает под рутом

Ну или тех сущностей, сто ты отдаешь по id

в докере :)

Дамп бд

это если ты права не проверяешь

это если ты права не проверяешь

Ну, я как пример.

тут вопрос именно в том, что целочисленные индентификаторы это пережиток тех времён, когда числа было хранить сииииильно выгоднее чем всё остальное

Перебирая id можно получить все записи

сделать уникальный индекс на поле token, и генерировать туда случайное значение

или uuid

v4 помоему псевдослучайный

тут вопрос именно в том, что целочисленные индентификаторы это пережиток тех времён, когда числа было хранить сииииильно выгоднее чем всё остальное

Да можно и сейчас хранить так :) только sha1 :)

плохя идея дерайвить ключи от какие-то значений

Тебе зачем именно по числу? Почему не какой-либо хеш или случайное значение?

у документа всегда есть поле с неким индентификатором выглядящим как некий хеш, и все что уходит в сторону клиента идентифицриует объект именно по этому ключу.

да.

а последние 30 реализуй просто датой

и индексом по ней если много записей.

в монге есть паршал индексы, если ты уверен что не будешь выбирать данные за большой период времени

это скоратит размер индекса.

Например если pid == 1, значит твоя субд работает под рутом

Это значит, что у тебя БД вместо init

это значит у тебя докер ;)

или МИКРОЯДРО

прости господи

Даже в докере плохая идея держать что-то с pid=1

Не зря в всякие dumb-init придумали

Хотя, докероводы обычно на это плюют

facepalm.jpg

При желании, можно запатчить исходники и вместо pid писать что-то другое

Некую константу, сгенеренную при старте инстанса базы

посоны, смотрите есть задача.

здесь кто нить есть ? )

ты пишы пишы )

ок

есть к примеру данных 800м объектов в коллекции. производительности запроса по индексу в данной колекции недостаточно. индекс большой получается. запросы по своей специфике могут быть адресованы только части данных. Тоесть, скажем у нас есть поле в документе "регион" и к примеру все наши данные равномерно распредлены по нескольким десяткам этих регионов.

идея заключается в том, чтобы разрезать индекс на эти несколько десятков

да да да

первая мысль которая приходит в голову

проблема заключается в том, что чанки будут содержать данные от всех регионов

tag aware sharding

а нет разве ?

а нет разве ?

tag aware shading

документацию читай )))))))

а, этож не докерчят

тут шутку не поймут!

тогда получается что мы ручками должны балансить на основании тегов

не вы, а монга

ты назначешь на шард тег

и оно само

у нас коллекция разбита на N чанков

чанки привязаны к шардам