piekuns18 Ierakstīts Oktobris 27, 2015 Share Ierakstīts Oktobris 27, 2015 Sveiki. Tiek plānota datubāze, kura nākotnē varētu saturēt tabulu ar 100 miljoniem ierakstu. pati datubāze saturēs ~10 tabulas Ir doma izvēlēties mysql. Vai tā ir ciešama izvēle vai tomēr izmantot teiksim: postgres,oracle,mssql? Noteikti, ka mssql un oracle ir daudz jaudīgākas, bet vai uz tik lielu ierakstu skaitu ir kāda acīmredzama atšķirība datu ieguves laika ziņā? varbūt kāds ir kaut ko tamlīdzīgu testējis savā praksē? Link to comment Share on other sites More sharing options...
usver Oktobris 27, 2015 Share Oktobris 27, 2015 10 tabulas - baigi maz. Kaut kāda pavisam primitīva veblapiņa izklausās. Praksē uzskaites sistēmas mierīgi iebrauc 50..100..150 tabulās, kad apaug ar vajadzībām. Kolēģi daudziem miljardiem ierakstu faktiski real-time portālam izmantoja TokuDB iekš MariaDB un paralēli Redis. Nodalot, ko tad īsti vajag glabāt relācijās un ko - kā key/value ierakstus. Protams, ka bija šārdošanās visu laiku. Protams, ka bija māsteri/sleivi klāsterī. Nebija tā, ka iestum visu vienā lielā tabulā un ceri uz 0.0001ms garantētiem rezultātiem uz 5400rpm cietņa pie 100mio ierakstiem un 512MB RAM patēriņa un 1000 vienlaicīgiem klientiem. Bet uz Oracle/MSSQL pat netaisās pāriet, laimīgi dzīvo, bremžu nav. Link to comment Share on other sites More sharing options...
Eric Oktobris 27, 2015 Share Oktobris 27, 2015 Ierakstu skaitam db izvēlē nav lielas nozīmes. Svarīgi ir tas, ko ar tiem ierakstiem Tu taisies darīt. Pilno pārlasi miljons ierakstiem apmēram vienādi ilgi veiks visas DB Oracle ir ļoti dārgs risinājums, bet ļaus taisīt visādus trikus ar pieejamību, slodzes dalīšanu, backupiem, kriptēšanu, monitorēšanu, administrēšanu utt. Ja sistēmā vēl nav neviena ieraksta, tad izvēlies mysql/postgre. Kad būsi sasniedzis griestus, domāsi, kur migrēt. Link to comment Share on other sites More sharing options...
Ronalds Oktobris 27, 2015 Share Oktobris 27, 2015 Oracle ir daži ļoti debili ierobežojumi, kuri pamatīgi traucē normālas db izstrādei. Link to comment Share on other sites More sharing options...
Bruketajs Oktobris 27, 2015 Share Oktobris 27, 2015 +1 par atvērtā koda risinājumu - postgres, mysql, firebird. 1 Link to comment Share on other sites More sharing options...
MIGs Oktobris 27, 2015 Share Oktobris 27, 2015 MySQL Vai Postgres ! Postgress ir ritīgi powerfull datubāze ! Nevajag Firebird - nav neviena jēdzīga iemeslu to izvēlēties. Man ir pieredze ko par mazu nenosauksi - nepatīk, nesaskatu nevienu plusu. Oracle vispaŗ ir kaut kāds arhaisms un samurgojums. Vienkāršas lietas jādara caur pēcpusi un brīžiem neatbalsta pašsaprotamas lietas. MSSQL navv slikta bāze, bet atkal jau nav īsti neviena iemesla izvēlēties to nevis PostgreSQL. J nu vineīgi ciešāka savietojamība ar M$ vidēm, bet arī ar Postgresu un MySQL neesmu novērojis savietojamības problēmas. PostgreSQL ir dikti laba, spēcīga un bez maksas, ko nevarētu tiekt par MSSQL un Oracle. Link to comment Share on other sites More sharing options...
Biete Oktobris 27, 2015 Share Oktobris 27, 2015 Kas Oracle ir par tādiem ierobežojumiem, ja neskaita $$$? mysql LIMIT utml? Link to comment Share on other sites More sharing options...
Ronalds Oktobris 27, 2015 Share Oktobris 27, 2015 Man visvairāk besī šis: https://www.google.lv/search?q=oracle+mutating+table+error&oq=oracle+mut&aqs=chrome.3.69i57j0l5.7318j0j4&sourceid=chrome&es_sm=122&ie=UTF-8 Tas pamatīgi ierobežo trigeru izmantošanu. Link to comment Share on other sites More sharing options...
MIGs Oktobris 27, 2015 Share Oktobris 27, 2015 Oracle pieturas pie ideoloģijas, ka jo sarežģītāks produkts, jo vairāk varēs nopelnīt uz supportu un apmaācībām. Iespējams tieši tāpēc nav visādu ērtu komandu/šortkutu, kā show databases; show tables,create db LIMT, utt. Es protams saprotu, ka īsti vīri skujas ar cirvi vai vismaz sasistu alus pudeli, bet nu tomēr... Un to saku es, kā cilvēks kurš Unix-like shelā jūtas tīri labi un nealkst lai visur būt Click-Click. Tas, ka softs ir sarežģīts to nepadara par baigo kvalitātes etalonu - taisni otrādāk. Jā, mana Oracle pieredze un zināšanas varētu būt lielāka. Taču nav arī tā, ka neko no viņas nemāku. Ir kāds brītiņš mazāku sistēmu un ir viena sirsnīgi liela DB uz ~7TB(Tur tiek glabāti arī BLOBi, tāpēc tik drastisks izmērs). Tur gan ne visu daru es viens. Jā man pat uz 1TB neviena Postgres bāze nav. Nevaru pateikt, kā perfomētu Postgres. Taču ar Oracle NEĒRTUMU es saskaros ik dienas, ik uz soļa. No saviem koderiem es arī nedzirdu labus vārdus par Oracle. Link to comment Share on other sites More sharing options...
HTC Oktobris 27, 2015 Share Oktobris 27, 2015 (labots) ronalds, katram savas problēmas, pats tagad uz mysql domāju risināt Deadlock situāciju ^_^ Labots Oktobris 27, 2015 - HTC Link to comment Share on other sites More sharing options...
zeds Oktobris 27, 2015 Share Oktobris 27, 2015 100 milj ierakstu nav pārāk liela DB. beigu beigās viss reducēsies uz roku taisnību un galvas skaidrumu, nav nozīmes kāda DB. Ja Tu plāno visus 100milj vienkārši sagrūst vienā lielā tabulā, tas gan jau ir ceļš uz elli. visticamāk. Kas attiecas uz oracle - viņu alkatība ir neaprakstāma un kā jau biedrs MIG teica - nekāds kvalitātes etalons tas vairs sen nav. Par licencēšanu - ieliekot VM VMWARE poolā vajag pirkt licenci uz visiem virtualizācijas hostiem pa pilno uz visiem CPU. Vispār daudzos lielajos kantoros cilvēki ir sākuši strādāt lai no oracle atkratītos vai vismaz radikāli samazinātu viņa lietošanu - tas prasīs iespējams 10 un vairāk gadus, bet process ir sācies. Link to comment Share on other sites More sharing options...
rubb Oktobris 27, 2015 Share Oktobris 27, 2015 (labots) Emm.. laikam būšu minoritāte. Oracle maksā par suportu. Pati DB nemaksā īpaši dārgāk par MSSQL tādam pašam pielietojumam. Oracle lielais pluss - normāli debugojama servera puse, nav bremzes situācijās, kad MSSQL ir vienkārši PĪ. Oracle neļauj darīt daudzas lietas... tikai tāpēc, ka projektētājs ir kaut ko salietojies un tas pēc būtības NEDRĪKST darboties. Toties MSSQL viss darbojas, tikai lēēēēēni... MSSQL pat mūsdienās Servera puses debugošana ir bērnu autiņos. Tieši tāpat kā lietas, ko Netware piedāvā jau seeen, jaunie Win servaki vēl mocās. Ja kas, jo nopietnāks risinājums, jo vairāk prasās lietot servera puses fīčas. Ar Oracle un MSSQL pieredze > 20 gadi... Any way, tēmā aprakstītajai DB derēs arī opensorcīgie varianti, par kuriem biedri jau iepriekš minēja Labots Oktobris 27, 2015 - rubb Link to comment Share on other sites More sharing options...
b25 Oktobris 27, 2015 Share Oktobris 27, 2015 Tai DB kāda noslodze plānota? Dienā cik ierakstu/ nolasīšanu, trafika apjoms. Link to comment Share on other sites More sharing options...
Biete Oktobris 27, 2015 Share Oktobris 27, 2015 Skaidrs par Oracle nepilnībām, nebiju lidz šim to baigi uztvēris kā trūkumus. Man kā orāklistam citās DB atkal kaut kas cits liekas neērti/nepatīk utt, bet nu tas gan jau vairāk pieraduma jautājums. Un velns nav tik melns kā viņu mālē arī $$$ ziņā... Anyway vienalga nestādos priekšā kā ar opensource risinājumiem var uzturēt biznesam svarīgas sistēmas gadījumā, ja kaut kas notiek ar pašu DB - Oracle gadījumā supports pa tiešo no softa izstrādātāja (protams vēl jautājums vai kaut ko atrisinās sapratīgā laikā), bet kam prasīt atbildību postgresql gadījumā Bet nu labi - gan jau var dabūt komerciālu suportu arī tur, jautājums tikai cik maksā un kādi nosacījumi. Par tēmu un offtopic reizē - neviens nav pieminējis NoSQL 1 Link to comment Share on other sites More sharing options...
MIGs Oktobris 27, 2015 Share Oktobris 27, 2015 Supports tāpat neaizvietos, ne stabilus dzelžus, ne rezerves kopijas. Tāpat supports, visticamāk, neribēs čakarēties ar softu/aplikāciju piešķilšanu uz jaunākas Oracle versijas un citas līdzīgas bēdas. Tur būs jāmokās pašam, vai jau atkal, kaut kas stipri astranomisks jāmaksā. Ir daudz dzirdēts viedoklis, ka OpenSource produkti nav izmantojami, jo redzi tur aizmugurē nav supports un nav kam paprašit atbildību. Tak izlasiet licenzes līgumus - neviens, nekad, neparko nenes atbildību ! Katrā ziņā par Oracle man bija vismaz 10 reizes labāks iespaids, pirms es ar to sāku ņemties. Par ērtumu - nu Oracle defaultā komandriunda(Shells) man liekas neērtēks par Postgresa. Postgresam tur viss ir ļoti eleganti un ērti nostrādāts. Link to comment Share on other sites More sharing options...
Ronalds Oktobris 28, 2015 Share Oktobris 28, 2015 nebiju lidz šim to baigi uztvēris kā trūkumus. Piemēri no manas prakses - vajag rēķina rindas numurēt, lai varētu viņas sakārtot vēlamajā secībā. Citās db iekš trigera before post tabulai REKINI_PRECES IF NEW.NPK IS NULL THEN SELECT MAX(NPK)+10 INTO :NEW.NPK FROM REKINI_PRECES WERE REKINS_ID=:NEW.REKINS_ID Viss! Viena rinda! Oraclem - mutating table error - jātaisa satment limeņa trigeri, papildus pagaidu tabulas, beigās ļoti sarežģīts un nepārskatāms kods sanāk.... Nākošais. Kā izrādās oracle foreign key nenozīmē ka tiks automātiski indekss uztaisīts! Grūti iedomāties kāpēc tā, jo pēc sql loģikas kur foreign key, tur vajag indeksu. Bet nu labi, pieņemsim.... Pats smieklīgākais ir, ka db nestrādā normāli ar vairāk kā vienu lietotāju, ja ir fk bez indeksiem! Viens useris sāk labot rēķinu, sākas tranzakcija. Kamēr viņš tranzakciju nav pabeidzis, jebkurš citas tranzakcjas update ar rēķiniem saistītās tabulās gaida kamēr pirmā tranzakcija tiks pabeigta - vienkārši gaida, ne kļūdas paziņojumu, ne timeoutu! Ja viens useris attaisa iekš gui kādu rēķinu uz labošanu un aiziet pusdienās - visam ofisam darbs apstājas! Sataisot bāzē visiem fk indeksus šis efekts pazūd! Un vēl ir kaudze ar kaitinošiem sīkumiem, kas mākslīgi sarežģī kodu, padara to nelasāmu... Link to comment Share on other sites More sharing options...
Jeasus Oktobris 28, 2015 Share Oktobris 28, 2015 Postgres arī netaisa indeksu uz fk Link to comment Share on other sites More sharing options...
Mezavecis Oktobris 28, 2015 Share Oktobris 28, 2015 Vispār DB izvēli balstīt uz ierakstu skaitu nav objektīvi. Arī tajā pašā MySQL var būt miljardiem ierakstu un nekas nebremzēs, ja neko sevišķu ar šo tabulu nedara. Protams, ja vajadzēs full-text search, blobos pēc bildes atpazīt cilvēku, lietot trigerus, taisīt lielus reportus, meklēt saistītajās tabulās, kur vismaz 100 kolonnas, tad izvēle var būt izdevīgāka citā virzienā. 1 Link to comment Share on other sites More sharing options...
usver Oktobris 28, 2015 Share Oktobris 28, 2015 (labots) Par tēmu un offtopic reizē - neviens nav pieminējis NoSQL ja? starp citu, šitos noskaties tīri redzesloka paplašināšanai. sākot no 15:50 statistika un pielietojumu apspriešana. un Labots Oktobris 28, 2015 - usver Link to comment Share on other sites More sharing options...
Eric Oktobris 28, 2015 Share Oktobris 28, 2015 Autors tā arī nav pateicis, ko taisās tajā db glabāt un ko ar datiem iesākt. Var gadīties, ka labākais risinājums ir parasts teksta fails Bez fīčām, cenas un performances vēl ir vērts apdomāt esošo cilvēku zināšanas. Ja nav speciālu apsvērumu, jāizmanto, tas kas ir vispazīstamākais. Tad nebūs ieberzienu ar zemūdens akmeņiem neprasmīgi lietojot kaut kādu pārāko tehnoloģiju. Link to comment Share on other sites More sharing options...
Biete Oktobris 28, 2015 Share Oktobris 28, 2015 (labots) Es +- zinu NoSQL spēcīgās un vājās puses. Tas komentārs bija tāds tāpēc, ka pirmajā postā autors prasīja relāciju DB, bet iespējams to nemaz nevajag... Par pārējo - jā, Oracle ir mīnusi, bet tāpat taču ir arī citām DB. Un lielākā daļa mīnusu tāpat ir pieraduma jautājums, pārejot no citas DB. Labots Oktobris 28, 2015 - Biete Link to comment Share on other sites More sharing options...
piekuns18 Oktobris 28, 2015 Author Share Oktobris 28, 2015 Nu man principā vajadzēja zināt vai ir jēga ņemt Oracle vai MS SQL. Katru dienu pa nakti notiks DB iztīrīšana un pāris miljonu ierakstu imports. Ar kuriem pēctam vajadzēts taisīt dažādus pārskatus iekš web. Paldies par atbildēm izskatās, ka ar MySQL nebūs nekādu problēmu. Link to comment Share on other sites More sharing options...
HTC Oktobris 28, 2015 Share Oktobris 28, 2015 (labots) Katru dienu pa nakti notiks DB iztīrīšana un pāris miljonu ierakstu imports. Nu a kā imports notiksies? Tīrs insert vai tomēr insert un ja eksistē tad updeito esošo / dzēš lieko? No kurienes tiks veikts imports? Imports tiks veikts vienā tabulā vai vairākās un tās sajūgtas ar keyiem? Varbūt tomēr tiešām pārskatiem apstrādāt tikai failus, vai datubāzē saglabāt to informāciju, kas būs pārskatā? Nevienā pašā brīdī neesi norādījis neko, kas būtu vajadzīgs, lai izvēlētos pareizāko risinājumu. Šķiet, ka tomēr vajadzētu padalīties ar vairāk informācijas nekā "100 miljoni ierakstu" Jebkurā gadījumā - pareizākais risinājums būs tas ko pats vislabāk pārzini (ja pats taisies taisīt) Pēc pašreizējās info, sanāk moments: gribu dārgu auto, tur tiks ielieti 60L degvielas, ko iesakat. Ā, tomēr arī var piedāvāt bezmaksas auto... Labots Oktobris 28, 2015 - HTC Link to comment Share on other sites More sharing options...
piekuns18 Oktobris 28, 2015 Author Share Oktobris 28, 2015 (labots) Katru dienu pa nakti notiks DB iztīrīšana un pāris miljonu ierakstu imports. Nu a kā imports notiksies? Tīrs insert vai tomēr insert un ja eksistē tad updeito esošo / dzēš lieko? No kurienes tiks veikts imports? Imports tiks veikts vienā tabulā vai vairākās un tās sajūgtas ar keyiem? Varbūt tomēr tiešām pārskatiem apstrādāt tikai failus, vai datubāzē saglabāt to informāciju, kas būs pārskatā? Nevienā pašā brīdī neesi norādījis neko, kas būtu vajadzīgs, lai izvēlētos pareizāko risinājumu vajadzētu padalīties ar vairāk informācijas nekā "100 miljoni ierakstu" ķipa tavi nosauktie lielumi ir no savra izvēloties DB? Man pēc komentāru sniegtajām atbildēm radās iespaids, ka DB izvēle ir svarīgāka pie daudz nopietnākām sistēmām un lietojumiem. + Es vispār aprakstiju, kā notiksies darbība iepriekšējā komentārā. Es neko par update un dzēšanu neminēju, ne tā?. Arī cik tabulas būs es rakstiju. Nu ja tev kaut kas vēl nav skaidrs. Droši jautā. Labots Oktobris 28, 2015 - piekuns18 Link to comment Share on other sites More sharing options...
HTC Oktobris 28, 2015 Share Oktobris 28, 2015 "Es neko par update un dzēšanu neminēju, ne tā?" Tu arī neminēji, ka 100 miljonu rowu imports un datu sagatavošana pārskatiem notiks reizi naktī līdz ar to uzskatīju, ka izlaidis esi arī `update`, tāpat arī neesi minējies aptuveni ar cik gb lieliem datiem nāksies strādāt, vai tie būs 5Gb vai 50Gb ko importēt per night, eksistē arī interesanti limiti atkarībā no os,db veida. Lai vai kā - veiksmi projektā. Link to comment Share on other sites More sharing options...
Livingston Oktobris 28, 2015 Share Oktobris 28, 2015 100m ierakstu? Cik liels būs ieraksts? 80 baiti vai 200k ? Par Oracle trūkumiem - nu ja kādam svarīgāk ir iespēja ierakstīt "show db", nekā iegūt normālu ātrdarbību operējot ar vairākām tabulām, tas ir prioritāšu jautājums Starp citu, par godu MySQL faniem Oracle jau kādu laiku arī atbalsta LIMIT selektos. Ja paredzams, ka dati ielīdīs 11GB datu bāzē, tad visiem iesaku izmantot bezmaksas Oracle XE versiju. P.S. ja importējamie dati ir CSV vai kaut kas tamlīdzīgs (visticamākais, ka ir), tad tos vispār nevajag importēt - taisa external table uz CSV failiem, veic analīzi, rezultātus ilgstošai uzglabāšanai saglabā normālā DB un nodropo external tables. Importēšana, kam seko dzēšana būtu lieka laika tērēšana. Link to comment Share on other sites More sharing options...
Ronalds Oktobris 28, 2015 Share Oktobris 28, 2015 nekā iegūt normālu ātrdarbību operējot ar vairākām tabulām Cik ir strādāts ar dažādām DB, tad dramatiskas ātrdarbības atšķirības nemanīju! Es runāju par to, ka oracle ir kaudze ar vēsturiski iegājušām nepilnībām, kas pamatīgi traucē! Tas pats trigeru izmantošanas ierobežojums, jeb mutating table error jau pats par sevi ir ko vērts! Uzskatu ka šis ir pilnībā pietiekams iemesls, lai oracli atmestu kā šķiru jebkuram jaunam projektam! tad visiem iesaku izmantot bezmaksas Oracle XE versiju Aha - izmanto tikai vienu kori un 1GB ram - tiešām lietojami īpaši pie lielām bāzēm :D ! Link to comment Share on other sites More sharing options...
Livingston Oktobris 28, 2015 Share Oktobris 28, 2015 Cik ir strādāts ar dažādām DB, tad dramatiskas ātrdarbības atšķirības nemanīju! Es runāju par to, ka oracle ir kaudze ar vēsturiski iegājušām nepilnībām, kas pamatīgi traucē! Tas pats trigeru izmantošanas ierobežojums, jeb mutating table error jau pats par sevi ir ko vērts! Uzskatu ka šis ir pilnībā pietiekams iemesls, lai oracli atmestu kā šķiru jebkuram jaunam projektam! Tā nav nepilnība pati par sevi, bet gan situācija, kurā var nonākt, ja īpašā veidā tiek izmantoti Oracle trigeri. Daudzās citās datu bāzēs situāciju nevar atkārtot, jo ir pārāk daudz ierobežojumu uz trigeru izmantošanu. Aha - izmanto tikai vienu kori un 1GB ram - tiešām lietojami īpaši pie lielām bāzēm ! Šis ierobežojums ir TIKAI Orace XE BEZMAKSAS versijai, kam arī lietotāju datu apjoms ir ierobežots līdz 11GB. Pats esmu daudzus gadus strādājis ar daudzu terabaitu datu bāzēm, tagad ir desmitiem klientu ar simtiem GB un TB DB un visas tās ir Oracle datu bāzes kur uz tabulām ir daudz trigeru un kurās realizēta sarežģīta loģika. Dramatisku atšķirību ātrdarbībā nevar redzēt tikai tad, ja bāzes ir mazas un pieprasījumi triviāli. Link to comment Share on other sites More sharing options...
japets Oktobris 28, 2015 Share Oktobris 28, 2015 Dinamiski pārskati? Statiski? 2. gadījumā db nav vajadzīgs vispār. Link to comment Share on other sites More sharing options...
piekuns18 Oktobris 28, 2015 Author Share Oktobris 28, 2015 (labots) P.S. ja importējamie dati ir CSV vai kaut kas tamlīdzīgs (visticamākais, ka ir), tad tos vispār nevajag importēt - taisa external table uz CSV failiem, veic analīzi, rezultātus ilgstošai uzglabāšanai saglabā normālā DB un nodropo external tables. Importēšana, kam seko dzēšana būtu lieka laika tērēšana. Nē. Plānots, ka dati tiek iegūti no vairāk kā 70 ar vienādu struktūru firebird DB un tiek kopā likti vienā db ar vajadzīgajiem laukiem un tabulām nepazaudējot piederību. Tagad to mēģinu darīt iekš mysql ar PDO taisu multiple insert. No sākuma iet raiti ir ok. Bet kā tabulas aug, tā multiple insert paliek lēnāks un lēnāks.... Kādam varbūt ir kāds ieteikums kā to paātrināt. es pāris veidus jau pamēģināju(transaction, konkrētu vajadzīgo lauku daydzums, not null noņēmu, tikai indeksi kur vajag, taisu ne vairāk kā 500 vienā insert, saliku tipus ar nepieciešamo garuma ierobežojumu), bet varbūt ir kas tāds, ko es varu vēl izdarīt? Iekš mysql konfigurācijas? Dinamiski pārskati? Statiski? Būs dinamiski. Principā visas 10 tabulas tiek sadžoinotas. Un Lielotājam iespēja filtrēt dažādos griezumos. Labots Oktobris 28, 2015 - piekuns18 Link to comment Share on other sites More sharing options...
Eric Oktobris 28, 2015 Share Oktobris 28, 2015 Tas ko aprakstiji ir data warehouse.. Ja jau tikai reportings, tad varbūt var piemeklēt kādu gatavu risinājumu? par ielādi: https://dev.mysql.com/doc/refman/5.6/en/optimizing-innodb-bulk-data-loading.html Link to comment Share on other sites More sharing options...
Ronalds Oktobris 28, 2015 Share Oktobris 28, 2015 (labots) Plānots, ka dati tiek iegūti no vairāk kā 70 ar vienādu struktūru firebird DB un tiek kopā likti vienā db ar vajadzīgajiem laukiem un tabulām nepazaudējot piederību. Šajā gadījumā vismaz es šo problēmu risinātu izmantojot firebird replikācijas. Vai nu pats programmētu, vai ko no šī mēģinātu piemērot http://www.firebirdfaq.org/faq249/ Taisītu vienu kopīgu firebird datu bāzi, uz lokālajām atsekotu izmaiņas un replicētu viņas uz centrālo bāzi. Ideja ka pa nakti visu nodzēšam un importējam par jaunu nav pareiza šajā gadījumā. Principā risinājums elementārs - papildinām vajadzīgās tabulas ar trigeri, kas papildus laukā ieraksta modifikācijas laiku. Vēl papildus lauks DB instances ID. Atlasam visus ierakstus, kas modificēti pēc pēdējās replikācijas. Izdzēšam viņus no galvenās db pēc instances + ieraksta ID un pārkopējam jaunos ierakstus no filiāles db uz galveno. Easy Labots Oktobris 28, 2015 - ronalds_ Link to comment Share on other sites More sharing options...
piekuns18 Oktobris 28, 2015 Author Share Oktobris 28, 2015 Šajā gadījumā vismaz es šo problēmu risinātu izmantojot firebird replikācijas. Vai nu pats programmētu, vai ko no šī mēģinātu piemērot dēēmmm. Būs jāpaskatās. nezināju nemaz par ko tādu. Laikam būs te biežāk jāuzdod jautājumi Paldies. Principā risinājums elementārs - papildinām vajadzīgās tabulas ar trigeri, kas papildus laukā ieraksta modifikācijas laiku. Vēl papildus lauks DB instances ID. Atlasam visus ierakstus, kas modificēti pēc pēdējās replikācijas. Izdzēšam viņus no galvenās db pēc instances + ieraksta ID un pārkopējam jaunos ierakstus no filiāles db uz galveno. Easy Nu painteresēšos. Izklausās jau labs risinājums , bet nezinu vai varu tur kaut ko čakarēt, jo tā nav mana db vai iepriekšēja programmētāja db, bet gan sistēmas db, ko izmantojam par maksu. Link to comment Share on other sites More sharing options...
Bruketajs Oktobris 28, 2015 Share Oktobris 28, 2015 Ideja ka pa nakti visu nodzēšam un importējam par jaunu nav pareiza šajā gadījumā. Sevišķi tāpēc, ka tas var kādreiz vienkārši nenotikt, jo.... vienkārši var nenotikt un ko tad?... +1 par Firebird. Katram ir sava pieredze, bet es ar FB ņemos vēl kopš Interbase laikiem un nav nekas īpašs atgadījies, ja neskaita paša, uz tās bāzes strādājošā, softa brīnumus, bet tas jau ir ieviešanas jautājums. Link to comment Share on other sites More sharing options...
Ronalds Oktobris 28, 2015 Share Oktobris 28, 2015 (labots) , bet nezinu vai varu tur kaut ko čakarēt Pieliekot papildus lauku un papildus trigeri - tas nekādi neietekmēs esošās sistēmas darbību! Bet bez datiem par ierakstu mainīšanu nekādi replikācija nesanāks. Tā kā datu apjoms ievērojams, tad bez replikācijas nez vai sanāks visu vienā bāzē atskaitēm salikt. Vienīgais pie sistēmas updeitiem var būt problēmas - var tikt jaunie lauku un trigeri nodzēsti un pazust dati par replikāciju. Tāpēc potenciāli vajadzēs skriptu, kas visu atliek atpakaļ. Bet parasti normālas sistēmās tiek pierakstīts, kad mainīti dati, piemēram rēķini. Tā kā potenciāli varbūt neko pievienot nevajag. Labots Oktobris 28, 2015 - ronalds_ Link to comment Share on other sites More sharing options...
Jeasus Oktobris 28, 2015 Share Oktobris 28, 2015 No sākuma iet raiti ir ok. Bet kā tabulas aug, tā multiple insert paliek lēnāks un lēnāks.... Kādam varbūt ir kāds ieteikums kā to paātrināt. Inserti paliek lēnāki jo, ja tabulai ir indeksi, tad tie ir jāpārrēķina. Risinājums, drop indexus, iztira db, piepilda db, create index. Link to comment Share on other sites More sharing options...
Livingston Oktobris 28, 2015 Share Oktobris 28, 2015 Pieliekot papildus lauku un papildus trigeri - tas nekādi neietekmēs esošās sistēmas darbību! Kā papildus lauks var neietekmēt esošās sistēmas darbu? Ja esošajā sistēmā ir forma vai atskaite, ar "select * from tabula" ? Trigeris arī rada nelielu overhead, bet ar to vieglāk sadzīvot. Link to comment Share on other sites More sharing options...
Bruketajs Oktobris 28, 2015 Share Oktobris 28, 2015 Risinājums, drop indexus, iztira db, piepilda db, create index. Firebirdam to lieliski paveic bak-rest process, bet jānoliek bāze offlainā... Link to comment Share on other sites More sharing options...
Ronalds Oktobris 28, 2015 Share Oktobris 28, 2015 (labots) Ja esošajā sistēmā ir forma vai atskaite, ar "select * from tabula" ? Ja GUI ir iekš delphi rakstīts - 100% neietekmēs, citās vidēs arī nē, cik zinu! Bet šo takš var elementāri notestēt! Cik zinu firebirdam vienīgā vieta kur var būt problēmas ir stored procedūra/trigers, kur ir SELECT * FROM TABLE1 INTO :VAR1,:VAR2,:VAR3 Te gan neies, bet šāda veida pieprasījumus rakstīt ir galīgi slikts stils un vismaz es šāda veida pieprasījumus NEKAD neizmantoju! Ja nu testējot tomēr noskaidrojas ka jaunu lauku nevar, tad taisam papildus tabulu ar diviem laukiem - id un datums. Un glabājam labošanas laiku papildus tabulā. Labots Oktobris 28, 2015 - ronalds_ Link to comment Share on other sites More sharing options...
Livingston Oktobris 28, 2015 Share Oktobris 28, 2015 Visu var notestēt, es tikai iesaku nepārsteigties ar secinājumiem, ka elementāra izmaiņa neko neietekmē Link to comment Share on other sites More sharing options...
Recommended Posts
Izveido kontu, vai pieraksties esošajā, lai komentētu
Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas
Izveidot jaunu kontu
Piereģistrējies un izveido jaunu kontu, tas būs viegli!
Reģistrēt jaunu kontuPierakstīties
Jums jau ir konts? Pierakstieties tajā šeit!
Pierakstīties tagad!