Имеем FB2.0.3, IBExpert от 08.10.2010
(аналогичное поведение на FB2.5 и последнем IBExpert)

Не спрашивайте зачем мне это надо, но создаем БД в UTF8
размер страницы 16к.

В ней создаем таблицу

CREATE TABLE TEST_ASCI (
ID INTEGER NOT NULL,
ASCI_1 VARCHAR(32760) CHARACTER SET ASCII,
ASCI_2 VARCHAR(8185) CHARACTER SET ASCII
);

И вот парадокс, длина поля ASCI_2 не может быть больше 8185,
иначе при заходе на закладку Data в IBExperte вылезает ошибка
block size exceeds implementation restriction.
Почему? Поля в ASCI, соответственно длина всей записи
(не учитывая служебные) 4+32760+8185=40949, это сильно
меньше ограничения в 64к.
Причем никакое поле больше впихнуть в эту таблицу нельзя.

Причем, если увеличить ASCI_2 до 8186 (на единицу),
то ошибка вылезает, а если увеличить ASCI_1 до
32761 (на единицу) то ошибки нет.

UTF8

А как быть, если мне нужно два поля в таблице по 30кб? BLOB не могу использовать ввиду низкой производительности. На базе в 1251 все работало и летало. Проба использовать BLOB показала жуткие тормоза.

>> Не использовать utf8 на клиенте.

Надо.

>>Значит ты неправильно его использовал.

Несколько сот записей за раз загружаются, 1,2,3 записи могут содержать один документ (картинка) - результат сразу пакуется и по tcp/ip отправляется на сервер. Т.е. экспорт.
BLOB всяко тестировался, т.к. очевидно, что он удобнее, но хранение построчно документа в base64 дает сильное преимущество по производительности при выгрузке да и вообще даже при отображении одной картинки.

Когда наконец не будет ограничений 32к и 64к??

> Я чую дот-нет провайдер...

:-)

Нет, FIBPlus 7.0.15, Delphi XE Prof.
Тормоза из-за массовости. Понятно, что загрузка 2-3 картинок из блоба не покажется юзеру утомительной, но если их 100...

Попробую не упоминать оба поля в одном запросе. Т.е. по два запроса на запись будет. Если результат покажет сравнимое с BLOB время, то видимо придется юзать BLOB.

А вот если б небыло ограничения в 32 и 64к, то таких проблем небыло бы. 21 век, 64-разрядные процы о ОС... а у нас 64к.. Ппц, так и сидим в 1980х. :-(

2 kdv

Сам болен ;-)

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

> чтобы хранить мегабайтные картинки в варчаре? да ты болен :-)

Картинки как раз по 10-100кб примерно. На самою большую, которая пока была, уходило 2 записи с двума варчарами.

> Ох, что-то ты делаешь не так... При таком размере блоба не должно быть разницы.

Есть. Большинство картинок умещается в одну запись с двумя варчарами. Поэтому на извлечение одной картинки уходит одно обращение к серверу. При этом открыв pFIBQuery и слизав оттуда одну за другой картинки сильно быстрее. В один запрос все сразу. А как извлекается блоб? Фактически в два обращения к серверу! Т.е. на каждую заголовочную запись картинки еще идет обращение за содержимым блоба. Вот и разница.

Я не прав?

2 kdv

> какие то два несчастных tcp пакета в ЛОКАЛЬНОЙ системе замедляют работу прямо жуть?

Логика: Юзер жмет кнопку "Экспорт". Программа выводит modal-окно с индикатором, быстренько готовит пакет, ложит его на диск, закрывает окно с индикатором и запускает отдельный TThread, который и уже гонит в фоне данные через интернет. Если юзер будет ждать пока данные онлайн из базы через инет перекачаются на сервер, то он курить замучается.
Т.е. речь идет о том, чтобы быстро приготовить данные и запустить их отправку уже в фоне.

Короче, спасиба всем. Ваши мысли я понял. Сеня действительно попробую сделать просто одну таблицу с одним полем варчар 32к вместо блоба и попробую так, т.е. на картинку будет уходить по 2-4 записи в таблице. И тоже самое с использованием блоба. Время засеку, тут выложу. Посмотрим.

2 Dimitry Sibiryakov

Не прав в чем именно?

Если кто-то спросит почему нельзя готовить пакет в фоне, отвечаю, потому что логика такая, не должен юзер во время подготовки пакета ничего изменять, поэтому modal окно с индикатором. Программа не сетевая.

2 Dimitry Sibiryakov

Тогда чем объяснить, что блоб медленнее варчара? Реально медленнее - факт!

> Кривые обёртки - фтопку.

Ты имеешь ввиду FIB+ и мое приложение?:)

> уровень изоляции снапшот запретили враги. От жеж негодяи!

Приложение однопользовательское со встроенным FB

2 Dimitry Sibiryakov

> Именно.

Ну если писать на API не используя FIB+ и др., тогда преимуществ у FB маловато остается.

2 Dimitry Sibiryakov
2 kdv

Ладно, забьем что быстрее, варчар или блоб. Не суть уже. Объясните пожалуйста это:

Можно так:
CREATE TABLE TEST_1 (
ASCI_1 VARCHAR(32764) CHARACTER SET ASCII,
ASCI_2 VARCHAR(8186) CHARACTER SET ASCII
);
Т.е. всего 32764+8186=40950 символов

Можно и так:
CREATE TABLE TEST_2 (
ASCI_1 VARCHAR(8186) CHARACTER SET ASCII,
ASCI_2 VARCHAR(32764) CHARACTER SET ASCII
);
Т.е. те же 40950 символов.

А вот так, те же 40950 символов, уже нельзя:
CREATE TABLE TEST_3 (
ASCI_1 VARCHAR(20475) CHARACTER SET ASCII,
ASCI_2 VARCHAR(20475) CHARACTER SET ASCII
);
Выдает ошибку про блок сайз.

Почему?

и ведь даже так нельзя!!
CREATE TABLE TEST_4 (
ASCI_1 VARCHAR(10000) CHARACTER SET ASCII,
ASCI_2 VARCHAR(10000) CHARACTER SET ASCII
);
Ошибка про блок сайз.

2 Dimitry Sibiryakov
> У тебя лимит в 64к преодолел конечный result set, который уже в кодировке utf8.

Поля в ASCI, т.е. 100% в UTF8 они будут по 1 байту. Откуда берется
переполнение 64к в "конечный result set, который уже в кодировке utf8."?

> Считай на пальцах: (10000*4+2)+(10000*4+2) = 80004. 80004 больше чем 65535.

Слушай, не тупи, Тогда почему можно
(32764*4+2)+(8186*4+2)=131056+2+32744+2=163804 ??

Максимальное с двумя одинаковыми полями в ASCI можно так:
CREATE TABLE TEST_5 (
ASCI_1 VARCHAR(8189) CHARACTER SET ASCII,
ASCI_2 VARCHAR(8189) CHARACTER SET ASCII
);

Это (8189*4+2)+(8189*4+2+)=32756+2+32756+2=65516.
Т.е. в случае двух полей в ASCI баг налицо.

Потому что я сижу за компом и пробую как можно.
В IBExpert-e таблица

CREATE TABLE TEST_1 (
ASCI_1 VARCHAR(32764) CHARACTER SET ASCII,
ASCI_2 VARCHAR(8187) CHARACTER SET ASCII
);

В нее можно вставить. Потом перезакрыть БД, открыть таблицу - все видно,
читается. Но вот редактировать, да, нельзя, "блок сайз" вылезает.
Но при вставке картинок редактирование и не надо. Поэтому я не сразу заметил,
что редактировать уже вставленное нельзя. За это сорри.

Почему под поля ASCI в UTF8 резервируется память в 4 раза больше чем надо?
В UTF8 символы ASCI всегда 1 байт, а не 4. (В UTF16 всегда 2 байта на все символы)

про UTF16 я винду имею ввиду и в частности Delphi XE

Блин, это что, если БД в UTF8, то побарабану какие чарсеты полей? Все чарсеты будут в 4 байта переводиться?? Бред. Тогда нафига такой выбор чарсетов, если все они себя как UTF8 ведут. Тогда все поля в UTF8 и все... Попал я с переходом на юникод, просто ппц... :-(

Хорошо, пусть переводятся. Но ведь строка в ASCI в UTF8 будет как есть. UTF8 плавающий формат, а не фиксированный, как UTF16.
Коннект в UTF8, тогда памяти под строку "абвгд" надо 10 (или 12 с BOM) байт, а под строку "abcde" точно 5 (или 7 с BOM). Нафига все конвертировать в 4 байта? Хотя наверняка так - выделяется память под все поля без учета их чарсетов, т.е. тупо все по 4 байта, причем при использовании полей ASCI остается масса ненужно выделенной памяти. Это же не правильно, не рационально. Наверно нужно сначала анализировать чарсеты... Я разочарован в FB. Т.е. под строки даже в 10кб нужно использовать блоб? Это однозначно мертворожденное приложение получится...

Нет. Но если поле ASCI, то максимальный размер символа 1 байт всегда. Как можно символ с кодом меньше 128 впихнуть в 4 байта.. Стандарт UTF8 такое предусматривает... Интересно даже. Сейчас посмотрю.

2 Esperito
Ну это уже решение на коленках, тоже самое, что все строки хранить кусками в варчарах в разных записях одной таблицы. Вопрос уже не про блобы и варчары, вопрос уже ппц... Принципиальный. С ужасом осознал что имеющиеся проекты на FB на юникод не перевести, проще начинать сначала и на другом сервере. А я то наивный думал, что в Delphi буду мучаться c PAnsiChar/PWideChar :-) В Delphi все перевелось на юникод в течении суток и прекрасно работает, а с FB просто патовая ситуация. Расстроился, честно, ппц...

Здравый смысл: два поля, одно UTF8(10 символов) второе ASCI(10 символов). Во что превратится итоговая строка UTF8? Здравый смысл подсказывает что 10*4+10=50, а не 10*4+10*4=80. 30 байт просто зря выделены и являются паразитирующими.

Навеяло, с баш.орг:

Наш программер по телефону: Это вы рассуждаете с точки зрения здравого смысла, а не реализации в FB....


Может кто знает, на какой сервер можно срочно слинять? Может у Yaffil с этим получше?

2 hvlad

Опа, забрезжила надежда. Скажи в двух словах, куда копать? Разве OCTETS
не будет так же в 4 байта переводиться? Мне в таблице кроме
этих двух полей в OCTETS надо еще поле в UTF8 под комментарий.
Думаешь получится? Не будет из-за одного поля в UTF8 все в 4 байта переводиться?

2 Гаджимурадов Рустам

OCTETS ниразу не юзал, здравый смысл пока не сформировался.

2 hvlad

Спасиба! Реально есть надежда. Ночь впереди, буду пробовать.

> А скажи мне - на кой тебе там 2 поля ?

Лучше не спрашивай :-) Я там в base64 картинки храню с целью быстрого извлечения их, т.к. мне "кажется" (в чем меня тут заставляют сомневаться), что 1000 картинок по 50кб быстрее вытащить из 1000 строк с двумя варчарами, в которых они хранятся, нежели вытаскивать 1000 блоб-полей.

Еще ты скажи, что надо блобы использовать, и что они такие же быстрые, как и строки с варчарами.

2 Гаджимурадов Рустам

В смысле свалить все в кучу? На кой? С ними по отдельности работают. Это фотки людей, кто вошел на режимное предприятие по проксимити-карте. В один большой блоб зачем складывать? Чтобы потом извлечь одну конкретную нужно извлекать все (весь блоб)??

Пожалуйста, не умничай.

2 hvlad

> Через сеть - медленнее, локально - нужно мерять.

Локально быстрее. Поверь, меряли и не раз, и не я один. Варчары сильно быстрее блобов.
Тут kdv похоже идею для тестов придумал, вдруг на самом деле сделает такие тесты.
Я уверен, что у него результат по скорости в пользу варчаров окажется. У нас с ним
одни и те же инструменты так то.