Resultaten 1 tot 11 van de 11
Geen

Onderwerp: Storage vraagstuk

  1. #1
    Storage vraagstuk
    geregistreerd gebruiker
    14 Berichten
    Ingeschreven
    17/05/11

    Locatie
    Zedelgem

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter

    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!

  2. #2
    Storage vraagstuk
    Geregistreerd Gebruiker
    4.704 Berichten
    Ingeschreven
    23/04/05

    Locatie
    Eindhoven

    Post Thanks / Like
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    353 Berichten zijn liked


    Naam: Toin Bloo
    Bedrijf: Dommel Hosting
    URL: www.dommelhosting.nl
    ISPConnect: Lid
    KvK nummer: 17177247

    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.

  3. #3
    Storage vraagstuk
    geregistreerd gebruiker
    462 Berichten
    Ingeschreven
    22/05/06

    Locatie
    Belgie

    Post Thanks / Like
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    26 Berichten zijn liked


    Ondernemingsnummer: 0812210395

    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.

  4. #4
    Storage vraagstuk
    3.810 Berichten
    Ingeschreven
    16/05/04

    Locatie
    Middelburg

    Post Thanks / Like
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    130 Berichten zijn liked


    Registrar SIDN: Ja

    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.

  5. #5
    Storage vraagstuk
    geregistreerd gebruiker
    416 Berichten
    Ingeschreven
    17/07/08

    Locatie
    Almelo

    Post Thanks / Like
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    53 Berichten zijn liked


    Naam: Dick
    Registrar SIDN: ja
    KvK nummer: 09107826
    Ondernemingsnummer: nvt

    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.

  6. #6
    Storage vraagstuk
    Dimotion
    140 Berichten
    Ingeschreven
    13/06/04

    Locatie
    Zutphen

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Functie: Projectmanager
    Registrar SIDN: Nee
    Ondernemingsnummer: nvt
    View http://nl.linkedin.com/in/chrisschwartznl/'s profile on LinkedIn

    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.



  7. #7
    Storage vraagstuk
    Internet Services
    3.188 Berichten
    Ingeschreven
    27/03/06

    Locatie
    Utrecht

    Post Thanks / Like
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    43 Berichten zijn liked


    Naam: Jeroen
    View nl.linkedin.com/in/jeroenvheugten's profile on LinkedIn

    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.

  8. #8
    Storage vraagstuk
    Ondernemer
    244 Berichten
    Ingeschreven
    07/03/06

    Locatie
    drenthe

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Naam: CJ
    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    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.

  9. #9
    Storage vraagstuk
    Dimotion
    140 Berichten
    Ingeschreven
    13/06/04

    Locatie
    Zutphen

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Functie: Projectmanager
    Registrar SIDN: Nee
    Ondernemingsnummer: nvt
    View http://nl.linkedin.com/in/chrisschwartznl/'s profile on LinkedIn

    Citaat Oorspronkelijk geplaatst door Costeijn Bekijk Berichten
    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?

  10. #10
    Storage vraagstuk
    geregistreerd gebruiker
    14 Berichten
    Ingeschreven
    17/05/11

    Locatie
    Zedelgem

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter
    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 :-).

  11. #11
    Storage vraagstuk
    geregistreerd gebruiker
    462 Berichten
    Ingeschreven
    22/05/06

    Locatie
    Belgie

    Post Thanks / Like
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    26 Berichten zijn liked


    Ondernemingsnummer: 0812210395

    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.

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2018 Webhostingtalk.nl.
Web Statistics