[Comm] Re: Еще о локали utf-8 и файле Compose

[Aleksey Avdeev]

Денис Смирнов пишет:
> On Wed, Jan 28, 2004 at 06:45:22PM +0300, Aleksey Avdeev wrote:
> 
>  >   Разница в объёме данных, а следовательно в накладных расходах на:
>  > 1. хранение (диски не резиновые)
> 
> Есть такое, но не так уж и критично.

   Критичность зависит от объёма и скорости его роста: для БД 
растущих со скоростью несколько (10, 100 и т. д.) гиг в месяц - 
уже может быть критично.

>  
>  > 2. резервное копирование (ленты не резиновые + время + 
>  > _физический_ объём)
> 
> 
>    642947 Ноя 13  1996 Лабиринт_отражений
>    205139 Янв 28 19:26 Лабиринт_отражений.bz2
>    273723 Янв 28 19:23 Лабиринт_отражений.gz
>   1094149 Янв 28 19:23 Лабиринт_отражений.utf
>    212953 Янв 28 19:26 Лабиринт_отражений.utf.bz2
>    319371 Янв 28 19:23 Лабиринт_отражений.utf.gz
> 
> (319371 - 273723) / 273723 * 100 ~= 16% (для gzip -9)
> (212953 - 205139) / 205139 * 100 ~= 3%  (для bzip2 -9)
> 
> То есть увеличение объёма составит 3% при использование bzip2.

   Согласен. Но в некоторых случаях на ленту льют не сжимая: 
bzip2 -9 длительная и ресурсаёмкая операция, при больших объёмах.

> 
>  > 3. скорость обработки (в том числе - полнотекстовый поиск)
> 
> А индексы на что?

   Проиндексировать каждое слово не всегда возможно. + любые 
индексы хороши, когда _заранее_ известно что надо искать.

>  
>  > 4. поддержка индексов (объёмы + скорость поиска)
> 
> Бр-р-р-р-р. Индексирование строк без хэшей?

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

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

>  
>  > 5. ...
> 
> ?

   Лениво вспоминать. ;-)

   Всё очень завязано на объёмы БД и количество строк (данных 
и/или индекса) помещающихся на странице.

>  
>  >   Собственно уменьшение размера поля на 1 _бит_ - уже большой 
>  > "+" для крупной БД! А Вы предлагаете 2х кратное _увеличение_ 
>  > объёма для кириллической информации...
> 
> Увы, при моих (весьма скромных объёмах) для меня простота и прозрачность
> кода значение имеет. Производительность значение имеет (но на ней размер
> text/varchar/char полей особо не отражается). А вот объём, увы, не имеет.

   При больших таблицах (не вмещающихся в _физическую_ память) 
сильно отражается: уменьшение количествы строк на странице БД 
повышает количество дисковых операций. А если учесть, что если 
запрос затрагивает больше некоторого порога строк (10-30% или 
5%-10%, точнее непомню: давно доку на Oracle не смотрел) то 
выполнение запроса полным перебором таблицы часто _выгодней_ 
индексного.

> И не будет иметь до тех пор, пока объёмы баз данных не станут превышать
> хотя бы сотню гигабайт (SCSI HDD такого размера, что его стоиомть
> становится сколь-либо существенной).

   Весьма правильный подход! Просто в разных случаях, разные 
параметры имеют первоочередное значение.

-- 

С уважением. Алексей.