database gezocht met wat specifieke eisen

[nielsl]

Ik ben voor een prive project eea aan het onderzoeken. Het priveproject omhelst abstract het volgende.
Er is een evenement waarbij langs de route van het evenement een aantal posten zijn die een dienst aanbieden aan de deelnemers van het evenement. De deelnemers die gebruik maken van die dienst moeten worden geregistreerd. Dat is an sich geen probleem want de deelnemers dragen reeds een unieke identifier met zich.
Bij aanmelding voor de dienst kun je dus gewoon de identifier gebruiken om de gebruiker te registreren en te koppelen van welke diensten de persoon gebruik maakt.

Elke locatie langs de route wordt verbonden dmv een UMTS verbinding met het centrale punt. Bedoeling is dat alle gegevens die de locaties verzamelen naar het centrale punt worden weggeschreven. De verbindingen kunnen echter nog wel eens wegvallen, dus er moet een vorm van controle plaatsvinden mbt de vraag of de queries centraal wel netjes zijn weggeschreven. Iets transactioneels zou ik zeggen.

Ik heb gekeken naar multi master replication, maar dit is niet wat ik zoek. De data hoeft namelijk niet beschikbaar te zijn op de locaties langs de route. Langs de route wordt er voor 99% enkel data weggeschreven naar het centrale punt. Lookups mogen dus ook op het centrale punt worden gedaan.

Wat zoek ik dan wel? Ik noem het maar batched queries. Een client spaart zn queries op tot de verbinding er weer is en pompt ze er dan doorheen. Als de queries succesvol zijn weggeschreven worden ze verwijderd uit de queue van de client. Op deze manier kan op een locatie in het veld de verbinding wegvallen en wordt op een later tijdstip alles automatisch bijgewerkt.

Nu mijn vraag, is er een open source database die bovenstaande ondersteund? En zoja, kan iemand me een duwtje in de rug geven? Ik heb best wel wat ervaring met PHP en MySQL maar ik ben eager to learn
Alvast bedankt!

[roy-t]

Nouja MySQL e.d. kan gewoon op een server. Het batchen van queries zal op de clients moeten gebeuren en zul je zelf moeten implementeren, maar zal niet veel moeilijker zijn dan alvast wat query objecten opbouwen en dan te pollen voor connectie met de database.

[Cloud]

Query batching is een vrij situatie specifiek iets, ik ken zo geen databases die dat zélf al ondersteunen. Te meer ook, omdat dat batching op de client moet plaatsvinden en niet in de databaseserver zelf.

Maar met een centrale database (maakt eigenlijk niet uit welke) en robuuste clients moet dit vrij goed te realiseren zijn. De logica voor het opsparen van queries zul je dan in de client in moeten bouwen maar dat kan op tig verschillende manieren Je hoeft ze niet eens als zijnde queries op te sparen, maar gewoon de data. Eventueel met een locale opslag, als je zeker wilt weten dat de clients ook hun data bewaren mocht de applicatie afgesloten worden (of raken).

Vóór het uitvoeren van de queries nog even controleren of er daadwerkelijk verbinding is en per query een resultaat eisen zodat je zeker weet dat de operatie geslaagd is op de server. Bijvoorbeeld een nieuw aangemaakt ID uit de PK

[nielsl]

roy-t schreef op woensdag 23 februari 2011 @ 09:47:
Nouja MySQL e.d. kan gewoon op een server. Het batchen van queries zal op de clients moeten gebeuren en zul je zelf moeten implementeren, maar zal niet veel moeilijker zijn dan alvast wat query objecten opbouwen en dan te pollen voor connectie met de database.

snap ik, desnoods met een eigen lokale mysql tabel waar je de queries bewaart en deze periodiek terugstuurt. Maar geeft mij dit voldoende garanties? Wat als de verbinding wegvalt gedurende een query? Is innoDB dan voldoende om transactioneel enige queries door te sturen? Is dit (of soortgelijke manieren van werken) een methode die in dit soort situaties vaker wordt toegepast?

[The Lord]

nielsl schreef op woensdag 23 februari 2011 @ 09:35:
Wat zoek ik dan wel? Ik noem het maar batched queries. Een client spaart zn queries op tot de verbinding er weer is en pompt ze er dan doorheen. Als de queries succesvol zijn weggeschreven worden ze verwijderd uit de queue van de client. Op deze manier kan op een locatie in het veld de verbinding wegvallen en wordt op een later tijdstip alles automatisch bijgewerkt.

Nu mijn vraag, is er een open source database die bovenstaande ondersteund? En zoja, kan iemand me een duwtje in de rug geven? Ik heb best wel wat ervaring met PHP en MySQL maar ik ben eager to learn
Alvast bedankt!

Ik zou zoiets niet met een database oplossen, maar iets wat 'loosely coupled' is van nature. En dan kom je al snel op een message bus. Uit eigen voorkeur zou ik in de situatie die jij schetst voor Microsoft MQ (de message queuing), WCF (het framework voor communicatie) en .NET 4 (Het programmeer framework waar WCF en MSMQ wrappers inzitten) kiezen.

[Cloud]

Een lokale MySQL installatie kán, maar hoeft volgens mij niet. De manier waarop je lokaal de 'cached' data voor de server opslaat, doet er eigenlijk niet zoveel toe. En hoeft zeker niet overeen te komen met die van de centrale databaseserver.

Wat betreft wegvallende verbindingen tijdens queries; als het goed is krijg je daarvan gewoon bericht en kun je de query herhalen. Als je met transacties gaat werken kun je prima garanderen dat het ook daadwerkelijk in de databaseserver is opgeslagen. Controleer tevens het resultaat van de query (ook een insert, kan in principe een resultaat geven) en dan kun je aardig zeker weten dat het geslaagd is. En bij elke fout, gewoon de operatie herhalen. Je zei dat je al een unieke identificatie hebt per record, dus daar kun je prima duplicaten mee vermijden in je DB.

Dit probleem wat je beschrijft, wordt overigens vaak 'occasionally connected' genoemd. Is al vrij veel over geschreven op internet, dus daar kun je misschien ook wel wat bij vinden

[Gé Brander]

Kijk ook even naar Service Broker van SQL Server. Wellicht kan dat wat jij wil.

MSDN: An Introduction to SQL Server Service Broker

In SQL Server 2005 is een Workgroup of hogere editie nodig:
http://www.microsoft.com/.../us/compare-features.aspx

In SQL Server 2008R2 is een Standard of hogere editie nodig:
http://www.microsoft.com/...product-info/compare.aspx

Dus voor een prive opdracht zal dat een probleem kunnen zijn.

[ Voor 88% gewijzigd door Gé Brander op 23-02-2011 10:14 ]

[nielsl]

geweldig, dank voor de reacties en de duwtjes in de goede richting. Meer duwtjes zijn vanzelfsprekend altijd welkom, desalniettemin kan ik even vooruit!

Thanks!

[djc]

Ik zou eens kijken naar CouchDB replication. Is even wat anders dan je standaard RDBMS, maar volgens mij bij uitstek geschikt voor het soort dingen dat je hier wil doen. Als je vragen hebt, laat maar weten.

http://guide.couchdb.org/draft/replication.html
http://wiki.apache.org/couchdb/Replication

[ Voor 18% gewijzigd door djc op 23-02-2011 12:31 . Reden: linkjes ]

[BCC]

CouchDB of MongoDB kunnen dit dmv http://www.mongodb.org/display/DOCS/Replication en http://www.mongodb.org/display/DOCS/Sharding . Ik zou hiervoor Couch pakken.

[ Voor 19% gewijzigd door BCC op 23-02-2011 11:27 ]

[bomberboy]

The Lord schreef op woensdag 23 februari 2011 @ 10:03:
[...]

Ik zou zoiets niet met een database oplossen, maar iets wat 'loosely coupled' is van nature. En dan kom je al snel op een message bus.

Zoiets is een mogelijkheid. Een database is hier volgens mij helemaal niet nuttig aan de client kant.

Het lijken eigenlijk ook allemaal inserts die je gaat doen als ik je verhaal zo lees?

enkele "eenvoudigere" oplossingen die volgens mij ook een pak robuuster zijn

• upload een (xml-)bestandje met de actie die je wenst naar de server. Een parser aan de serverkant leest het en voert de gerelateerde db-acties uit. Als het de upload (via ftp, http-post, iets anders) niet gelukt is weet je client dat wel, en indien wel, dan moet je server problemen maar afvangen.
• ipv een bestandje te uploaden gewoon via een html form of iets dergelijks werken. Is misschien wat eenvoudiger aan de client kant
• maak er een webservice van (al dan niet restful)

conclusie: stop alle db-acties aan de serverkant en gebruik een "lichte" client. Bij bovenstaande acties heb je altijd feedback in de client of een actie gelukt is of niet (zij het een error code dat de upload ofzo mislukt is of een echte response van je server). De eigenlijke transactie moet je dan maar aan de serverkant (centraal) implementeren.

Logica aan de client-kant is zeer eenvoudig en je kan het netwerkverkeer sterk minimaliseren. Altijd handig als je 3G op een bepaald moment terugvalt naar gprs ofzo. (succes met je rechtstreekse db-toegang over gprs)