Есть такой массив чисел. кол-во продаж по дням недели за некоторый период.
Надо это хранить в базе занимая как можно меньше места. Период в среднем может быть 30 дней. Получается будет порядка 100 байт в среднем.
Пока вот первое что в голове есть — через тире.
Думал над генерацией хэша еще. У кого какие мысли

1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552

Здравствуйте, merge, Вы писали:

M>Надо это хранить в базе занимая как можно меньше места. Период в среднем может быть 30 дней. Получается будет порядка 100 байт в среднем.
M>Пока вот первое что в голове есть — через тире.

Можно так и хранить как байты, можно как base64.
Могут быть проблемы с little-big-endian, но вряд ли это актуально.

Здравствуйте, merge, Вы писали:

M>1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552

Можно использовать unsigned int16, у тебя явно не больше 32 тысяч продаж. Если этого не хватает, то хранить не абсолютные значения, а дельты.

Здравствуйте, merge, Вы писали:

M>Надо это хранить в базе занимая как можно меньше места.
M>Пока вот первое что в голове есть — через тире.


Такие задачи очень сильно зависят от последующих режимов чтения. Если не оглядываться на них, то нужно хранить в двоичном формате дельты и сжимать gzip. Получится очень близко к эффективному размеру информации, ниже которого сжимать можно только с потерями.

Здравствуйте, Nuzhny, Вы писали:

N>Можно использовать unsigned int16, у тебя явно не больше 32 тысяч продаж.
64к же)

Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, merge, Вы писали:

M>>1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552

N>Можно использовать unsigned int16, у тебя явно не больше 32 тысяч продаж. Если этого не хватает, то хранить не абсолютные значения, а дельты.

я плохо объяснил. массив целых чисел надо эффективно хранить в базе. Пока вариант рассматривал только строкой в виде 1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552
на бэке, да, unsigned int16 эффективней int будет.
или я не понял мысль)

Здравствуйте, merge, Вы писали:

M>я плохо объяснил. массив целых чисел надо эффективно хранить в базе. Пока вариант рассматривал только строкой в виде 1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552
M>на бэке, да, unsigned int16 эффективней int будет.
M>или я не понял мысль)

В базе — это обязательно строка? Вот твоя строка по байту на символ занимает 56 байт. Если хранить эти 17 значений каждое как uint16, то будет 34 байта. Это же маленькие blob, нет?

Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, merge, Вы писали:

M>>я плохо объяснил. массив целых чисел надо эффективно хранить в базе. Пока вариант рассматривал только строкой в виде 1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552
M>>на бэке, да, unsigned int16 эффективней int будет.
M>>или я не понял мысль)

N>В базе — это обязательно строка? Вот твоя строка по байту на символ занимает 56 байт. Если хранить эти 17 значений каждое как uint16, то будет 34 байта. Это же маленькие blob, нет?

необязательно строка. а, понял мысль. ты предлагаешь одно поле blob сделать и в нем хранить unsigned int16 массив по сути?

Здравствуйте, merge, Вы писали:

M>Есть такой массив чисел. кол-во продаж по дням недели за некоторый период.
M>1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552

В строке выше 17 значений. Как это связано с днями недели? Может имелись в виду дни месяца (для каждого месяца хранить количество продаж за каждый день)?

Здравствуйте, merge, Вы писали:

M>необязательно строка. а, понял мысль. ты предлагаешь одно поле blob сделать и в нем хранить unsigned int16 массив по сути?

Да

Здравствуйте, cppguard, Вы писали:

C>Здравствуйте, merge, Вы писали:

M>>Надо это хранить в базе занимая как можно меньше места.
M>>Пока вот первое что в голове есть — через тире.
C>

C>Такие задачи очень сильно зависят от последующих режимов чтения. Если не оглядываться на них, то нужно хранить в двоичном формате дельты и сжимать gzip. Получится очень близко к эффективному размеру информации, ниже которого сжимать можно только с потерями.

я про такое слышал, но реализацией не занимался.
можно примером пояснить?
к примеру такие данные есть: 5 — 8 — 4 — 12 в дельте будут как и как потом храним в двоичном виде?

а сжатие оно имеет тут смысл если строка редко будет больше 100 байт? а то мне кажется сжатие\расжатие не очень быстрая операция и есть смысл на больших размерах данных

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, merge, Вы писали:

M>>Есть такой массив чисел. кол-во продаж по дням недели за некоторый период.
M>>1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552

_FR>В строке выше 17 значений. Как это связано с днями недели? Может имелись в виду дни месяца (для каждого месяца хранить количество продаж за каждый день)?

да, ошибься. месяца. есть период в двух других полях и есть 2 поля: в одном храним по дням за весь период, во втором по неделям на этот же период

Здравствуйте, merge, Вы писали:

M>>>Есть такой массив чисел. кол-во продаж по дням недели за некоторый период.
M>>>1-4-5-63-2-43-23-31-123-343-312-5646-12-42-4533-1123-552

_FR>>В строке выше 17 значений. Как это связано с днями недели? Может имелись в виду дни месяца (для каждого месяца хранить количество продаж за каждый день)?
M>да, ошибься. месяца. есть период в двух других полях и есть 2 поля: в одном храним по дням за весь период, во втором по неделям на этот же период

Известно, на сколько большими могут быть числа? Если нормализация данных (в каждой строке хранить дату и количество продаж) по какой-то причине не подходит и нужно всё в строке, да и место сэкономить, то можно поработать над уменьшением длины строки.
Например, числа записывать не в десятичном формате, а в 52-ричном (английский алфавит с прописными и заглавными буквами) или даже ещё больше, набор символов можно выбрать произвольный.

Блоб, в котором просто массив целых (из подходящего числа битов), кажется (кто его знает, что у вас за база?), будет ещё экономнее (но, возможно, менее удобно). Чтобы как-то оптимизировать дальше размер этого блоба (если требуется) нужно что-то знать дополнительное об этих числах.

Здравствуйте, _FRED_, Вы писали:



_FR>Известно, на сколько большими могут быть числа? Если нормализация данных (в каждой строке хранить дату и количество продаж) по какой-то причине не подходит и нужно всё в строке, да и место сэкономить, то можно поработать над уменьшением длины строки.

да, уход от нормализации как раз связан с производительностью и объемом. там было порядка 150к строк на вставку и энтити умирал на этой вставке. а просто балком вставить сложно потому, что там винегрет-транзакция из даппера + вставка других данных без балка.

_FR>Например, числа записывать не в десятичном формате, а в 52-ричном (английский алфавит с прописными и заглавными буквами) или даже ещё больше, набор символов можно выбрать произвольный.

а есть готовые алгоритмы или либы для этого?

_FR>Блоб, в котором просто массив целых (из подходящего числа битов), кажется (кто его знает, что у вас за база?), будет ещё экономнее (но, возможно, менее удобно). Чтобы как-то оптимизировать дальше размер этого блоба (если требуется) нужно что-то знать дополнительное об этих числах.

база мсскл — 19. ну получается, что 52 ричный формат или блоб уже особой разницы не играют, всё равно придется конвертер писать на бэке до\перед вставкой?
на бэке работа идёт с линейный списком, то есть 10 дней будет как 10 элементов массива, просто в базе будет 1 строка и продажи будут в одном поле

Тип столбца — bytes.

Число хранится в переменном числе байтов, можно посмотреть в UTF-8 как сделано, в принципе вариантов много.

Сначала хранится абсолютное значение за 1 число, все последующие числа это разность между предыдущим и текущим. Т.е. если продажи 120, 105, 110, то хранятся числа 120, -15, +5.

Альтернативный подход: сначала просто записать числа как есть, можно в 4-байтовом формате, без выпендрёжа, в общем, а потом прогнать через какой-нибудь библиотечный gzip.

Думаю, будет плюс-минус одно и то же.

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

Здравствуйте, vsb, Вы писали:

vsb>Сначала хранится абсолютное значение за 1 число, все последующие числа это разность между предыдущим и текущим. Т.е. если продажи 120, 105, 110, то хранятся числа 120, -15, +5.

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

Здравствуйте, _FRED_, Вы писали:

FRE> А что может дать хранение дельты по сравнению с хранением абсолютного значения?

Да ничего, скорее всего, не даст. Тут и так-то размер данных крошечный: даже если отвести 4 байта на количество продаж, то для 31 дня нужно хранить всего 124 байта. Если это сжимать, то точно не gzip т.к. он прибавит минимум 22 байта к сжатым данным. Если заполнить такой массив значениям от 1 до 31 (три байта остаются нулевыми) то deflate с дефолтным уровнем сжатия его сожмет до 54 байт. Отрицательные дельты вполне могут привести к ухудшению сжатия, да еще и усожнят получение значений на конкретный день месяца. Тут, скорее, нужно просто определиться с требуемым количеством байтов, чтобы число продаж уместилось, и не страдать фигней.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, _FRED_, Вы писали:

FRE>> А что может дать хранение дельты по сравнению с хранением абсолютного значения?

R>Да ничего, скорее всего, не даст. Тут и так-то размер данных крошечный: даже если отвести 4 байта на количество продаж, то для 31 дня нужно хранить всего 124 байта. Если это сжимать, то точно не gzip т.к. он прибавит минимум 22 байта к сжатым данным. Если заполнить такой массив значениям от 1 до 31 (три байта остаются нулевыми) то deflate с дефолтным уровнем сжатия его сожмет до 54 байт. Отрицательные дельты вполне могут привести к ухудшению сжатия, да еще и усожнят получение значений на конкретный день месяца. Тут, скорее, нужно просто определиться с требуемым количеством байтов, чтобы число продаж уместилось, и не страдать фигней.

оказалось, что может быть и годовые продажи, нечасто, но может. Квартал достаточно часто. так что получается 150 * 4 = 600 байт. это меняет что-то?

Здравствуйте, merge, Вы писали:

m> оказалось, что может быть и годовые продажи, нечасто, но может. Квартал достаточно часто. так что получается 150 * 4 = 600 байт. это меняет что-то?

Массив чытерыхбайтовых целых заполненный значениями от 1 до 150 deflate сжимает до 238 байт.

Здравствуйте, merge, Вы писали:

M>оказалось, что может быть и годовые продажи, нечасто, но может. Квартал достаточно часто. так что получается 150 * 4 = 600 байт. это меняет что-то?

А вам эти данные, внутренности, нужно когда-либо обновлять? Например, в строке данных за месяц исправить несколько каких-то значений?