Comments 8
Очевидно, что рядом с блобом должен храниться метод его сжатия. Дальше обертка БД должна получать от слоя бизнес-логики три параметра - коэффициент критичности скорости записи относительно скорости чтения (можно вывести из среднего количества чтений на одну запись), коэффициент важности степени сжатия, и текущий коэффициент нагрузки на бакенд. На основании поля этих коэффициентов слой может выбрать один из четырех путей - хранить напрямую (может быть с отложенным пережиманием в стендбае или при уходе блоба из лидеров по частоте обращения), сжимать в приложении параллельно (если БД сильно загружена), сжимать в БД слабым, но быстрым алгоритмом, сжимать в БД сильным но долгим.
В принципе, модуль, который автоматизирует принятие этого решения - это натренированная AI-модель по нескольким входным параметрам
Прикольная идея - динамическая архитектура сжатия, если я правильно понял. Уверен, мои коллеги оценят. Мне с одной стороны нравится, но с другой же - не хотелось бы видеть такой модуль на своих проектах. Объясню почему.
Мне нужно будет оборудовать кластер под все три модели. Выделить ресурсы и так далее. А что, если модуль будет всегда выбирать только один вариант архитектуры? Что будет происходить при переключении между моделями? А нужно ли этот процесс мониторить?
С другой стороны, если я могу назвать коэффициенты, я тогда могу сразу определить нужную из трёх архитектуру. Я могу контролировать число экземпляров кластера и их роли. Мне легче один раз задать конфигурацию под нужную задачу. Я хочу простоты. Простота - это надёжность.
Спасибо, что поделились мыслью.
Я бы предложил другую схему динамической архитектуры сжатия, типа как JS компилируется в движке V8.
Вначале происходит быстрая компиляция без оптимизаций, а дальше если происходит частое обращение к кода, то применяются повторные компиляции.
И аналогично здесь сделать для сжатия, сжимать вначале быстро и не сильно. А потом делать немножко наоборот, если данные горячие и идет частое обращение, то оставляем как есть или вообще к примеру убираем сжатие, а если данные холодные и не часто требуются, то пробуем ужимать еще больше.
Но на словах это конечно, просто звучит. Но на сколько это совместимо с архитектурой тарантула, мне сложно говорить.
100 тысяч различных JSON-документов
Видимо мой вопрос будет довольно внезапным, но все же спрошу: а в бинарном формате не пробовали хранить?
Спасибо за вопрос. Речь, видимо, про BSON.
Давайте представим два случая. В первом случае мы просто сжимаем строку. Во втором случае мы преобразуем JSON в BSON и потом сжимаем. Дело в том, что и в первом и во втором случае получится плюс-минус такой же результат. Во втором случае просто степень сжатия будет меньше.
Мне тут коллеги подсказали, что внутри Tarantool так и хранит - в бинарном формате msgpack.
Не смотрел код, поэтому мои вопросы могут показаться капитанскими
А анализируется как нибудь размер сжатых данных, могут быть настолько рандомные данные, сжатие будет мизерное. Только тратится лишнее время на сжатие и разжатие. На моей практике все что выше 0.8 от изначального объема не имеет смысла сжимать, только ухудшаем скорость доступа.
Как мы сжимаем данные в больших проектах