Onderwerp: Storage vraagstuk

Hallo,

Ik ben op zoek naar een oplossing voor mijn storage-uitdaging. Het (enigszins versimpelde) probleem: er moet zeer veel (timed) data worden opgeslagen, afkomstig van verschillende nodes. Denk hierbij aan een tijdstip met de temperatuur, luchtvochtigheid e.d. Er zullen om te beginnen ongeveer 100 entries per seconde worden toegevoegd, wat allemaal een jaar blijft staan, dus het zou om een paar miljard entries gaan. Later neemt dit waarschijnlijk nog (sterk) toe.

Voor elke data-source zullen er een paar van deze waarden worden bijgehouden, allemaal gemiddeld één keer per minuut, maar niet per sé op vaste tijden / intervallen. De data per data-source zal dus meevallen, het grote aantal entries wordt bereikt door de vele data-sources. Af en toe zullen er range queries op de data worden gedaan, bijvoorbeeld “wat was de gemiddelde luchtvochtigheid tussen … en …”, maar er zullen vele malen meer write acties gedaan worden, dus de performance daarvan is in principe belangrijker. Het hele idee lijkt sterk op de monitoring van servers, maar dan net wat anders (geen vaste intervallen).

De vraag is dus met welke oplossing dit het beste te bereiken is. Uiteindelijk zal er één storage API moeten komen waar nodes hun data naartoe pushen, en waarop ook weer de range queries gedaan kunnen worden. Verder zal het schaalbaar moeten zijn over meerdere storage servers, mocht de data in de toekomst verder groeien.

RRDtool valt af; er zijn geen vaste intervallen en verder is het met RRD sowieso lastig cachen / transacties batchen waardoor je waarschijnlijk snel tegen IO problemen aanloopt.

Ik had zelf het idee een soort eigen opslag te knutselen met SQL databases (MySQL, MariaDB, …), en het daarmee ook te verdelen over de servers. De centrale API server ontvangt in dat geval de requests, houdt zelf in een SQL database een lijst bij met welke data-entries op welke storage servers staan, en stuurt de data of requests daarna door naar de juiste storage server. Op die storage server draait dan ook weer een SQL database, maar dan flink geoptimaliseerd voor de miljoenen kleine entries die opgeslagen worden.

Als laatste puntje zijn backups nog wel nodig, als er een paar entries verloren gaat is dat geen groot probleem, maar de historische data moet wel bewaard blijven. Hiervoor leek ZFS met snapshots me een oplossing.

Misschien hebben jullie nog (betere) ideeën voor deze case. Ik ben zelf niet helemaal into technieken als NoSQL / hadoop / cassandra etcetera, zouden die hier geschikt voor zijn en moet ik me daarin gaan verdiepen?

Als er wat in je opkomt, gooi het maar neer, misschien stuurt het me de goede richting in.

Alvast bedankt!

Exact dit is een dienst die een van mijn klanten heeft: het centraal bijhouden van heel veel van dergelijke meetwaarden. Er is gekozen voor een API met JSON die textfiles op ZFS schrijft. Dergelijke meetwaarden comprimeren heel erg goed of FS niveau. Doordat het vooral eenrichtingsverkeer is, zijn tekstbestanden in een handige directorystructuur een hele efficiënte oplossing.

Naar DB toe lijkt me dit eerder iets voor MongoDB. Daar heb je eigenlijk een soort shoot-and-forget, waarbij je eigenlijk niet wil wachten op de bevestiging dat een record daadwerkelijk weggeschreven is (data-loss kan dan natuurlijk wel in geval van panne van een node). Sharding en replicatie zijn ook vele malen simpeler op te zetten dan bv. bij een MySQL/MariaDB, en het heeft ook een eigen mapreduce ingebouwd.

ElasticSearch? Dat draai je gewoon op een paar stevige machines en dan kan je gewoon dozen bij prikken indien nodig.

De API is gewoon HTTP met JSON data. Voor alle bekende talen zijn er ook bindings beschikbaar.

SQL zou ik voor deze use-case zeker niet in zetten.

Ik zat inderdaad ook direct aan ElasticSearch te denken. Zowel voor development als voor systeembeheer wel handig. Voor de developers van de applicatie is zoals Wido al aangeeft een goede API beschikbaar. En voor de systeembeheerders is het vrij goed op te zetten en te beheren. Monitoring is bijv. goed te doen en er is met behulp van plugins (zoals Bigdesk) heel makkelijk te interpreteren overzichten uit te trekken van o.a. de cluster health en performance: http://bigdesk.org/

Je kunt er gewoon eens mee testen op een paar VM's. Dan weet je nog niet de uiteindelijke performance natuurlijk, maar kun je i.i.g. kijken of het makkelijk te implementeren is en hoe het zich gedraagt met bijv. redundantie.

Ik run nu een project waar we een vergelijkbare use-case hebben, heel-veel sensor data distribueren en opslaan. bij ons gaat het om 50.000+ records per seconden.

We gebruiken hier een MongoDB voor opslag, RabbitMQ (AMQP) voor distributie en eigen ontwikkelde software voor de archiver (opslag naar DB) en RPC voor authenticatie en authorisatie en het toevoegen van meta-data.

MongoDB is natuurlijk zeer geschikt voor dit soort projectjes, maar ik zou ook eens kijken naar Graphite. Je kan dat ook goed schaalbaar maken, en dan hoef je niet zelf de logica van wat staat waar te bedenken.

Cassandra is erg geschikt wanneer je voornamelijk writes doet. Je kan Hadoop gebruiken voor map/reduce functies.

MongoDB is voornamelijk geschikt wanneer je veel reads doet. Bij writes legt MongoDB een lock op je gehele database wat ervoor zorgt dat andere writes moeten wachten tot de lock wordt opgeheven. De mogelijkheid tot indexes en dynamische queries maakt het wél een goed alternatief voor bijvoorbeeld MySQL. Je hebt hierbij wel de voordelen van NoSQL zoals een flexibel schema, etc.

Oorspronkelijk geplaatst door Costeijn

Cassandra is erg geschikt wanneer je voornamelijk writes doet. Je kan Hadoop gebruiken voor map/reduce functies.

MongoDB is voornamelijk geschikt wanneer je veel reads doet. Bij writes legt MongoDB een lock op je gehele database wat ervoor zorgt dat andere writes moeten wachten tot de lock wordt opgeheven. De mogelijkheid tot indexes en dynamische queries maakt het wél een goed alternatief voor bijvoorbeeld MySQL. Je hebt hierbij wel de voordelen van NoSQL zoals een flexibel schema, etc.

De reden dat wij voor MongoDB gekozen hebben is de ondersteuning voor spacialdata en het doen van queries op spacialdata. wij slaan coördinaten op in geoJSON en kunnen daar achteraf allerhande queries en analyses op loslaten.

ik zal een van onze programmeurs eens vragen naar Cassandra te kijken, hoe gaat Cassandra om met paging en sharding?

Bedankt voor alle reacties tot nu toe, wordt gewaardeerd.

Tussen de feestdagen door hebben we een paar genoemde oplossingen eens goed bekeken en getest, en we zijn uiteindelijk wel erg te spreken over Mongo. Het presteert goed en sharding is ideaal om horizontaal te schalen, draaien nu een testopstelling met een berg shards en een miljard documents en dat gaat prima, zowel writes als reads. Heel af en toe wel een query die mislukt (één op de miljoen o.i.d.), maar ben er nog niet uit of dit komt door een brak intern netwerk, een bug in Pymongo of een andere fout.

De lock op de gehele database is nu niet zo’n probleem, bij sharding is dit alleen op de shard waar het naartoe geschreven wordt en dan valt dit alles mee, 1000 nieuwe documenten per seconde op een shard gaat zonder problemen en dat is ruim voldoende.

Uiteindelijk dus toch iets heel anders (en mooiers) geworden dan van tevoren gedacht, bedankt! Als ik nog dingen tegenkom zal ik ze zeker posten voor future reference, discussier ook vooral verder :-).

Als dit je eerste echte project met Mongo is, kan ik je ten zeerste de (gratis) M102 MongoDB for DBA's aanraden (zie https://education.mongodb.com/), dat is een zeer goede en duidelijke tutorial (soms wel een beetje langdradig) waarin uiteraard ook in detail gekeken wordt naar heel het deel van replicasets en sharding.