быстрее будет маленький блоб внутри процесса зафетчить и передать
клиенту с остальными записями чем клиенту за каждым блобом лезть на сервер.
Это нужно ограниченному числу приложений. Случай, когда приложение
работает не с кучей блобов сразу а с 1-м я считаю более распространённым.
Я не прав ?
Ну как я понял, ты предлагаешь заменить большие VARCHAR на блобы...
против этого и выступаю :) а в общем случае идея кажется здоровой,
поскольку во многих случая (у меня, по крайней мере) пишутся бинарные
данные маленького размера, но 100% гарантии на то, что никогда не будет
больше 32к дать не могу.
1. как коннектился к БД ? если по TCP, то через fbclient, или через
код jaybird ?
В обоих случаях Jaybird напрямую по TCP.
2. что делают (в двух словах) тесты
testProjection100
SELECT DISTINCT blob_col, int_col FROM some_table
testVariableSelectivity
SELECT int_col, char_col, another_blob_col FROM another_table WHERE
int_col < ?
testSelect10TenPctNonClustered
SELECT int_col, char_col, another_blob_col FROM another_table WHERE
blob_col = 'some string'
в которых отставание блобов более чем 10-кратное
3. даже не вопрос - обрати внимание, что 17 тестов (из 70) выполнились
быстрее с блобами, и 8 из них - более чем в 2 раза быстрее
Ага, я видел :) Тоже интересный эффект.
testMode10kFile - фетч некоторого числа записей (включая блобы) и запись
в файл. объяснить не могу
testTenPctDecimIndex - создание индекса по NUMERIC полю, думаю, что это
просто отклонение.
testUpdatesCodeIndex - создание индекса по CHAR(10) полю, отклонение.
testTenPctCodeIndex - см. выше, другая таблица
testMode10kScreen - то же что и testMode10kFile, но с выводом на консоль
testTableScan - поиск одной записи в базе полным сканом. тест под
вопросом - фетч не используется, надо сравнить с описанием теста, баг ли
это. Хотя он показывает, что на одну страницу влазит больше записей,
поэтому скан идет быстрее.
testSubtotalReport - SELECT avg(...), min(...), max(...), ...,
count(blob_col) FROM some_table WHERE decimal_col > ... GROUP BY
char_col, int_col. Думаю, что эффект от более плотной "упаковки" записей
на странице
testJoin2Clustered:
+ "SELECT "
+ UNIQUES_SIGNED_COL + ", " + UNIQUES_NAME_COL + ", "
+ HUNDRED_SIGNED_COL + ", " + HUNDRED_NAME_COL + " "
+ "FROM " + UNIQUES_TABLE + ", " + HUNDRED_TABLE + " "
+ "WHERE "
+ UNIQUES_KEY_COL + " = " + HUNDRED_KEY_COL + " "
+ "AND "
+ UNIQUES_KEY_COL + " = 1000"
здесь UNIQUES_NAME_COL и HUNDRED_NAME_COL - блобы.
testJoin4Clustered:
+ "SELECT "
+ UNIQUES_DATE_COL + ", " + HUNDRED_DATE_COL + ", "
+ TEN_PCT_DATE_COL + ", " + UPDATES_DATE_COL + " "
+ "FROM " + UNIQUES_TABLE + ", " + HUNDRED_TABLE + ", "
+ TEN_PCT_TABLE + ", " + UPDATES_TABLE + " "
+ "WHERE "
+ UNIQUES_KEY_COL + " = " + HUNDRED_KEY_COL + " "
+ "AND "
+ UNIQUES_KEY_COL + " = " + TEN_PCT_KEY_COL + " "
+ "AND "
+ UNIQUES_KEY_COL + " = " + UPDATES_KEY_COL + " "
+ "AND "
+ UNIQUES_KEY_COL + " = 1000"
здесь блобы не используются. Единственное объяснение - более плотная
упаковка страниц.
testJoin4NonClustered:
+ "SELECT "
+ UNIQUES_DATE_COL + ", " + HUNDRED_DATE_COL + ", "
+ TEN_PCT_DATE_COL + ", " + UPDATES_DATE_COL + " "
+ "FROM " + UNIQUES_TABLE + ", " + HUNDRED_TABLE + ", "
+ TEN_PCT_TABLE + ", " + UPDATES_TABLE + " "
+ "WHERE "
+ UNIQUES_CODE_COL + " = " + HUNDRED_CODE_COL + " "
+ "AND "
+ UNIQUES_CODE_COL + " = " + TEN_PCT_CODE_COL + " "
+ "AND "
+ UNIQUES_CODE_COL + " = " + UPDATES_CODE_COL + " "
+ "AND "
+ UNIQUES_CODE_COL + " = 'BENCHMARKS'"
UNIQUES_CODE_COL - CHAR(10), блобы не используются. См. выше.
testIntegrity - UPDATE который приводит к нарушению уникальности
индекса. Упаковка страниц?
testBulkSave -
+ "INSERT INTO " + SAVE_UPDATES_TABLE + " "
+ "SELECT * FROM " + UPDATES_TABLE + " "
+ "WHERE " + KEY_COL + " BETWEEN 5000 AND 5999"
вопрос - в этом случае используется один и тот же идентификатор блоба?
testUpdateMiddleCode - UPDATE по индексу. Без понятия.
testAppendMiddle - INSERT затрагивающий блобы. Не понятно, поскольку те
же вставки в главном testLoadData привели к замедлению в 3 раза.
Роман
