Search  
Thursday, October 22, 2020 ..:: Forum ::.. Register  Login
 Forum Minimize
Pentru a putea posta mesaje trebuie să vă înregistraţi.
Notă: Mesajele cu conţinut jignitor sau ilegal (inclusiv cereri de soft piratat) nu sunt acceptate şi vor fi şterse imediat .

Pentru a primi raspunsuri rapide si corecte, scrieti in mesaj ce intentionati sa faceti, ce mesaj de eroare primiti, in ce context si in urma caror actiuni. De asemenea, mentionati versiunea de FoxPro in care lucrati!
Dacă nu specificați versiunea, se consideră VFP 9.0 SP2.

SearchForum Home
  Visual FoxPro  Baze de date, tabele, view-uri si indecsi  BAZA DE DATE IM...
 BAZA DE DATE IMENSA
 
 8/20/2011 1:26:02 PM
User is offlinedorelH
15 posts


BAZA DE DATE IMENSA
 (N/A)
Am onoarea sa va salut

As avea o mica problema:
Am de creat o baza de date care va contine inregistrarile din minut in minut de la 5 milioane se senzori, deci 7,2 miliarde records/zi.

Cum sa o fac?
1. Creez tabele diferite pt. fiecare zi (sau saptamana).
2. Creez un tabel cu toate datele (stocat in mai multe fisiere sau partitii) - (intr-un an va ajunge la aprox 2Tb!)

Mentionez ca:
  - Tabelul cu datele va fi read only
  - voi avea nevoie de interogari complexe (de genul Select data from 10 sensors for 3 nonconsecutive month)
  - Interfata vreau sa o scriu in VFP iar pt. rapoarte voi folosi SQL (T-SQL)
  - Intentionam sa stochez baza de date cu MS SQL server 2008

Va multumesc anticipat!
Dorel HAVA
 8/20/2011 4:05:58 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: BAZA DE DATE IMENSA
 (N/A)
Deci in fiecare minut faci 5*10^6 inregistrari in baza de date?
Sau o inregistrare cu 5*10^6 campuri?
Mai intai verifica daca serverul+sistemul de operare suporta asta.
Ma indoiesc sa poti realiza asta cu un buget modic - si inteleg ca bugetul asa este, altfel nu aveam aceasta discutie.

Exista perioade de repaus? Serverul se poate opri pentru mentenanta? Ce se intampla daca serverul cade?
E nevoie de miroring?

Daca insa preiei de undeva inregistrarile, si nu le faci in timp real, e ceva mai simplu.
Cate tabele faci si cum partitionezi informatia tine de interogarile pe care le faci.
Scindarea pe perioade calendaristice nu este o optiune, mai degraba pe grupe de senzori.
Incearca interogarile pe tabele de test, ajuta-te de profiler si de query plan, doar asa poti sa validezi o solutie sau alta.


Daniel Buduru
 8/21/2011 9:12:00 AM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A)
Va multumesc pt. promptitudine
- da, in fiecare minut se fac 5 milioane inregistrari (records) dar tabelul este simplu, gen: sensorID, datetime, value
- o sa testez azi daca PC-ul meu suporta
- in ceea ce priveste bugetul momentan el nici macar nu exista. Daca gasesc o solutie viabila, beneficiarul are sigur bani
- serverul se poate opri pt. mentenanta si probabil va fi nevoie si de mirroring
- inregistrarile se preiau din alta baza de date, care este in timp real, dar pastreaza doar 15-60 de minute de inregistrari (cu mentiunea ca datele necesita o mica prelucrare cu o functie, deci nu se coipaza identic intreg continutul).
- din pacate nu pot scinda pe grupe de senzori

La prima vedere, scindarea pe zile parea Ok. Dar daca mi se cere o interogare pt mai multi senzori, pentru intersectii de perioade (deci zile neconsecutive), ma ia cu groaza cand ma gandesc ce Select trebuie sa fac.

 8/21/2011 1:41:54 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: BAZA DE DATE IMENSA
 (N/A) Modified By Daniel Buduru  on 8/21/2011 1:54:02 PM)
Creeaza o baza de date pe serverul sql pe care vrei sa-l utilizezi, apoi ruleaza codul asta:

CREATE TABLE [dbo].[Sensor](
    [sensorid] [bigint] NOT NULL,
    [datetime] [datetime] NOT NULL,
    [value] [bigint] NOT NULL
) ON [PRIMARY]

GO

--truncate table dbo.sensor
declare @i int=1
while @i<1000001
begin
 insert into dbo.sensor (sensorid, datetime, value) values (1,getdate(),@i)
 set @i=@i+1
 end
 
 select count(*), min(datetime), max(datetime), cast(max(datetime)-min(datetime) as time) as durata from sensor


Codul insereaza 1 milion de inregistrari. Pe un pc, E6300, sata III, cu sql server 2008R2 developer (nu express), face cam 5 minute, deci 25 minute pentru 5*10^6 inregistrari.
Sa zicem ca ridici performanta pc-ului, o faci de 5x mai buna (nu prea vad cum, dar ...), tot iti ia 5' pentru 5*10^6 inregistrari ...
Chiar daca se face captura in timp real pe alta masina, tot trebuie sa aduci in baza ta de date acelasi volum in acelasi interval, cu un consum de resurse ceva mai mare - intervine o functie de prelucrare.

Daca se face deja captura, fie nu e vorba de 5.000.000 inregistrari/minut, ci de ceva mult mai subtire, fie e vorba de o masina foarte puternica.
Oricum, chiar la valori de 5 ori mai mici., 1 milion de inregistrari pe minut, e nevoie de o masina server, nu de un pc botezat asa, poate si de clustering.

Scindarea inregistrarilor pe perioade nu e o optiune. Cel mult, poti trece in alta baza de date inregistrarile perimate, cele care nu mai sunt interogate curent.
Daca nu vei dispunde de clustering, scindarea in baze de date diferite pe grupe de senzori, baze de date plasate pe unitati de disc diferite, e singura optiune pe care o ai. Poti face interogari pe tabele din mai multe baze de date in acelasi select, daca asta te ingrijoreaza.
Oricum, costurile implementarii - la valorile pe care le-ai enuntat, 5 milioane de inregistrari pe minut, vor fi foarte mari.



Daniel Buduru
 8/21/2011 6:45:38 PM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A)
Multumesc foarte mult pt. sfaturi

Solutia finala va fi evident un server consacrat (grup de servere).
Din pacate numarul de inregistrari este de minim 1 mil/min. pentru o tara ca Romania. Pt. US estimez la 10-15 mil/minut.

Voi incerca sa vad cum pot scinda tabelul pe senzori si pe timp astfel incat voi avea informatia in sute sau mii de table.
(de exemplu creez tabele cu datele zilnice si senzori grupati pe zone geografice)
Iar interogarea, ma gandesc sa o fac in 2-3 pasi.
1. Voi crea un tabel temporar cu ce ma intereseaza (selectez doar zilele care ma intereseaza si eventual zona geografica daca se poate)
2. Din tabelul temp. voi face interogarea finala, care este mult mai complexa.

Am sa studiez clustering-ul, nu sunt deloc familiarizat cu el.
Asa cum ai observat, problema cea mai mare a aplicatiei este crearea si stocarea bazei de date.

Numai Bine!

 8/23/2011 12:46:36 AM
User is offlinemgabi
1094 posts
1st


Re: BAZA DE DATE IMENSA
 (N/A)
Chiar daca ai sa ai informatia in 1000 de tabele, nu te ajuta decat daca le distribui pe un cluster (daca isi permite clientul), sau pe mai multe servere , fiecare dedicat unui grup de senzori.
Preluarea (salvarea) datelor de pe serverele care primesc online datele de la senzori o poti face si cu replicare. N-am testat, dar ar tb. sa fie mai rapida replicarea decat interogarea si copierea (SQL)

Eu as merge pe varianta cu mai multe servere, fiecare responsabil de un set de senzori. Astfel va reusi sa faca fata fiecare volumului de date.
Nu uita si de volumul de date ce urmeaza a fi transmis, in cazul in care folosesti o retea de servere legate. Viteza retelei (banda reala) este mult mai mica decat capacitatea de prelucrare a unui comp. Eu zic ca aici vei avea cea mai mare limitare in prima faza. (asta daca nu pui la socoteala "citirea" unui milion de senzori ... nici nu vreau sa ma gandesc cat dureaza)

Probabil ca aceasta problema se mai poate rezolva si "etajat", pe nivele de stocare.
nivel1=severe de culegere date , care preiau de la senzori.
nivel2=servere de stocare generale , cu arhive pe zile de ex.
nivel3=server de filtrare/interogare
....
sau ceva asemanator.

 8/23/2011 1:18:42 AM
User is offlineDumitru
206 posts
4th


Re: BAZA DE DATE IMENSA
 (N/A) Modified By Dumitru  on 8/23/2011 1:19:23 AM)
Ai: sensorID, datetime, value
Am o idee de micsorare a numarului de inregistrari salvate.
Banuiesc ca sunt situatii (si nu putine) in care "value" nu se modifica.
Faci o tabela tampon cu un milion de inregistrari (sau cati sunt intr-o zona geografica) , cate una pentru fiecare senzor: sensorID, datetime, value, flag (boolean). Actualizezi tabela cu valorile de la senzori si setezi "flag" pentru valorile care s-au modificat, apoi inserezi in tabela mare numai inregistrarile cu flagul true. Resetezi flagul cu un update si reiei operatia cu alt set de date. Consuma ceva timp dar poate merita pentru memoria castigata si implicit timpul mai mic de interogare (depinde cat de iscusit faci interogarile).
Avand in vedere ca ai date pentru 15-30 min poti sa faci o statistica sa vezi daca merita, adica daca exista senzori care-si pastreaza valoarea in timp.
Nu cred ca valoarea se modifica la toti de la o secunda la alta si in felul asta ai deja informatia putin prelucrata si daca combini cu gruparea senzorilor pe zone geografice parca se vede ceva lumina.


 8/23/2011 9:31:06 AM
User is offlineGrigore Dolghin
4001 posts
www.class-software.ro
1st






Re: BAZA DE DATE IMENSA
 (N/A)
Problema cea mai mare nu este interogarea, ci scrierea tranzactiilor pe disc. Sunt 83.333 de tranzactii PE SECUNDA. Sunt curios sa vad hardware-ul care scrie cu viteza aia.

Grigore Dolghin
Visual FoxPro MVP 2006 - 2010
Class Software
My blog
 8/23/2011 9:48:28 AM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A)
Mersi pt sfat, deja am folosit ideea asta. Initial era vorba de 5 milioane senzori/records si am reusit sa-i reduc la 1 milion, pe aceasta baza.

 8/23/2011 4:55:20 PM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A)
 dorelH wrote
Mersi pt sfat, deja am folosit ideea asta. Initial era vorba de 5 milioane senzori/records si am reusit sa-i reduc la 1 milion, pe aceasta baza.


 (reply la Dumitru)
 8/25/2011 1:47:43 PM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A) Modified By dorelH  on 8/25/2011 2:01:44 PM)
REFERITOR LA VITEZA DE EXECUTIE/SCRIERE

Am testat codul urmator din VFP
? DATETIME ()
FOR  i=1 TO 10 000 000 STEP 1
 INSERT INTO Table1 (inid, timp, value, status) VALUES (i, date(), i, "S")
ENDFOR
? DATETIME()

Pe PC-ul meu cu Core 2 Duo E6300, 2 Gb Ram, HDD 320 Gb, face 24 secunde! si insereaza cam 400 Mb date in Table1.dbf
Deci SQL Server face 5 min pt 1 milion inregistrari iar VFP 24 secunde pt 10 Milioane de inregistrari ?!
Foarte ciudat, SQL Server nu poate fi de 100 de ori mai incet ca VFP

 8/25/2011 2:22:44 PM
User is offlineGrigore Dolghin
4001 posts
www.class-software.ro
1st






Re: BAZA DE DATE IMENSA
 (N/A)
In anumite circumstante e posibil. Codul de mai sus nu e suficient pentru a ne putea da cu parerea. Ai indecsi pe tabela VFP? (banuiesc ca in SQL Server ai). La fiecare inserare indecsii trebuie actualizati. Daca in tabela VFP nu ai indecsi e posibil sa fie mai rapid - pana la urma, insertul este un append la sfarsitul fisierului. In SQL Server nu - se reorganizeaza si paginile. Ideea e ca SQL Server face mult mai multe operatiuni la un INSERT fata de VFP.

Grigore Dolghin
Visual FoxPro MVP 2006 - 2010
Class Software
My blog
 8/25/2011 5:03:22 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: BAZA DE DATE IMENSA
 (N/A)
 dorelH wrote
Pe PC-ul meu cu Core 2 Duo E6300, 2 Gb Ram, HDD 320 Gb, face 24 secunde! si insereaza cam 400 Mb date in Table1.dbf
Deci SQL Server face 5 min pt 1 milion inregistrari iar VFP 24 secunde pt 10 Milioane de inregistrari ?!
Foarte ciudat, SQL Server nu poate fi de 100 de ori mai incet ca VFP



Instaleaza SQL Server 2008 R2 express (sau developer) si fa propriul test.

Daniel Buduru
 8/25/2011 7:46:46 PM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A)
Nu sunt indecsi nici in VFP nici in SQL server.
Datele odata stocate nu mai trebuiesc modificate, deci creez indexul dupa stocare.

Si totusi in SQL server inserarea a 1 milion de records dureaza 2,55 minute iar in VFP se face in 2 secunde (deci de ~100 de ori mai rapid).
In VFP am creat indexul ulterior si mi-a luat tot 2 secunde.
Mai studiez problema fiind ca nu mi se pare normal.

Va multumesc!


 8/25/2011 7:49:30 PM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A)
Am instalat SQL Server Developer.
Intr-adevar in SQL server inserarea a 1 milion de records dureaza 2,55 minute iar in VFP se face in 2 secunde (deci de ~100 de ori mai rapid).

In VFP am creat indexul ulterior si mi-a luat tot 2 secunde.

Mai studiez problema fiind ca nu mi se pare normal.

Va multumesc!
 8/25/2011 10:09:35 PM
User is offlineDaniel Buduru
3522 posts
1st




Re: BAZA DE DATE IMENSA
 (N/A) Modified By Daniel Buduru  on 8/26/2011 12:51:23 AM)
Un articol peste care am dat cautand altceva, dar din care iti poti face o idee despre viteza uzuala de inserare pe un server sql:

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Nu tema articolului conteaza, uita-te doar la timpii realizati si la viteza cea mai buna obtinuta.

Update
Vezi si aici:
http://sqlserverperformance.wordpress.com/2010/02/07/some-initial-insert-test-benchmarks-on-sql-server-2008-r2/

Uite si o configuratie hardware care poate realiza mai mult decat ce ai nevoie:
http://henkvandervalk.com/sql2008-r2-dce-on-a-96-core-unisys-es7000-server-with-dsi-solid-state-storage-bulk-inserting-1-terabyte-within-10-minutes

Iar aici e o situatie asemanatoare cu cea in care te vei gasi la fiecare 30' - transferul a 150 miliaone de linii din baza de date in care se face captura in baza ta de date:
http://dba.stackexchange.com/questions/1293/bulk-insert-best-usage

Si alte solutii hardware:
http://www.sql-server-performance.com/forum/threads/insert-a-billion-rows-fastest.2521/


Daniel Buduru
 9/3/2011 5:20:39 PM
User is offlinedorelH
15 posts


Re: BAZA DE DATE IMENSA
 (N/A)
Am modificat codul pt sql server astfel incat tot Insert-ul sa fie intr-o singura tranzactie si nu fiecare rand cate o tranzactie:

DECLARE @i AS INT
SET @i = 0

BEGIN TRANSACTION
  WHILE(@i < 1000000)
     BEGIN
         INSERT INTO table_1 values(@i, GETdate(), @i, 'F')
        set @i += 1
     END
COMMIT TRANSACTION

Inserarea a 1 milion de randuri a durat 24 de secunde.
Deja ma incadrez la viteza dorita (cel putin 1 milioin rec/min), dar tinta mea este 1mil rec/10 sec. (poate va creste volumul de date)
Am sa incerc si cu SQL Bulk Copy sa vad ce obtin.
  Visual FoxPro  Baze de date, tabele, view-uri si indecsi  BAZA DE DATE IM...

Search  Forum Home         

 Google Ads Minimize

    

Copyright 2002-2013 Profox   Terms Of Use  Privacy Statement