Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
hooky-mars
Зарегистрирован: 03.01.2006 Сообщения: 39
|
Добавлено: Чт Мар 15 2007 10:49 Заголовок сообщения: Большие таблицы в Oracle |
|
|
Saluer!
Такая ситуация. В начале каждого месяца содается таблица <что-то>mmyyyy в нее каждый день вносятся данные (около 500 тыс. записей). В результате в конце месяца получается просто огроменная таблица, и их кол-во будет увеличивытся. В идеалие информация должана храница в течении 5 лет.
Так вот в любой момент может понадобится информация за эти 5 лет. При чем поиск надо производить автоматически.
Но я даже не представляю как автоматически сотавить подобный запрос (select * from <что писать тут?>). Как определить существуютли таблицы за указанный период, и желательно чтоб это работало пошустрее.
Может создать какоето хитрое представление? но, ведь там тоже надо указть список таблиц.
Подскажите что можно сделать. |
|
Вернуться к началу |
|
|
OverCPU
Зарегистрирован: 04.02.2007 Сообщения: 61
|
Добавлено: Пт Мар 16 2007 00:55 Заголовок сообщения: |
|
|
Именно в Oracle такую проблему не решал а вот в MySQL сталкивался при работе с Огромными базами.
Решть можно так:
Попробуй к примеру создовать доп тоблицу раз в сутки называя ее текущей датой к примеру 20070315 тоесть у тебя на кадый день получиться 1 таблица. Для облегчения поиска создай таблицу которая будет запоминать имя и дату(В ней ищиш дату, когда найдеш дату обращаешся к нужной таблици по найденому названию). _________________ OverNet - Конец Inet'a |
|
Вернуться к началу |
|
|
and3008
Зарегистрирован: 12.10.2001 Сообщения: 14893 Откуда: Н.Новгород
|
Добавлено: Пт Мар 16 2007 09:10 Заголовок сообщения: |
|
|
В Oracle это решается партиционированием базы данных.
Поддерживается только в версии Enterprise.
У нас SMS-ки там лежат. В праздники их до миллиона в сутки может быть.
Партиции разбиты по неделям.
Поиск и выборка за любой период занимает доли секунды.
Работает все на DL-380. Правда хранилище базы на такой вот железке:
http://www.hds.com/products_services/storage_systems/modular_storage/ |
|
Вернуться к началу |
|
|
hooky-mars
Зарегистрирован: 03.01.2006 Сообщения: 39
|
Добавлено: Пт Мар 16 2007 16:01 Заголовок сообщения: |
|
|
OverCPU писал(а): | Именно в Oracle такую ... |
Уже начал работать по такой схеме, токо не подням а по месяцам.
To and3008
А можно по подробнее? Где проэто почитать? |
|
Вернуться к началу |
|
|
hooky-mars
Зарегистрирован: 03.01.2006 Сообщения: 39
|
Добавлено: Пт Мар 16 2007 16:47 Заголовок сообщения: |
|
|
Я нашол как работать с парититионами, но мне надо разбить разделы по датам, а на скоко я понл парититионы позволяют содавать разделы по записям. Или это не так?
И еще, такая разбитая таблица будет обрабатываться быстрее, чем единая? |
|
Вернуться к началу |
|
|
hooky-mars
Зарегистрирован: 03.01.2006 Сообщения: 39
|
Добавлено: Пн Мар 19 2007 09:40 Заголовок сообщения: |
|
|
И как организовать поле автоинкремента? на всю таблицу одна последовательность?
И если я сделаю разделы по месяцам, то при выборке обращение будт происходить к соответсвующему разделу или ко всей таблице?
Вот пример:
Код: |
create aaa(id number,
cdate date,.....)
....
PARTITION P1 VALUES LESS THAN (to_date('01-04-1999','DD-MM-YYYY')),
PARTITION P2 VALUES LESS THAN (to_date('01-07-1999','DD-MM-YYYY')))
/
select * from aaa where cdate between '01-04-1999' and '10-04-1999'
/
|
|
|
Вернуться к началу |
|
|
PR
Зарегистрирован: 05.06.2007 Сообщения: 2
|
Добавлено: Вт Июн 05 2007 14:50 Заголовок сообщения: |
|
|
Есть интересная тема, которая может помочь в данном вопросе, реализованная конкретно в Oracle. Это материализованные вьюшки (materialized view, пр.: create materialized view my_all_objects), которые прекрасно описаны во втором томе у Том Кайта. Они рассчитаны как раз для работы с очень большими таблицами. На первый взгляд может показаться, что использовать этот механизм сложно и запутанно, но страшного ничего нет (пробовал сам - успешно "тема" себя зарекомендовала). В завершение слов скажу цитатой из книги - "...повышение производительности. Получив (однажды) ответы на сложные вопросы, можно существенно снизить нагрузку на сервер. При этом:
1) Уменьшается количество физических чтений. Приходится просматривать меньше данных.
2) Уменьшается количество записей. Не нужно так часто сортировать/агрегировать данные.
3) Уменьшается нагрузка на процессор. Не придется постоянно вычислять агрегаты и функции от данных, поскольку это уже сделано.
4) Существенно сокращается время ответа. При использовании итоговых данных запросы выполняются значительно быстрее по сравнению с запросами к исходным данным.". А партиционирование базы данных это не лучший вариант, на мой взгляд. |
|
Вернуться к началу |
|
|
|