Opslaan grote hoeveelheid berichten

[Erapaz]

Stel ik wil een grote hoeveelheid berichten (miljarden) betrouwbaar opslaan voor langere tijd, wat voor oplossingen zijn hier dan voor beschikbaar?

Enkele requirements:

• De volgorde van de berichten is belangrijk, dit kan eventueel met een sequence nummer die meteen de key is.
• Het gaat vooral om opslag, incidenteel moet een reeks berichten kunnen worden teruggehaald uit de store.
• De aanvoer is ongeveer 50 m/s
• Berichten zijn klein ( < 1 MB)
• Berichten mogen niet verloren gaan

De meeste messaging oplossingen zijn queue producten. Een queue is echter volgens mij geen goede oplossing. Ik wil namelijk de berichten bewaren en niet doorsturen. Daarnaast bestaan de berichten uit honderden groepen die per groep vanaf een bepaald bericht moeten kunnen worden opgehaald. Met een queue oplossing zou je dan per groep een queue krijgen.

Zelf zat ik te denken aan een key-value store die de opslag op het filesystem doet, bestaande uit meerdere nodes die onderling gesynchroniseerd worden.

Enkele kandidaten:
• LevelDB, geschreven door google. Ik weet alleen niet of deze uit meerdere nodes op te bouwen is
• Een van de Hadoop databases (HBase?), hoewel dit misschien overkill is in features
• Kafka, van LinkedIn, toch een queueing product, wel specifiek geschikt voor veel berichten op verschillende nodes (in combinatie met zookeeper)

Denk ik in de goede richting? Zijn er andere oplossingen of producten?

[mrwiggs]

Ik heb wat gewerkt met CouchDB en dat werkt erg goed. Is geen key-value store maar een document store, en jouw berichten kunnen denk ik goed als documenten gezien worden. Kijk ook eens naar Couchbase, is gebouwd op CouchDB, heel gemakkelijk op te zetten en ondersteunt ook sharding (beide geldt ook voor CouchDB). Overigens komt CouchDB 2 er ook aan en die blijkt ook gaaf te worden. Ze slikken ook allebei direct multidimensionale JSONs wat erg makkelijk werkt.

[ Voor 24% gewijzigd door mrwiggs op 15-11-2014 10:52 ]

[Snow_King]

ElasticSearch? Is ook makkelijk te schalen met meerdere machines en is echt bizar snel.

[Erapaz]

CouchDB is een goede tip. Inmiddels heb ik ook nog Berkeley DB gevonden als optie.

ElasticSearch is meer voor het indexeren en zoeken van grote hoeveelheden data.
Ik ben totaal niet geïnteresseerd in de berichtinhoud. Het gaat om XML, maar het mag ook binary worden opgeslagen. Zolang ik een volgordelijkheid kan bijhouden en hiermee de berichten kan ophalen, is het goed. Het gaat dus niet om dataverwerking, maar puur om opslag en het opnieuw aan kunnen bieden van een serie berichten.
Belangrijke functionaliteiten zijn dus replicatie en recovery. Daarnaast moeten berichten niet verloren gaan als ze eenmaal door de message store geaccepteerd zijn.

[HMS]

Een paar vragen:

Wat is langere tijd in deze context? Jaren?
Op welk OS / platform moet dit draaien?
Is de inhoud van de berichten confidentieel?
Willen jullie zelf de infrastructuur beheren, of mag cloud ook?

[mrwiggs]

Als het echt om 1 binary value gaat en 1 opvolgende primary key heeft is misschien een key-value store als Redis beter geschikt. Maar ik zou toch overwegen de XML naat JSON om te zetten en in bijv. CouchDB te zetten, wellicht wil je namelijk later nog wel queries uitvoeren op losse velden.

[ Voor 41% gewijzigd door mrwiggs op 15-11-2014 12:00 ]

[HuHu]

Tekstbestanden wegschrijven op een harde schijf. 1.txt, 2.txt, 3.txt, enzovoorts... Mapjes per "groep".

Het voldoet aan alle requirements . De OP is niet compleet genoeg om een beter antwoord te geven.

[ Voor 24% gewijzigd door HuHu op 15-11-2014 12:09 ]

[Erapaz]

HuHu schreef op zaterdag 15 november 2014 @ 12:07:
Tekstbestanden wegschrijven op een harde schijf. 1.txt, 2.txt, 3.txt, enzovoorts...

Het voldoet aan alle requirements .

Dit is een hele goede opmerking en was ook mijn eerste ingeving. Zie ook deze post op stackoverflow: http://stackoverflow.com/...k-based-key-value-storage

De filesystem oplossing is dan verantwoordelijk voor de replicatie en beschikbaarheid. Een SAN oplossing met backup zou dan misschien al voldoen?

HMS schreef op zaterdag 15 november 2014 @ 11:55:
Een paar vragen:

Wat is langere tijd in deze context? Jaren?
Op welk OS / platform moet dit draaien?
Is de inhoud van de berichten confidentieel?
Willen jullie zelf de infrastructuur beheren, of mag cloud ook?

Langere tijd is enkele maanden
Linux
Inhoud is confidentieel
Het is een uitbreiding op een bestaande infrastructuur die zelf beheerd wordt.

[Salmon]

Inderdaad een nosql database waar je naar kan gaan kijken, deze hebben ook replicatie

[Gomez12]

HuHu schreef op zaterdag 15 november 2014 @ 12:07:
Tekstbestanden wegschrijven op een harde schijf. 1.txt, 2.txt, 3.txt, enzovoorts... Mapjes per "groep".

Het voldoet aan alle requirements . De OP is niet compleet genoeg om een beter antwoord te geven.

Dit, dit is imho het enige wat op langere termijn goed blijft.

Dan kan je desnoods nog een key-value store ernaast zetten die weer de tekstbestanden inleest en beschikbaar maakt, maar je storage op zichzelf zou ik zo simplistisch mogelijk doen.

Wie weet of een bepaalde NoSQL-db over 10 jaar nog supported is, tekstbestanden blijven altijd supported.
Ik zou er niet op zitten te wachten om mijn storagemanier elke x jaar opnieuw te moeten updaten omdat er een nieuwe versie is die net even wat anders werkt of net even een bug heeft waardoor je een paar uur messages corrupt krijgt.

Als ik het goed inschat dan krijg je 50m/s van een derde partij, dus downtime kan je niet hebben want dan mis je messages (en nieuwe versie van x/y is altijd downtime). En als het je voornamelijk om storage gaat houd het dan zo simpel mogelijk en bouw je rapportage naast je storage.

Dan bevat je storage alles, je rapportage kan wat dingen missen met downtime, maar dan is het missende gedeelte weer opnieuw op te bouwen uit storage.

[Erapaz]

Gomez12 schreef op zaterdag 15 november 2014 @ 15:13:
[...]

Dit, dit is imho het enige wat op langere termijn goed blijft.

Dan kan je desnoods nog een key-value store ernaast zetten die weer de tekstbestanden inleest en beschikbaar maakt, maar je storage op zichzelf zou ik zo simplistisch mogelijk doen.

Wie weet of een bepaalde NoSQL-db over 10 jaar nog supported is, tekstbestanden blijven altijd supported.
Ik zou er niet op zitten te wachten om mijn storagemanier elke x jaar opnieuw te moeten updaten omdat er een nieuwe versie is die net even wat anders werkt of net even een bug heeft waardoor je een paar uur messages corrupt krijgt.

Als ik het goed inschat dan krijg je 50m/s van een derde partij, dus downtime kan je niet hebben want dan mis je messages (en nieuwe versie van x/y is altijd downtime). En als het je voornamelijk om storage gaat houd het dan zo simpel mogelijk en bouw je rapportage naast je storage.

Dan bevat je storage alles, je rapportage kan wat dingen missen met downtime, maar dan is het missende gedeelte weer opnieuw op te bouwen uit storage.

Ik hou wel van een eenvoudige oplossing. Hoe goed/makkelijk zijn zaken als meerdere nodes, replicatie, gegarandeerd geen message loss te regelen?

[HollowGamer]

Een hoofdstation en dan de files syncen tussen nodes met rsync bijv.

Ik zelf zien toch iets meer met redis (puur voor access time), maar je kan misschien eens uitzoeken hoe de grote het doen, als Telegram whatsapp, etc.

[Cartman!]

Waar moet je t hosten? Ik zou zelf denken aan een combinatie van een load balancer (ELB), appnodes (EC2) voor t ontvangen van de berichten en wegschrijven naar S3/DynamoDB/ElastiCache.

[Gomez12]

HollowGamer schreef op zaterdag 15 november 2014 @ 19:16:
Een hoofdstation en dan de files syncen tussen nodes met rsync bijv.

Ik zelf zien toch iets meer met redis (puur voor access time), maar je kan misschien eens uitzoeken hoe de grote het doen, als Telegram whatsapp, etc.

Redis heeft wmb als nadeel dat je bij een update minimaal enkele minuten offline bent en dus berichten mist, plus dat je zelf programmeurs in huis moet hebben die bijv ooit in de toekomst een fork kunnen maken als redis ooit eens besluit om de handdoek in de ring te gooien. Of als ze besluiten 1 versie niet backwards compatible te maken.
Of als er bugs zijn waardoor er berichten missen.

Telegram / whatsapp etc hebben hele andere doelen. Die maakt het niet uit als ze er een paar missen.

Als het echt een eis is dat er geen berichten mogen missen dan moet je het imho zo simpel mogelijk houden.

Ik denk dat het een beetje neerkomt op de vraag of het acceptabel is om op jaarbasis een paar minuten te missen of dat dat onacceptabel is. Is dat acceptabel dan kan je gokken op key-value stores als redis etc en hopen dat die voor langere tijd blijven bestaan en uitleesbaar zijn, is dat niet acceptabel maak dan de storage zo simpel mogelijk

[HollowGamer]

Hoewel ik het deels met je eens ben, vind ik het punt van redis nogal wat overdreven. Dan kun je nog een stap verder gaan:
Als je de bestanden gaat storen, op welk FS? NTFS is misschien over een aantal jaren obsolete, zelfde voor ext4, btrfs.. Je applicatie moet je regelmatig updaten, dus ook de backends. Je kunt immers niet in de toekomst kijken, zeker niet op dit tempo. .

[Erapaz]

Op jaarbasis een paar minuten offline is zeker acceptabel. De aanlevering gebeurt op een queue die ook een aantal duizenden berichten kan bufferen indien nodig.

[HollowGamer]

Erapaz schreef op zondag 16 november 2014 @ 08:18:
Op jaarbasis een paar minuten offline is zeker acceptabel. De aanlevering gebeurt op een queue die ook een aantal duizenden berichten kan bufferen indien nodig.

Dit is niet SMART geformuleerd zou mijn leerkracht zeggen.

Zet gewoon eens op papier waar de applicatie aan moet voldoen, daarmee bedoel ik vooral cijfermatig.

Als ik het dus goed begrijp worden de berichten verwerkt in 'een centrale', vervolgens verdeeld over knooppunten, en van waar worden ze weer terug gestuurd?
Je hoeft niet alles te beschrijven, maar er is wel al een systeem/proto gevonden waarmee je dit wilt bereiken?

[Erapaz]

Dat komt omdat het een deelprobleem is van een groter geheel. Deze component zit tussen een ingaande en een uitgaande queue in. Het gaat me nu vooral om het opslaan van de berichten binnen deze component voor noodgevallen. Ik vroeg me af of ik ergens overheen keek.

100% uptime is niet noodzakelijk en ook niet realistisch. Als echter een bericht eenmaal aangenomen is, dan mag het niet meer verloren gaan.

Overigens heb ik al behoorlijk waardevolle antwoorden gehad.

Wat betreft de grootten in de markt, LMAX is een mooie case (miljoenen berichten per seconde). In de artikelen focussen ze vooral op de verwerking, wat ook spannender is. Opslag is gewoon een blokje in de keten.
De case is min of meer hypothetisch, ik ben vooral benieuwd wat de usual,suspects zijn voor het opslaan van veel (niet SMART, laten we zeggen 1 miljard) berichten waarbij de inhoud niet belangrijk is.

[Camulos]

Als het on-premise moet zijn: NoSQL database.. deze schalen makkelijker en back-uppen/syncen is vaak net wat beter geregeld dan losse-files waar je zelf een applicatie overheen legt.
Probeer niet het wiel opnieuw uit te vinden voor bestaande issues/oplossingen

Als het in de cloud mag: Azure TableStorage (nosql Key value store).. of als je liever AWS gebruikt dan DynamoDB (nosql). Beide kunnen aangesproken worden door verschillende programmeer talen (.net/ java/ python / php).

[Erapaz]

Camulos schreef op zondag 16 november 2014 @ 09:33:
Als het on-premise moet zijn: NoSQL database.. deze schalen makkelijker en back-uppen/syncen is vaak net wat beter geregeld dan losse-files waar je zelf een applicatie overheen legt.
Probeer niet het wiel opnieuw uit te vinden voor bestaande issues/oplossingen

Als het in de cloud mag: Azure TableStorage (nosql Key value store).. of als je liever AWS gebruikt dan DynamoDB (nosql). Beide kunnen aangesproken worden door verschillende programmeer talen (.net/ java/ python / php).

Dank je. Een NoSQL database over verschillende nodes met replicatie lijkt me inderdaad de beste oplossing. Bestanden kunnen dan als bytes worden opgeslagen en opgehaald worden op een volgordelijk ID.

[Zoijar]

Of gewoon postgresql, ik snap niet helemaal waarom je nosql nodig hebt. Ik snap sowieso de hype daaromtrent niet altijd helemaal. Als je een postgresql database een beetje tuned kan je makkelijk ~5000 transacties per second doen. TS heeft het over 50, een factor 100 minder. Geen enkel probleem voor pgsql. Dan heb je alle voordelen van gegarandeerde transacties, geen mogelijk nosql data verlies of andere vreemde vreemde condities. Alle voordelen van standaard database robustness, concurreny, replication, fallbacks. (ok, enige nadeel is dat je misschien partitioning moet gebruiken om het op te delen in <32TB tabellen)

[ Voor 9% gewijzigd door Zoijar op 16-11-2014 10:49 ]

[mrwiggs]

Zoijar schreef op zondag 16 november 2014 @ 10:39:
(ok, enige nadeel is dat je misschien partitioning moet gebruiken om het op te delen in <32TB tabellen)

Daarom dus.

Het is compleet relatieloze data en het moet over servers verspreid kunnen worden. Waarom zou je dan in hemelsnaam een RDBMS gebruiken? Dat lijkt me een betere vraag.

[Zoijar]

Snooby schreef op zondag 16 november 2014 @ 12:18:
Daarom dus.

Het is compleet relatieloze data en het moet over servers verspreid kunnen worden. Waarom zou je dan in hemelsnaam een RDBMS gebruiken? Dat lijkt me een betere vraag.

Omdat partitioning helemaal niet moeilijk is; je kan bv een keer per jaar of half jaar een nieuwe table partition maken en de oudere naar goedkope/trage opslag verplaatsen.

Verder is het time-tested, standardized, performant genoeg, krijg je een berg features kado, zoals replication, compression, fault tolerance, guaranteed writes, atomicity, (eventueel json opslag). Natuurlijk, als de performance echt een dusdanig issue is dat je het niet meer redt met een standaard oplossing kan je ook bv naar Cassandra kijken, maar performance is hier helemaal geen issue met 50 m/s. Typische casandra applicatie: 2,500 nodes, 420 TB, over 1 trillion requests per day. Dan heeft het nut TS komt daar volgens mij helemaal niet bij in de buurt.

Idee is meer, kom eerst met een makkelijke oplossing die goed genoeg is, in plaats van allemaal oplossingen voor problemen die je niet hebt. Niet meteen denken, oh, "veel" berichten, big data! no sql! Maar eerst je daadwerkelijke probleem, als dat er al is, analyseren.

[ Voor 11% gewijzigd door Zoijar op 16-11-2014 14:02 ]

[The Eagle]

Ik zat mezelf ook af te vragen of dit classificert als big data, maar volgens mij niet echt. Zo groot zijn de berichten namelijk niet. Waren het nou logfiles van 1GB per stuk die je ook nog eens moest kunnen doorzoeken, dan was het een ander verhaal. Maar dat is het niet.

IMHO voldoet een beetje DBMS met een tabel met daarin wat losse velden en een LOB al.

[Erapaz]

Het is inderdaad geen big data vraagstuk. Bij big data gaat het naast opslag ook om verwerking, dit is puur opslag. De meeste artikelen beantwoorden deze vraag in de big data sfeer. Mijn vraagstuk is veel eenvoudig, daarom wordt er in de oplossing vaak aan voorbij gegaan.

Rekening houdend met 50 MB/s (1 MB per bericht) een maand lang, dan heb je het toch over 130 TB per maand. Het zou zonde zijn als je dan al na een week uit je maximale tabelgrootte loopt (postgresql oplossing).

Vandaar dat een disk based key-value store meer voor de hand ligt. Maar misschien is het antwoord zo triviaal dat ik het in het Showoff topic >20 TB storage systems kan terugvinden.

[HuHu]

Ik vind het eerlijk gezegd wel een hele vreemde vraag. 130 TB per maand opslaan is enorm veel. Meer dan een petabyte per jaar. Dat is geen vraag die je zo op een forum correct kunt beantwoorden. Daar heb je gespecialiseerde opslagsystemen voor nodig, zeker als je het ook nog lang (jaren) wilt kunnen bewaren én doorzoeken. Voor zoiets zijn experts nodig en het lijkt me dat je dat niet zomaar in je eentje in elkaar kunt zetten.

Ik vermoed dat er ook weinig mensen zullen zijn met ervaring met opslagsystemen van een dergelijke grootte.

Hier kun je wat voorbeelden vinden over opslagsystemen van dergelijke grootte (of groter): http://en.wikipedia.org/wiki/Petabyte

[mrwiggs]

HuHu schreef op maandag 17 november 2014 @ 11:14:
Ik vermoed dat er ook weinig mensen zullen zijn met ervaring met opslagsystemen van een dergelijke grootte.

Ik denk niet dat ervaring persé nodig is, maar kennis van de mogelijkheden van bepaalde systemen.

http://guide.couchdb.org/draft/clustering.html
We’ve seen that even a cluster with a depth of 2 can hold a vast amount of data. Basic arithmetic shows us that by applying the same process to create a cluster with three layers of proxies, we can manage 262 petabytes on thousands of machines. Conservative estimates for the latency introduced by each layer is about 100 ms, so even without performance tuning we should see overall response times of 300 ms even with a tree depth of 3, and we should be able to manage queries over exabyte datasets in less than a second.

Vandaar dat ik met CouchDB aankwam.

[HuHu]

Snooby schreef op maandag 17 november 2014 @ 12:08:
[...]


Ik denk niet dat ervaring persé nodig is, maar kennis van de mogelijkheden van bepaalde systemen.


[...]


Vandaar dat ik met CouchDB aankwam.

Als ik een ander deel uit die zin highlight:

Basic arithmetic shows us that by applying the same process to create a cluster with three layers of proxies, we can manage 262 petabytes on thousands of machines.

Oftewel: ze denken het, ze hebben geen ervaring.

En daarnaast gaat dit over de software, maar de hardware is al het eerste grote probleem.

[Gomez12]

Snooby schreef op maandag 17 november 2014 @ 12:08:
[...]
Ik denk niet dat ervaring persé nodig is, maar kennis van de mogelijkheden van bepaalde systemen.

Hiervoor is nu juist wel ervaring benodigd.

Je wilt niet weten hoeveel systemen er verkocht worden op dezelfde basis als dat jij nu couchdb quote.

En dan heb je na 6 maand 780 TB opgeslagen en loop je tegen een dingetje aan wat toch niet zo werkt als verwacht. Dan heb je een uitdaging, want je kan bijna niet meer terug (780 TB converteren naar iets anders is waarschijnlijk weken werk als je het alleen al moet doorvoeren). Maar je kan ook niet meer vooruit vanwege je bug.

En o ja, per maand dat je naar een oplossing zoekt wordt het probleem groter. Hiervoor wil je juist iemand hebben die het al eens gedaan heeft en weet waar hij moet gaan kijken als er iets scheef gaat en niet enkel maar reclame-cijfertjes.

[Cartman!]

Zou vooral ook kijken of die messages niet kleiner gemaakt kunnen worden, als je dat een paar TB per maand kan besparen is dat toch mooi meegenomen.

[Mr_x007]

Je zou naar Ceph: http://ceph.com kunnen kijken. Die bieden een object store, die schaalbaar en redundant is. Heb er zelf geen ervaring mee maar er is wel een topic over hier: Ceph, an open source distributed file system

[Cartman!]

Amazon Redshift kan ook omgaan met petabytes en is goed betaalbaar volgens mij: http://aws.amazon.com/redshift/ Eventueel kun je t ook combineren met Amazon Elastic MapReduce

[ Voor 22% gewijzigd door Cartman! op 17-11-2014 16:29 ]

[HMS]

Bij een volume van 130TB per maand zou ik zeker het gebruik van cloud diensten overwegen, tenzij jullie de capaciteit hebben om het zelf allemaal te regelen (maar dan verwacht ik niet dat je met deze vraag hier terecht komt). Bij zulke datasets is het uitvallen van een harde schijf geen uitzondering maar een zekerheid, en dus zie je vaak dat je de data 2, 3, of meer keer repliceert.

Mijn Master thesis ging over het opslaan van zulke data sets in de cloud, voornamelijk voor de langere termijn. Mocht je overwegen het zelf te doen, dan is misschien GlusterFS een oplossing.

[Soultaker]

Waar komt die 130TB/maand vandaan? In de TS staat "50 m/s" wat eerst geïnterpreteerd werd als 50 messages/second. 50 messages van hooguit 1 MB per stuk is 1.5 TB per jaar (of minder, als berichten gemiddeld kleiner zijn).

Mijn 2 cents: dump alles op Amazon S3. Die bieden goede garanties voor durability, hebben de expertise om die garanties te kunnen maken, en de prijs is niet heel hoog.

[mrwiggs]

Soultaker schreef op maandag 17 november 2014 @ 17:18:
Waar komt die 130TB/maand vandaan? In de TS staat "50 m/s" wat eerst geïnterpreteerd werd als 50 messages/second. 50 messages van hooguit 1 MB per stuk is 1.5 TB per jaar (of minder, als berichten gemiddeld kleiner zijn).

50 * 60 * 60 * 24 * 365 / 1e6 = 1576 TB dus ik denk dat je een factor 1000 te laag zit.

Soultaker schreef op maandag 17 november 2014 @ 17:18:
Mijn 2 cents: dump alles op Amazon S3. Die bieden goede garanties voor durability, hebben de expertise om die garanties te kunnen maken, en de prijs is niet heel hoog.

S3 is inderdaad een optie als je echt alleen storage wilt en dat lijkt inderdaad te voldoen voor TS. Wellicht met een archiveeroptie naar Glacier om kosten te besparen (als oude data niet regelmatig ingezien hoeft te worden). Nadeel van S3 is overigens wel dat het bij een derde partij staat en als zij de stekker eruit trekken wens ik je succes met het overzetten van duizenden TB's.

[ Voor 14% gewijzigd door mrwiggs op 17-11-2014 17:45 ]

[Kettrick]

Snooby schreef op maandag 17 november 2014 @ 17:40:
Nadeel van S3 is overigens wel dat het bij een derde partij staat en als zij de stekker eruit trekken wens ik je succes met het overzetten van duizenden TB's.

S3 ( of iets soortgelijks, maar mijn keuze waarschijnlijk S3 zijn ) lijkt een goede oplossing. De kans ze de stekker er uit trekken lijkt me redelijk klein, en als dat al gebeurd zullen er verschillende alternatieven opduiken met migratie opties.

De kans dat je zelf iets verkloot met je database, of dat je serverhok in de fik vliegt, lijkt me aanzienlijk groter dan dat amazon de stekker uit S3 trekt.

[The Eagle]

@TS: wat is eigenlijk het bewaarcriterium van de berichten? Is er specifieke relevante data? En tot hoe ver wil je terug kunnen zoeken?
Kan me voorstellen dat berichten alleen interessant zijn om te bewaren als er bepaalde zaken in staan. Dan kun je dus ook een filter toepassen dat zut wegmikt na een bepaalde datum als ze niet door het filter komen

[Zoijar]

Oh, ik onderschatte de schaal van het probleem dan een beetje -- in dat geval vergeet postgres maar Als je al met iets redundancy iets van 35 nieuwe 5TB disks moet hebben elke maand, los van racks om ze in te schuiven, waarbij je kosten dan als snel richting de zeg 50.000 euro per maand schieten, dan kan je niet meer zelf iets doen met een opslag kiezen etc. Dan moet je wel een professionele partij inhuren. Inderdaad eens offertes van bv amazon of google vragen.

[Soultaker]

Snooby schreef op maandag 17 november 2014 @ 17:40:
50 * 60 * 60 * 24 * 365 / 1e6 = 1576 TB dus ik denk dat je een factor 1000 te laag zit.

Oh ja, rekenen sucks.

[pedorus]

50 MB/s is nog wel een interessante hoeveelheid als dat waar is, dat vraagt om een wat betere beschrijving van het probleem om een zinnig antwoord te geven. Onder andere de mogelijke compressiefactor is dan nogal interessant, net als fluctuaties, eventuele uplinks naar Amazon en/of infrastructuur zoals verdeling van harde schijven over machines, verdeling van groepen over de tijd, ernstigheid van uitval ten opzichte van duurzaamheid, is het doel backup of teruglezen, enz.

De beschrijving lijkt nu ook niet consistent, met enkele maanden met 50 berichten/seconde aan opslag kom je nooit aan miljarden berichten.

Overigens vind ik suggesties als Redis vreemd, een ongeclusterde opslag gelimiteerd aan het geheugen... Dan komt iets als Kafka of Flume, wat al in de startpost stond, waarschijnlijk toch meer in de buurt.

[Cartman!]

pedorus schreef op dinsdag 18 november 2014 @ 21:13:
De beschrijving lijkt nu ook niet consistent, met enkele maanden met 50 berichten/seconde aan opslag kom je nooit aan miljarden berichten.

Reken het eens na voor de gein

[pedorus]

http://www.wolframalpha.com/input/?i=3*30*24*60*60*50

[Foeijonghaai]

Ik heb hier een setup die 35 miljoen records per dag (iets meer dan 100 bytes per record) in pakketjes van 30 records ontvangt en classificeert (op uniek nummer). Ik schrijf 3 stromen weg: een archief-stroom met alle records, een iets-meer human-readable stroom en een stroom met de geclassificeerde data. De geclassificeerde data eindigt in bestanden per uniek nummer (ongeveer 3000 duizend unieke nummers). De records krijgen opeenlopende nummers.

Ik verzamel zo'n 4GB per dag en hou een retentie van 90 dagen aan.

Ik gebruikte eerst een postgres-database, maar deze liep al snel vol en vanwege allerlei indexen werd de data eigenlijk 'opgeblazen' tot 4-5 keer zoveel per dag (dus 4GB aan data werd 16-20GB in de DB). Retentie was een ramp omdat het verzamelen van de records en het daadwerkelijke weggooien enkele uren duurde. De database zelf 'trashte' eigenlijk al snel. Alleen na een vacuum/analyze was het een paar dagen werkbaar, maar dan had ik loss van data. Ook het zoeken ging niet snel. Inserten was een aanzienelijke belasting, ook al groepeerde ik de inserts. De machine zat altijd rond 60% CPU en veel disk IO.

Nu schrijf ik dus weg naar file en gebruik ik logrotation voor de retentie en compressie en wordt de 4GB per dag zo'n 500MB. Het weggooien van een dag aan info is feitelijk het weggooien van een bestand. 'inserten' is nu geen enkele moeite. De machine zit nu rond de 4%CPU en nauwelijks disk IO, behalve als logrotate zijn ronde doet.

Het scheelt misschien wel dat mijn data plain-text is.

[Zoijar]

Foeijonghaai schreef op woensdag 19 november 2014 @ 09:43:
Ik gebruikte eerst een postgres-database, maar deze liep al snel vol en vanwege allerlei indexen

Tsja, ik neem wel aan als je met grotere volumes data gaat werken dat je niet zo maar allerlei indices hebt, maar wel een beetje optimized voor je use-case.

[pedorus]

Ik vermoed inderdaad dat je met wat tuning dat goed had kunnen krijgen (oa minder disk sync, indexes, partitioning).

Ik vraag me af hoe je logrotate zou combineren met data die niet verloren mag gaan. Op de overgang is er kans op dataverlies, tenzij je logica schrijft om een nieuw bestand te beginnen. En als je dan toch logica schrijft, dan kun je beter gelijk compressie doen en naar de juiste bestanden schrijven. Dus dan heb je logrotate niet meer nodig. (Overigens heb ik ervaring met beide situaties, met miljarden berichtjes. Logrotate zet nu eenmaal erg makkelijk op en een klein aantal verloren berichtjes boeien meestal niet.)

[Foeijonghaai]

Zoijar schreef op woensdag 19 november 2014 @ 18:46:
[...]

Tsja, ik neem wel aan als je met grotere volumes data gaat werken dat je niet zo maar allerlei indices hebt, maar wel een beetje optimized voor je use-case.

Probleem was dat o.a. de timestamp een kenmerk is voor het achteraf kunnen classificeren. Voorheen gebeurde het classificeren op request. Nu het classificeren at runtime gebeurt, scheelt dat een heleboel.

[Foeijonghaai]

pedorus schreef op woensdag 19 november 2014 @ 23:23:
Ik vermoed inderdaad dat je met wat tuning dat goed had kunnen krijgen (oa minder disk sync, indexes, partitioning).

Ik vraag me af hoe je logrotate zou combineren met data die niet verloren mag gaan. Op de overgang is er kans op dataverlies, tenzij je logica schrijft om een nieuw bestand te beginnen. En als je dan toch logica schrijft, dan kun je beter gelijk compressie doen en naar de juiste bestanden schrijven. Dus dan heb je logrotate niet meer nodig. (Overigens heb ik ervaring met beide situaties, met miljarden berichtjes. Logrotate zet nu eenmaal erg makkelijk op en een klein aantal verloren berichtjes boeien meestal niet.)

Logrotate maakt bij mij eerst een kopie van het origineel en maakt dan de file leeg. Kwestie van goed configureren. Daar hebben de ontwikkelaars van logrotate ook wel over nagedacht Compressie wordt gedaan op de kopie. Het schrijfproces blijft in dezelfde file schrijven en merkt er niets van.

Doordat iedere regel een record-id heeft, kan ik controleren of ik data mis. Ik moet wel zeggen dat in mijn geval het niet erg zou zijn als ik wat records mis.

Ik heb zelf de logica geschreven. Ik gebruik onder andere queues en meerdere threads zodat de berichtenstroom (aangeleverd via het netwerk) altijd opgevangen wordt. Het classificeren van de data gebeurt in een andere thread. Deze maakt meerdere kopieren van het record (afhankelijk van de classificatie) en zet het weer op een queue, samen met de destinatie. Een andere thread schrijft de entries naar de juiste files. Nog een andere thread houdt de open bestanden bij en sluit ze indien er een bepaalde periode niet naar geschreven is. Er vindt buffering plaats, maar wel zo dat er nooit halve regels in de logbestanden terecht komen.

Compressie zou idd een logische uitbreiding zijn, ware het niet dat er de wens bestaat om de actuele bestanden te kunnen 'tailen' om live mee te kunnen kijken.

[ Voor 4% gewijzigd door Foeijonghaai op 20-11-2014 09:53 ]

[cariolive23]

50 berichten per seconde van elk 1MB, dat is op jaarbasis ongeveer 1,5 PB. Wanneer je nog iets wilt doen met deze data, heb je dus een systeem nodig dat in elk geval 1,5 PB per jaar kan opslaan maar ook nog snel genoeg is om jouw vragen te kunnen beantwoorden.

Ik heb nooit met zo'n enorme vracht data gewerkt, met een paar TB hield het al wel op... En dat werkt prima in een RDBMS zoals bijvoorbeeld PostgreSQL.

[SBTweaker]

Nog wat vragen. Moet het mogelijk zijn om data te verwijderen of te doorzoeken ? Of is echt alleen de vogoorde belangrijk ? Excuses als het eerder geplaatst is maar zag het er zo niet tussen staan .

[pedorus]

Foeijonghaai schreef op donderdag 20 november 2014 @ 09:50:
Logrotate maakt bij mij eerst een kopie van het origineel en maakt dan de file leeg. Kwestie van goed configureren. Daar hebben de ontwikkelaars van logrotate ook wel over nagedacht

Jazeker, dat hebben ze, ik neem aan dat je copytruncate bedoelt:

quote: http://linux.die.net/man/8/logrotate

Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost.

Nu gaat het inderdaad om erg weinig tijd, als ik kijk gaat het om milliseconden die je verliest (met delaycompress). De logrotate gebeurd natuurlijk op de rustigste tijd van de dag, niet met ~2000 messages/second/server zoals op de drukkere tijden. Ik kan daarom niet goed zien hoe lang het echt duurt, maar copytruncate kan gewoon niet atomic gebeuren onder linux. Zie hier ook een experiment dat dit aantoont: https://www.mail-archive....project.org/msg61805.html

Compressie zou idd een logische uitbreiding zijn, ware het niet dat er de wens bestaat om de actuele bestanden te kunnen 'tailen' om live mee te kunnen kijken.

gunzip <file |tail duurt gewoon wat langer. Ik heb ook een implementatie voor tail -f met gzip, maar data komt wel pas per block (max 64 kb) beschikbaar, dus dat werkt alleen met genoeg flow. Er zijn ook andere encodingen dan gzip die hier geschikter voor zijn, omdat ze splittable zijn (lzo, bzip2 bijvoorbeeld).