|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Andrew Lesnichenko 2:5020/400 30 Aug 2002 09:07:16 To : Andrew Sagulin Subject : Re: Hужна СУБД с быст рым добавлением запис ей --------------------------------------------------------------------------------
Andrew Sagulin wrote:
> Привет, All!
>
> 28 Aug 02 21:58, Andrew Sagulin wrote to All:
>
> AS> Hа добавление полученных данных (по разным причинам) отводится не
> AS> более 2 часов. Т.е. выходит, что скорость добавления должна быть не
> AS> менее 50 записей/сек. Это первое главное требование. Всего в базе
> AS> хранятся данные за 2 года, т.е. что-то около 250 млн. записей.
>
> Мы с коллегой ещё раз всё прогоним на разных СУБД и при разных условиях.
> Hедавно были попробованы: mySQL (для разнообразия) и Interbase. Они тормозили
> на создании индексов. И по этому поводу вопрос (извините, если спрашиваю
> очевидное, но я не специалист в СУБД): нужно искать по трём полям: дата, номер
> А и номер Б. Ищется обычно парами: дата-номер А или дата-номер Б. Когда
> проводились испытания (ими занимался коллега), он создавал два составных
> индекса (дата-номер А и дата-номер Б). Может ли это быть причиной тормозов при
> добавлении? Hе будет ли лучше создать три простых индекса по этим трём полям?
1. У вас довольно слабая задача и маленькие объемы и ее потянет любая
СУБД. Ваша прошлая проблема была не в Oracle, а в вашем
приложении/методике загрузки данных. Пока вы ее не решите, вы на любой
СУБД будете иметь плохой результат.
2. Вообще говоря, перед массовой заливкой данных индексы следует убивать
и потом создавать заново.
3. Если вы выберете Oracle, то делаете секционированную таблицу с
секциями размером в каждую заливку. Тогда вытирание старых данных
сводится всего лишь к drop partition - это очень быстро отработает. При
добавлении же: заливаете в отдельную таблицу, строите по ней индексы,
добавляете этот раздел в общую таблицу командой exchange partition.
--
Andrew Lesnichenko
--- ifmail v.2.15dev5
* Origin: Mobile TeleSystems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /su.dbms/1224221345eb0.html, оценка из 5, голосов 10
|