Re[5]: Вертикальное партицирование - есть ли смысл?
От: MozgC США http://nightcoder.livejournal.com
Дата: 20.02.10 19:50
Оценка:
Здравствуйте, MozgC, Вы писали:

Основные причины:

1) Уменьшение размера базы данных. Так как в большинстве случаев используется фиксированный размер строк, поэтому если в таблице с миллионом строк указано только 10% комментариев (varchar(250)), то экономия размера базы будет — сотни мегабайт (примерно от 235 Мб до более полугигабайта в зависимости от используемой кодировки).

2) Ускорение чтения (и записи) с жесткого диска. Допустим чтение происходит блоками по 8К и размер записи — N, тогда в 1 блоке уместится 8К/N записей в случае если комментарий у нас в общей таблице и 8K/(N-250) если комментарий в отдельной таблице. С одной стороны зачастую практически вся БД может находиться в кеше, с другой стороны даже в таком случае время от времени происходит сохранение из кеша на жесткий диск, т.е. некоторая разница все равно будет.

3) Ускорение выполнения некоторых запросов, иногда многократное ускорение. И речь идет не только о случае с SELECT * FROM order_lines когда комментарии не нужны в выборке.
Допустим заполнен малый процент комментариев. И нужно выбрать все комментарии за сегодня. В случае когда комментарии находятся в той же таблице запрос будет такой:

SELECT ... FROM order_lines WHERE Comment IS NOT NULL AND CAST(TSComment AS DATE) = '2009-11-02'

Будет перебрана куча записей, чтобы найти требуемые записи с комментариями.
Такая выборка будет заметно менее быстрой чем в случае когда комментарии хранятся в отдельной таблице:
SELECT ... FROM order_line_comments INNER JOIN order_lines ON (...) WHERE CAST(TSComment AS DATE) = '2009-11-02'

Разница в скорости в таких запросах скорее всего будет в разы.

4) Разносим индексы по разным таблицам. Во-первых, теперь индексы будут обновляться реже: к примеру при вставке записи без комментария индексы в таблице комментариев не трогаются. Во-вторых, в некоторых СУБД будет и сокращение размеров индексов (к примеру в SQL Server индексы включают указатели на строки с null-значением индексируемого столбца, соответственно индекс по Comment в таблице order_lines будет намного больше, чем индекс по Comment в таблице order_line_comments).


5) Повышение конкурентности — т.е. строки исходной таблицы или вся таблица (если произойдет lock escalation или если определенный движок СУБД не поддерживает блокировку на уровне строк) не будут теперь блокироваться при изменении новых столбцов, т.к. эти столбцы вынесены в отдельную таблицу.
Re[6]: Вертикальное партицирование - есть ли смысл?
От: _d_m_  
Дата: 25.02.10 04:48
Оценка: -1
Здравствуйте, MozgC, Вы писали:

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


MC>Основные причины:


MC>1) Уменьшение размера базы данных. Так как в большинстве случаев используется фиксированный размер строк, поэтому если в таблице с миллионом строк указано только 10% комментариев (varchar(250)), то экономия размера базы будет — сотни мегабайт (примерно от 235 Мб до более полугигабайта в зависимости от используемой кодировки).


Ерунда. На то он и varchar, что занимает места по длине строки.
Re[7]: Вертикальное партицирование - есть ли смысл?
От: MozgC США http://nightcoder.livejournal.com
Дата: 25.02.10 07:50
Оценка:
Здравствуйте, _d_m_, Вы писали:

MC>>1) Уменьшение размера базы данных. Так как в большинстве случаев используется фиксированный размер строк, поэтому если в таблице с миллионом строк указано только 10% комментариев (varchar(250)), то экономия размера базы будет — сотни мегабайт (примерно от 235 Мб до более полугигабайта в зависимости от используемой кодировки).


___>Ерунда. На то он и varchar, что занимает места по длине строки.


Это зависит от СУБД и движка. Например в MySql если у MyISAM таблицы Row Format = FIXED, то все строки таблицы будут фиксированного размера, т.е. под строку таблицы резервируется максимальное место на диске.
Re[8]: Вертикальное партицирование - есть ли смысл?
От: _d_m_  
Дата: 25.02.10 08:40
Оценка: :)
Здравствуйте, MozgC, Вы писали:

___>>Ерунда. На то он и varchar, что занимает места по длине строки.


MC>Это зависит от СУБД и движка. Например в MySql если у MyISAM таблицы Row Format = FIXED, то все строки таблицы будут фиксированного размера, т.е. под строку таблицы резервируется максимальное место на диске.


MySQL недоСУБД.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.