Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
Есть таблица порядка 20 полей. Постоянно происходит INSERT (от 5 000 до 15 000 в сутки). Оперативный доступ к данным необходимо обеспечивать в течении года. Пока остановились на том, что одна таблица хранит записи в течении года, а потом переноситься в архив. Так же есть идея на каждый месяц сделать свою таблицу, а все запросы организовывать через SP(if или EXECUTE IMMEDIATE). Мож кто поделиться мыслями. ASA 9.0.2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 14:42 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
5.5 млн записей в год - не так уж и много. Я бы не стал ничего дробить. Удалял бы данные N-летней давности и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 14:46 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
Может стоит построить индексы? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 14:46 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
moteus пишет: > Есть таблица порядка 20 полей. Каких? LONG BINARY с многомегабайтными картинками? > Постоянно происходит INSERT (от 5 000 до 15 000 в сутки). > Оперативный доступ к данным необходимо обеспечивать в течении года. Всего 5.5 млн записей в год? > Пока остановились на том, что одна таблица хранит записи в течении года, > а потом переноситься в архив. > Так же есть идея на каждый месяц сделать свою таблицу, > а все запросы организовывать через SP(if или EXECUTE IMMEDIATE). А зачем? > Мож кто поделиться мыслями. Мысль одна: придумываешь себе сложности на ровном месте. Это предположение, которое может оказаться ошибочным. Но чтобы выяснить это, тебе придется привести структуру таблицы, охарактеризовать даные, которыми она заполняется и привести типовые запросы к этой таблице. Тогда можно будет что-нибудь более конкретное посоветовать. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 14:53 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
В таблице индексы есть, а удалять данные просто так нельзя, их необходимо сохранять для истории, но оперативного доступа не требуется. При больших селектах вставка сильно тормозит. Желательно чтобы скорость вставки была постоянной и максимально большой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 14:54 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
moteus пишет: > При больших селектах вставка сильно тормозит. А по-русски? > Желательно чтобы скорость вставки была постоянной и максимально большой. Скорость вставки обычно мало зависит от размера таблицы. Хотя, конечно, если извратиться и навешать триггеров, у которых скорость выполнения зависит от размера таблицы - тогда да. Но с дуру можно и... лоб сломать. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 15:03 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
"DBA"."CD" ( "ID" integer NOT NULL DEFAULT autoincrement, "DateTime" "datetime" NULL, "Log_1" char(2) NULL, "Log_2" char(2) NULL, "Log_3" char(40) NULL, "Log_4" char(40) NULL, "Log_5" char(10) NULL, "Log_6" char(3) NULL, "Log_7" char(3) NULL, "Log_8" char(40) NULL, "Log_9" char(15) NULL, "Log_10" char(40) NULL, "Log_11" char(15) NULL, "Min" double NULL, "Call" double NULL, "Updated" tinyint NULL, "Ref" integer NULL, PRIMARY KEY ( "ID" ), CID char(40) NULL ); CREATE INDEX "CD_Index3" ON "DBA"."CD" ( "Log_4" ASC ) IN "SYSTEM"; CREATE INDEX "CD_Index2" ON "DBA"."CD" ( "Log_3" ASC ) IN "SYSTEM"; CREATE CLUSTERED INDEX "CD_Index" ON "DBA"."CD" ( "DateTime" ASC, "Log_8" ASC ) IN "SYSTEM"; Выборка происходит по периоду DATETIME, LOG_3, LOG_4 плюс может присутствовать комбинация из LOG_8-LOG_11. Объем выборки для одного пользователя может доходить до 1000 записей. Кол-во пользователей (одновременных) до 10. Пишуших - до 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 15:11 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
moteus пишет: > CREATE CLUSTERED INDEX "CD_Index" ON "DBA"."CD" ( "DateTime" ASC, > "Log_8" ASC ) IN "SYSTEM"; А зачем Log_8 в кластерном индексе? Чем обычно заполняется DateTime при вставке? > Выборка происходит по периоду DATETIME, LOG_3, LOG_4 плюс может > присутствовать комбинация из LOG_8-LOG_11. Примеры выборок можно? Каково распределение значений полей Log...? Что дает ESTIMATE на условия по этим полям? И что все-таки тормозит, вставка или селекты? Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 15:33 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
В DateTime помещаеться момент вставки записи; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 15:43 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
Извените случайно сорвалось. Процент повторений для LOG_8..10 достаточно большой (существует порядка 100 различных значений) Для LOG_3,4 дела обстаят несколько лучше - их порядка 200000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 15:49 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
Скорость INSERT может достигать 40 строк в сек. COMMIT после каждой записи. При увелечении обьемов запросов (в конце месяца) приложение которое делает Insert периодически отваливаеться. Так же оно отваливаеться и при выполнении простого COUNT(*) по всей таблице. Я думаю может быть просто поменять уровни изоляции у транзакций. Приложения я не писал. На сколько я понял они стоят по умолчанию. С Sybase опыта работы не имею поэтому извеняйте если совсем не в ту сторону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 16:03 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
При больших селектах вставка сильно тормозит. Это как - при селектах вставка ? Желательно чтобы скорость вставки была постоянной и максимально большой. Скорость вставки и так постоянна. Не зависит от объема таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 18:33 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
Ага. Во-первых, "Log_1" char(2) NULL, "Log_2" char(2) NULL, "Log_3" char(40) NULL, "Log_4" char(40) NULL, "Log_5" char(10) NULL, "Log_6" char(3) NULL, "Log_7" char(3) NULL, "Log_8" char(40) NULL, "Log_9" char(15) NULL, "Log_10" char(40) NULL, "Log_11" char(15) NULL, надо выносить в отдельную таблицу. Ну или иметь веские аргументы против этого. Но это уже сократит тебе на один индекс кол-во индексов ( у тебя будет одно поле LOG). Дальше - кластерный индекс. По дате. Ну -- это классика как не надо делать. Потому что грозит при вставках (последовательных по дате) борьбой за последние страницы кластерного индекса (он же -- таблица). Ну и на скорость втавок влияет не самым лучшим образом. Я бы делал heap-таблицу или DOL таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 18:43 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
MasterZiv пишет: > Дальше - кластерный индекс. По дате. Ну -- это классика как не надо делать. > Потому что грозит при вставках (последовательных по дате) борьбой за > последние страницы кластерного индекса (он же -- таблица). В ASA не грозит. Он тут гораздо мене строгий, нежели в ASE. При наличии кластерного индекса ASA всего лишь стремится упорядочивать записи при наличии такой возможности, но не обязательно упорядочивает как в ASE. Хотя здесь дествительно достаточно обычного индекса - записи и так будут упорядочены более-менее по DateTime > Я бы делал heap-таблицу или DOL таблицу. Это что-то из ASE? Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 22:11 |
|
||
|
Как лучше организовать работу с большой таблицей
|
|||
|---|---|---|---|
|
#18+
наличии такой возможности, но не обязательно упорядочивает как в ASE. Хотя здесь дествительно достаточно обычного индекса - записи и так будут упорядочены более-менее по DateTime Понятно. Как в ASE на DOL. Это что-то из ASE? Ага. Извините, я что-то заработался, не обратил внимания, что про ASA речь идет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 00:22 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=92&tid=2013194]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
24ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 347ms |

| 0 / 0 |
