Вопрос к спецам по базам данных

[ura]

Если я заливаю данные в таблицу в которой записи не должны повторяться. Уникальность записи определяется 8-ю колонками. Что будет эффективнее в смысле производительнсти - создать unique constraint по этим восьми колонкам или сделать дополнительное поле в котором хранить уникальный hash code построенный по этим колонкам? Hash колонка будет строка символов на 30.

[CdR]

думаю, что если не учитывать время на построение hash, то это буде быстрее.
Хотя... unique constraint, собственно, делает примерно то же самое. Выигрыш можно получить, в методе построения hash c учётом специфики данных.
Я бы просто попробовал сравнить на какой-то тестовой базе с конкретным движком DB.

[pastor]

мне почему-то кажется, что движок базы шустрее будет обрабатывать constraint нежели считать/сверять хэш при insert/update
зачем изобретать велосипед?

[папа Карло]

Если я заливаю данные в таблицу в которой записи не должны повторяться. Уникальность записи определяется 8-ю колонками. Что будет эффективнее в смысле производительнсти - создать unique constraint по этим восьми колонкам или сделать дополнительное поле в котором хранить уникальный hash code построенный по этим колонкам? Hash колонка будет строка символов на 30.

зависит от многих факторов:

- тип базы
- сколько записей уже в таблице
- сколько заливаешь за раз
- как частно
- как именно заливаешь

?

[ura]

Движок Oracle 10g (базируется на HP-UX сервере).
Количество записей в этой таблице
20тыс в день и история должна храниться год. Интенсивная работа проводится в основном с новыми записями - неделя - две. Полей в таблице 15.

Констрейн по 8 полям по идее повлечет индексирование этих полей, но поскольку они не яволяются ключевыми при поиске данных я и сомневаюсь в эффективности. Хеш - это просто конкатенация строк, 100тыс хеш кодов создается меньше чем за полсекунды.

[папа Карло]

20к записей в неделю-две... должно бьть пофиг... слишком маленький объям чтобы о чем то говорить... если надо совсем быстро вынимать, то заведи хеш как сам говоришь на основе чексама или типа того... будешь потом кверить быстро...

[не местный]

Констрейн по 8 полям по идее повлечет индексирование этих полей, но поскольку они не яволяются ключевыми при поиске данных я и сомневаюсь в эффективности.

Сомневаюсь я, что из 8 полей, составляющих уникальный ключ, ни одно не используется как условие выборки. Все равно будет индекс, построенный по искусственному "ключу" - по сути просто дублирование данных. Так что не выдумывай сложностей, пусть движок базы занимается своими прямыми обязанностями. Особенно учитывая мизерное количество новых записей.

[ura]

Понятно, спасибо.
Т.е. если количество записей будет не мизерным а большим, или количество полей определяющих уникальность записи удвоится, то такая операция имела бы смысл?
Пока что борьба идет над минимизацией времени добавления записей. Опыт показывает, что самый быстрый способ это не добавление по одной записи, а сваливание всего нового хозяйства во временные таблицы и потом одним красивым инсертом в таблицы самой базы. Но поскольку времени на переделки особенно нет, надо по крайней мере обеспечить приемлемую производительность. А то когда смотришь в ТЗ а там написано - обеспечить 1000 записей за 2 секунды, смех да и только.

[папа Карло]

Понятно, спасибо.
Т.е. если количество записей будет не мизерным а большим, или количество полей определяющих уникальность записи удвоится, то такая операция имела бы смысл?
Пока что борьба идет над минимизацией времени добавления записей. Опыт показывает, что самый быстрый способ это не добавление по одной записи, а сваливание всего нового хозяйства во временные таблицы и потом одним красивым инсертом в таблицы самой базы. Но поскольку времени на переделки особенно нет, надо по крайней мере обеспечить приемлемую производительность. А то когда смотришь в ТЗ а там написано - обеспечить 1000 записей за 2 секунды, смех да и только.

у оракла чего bcp нету, чтобы сразу лить в саму таблицу?

[ura]

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

[папа Карло]

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

препроцесьте на апликейшен боксе, а потом если позволят "целостность" (например грузате когда система в оффлайне) гразите сразу целеком.... а не по одной записи.

[не местный]

Понятно, спасибо.
Т.е. если количество записей будет не мизерным а большим, или количество полей определяющих уникальность записи удвоится, то такая операция имела бы смысл?

Думаю, что все равно не имела бы.

На самом деле типичная задача: найти оптимальное соотношение производительности при добавлении записей и актуальности запросов. Если запросы терпят данные, к примеру, пятиминутной давности, то добавление следует производить в промежуточную таблицу без каких-либо индексов в режиме APPEND, и периодически выбирать из нее уникальные записи и массово добавлять в главную таблицу. Если же на выходе нужны самые свежие данные и задержка в 5 минут неприемлема, то, может, уникальность не так уж нужна? В таком случае надо добавлять данные в главную таблицу, но убить все индексы, за исключеним минимально необходимых.

Если же требуется и актуальность, и уникальность - тогда можно попробовать параллельную вставку несколькими процессами (увеличив freelists), опять же APPEND, выделить для таблицы отдельный буфер, положить ее на отдельный RAID10, NOLOGGING, и так далее.

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