LINUX.ORG.RU

Вариант с ФС, на самом деле, не так уж и плох, вполне может сработать.

Постгрес умеет в нативное сжатие данных, но с оговорками https://www.postgresql.org/docs/current/storage-toast.html Возможно для того, чтобы это заработало придется переделывать структуру БД.

hippi90 ★★★★ ()
Ответ на: комментарий от anonymous

Postgreql и вправду жрет место как не в себя. И захлебывается bloat'ом своих индексов. Как результат - больше таблицы требуют регулярного и дорогого обслуживания

anonymous ()

А что кстати за данные? С чего их много, но срочно не нужны.

Может какой овер-инжиниринг закрался. Может не место там sql? Rrdb и вся любовь

anonymous ()

Данных много, скорость не важна. Нужно компактное хранение. Как это реализовать?

В реляционных базах не строить индексов, не создавать primary key колонок, индексы много места занимают. Как сжато хранить не подскажу.

Aber ★★ ()
Последнее исправление: Aber (всего исправлений: 2)
Ответ на: комментарий от Xwo

большое кол-во цифр

Это мало о чём говорит, без конкретики невозможно тебе что-то адекватно советовать. И «большое» количесво — это сколько? Миллионы, сотни миллионов, миллиарды записей?

Ну и важны не только данные, но и юзкейсы. Будут ли данные часто изменяться, или БД только под запись и выборки?

djangorest

Это варианты сильно сужает. Я бы на твоём месте плясал не от ORM, а от задач и той БД, что их лучше решает.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от pfg

Вопрос не относится к теме. Но SQLite простая и маленькая по размеру дистрибутива реляционная СУБД, поэтому хорошо подходит для слабых устройств (даже для телефонов) и для встраивания в свою программу. Плохо подходит для многопользователькой работы, Сжатие данных, если кого интересует, хуже чем в PostgreSQL(вряд ли оно на самом деле нужно автору темы, но мне отсюда плохо видно). PostgreSQL - самая мощная бесплатная реляционная СУБД. Подходит для важных многопользовательских проектов,

Partisan ★★ ()

Что значит много ? 30 Гб в минуту ?
Или канал к БД 2g поэтому скорость не важна ?

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

Serik ()
Ответ на: комментарий от Xwo

Ты дейтсвительно настолько беспросветное нубьё, что не понимаешь, что базы данных совсем разные бывают? Без конкретики никто ничего адекватного не посоветует, ещё раз тебе повторяю. Выпиши все БД, что сможешь нагуглить, наклей нарулетку и покрути, результат будет тем же.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Какая тебе конкретика нужна, гуру? Тебе говорят, что сжатие нужно данных, чтобы вместо 120гб занимало меньше и что данные - числа. Окей, конкретизирую конкретно для тебя, не просто числа, а float.

Xwo ()
Ответ на: комментарий от Xwo

Какая тебе конкретика нужна

Ну и важны не только данные, но и юзкейсы. Будут ли данные часто изменяться, или БД только под запись и выборки?

Что здесь не ясно-то, а?

Это какой-то адовый тупак. Пиши в CSV и жми lzma.

WitcherGeralt ★★ ()