Distrubuerad databas

C, C++, Pascal, Assembly, Raspberry, Java, Matlab, Python, BASIC, SQL, PHP, etc.
Användarvisningsbild
AndLi
Inlägg: 17051
Blev medlem: 11 februari 2004, 18:17:59
Ort: Knivsta
Kontakt:

Distrubuerad databas

Inlägg av AndLi »

Om jag ska köra en distrubuerad databas på säg 150 enheter med nån miljon records vad ska jag välja?

Ingen enhet behöver ha hela databasen, varje enhet kör embedded linux med 1gig ram och 1gb flash.

Säg att varje enhet kan generera 100 queries i minuten och 50 uppdates. 98% av uppslagen kommer röra samma poster för en unik enhet. Så en stor vinst skulle göras om dessa poster då såg till att ligga i den lokal enheten. Iof kommer backbonet mellan enheterna vara gigabit eternet...
johano
Inlägg: 1943
Blev medlem: 22 januari 2008, 10:07:45
Ort: Stockholm

Re: Distrubuerad databas

Inlägg av johano »

MongoDB!
Användarvisningsbild
Lennart Aspenryd
Tidigare Lasp
Inlägg: 12607
Blev medlem: 1 juli 2011, 19:09:09
Ort: Helsingborg

Re: Distrubuerad databas

Inlägg av Lennart Aspenryd »

En SQL databas Men frågan är ju hur statisk dessa miljonpostdatabas är!
Om det är mycket statiska så kan man enklare bygga svar. Men skall du skjuta in frågor är det en annan sak.
Jag gillar din frågeställning.

Detta är stora tankar där dygnsuppdatering kan vara lösning, vid ej träff, koll av frågor inom 24h! Hoppas att du förstår hur jag tänker!
Användarvisningsbild
sodjan
EF Sponsor
Inlägg: 43151
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping
Kontakt:

Re: Distrubuerad databas

Inlägg av sodjan »

Jag antar att du vid alla SQL frågor vill ha korrekta svar? Eller är som med Google att "ungefär rätt" är OK?

Vad är det som ska vara "distribuerat"? Lagringen av data (och varför det?)? Applikationerna?

1 miljon poster med 1 byte vardera blir bara 1 MB. Hur stor är datamängden "on disk"?

I princip spelar det ingen större roll om det är 1.000, 1.000.000 eller 100.000.000 poster,
vid unika indexbaserade läsningar och uppdateringar så ska en vettig databas hanterade
det ungefär lika bra. Väldigt mycket beror på hur läsningar och skrivningar är distribuerade.

100 databas frågor per minut från 150 enheter, så 250 frågor/sek. Plus 125 uppdateringar / sek.
En volym som gör att design av databas och frågornas karaktär kommer att vara viktiga.
Är alla frågor och uppdateringar mot enstaka poster eller är det även "range queries"?
Är det transaktioner med den hastigheten 24/7 eller finns den lugna perioder? Är det fixerat
vid ca 1 M poster som bara läses eller uppdateras? Eller skapas det nya poster också?

Om man summerar läsningarna från alla 150 enheter, kommer de då att bli jämnt
spridda över alla ca 1 M poster? Eller är det sannolikt att det är en mindre delmängd
av varje enhets poster som är "heta". Det påverkar eventuell cache i databasen.

Hur viktigt är det att den centrala databasen alltid är up-to-date? Är posterna i databasen
unika per enhet? Alltså ca 6.700 poster per enhet om det fördelas jämt mellan enheterna.
I så fall kan kanske varje enhet ha sin egen lagring av "sina" postar. Kanske med replikering.

Eller för att summera svaret, så ger det knappt att svara på, det "beror på"...
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: Distrubuerad databas

Inlägg av xxargs »

Här är det någon som verka fundera lite före... - skulle vilja se mer av det innan grejorna redan är på plats och det blir ett 'ojdå...'

Höll på säga att det låter nästan som vad man inte funderade på i en viss rätt stort låsprojekt - och jag vet hur det fungerar när man _inte_ tänker i tillräkligt stor skala och kommunikationen är för smalbandig (över RS485 typ) och för få portar från centralsidan och inte kan köra parallellt...

ingen leverantör nämnd men man hamnade i situationen att korttillstånden rullade ut fortare i tiden än uppdateringarna med nya korttillstånden för korten kunde matas ut i anläggningarna och man fick rullande ogiltiga kort för personal som skulle ha tillträde i olika sagda utrymmen på dagligbasis.... - inte helt bra, särskilt inte efter att man tog bort de gamla låscylindrarna helt och satte blindpluggar...

om du redan nu har avsättning för 150 enheter - bygg datahanteringen för minst 10 ggr så många och fundera på hur det hanteras om det blir ännu fler (tex med parallella strömmar) och hur det skall hanteras om datat inte finns lokalt (tex kan anropa central server om frågad data visade sig vara på fel enhet)
Användarvisningsbild
AndLi
Inlägg: 17051
Blev medlem: 11 februari 2004, 18:17:59
Ort: Knivsta
Kontakt:

Re: Distrubuerad databas

Inlägg av AndLi »

Jag skulle säga att posterna är relativt statiska, den data som alla enheter behöver komma åt är vilken "klient" som är ansluten till vilken enhet. De kan förflyttas och kräva en databas uppdatering, men oftast kommer datan vara relativt statisk. Möjligen vill man lagra 3-4 senaste lyckade kommunikationstidpunkt per klienten med.
Många av frågorna kommer röra vilken enhet som har kontakt med en viss klient. Det kan ju även vara trevligt med en loggsystem över händelser i systemet

Det rör sig om ca 1000 klienter (små embedded prylar) per enhet... (Ja det kan alltså bli 150 000 klienter i ett nät)

Jag tror att det är lämpligt att svaret är korrekt, men om svaret blir grannenheten är det sannolikt okej...
Datamängden för den data alla vill komma åt kan nog begränsas till 500-1000 bytes/klient.
Sen är det väl kanske nån megabyte data som mer är av konfigurationskaraktär.

Visionen är att bygga ett server less system där allt är distribuerat mellan de 150 enheterna som alla är likadana.
Krashar en enhet ska informationen om vilka klienter den hade vara lagrade på andra enheters databaser.
Men all information kan återskapas mot en viss energikostand.
Storleksmässig skulle nog varje enhet kunna ha hela databasen...

Jag tror vissa klienters hemenhet kommer efterfrågas oftare, och vissa enheter kommer kommunicera mindre än andra enheter.

>Hur viktigt är det att den centrala databasen alltid är up-to-date? Är posterna i databasen
>unika per enhet? Alltså ca 6.700 poster per enhet om det fördelas jämt mellan enheterna.
Det är inte superviktigt, den går som sagt att återskapa om det skulle visa sig vara fel.
Annars tror jag att

>I så fall kan kanske varje enhet ha sin egen lagring av "sina" postar. Kanske med replikering.
Jag tror det är något sånt jag ser framför mig.

>om du redan nu har avsättning för 150 enheter - bygg datahanteringen för minst 10 ggr så många
Största problemet med att skala upp det är att hela databasen inte ryms på en enhet då, så man behöver ju verkligen en distribuerad databas och inte bara en med komplett replikering.

>MongoDB
Man blev ju glad när man såg MongoDB Stich / Serverless platform. Men det verkar mer vara någon annans server :)
Men möjligheterna ska helt klart undersökas!
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: Distrubuerad databas

Inlägg av xxargs »

MongoDB verkar vara en av favoriterna när det gäller stora databasläckage (alltså dom med många miljoner läckta konton) med användarnamn, passord och email-adresser - så det gäller att få in säkerhetstänket tidigt i systemdesignen - allt som har en minsta chans att kunna attackeras - kommer att attackeras!...
Användarvisningsbild
KLset
Inlägg: 207
Blev medlem: 31 augusti 2014, 17:36:19
Ort: Uppsala

Re: Distrubuerad databas

Inlägg av KLset »

- dqlite
- rqlite

Jag har inte testat någon av dem, men de är baserade på SQLite, och det betraktar jag som ett plus.
guckrum
Inlägg: 1671
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: Distrubuerad databas

Inlägg av guckrum »

Jag är inte riktigt klar över varför du vill distribuera om det nu får plats i enheterna, är det av skalningsskäl?

Hur skall enheterna känna till varandra om "allt" är decentraliserat? Hur kommer nya enheter in? Hur märker systemet att enheter faller från?

Jag hade börjat fundera på loggning. När enheterna är där ute och klarar sig själva vill man ha överblick på läget. Fel i IoT-system kan bli "epidemiska" och svårhanterliga. Det tar orimligt med tid att samla in och manuellt pilla på enheterna. Centrala redundanta logservrar, absolut!

Skall du dela upp databasen bör du räkna på hur mycket redundans du rimligen behöver och hur du säkerställer att redundant data hamnar på fysiskt skilda platser.

Men mycket i implementationen beror nog på applikationen.
Användarvisningsbild
Lennart Aspenryd
Tidigare Lasp
Inlägg: 12607
Blev medlem: 1 juli 2011, 19:09:09
Ort: Helsingborg

Re: Distrubuerad databas

Inlägg av Lennart Aspenryd »

Det finns olika tider i alla serverapplikationer, somliga skall vara primära och allt kan återställas eller säkras vid någon cykeltid!

Fel av mig , jag såg inte förrån nu att det gällde en distrubirad databas Destruktion har jag inte mycket kunspak om!

Förssäkrir mig om att vara fyndig!
Användarvisningsbild
AndLi
Inlägg: 17051
Blev medlem: 11 februari 2004, 18:17:59
Ort: Knivsta
Kontakt:

Re: Distrubuerad databas

Inlägg av AndLi »

Jag vet inte själv om jag är helt på det klara med varför den behöver vara distribuerad, sannolikt pga att känslan av att den totala databasen skulle bli så stor att den inte skulle få plats på en enhet.
Varje enhet behöver ju egentligen bara ha koll på vilka klienter som är ansluten till sig, och kunna svara få frågor från andra vem som har hand om den klienten....

Men denna data vill man ju gärna backupa på någon av de andra enheterna, jag tror det är där tanken om distribuerad kommer in.

De databaser jag tittat på och fått förslag på verkar alla om de kör distribuerat ha all data på alla enheter, och det är inte det jag önskar...

Googlar man embedded database, får man ju inte alls databaser för inbyggda system, utan databaser som man ska ha i sina program...
Användarvisningsbild
sodjan
EF Sponsor
Inlägg: 43151
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping
Kontakt:

Re: Distrubuerad databas

Inlägg av sodjan »

Ja, precis. "Embedded database" betyder oftast att den är inbakad i en applikation.
Inte att den körs på något system av en viss storlek.

> De databaser jag tittat på och fått förslag på verkar alla om de kör distribuerat ha all data på alla enheter,

Nej. Många databaser stöder att datat delas upp på flera system. Men det bygger normalt på att
någon designar det hela utifrån att man i förväg vet hur datat ska delas upp. T.ex. en server
per månad eller något annat liknande sätt att dela det. Som jag tolkar det så vill du att det
hela ska vara helt och hållet dynamiskt, och det är mycket svårare.

> Men denna data vill man ju gärna backupa på någon av de andra enheterna,

Ska "den andra enheten" väljas slumpvis? Eller ska någon konfigurera det hela?

Är antalet enheter och deras "adresser" (hur det nu är definierat) något som
konfigureras i förväg eller är det helt dynamiskt?
Användarvisningsbild
Krille Krokodil
Inlägg: 4062
Blev medlem: 9 december 2005, 22:33:11
Ort: Helsingborg

Re: Distrubuerad databas

Inlägg av Krille Krokodil »

Låter mer som ett typiskt industriellt SCADA-system där man väljer vilken data en enhet ska prenumerera
på och så ombesörjer servern att den datan är aktuell inom de tidsgränser man sätter.

Hade jag tvingats utveckla ett sådant här system från 0 så hade jag koncentrerat mig på SQL i servern, med rätt
strukturer där så behöver inte en enda onödig bit skickas till klienterna.
Användarvisningsbild
Lennart Aspenryd
Tidigare Lasp
Inlägg: 12607
Blev medlem: 1 juli 2011, 19:09:09
Ort: Helsingborg

Re: Distrubuerad databas

Inlägg av Lennart Aspenryd »

Det skulle vara kul att veta mer om vad du vill uppnå!
Just nu, har jag en timme över, mellan kl 02:30 och 02:30 , så skulle man ha ofta i många applikationer. Då skulle man hinna med mycket!
Men ett eller två bollplank och man sätter sig ner och resonerar runt ett scenario är guld värt i din situation!
Synd att öfriga landet ligger så långt bort från källan ;-)
guckrum
Inlägg: 1671
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: Distrubuerad databas

Inlägg av guckrum »

Fundera på om du inte skall överväga centralisering en gång till. Du vill inte ha strul när enheterna är utplacerade. Håll det enkelt, typ.

Annars kolla lite på "distributed hash table", kanske speciellt "consistent hashing". P2P-system är relevant.
Skriv svar