Имеется таблица связи (назовём A_B), в которой расчетное количество строк при нынешней структуре БД может достугнуть миллиарда - совершенно монстроидальный размер на общем фоне БД. При этом накладные расходы в разы превышают собственно данные.
Получается это примерно так: на одну запись в таблице B приходиться 9000 различных записей в таблице A. Пополнение, в основном, идёт в таблице B.

Структура A_B:

Соответственно нужно каким-то образом изменить структуру A_B, так чтобы уменьшить приращение строк и при этом сохранить возможность более или менее нормально манипулировать данными.

Пока есть только одна идея - развернуть b_id в строку, закодировав значения - тогда количество строк будет соответствовать таблице А(~500K) и можно будет искать b_id с помощью LIKE, аналогично с a_freq. Однако перспективы такого способы очень сомнительны.

(СУБД PostgreSQL)

Senya_LМежду таблицами А и В, я так понимаю, связь многие-ко-многим?
Именно так.

За неимением лучших вариантов начал тестировать описанный способ.

Цифры на тестовом наборе данных такие:
записей в A_B 12000000 (размер 770 Мб)
записей в A_B_test 550000 (размер 210 Мб) (b_id и a_freq развернуты в varchar)
На обоих таблицах индесы по a_id.

Скорость выборки:

Абсолютная победа %]
Похоже меньший объем по строкам компенсирует затраты на like.
Только обрабатывать это всё будет сложно.

Bogdanov Andrey NtrНа обоих таблицах индесы по a_id.
А индекса по b_id нет? Ну тогда в обоих случаях фуллскан идет и то, что он по большей таблице идет медленнее вполне возможно. Попробуйте индекс по b_id создать.Индекс я привёл только для уточнения занимаемого дискового пространства. (индекс на A_B - ~150 Мб, A_B_test - ~12 Мб). Фуллскан, очевидно, будет иметь место в любом случае из-за like. У Postgres есть очень экзотичные типы индексов, но пока их не рассматривал.

Bogdanov AndreyА откуда взялся настолько меньший объем? Я, конечно, с Postres не знаком, но неужели он настолько неэффективно числа хранит? Ведь в вашем тестовом примере все те же числа записаны в строчку, да еще и куча разделителей добавлена.
www.postgresql.org/docs/faqs.FAQ_russian.html
24 байт: на каждый заголовок строки в таблице (приблизительно)
+ 4 байта: указатель на странице для всей табличной строки именно поэтому захотелось уменьшить количество строк.
Теперь получается, что накладных расходов - <3 байт на каждое значение b_id (оно вряд ли перевалит за 99999)

Кстати, Firebird на эту табличку понадобилось ~660мб без индекса.
Ещё есть подозрение, что они оба оставляют много места на каждой странице для версий.

MasterZiv
Надо ли ? Чем вас собственно миллиардная таблица не устраивает ?
...
Идея однозначно плохая.Ситуация самому не нравится, теряются преимущества реляционной модели и не известно как это будет себя вести на иных запросах. Таблица второстепенная, но полезная для аналитики. Объёмы заставляют изгаляться.
А работать это всё пока должно на персоналке, без всякого рэйда :)

miksoft Ntr Абсолютная победа %]Если бы...
А если число 10 встретится вначале или в конце строки?там собаки в качестве терм. символов написаны

Bogdanov AndreyПопробуйте индекс по b_id создать. С индексом по b_id на A_B чуть быстрее, но все равно дольше: 4-5 сек. Вполне закономерно - различных значений по этому полю всего 1300 - на 12 млн. строк.

miksoftЯ так понял, что знак "@" вы использовали просто как разделитель. Это не так?Так, этот же символ стоит и в начале и конце строки, поэтому "like '%@10@%'" работает корректно независимо от позиции искомого.

miksoftЕще вопросы:
В PostgreSQL бывают индексно-организованные таблицы?
В PostgreSQL бывают компрессированные индексы?Хорошие вопросы. Похоже я попытался изобразить как раз "индексно-организованные таблицы". С PostgreSQL разбираюсь всего полтора дня; быстрый поиск нечего ценного не дал, видимо их всё-таки там нет. Спасибо за намёк, теперь ясно что искать.

Konstantin~ http://www.postgresql.org/docs/8.1/interactive/sql-cluster.html]CLUSTER tablename Спасибо, нужно попробовать.
Нашел хорошее описание того, что требуется здесь :
Исключительно индексная таблица является индексом типа B-Tree базы данных, который одновременно исполняет роль таблицы. Все данные такой таблицы хранятся в индексе. Преимуществом создания полностью индексированных таблиц состоит в экономии места хранения на диске и сокращения объема ввода/вывода , поскольку ключевые колонки нет необходимости сохранять еще раз в таблице.Гугл сказал, что в явном виде это умеет делать (только) Oracle. В InnoDB и Sybase то же самое получается с помощью кластерного индекса, с PostgreSQL пока не ясно.

Senya_LА поинтересоваться можно (если это не коммерческая тайна, конечно ;)), что за информация в этих трех таблицах? Иногда правильнее перепроектировать, чем играться индексамиЗадача общего характера, подробности описывать не стану, но примерно так: есть множество составных объектов (таблица B) и множество элементов (таблица A), которые объект может использовать, т.е. включать в себя. Соответственно каждый элемент может принадлежать нескольким объектам. Связь позволяет охарактеризовать и объект и элемент.
Схема по сути стандартная, ничего не выкинешь.

Попробовал cluster table. Таблица занимает ровно столько же места. В общем, это обычный кластерный индекс.
Ключевым словом в описании было "b-tree", т.е. данные хранятся в виде дерева - таким образом исключается дублирование по заданным полям и получаются прочие прелести.

Решил остановиться на том, что наваял. Всем спасибо.