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

[Денис Смирнов]

On Wed, Jan 28, 2004 at 08:58:15PM +0300, Aleksey Avdeev wrote:

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

И это всё текстовые данные? Тогда опаньки, там действительно надо
применять много разных мер по экономии пространства. Но такие задачи
меньшинство, а для большинства эти потери не критичны. А когда критичны,
то уже надо совсем менять принципы хранения, например использовать сжатие
со словарём частоповторяемых образцов, lzo, возможно какой-то набор
эвристик для улучшения сжимаемости текста (типа замены uppercase на
спецсимвол перед буквой, при том после точки этот символ добавляется
исключительно если буква изначально была наоборот маленькая) и много
других средств увеличения эффективности. Речи о выборе между utf-8 и 8-и
битными кодировками там и не идёт -- может оказаться по каким-то причинам
удобнее сформировать даже свою кодировку.

Именно поэтому обсуждать такие решения в контексте реений общего
назначения я считаю бессмысленным.
 
 >>(319371 - 273723) / 273723 * 100 ~= 16% (для gzip -9)
 >>(212953 - 205139) / 205139 * 100 ~= 3%  (для bzip2 -9)
 >>То есть увеличение объёма составит 3% при использование bzip2.
 >   Согласен. Но в некоторых случаях на ленту льют не сжимая: 
 > bzip2 -9 длительная и ресурсаёмкая операция, при больших объёмах.

Дело отнюдь не в объёмах, а в скоростя стриммера и процессора. И, в любом
случае, если появляются такие проблемы, то это также неординарная
ситуация.
 
 >>> 3. скорость обработки (в том числе - полнотекстовый поиск)
 >> А индексы на что?
 >   Проиндексировать каждое слово не всегда возможно. + любые 
 > индексы хороши, когда _заранее_ известно что надо искать.

Ну хоть что-то заранее известно. Или делается полнотекстовый поиск по
сотням гигабайт plain text? Ой мама...
 
 >>> 4. поддержка индексов (объёмы + скорость поиска)
 >> Бр-р-р-р-р. Индексирование строк без хэшей?
 >   Иногда - да: когда двоичные деревья рулят, например. Или 
 > когда  выгодно вытащить данные из индекса, не обращаясь к самой 
 > таблице. Или когда таблица уже упорядочена.
 >   На самом деле в каждом случяи надо разбираться особо: смена 
 > типа индекса иногда меняет скорость доступа в разы. И хеш - 
 > далеко не всегда оптимальный (они однозначно рулят, когда 
 > хеш-таблица в память помещается _полностью_).

Причём тут это? В узлах дерева могут быть _строки_, а могут быть _хэши_ от
этих строк. И если используется именно первое, то это будет тормозить
(попарное сравнение строк и 32/64 бит целых чисел, после которых
происходит сравнение срок только если хэши оказались одинаковыми, это
большая разница).
 
 >   При больших таблицах (не вмещающихся в _физическую_ память) 
 > сильно отражается: уменьшение количествы строк на странице БД 
 > повышает количество дисковых операций. А если учесть, что если 
 > запрос затрагивает больше некоторого порога строк (10-30% или 
 > 5%-10%, точнее непомню: давно доку на Oracle не смотрел) то 
 > выполнение запроса полным перебором таблицы часто _выгодней_ 
 > индексного.
 > >И не будет иметь до тех пор, пока объёмы баз данных не станут превышать
 > >хотя бы сотню гигабайт (SCSI HDD такого размера, что его стоиомть
 > >становится сколь-либо существенной).
 >   Весьма правильный подход! Просто в разных случаях, разные 
 > параметры имеют первоочередное значение.

Именно так. Собственно речь идёт о том, что сейчас юникод не имеет никаких
причин, кроме унаследованого софта, чтобы не стать основным средством
(применимым в большинстве практических задач).
 
-- 
С уважением, Денис

http://freesource.info