Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Mnogo primnogo dannyh
|
|||
|---|---|---|---|
|
#18+
Hello! Izwiniajus cto nie cyrilica - nietu u mienia zdes. A wopros takow. Imieju dwa procesa. Odin proces piszet w bazu signaly (60), drugoj ich citajet. Kromie togo procesy piszut dannyje w kontrolnuju tablicu, cto by kazdyj iz procesow znal, rabotajet li jego naparnik. Signaly postupajut kazduju sekundu. Nu, poroj mozet nie wse 60, a predpolozim 20 - zapisywajutsa tolko izmienennyje signaly. Piszuscij process posle modifikacii tablicy CURRENT_VALUE (tam gde sidiat signaly), wyzywajet funkciju MoveToArchive. I izmienennyje dannyje iz CURRENT_VALUE kopirujutsa w tablicy archive. Byli problemy s CURRENT_VALUE - tablica ocen bystro razrastalas. Ispolowal vacuum full CURRENT_VALUE. No potom opiat problema - indeksy wyrosli. Poczemu???? CURRENT_VALUE imiejet index po polu CVAL_FullName. Eto pole nie mieniajetsa. Tolko CVAL_Value i CVAL_TimeStamp mieniajutsa. Poczemu ze index PK_CVAL_FULLNAME pri UPDATE rastet? Nu, s etim ja toze razobralsa. Delaju REINDEX. Wse eto wozlozil na pleci cron'a, kotoryj wypolniajet swoje zadanije kazdyje 10 minut. Nu i teper wopros. Po statistike w tecenii minuty proishodit okolo 1200 signalow kotoryje nado archivirowat. Aga, jesco eti signaly podeleny na bloki. (6), to jest na odin blok 200 signalow. W cas - 12000. W sutki - 288 000. Signaly nado derzat mesiac. To jest polucajetsa 8 640 000. Kak na eto posmotrit postgres? Mashina horosa - 2*xeon 2.4, 2GB RAM, HDD w RAID po 120GB. I miesiac eto derzit i mozno ich select "dovolno" bystro. Prodolzenije woprosa - na niekotorych obiektach signaly nado derzat 12 mesiacew!!! eto okolo 100 000 000 rekordow. Sumiejet li postgres imieja na primier uze 50 000 000 rekordow dobawlat nowyje 20 rekordow kazduju sekundu? (toko nie goworite cto by ja peredelal eto na file - baza soderzit tolko izmienienija, mnie by priszlos pisat sobstwennyje algoritmy poiska po file. a wremieni niet :( ) Jesli kto stolknulsa s pohozej problemoj, to ocen budu blagodaren za sowety! Spasibo! Piotrek. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2004, 19:44 |
|
||
|
Mnogo primnogo dannyh
|
|||
|---|---|---|---|
|
#18+
nado derzat 12 mesiacew!!! eto okolo 100 000 000 rekordow У нас в базе до десяти миллионов записей. Глюков, вызванных объемом базы не замечено. Sumiejet li postgres imieja na primier uze 50 000 000 rekordow dobawlat nowyje 20 rekordow kazduju sekundu? Мне кажется, что скорость добавления новых строк не должна зависеть от объема базы. Однако... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2004, 10:44 |
|
||
|
Mnogo primnogo dannyh
|
|||
|---|---|---|---|
|
#18+
Мне кажется, что скорость добавления новых строк не должна зависеть от объема а если табла индексирована (затраты то на переуопрядочивание/запись индексов должны зависеть от объема таблицы)? Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2004, 13:32 |
|
||
|
Mnogo primnogo dannyh
|
|||
|---|---|---|---|
|
#18+
затраты то на переуопрядочивание/запись индексов должны зависеть от объема таблицы Мне кажется что: переуопрядочивание индекса ~ n*log(n), добавление записи в индекс ~ log(n), где n - объем таблицы. Доказать эту теорему не берусь. :-) P.S.: Мое утверждение "скорость добавления новых строк не должна зависеть от объема базы" надо бы подправить так: "скорость добавления новых строк не должна сильно зависеть от объема базы", где под словом "сильно" понимается линейно или даже! еще сильнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2004, 13:54 |
|
||
|
Mnogo primnogo dannyh
|
|||
|---|---|---|---|
|
#18+
Ok. Spasibo. Eto horoso cto glukov nietu. Pri dobawlenii index nie dolzen pereuporiadociwatsa (nu i slowiecko), poskolku za indeks priniata data i tip signala. To jest polucajetsa cto kazdyj sledujuscij rekord bolsze predyduscego. Woobscem dolzno wse idti gladko. Mda, 10 millionow zapisiej - eto mnogo. Nadiejus cto i 100 millionow nie budiet jejo sbiwat. Tem boleje cto poisk glawnym obrazom budiet toko za poslednij miesiac. Spasibo za dobroje slowo! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 13:24 |
|
||
|
Mnogo primnogo dannyh
|
|||
|---|---|---|---|
|
#18+
Petr NadeikoOk. Spasibo. Eto horoso cto glukov nietu. Pri dobawlenii index nie dolzen pereuporiadociwatsa (nu i slowiecko), poskolku za indeks priniata data i tip signala. To jest polucajetsa cto kazdyj sledujuscij rekord bolsze predyduscego. Woobscem dolzno wse idti gladko. Mda, 10 millionow zapisiej - eto mnogo. Nadiejus cto i 100 millionow nie budiet jejo sbiwat. Tem boleje cto poisk glawnym obrazom budiet toko za poslednij miesiac. Spasibo za dobroje slowo! Вообще если главным образом выбираются данные за последний месяц, то я бы рекомендовал разнести таблицы 1 на последний месяц 2 архив. И написать простой скрипт, который каждый день берет данные из таблицы за последний месяц и вставляет их в архив. ТОгда база будет побыстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 13:08 |
|
||
|
|
start [/forum/topic.php?fid=53&fpage=350&tid=2007556]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 350ms |
| 0 / 0 |
