|
MySQL.RU - Webboard
 Вернуться
 blob vs text (для больших размеров данных) (alrond) 22/02/2007 - 12:13:07
From: alrond - 22/02/2007 - 12:13:07
Subject:blob vs text (для больших размеров данных)
-----------------
Привет!
у меня диллема. Выбираю между типом blob и текстовым для хранения сравнительно больших размеров данных.
Есть таблички с простой структурой:
1)Количество записей ориентировочно до 100-200 тысяч.
ID:USER_ID:USER_DETAIL
выборка только по USER_ID, тесктовое поле из 7 байт, поэтому только для него индекс.
Там должны представлены разные свойства для текстовых полей из другой таблицы:
2)Количество записей может достигать 10-20 тысяч
ID:TEXT_ID:TEXT:bla-bla1:bla-bla2...
Не играет роль что в ней и какого она размера.
При каждой генерации web-странички есть выборка как из первой таблицы, так и из второй.
Для первой таблица SQL запросы ограничиваются командами SELECT, INSERT, UPDATE.
Но этот апдейт очень частое явление. Ориентировочно при каждой генерации страницы будут как селекты так и апдейты.
Так вот, для каждого USER_ID есть 13 свойств каждого объекта TEXT_ID.
Можно конечно составить матричную структуру, где будет соответствие USER_ID и TEXT_ID. например так:
ID:USER_ID:TEXT_ID:SVOJSTVO
но тогда пришлось бы делать индекс по двум полям,а количество записей = 100-200 тысяч * 10-20 тысяч = 1-4 миллиарда
А для интенсивной работы, критичной к времени ответа(веб-приложение) это не реально.
Поэтому я решил каждому пользователю в первой базе в одной записи заносить информацию обо всех свойствах всех TEXT_ID в USER_DETAIL.
Для USER_DETAIL есть несколько путей:
1) простейший. текстовой поле, не фиксированной длины, где каждый символ однозначно определяет свойство TEXT_ID.
Например текст "0304AD" Определяет свойства, которые применяются в логике веб-приложения, для TEXT_ID=1 ... до TEXT_ID=6
Плюсы в том, что довольно легко внутри приложения обрабатывать, позиция символа определяет TEXT_ID, а сам символ свойство.
Минусы в том, что существует огромная избыточность. Насколько я помню видимая часть ASCII состоит 95 символов, а задействовано будет только 13.
Второй минус в том, что поле может достигать 20КБ (по количеству TEXT_ID). Я просто не знаю насколько быстр мускул будет в интенсивной работе с запросами, где каждый ответ достигает 20кил. Или того хуже - постоянные апдейты.
Реально размер может быть 4Кб (текстов около 4 тысяч)
2) поле типа BLOB, где один байт содержит информацию об двух TEXT_ID.
Так как данные хранятся в бинарном виде, можно использовать всю палитру в 256 символов.
Один символ как например 10011011, первые 4 бита содержат информацию об TEXT_ID=1, а второй о четном TEXT_ID=2
Тут существует тоже некоторая избыточность, что для 13 состояний используется 16. но она не такая большая.
В этом варианте мы экономим место (в два раза), но усложняюется логика в приложении по расчету TEXT_ID, из этого бинарного файла. Размер получается до 10 кил.
Реально размер может быть 2Кб (текстов около 4 тысяч)
Есть еще одна задача, при котором количество свойств ограничено тремя. Остальными десятью можно пренебречь.
Тогда первый вариант не изменяется, но во втором варианте на каждый байт можно записать информацию об четырех текстах.
Сокращение размера еще в два раза. Рельный размер около 1КБ, а максимальных до 5 КБ
Так вот. Я склоняюсь ко второму варианту, так как он легок для программирования, хотя в прилодении второй вариант может работать даже быстрее, все же битовые операции.
Но смущают постоянные выборки и апдейты с запросами такой длины. Насколько разница может быть с вторым или даже с третьим вариантом, при прочих равных условиях?
Тут может быть будут играть роль и тип поля. С каким-то мускул работает медленнее, с каким-то быстрее.
Кстати, размер каждый день может наращиваться, так как будет прибавляться TEXT_ID по несколько в день
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
30815
|
|
