TEXT/BLOB в InnoDB и размер таблицы

[FB3]

dimagolov
Да, понимаю. На 33% занимает больше, но сократить объем существующих данных можно на 25%, да Видимо, когда добавляли gzip, не захотели почему-то менять тип поля в таблице.

Это не решает проблему глобально. Просто я пытался искать решение, которое может решить проблему именно роста таблицы из-за существующих полей переменной длины, но видимо его просто нет, если серьезно не изменить архитектуру приложения (причем еще и в намного лучшую сторону, потому что сейчас принципы ООП применяются по минимуму). Надеялись, что такое решение найдется, поэтому не бросились сразу менять тип таблицы на blob.

 

[Fortop]

придумал сначала сериализовать в JSON и писать в текстовое поле, потом вдруг места стало не хватать, решили JSON жать зипом и потом base64, чтобы таблица меньше объемом была.

ух...

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

-~{}~ 31.03.10 17:26:

Просто я пытался искать решение, которое может решить проблему именно роста таблицы из-за существующих полей переменной длины, но видимо его просто нет

Оно есть - сделать структуры фиксированной длины.

-~{}~ 31.03.10 17:26:

А на блоб не торопитесь менять.

-~{}~ 31.03.10 17:29:

P.S. Кстати, у вас похоже разреженные матрицы и для данной пачки данных может подойти EAV

 

[dr-sm]

можно какой-нибуть google protobuf прикрутить попробовать вместо извратов с гзип.
тем более это круто .

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

 

[FB3]

Fortop
все идет к тому, что нужно серьезно менять архитектуру серверной части приложения, а возможно, что и клиентской. Пока это не возможно.
Структуры фиксированной длины раза в 2.5 больше места в базе займут без серьезных изменений архитектуры, потому что инфа о профайле может быть и 2КБ и 6КБ, но нужно выделять по максимуму, то есть 6КБ.

Про EAV в гугле сразу википедия открылась. Почитаю сегодня на досуге. Спасибо.

-~{}~ 31.03.10 20:20:

Автор оригинала: dr-sm
можно какой-нибуть google protobuf прикрутить попробовать вместо извратов с гзип.
тем более это круто .

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

Я понимаю, из-за чего растет, но сделать с этим ничего нельзя похоже. Пишу то я в InnoDB, а не в файл.

 

[Fortop]

Пффф, в довесок к memcache.
Можно посмотреть еще Redis, т.е. конкретно эту таблицу хранить не в MySQL. Пишут что он весьма быстр на вставках.

-~{}~ 31.03.10 21:55:

Структуры фиксированной длины раза в 2.5 больше места в базе займут без серьезных изменений архитектуры, потому что инфа о профайле может быть и 2КБ и 6КБ, но нужно выделять по максимуму, то есть 6КБ

А это неважно. Важно что БД не будет пухнуть от частых изменений. А только лишь от вставок.

-~{}~ 31.03.10 21:56:

К тому же если данные вида да/нет (или их можно к этому привести), то можно их хранить масками.
А это значит что типичного CHAR(255) хватит на 20000+ атрибутов.

 

[FB3]

Fortop
Если данные получится поместить в фиксированные поля, таким образом, что миллион записей будет помещаться примерно в 6 гигабайт с учетом того, что есть еще другие данные (эта основная таблица, о которой речь, всего лишь около 2 гигов), которые не так важны и вероятнее всего потеря небольшого куска ни на что не повлияет, то вероятно, что подумаем и над таким вариантом.
Там не совсем данные вида да/нет, но велика вероятность, что бОльшую часть данных можно будет привести либо к boolean, либо к 1 байту, если уж совсем тяжело будет, то привести к 9 битам.
Как я уже говорил, с моей точки зрения, вопрос сейчас стоит о серьезном изменении архитектуры серверной части приложения. Но чтобы это все быстро работало, нужно менять еще и клиентскую часть, за которую я не отвечаю. Если получится быстро выбирать и конвертировать данные в тот формат, который нужен клиенту, то у меня будут развязаны руки и я смогу над серверной частью и базой работать только в рамках ограничения времени на разработку и ресурсов самой базы.

 

[Fortop]

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

Простой стенд и пару тестов - дадут ответ насколько быстры будут выборки и конвертация.

Но для этого нужен профайлинг в рамках текущей системы для сравнения

-~{}~ 01.04.10 02:28:

FB3
а просто добавить воды не?
Т.е. нарастить память может быть быстрым и главное дешевым решением

 

[FB3]

Fortop
про память спрашивал, сказали, что вроде как физически не возможно.