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

[Aleksey Avdeev]

Денис Смирнов пишет:
> On Wed, Jan 28, 2004 at 08:58:15PM +0300, Aleksey Avdeev wrote:
> 
>  >   Критичность зависит от объёма и скорости его роста: для БД 
>  > растущих со скоростью несколько (10, 100 и т. д.) гиг в месяц - 
>  > уже может быть критично.
> 
> И это всё текстовые данные? Тогда опаньки, там действительно надо

   В некоторых случаях да. Например телеметрия от цифровых 
телефонных станций (уровня ГТС).

> применять много разных мер по экономии пространства. Но такие задачи
> меньшинство, а для большинства эти потери не критичны. А когда критичны,

   Что считать большинством, а что меньшинством? Каждый судит со 
своей колокольни. :-)

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

   Это уже решения уровня движка БД (или модулей к ниму). Реально:

1. Далеко не всегда есть средства для реализаций решений такого 
уровня.

2. Если требуется обеспечить переносимость продукта между 
различными БД - цена данного решения возрастает многократно.

   А решение хранить данные в 8 битной кодировке может принять 
архитектор БД. И оно будет достаточно оптимальным, особенно если 
известен характер хранимых данных (то, что 8 бит - достаточно).

> 
> Именно поэтому обсуждать такие решения в контексте реений общего
> назначения я считаю бессмысленным.

   А я считаю бессмысленным в контексте решений _общего_ уровня 
закладываться на юникод, когда большенство задач неплохо 
укладывается в 8 бит: _зачем_ транжирить ресурсы аппаратуры по 
пусту? ;-)

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

   Но опять, вопрос упирается в: Что считать _общим_ уровнем? ;-)

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

   Почему именно plain text? Кодировка БД влияет на _все_ 
текстовые поля. И текста _читаемого_человеком_ может быть очень 
мало, по сравнению с остальными _текстовыми_ данными. :-)

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

   Кроме случаев поиска по _части_ строки - тогда хеши идут 
лесом. ;-)

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

   Не факт. Средством обработки - да. Средством хранения -нет 
(кроме случая когда данные не укладываются в 8 бит, разумеется): 
зачем выбрасывать _половину_ диска? ;-) (Собственно опять: ЧТО 
считать _большинством_ практических задач? ;-))

   Повторюсь: БД данные не обрабатывает - она их _хранит_ и 
предоставляет к ним относительно быстрый доступ.

-- 

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