Centrale UserDB met "aangesloten" AppDB's ?

[Verwijderd]

Ik ben bezig met een aantal apps waar dezelfde users op in gaan loggen voor gebruik.

De users worden natuurlijk geauth aan de hand van username/password tegen een Database.

Mijn idee was eigenlijk om goed georganiseerd alle tabellen per app in één database te gooien, inclusief de gebruikers, ik denk hier momenteel toch anders over.

Ik ben van mening dat ik voor schaalbaarheid beter iedere app zijn eigen DB kan laten hebben zodat ik eventueel kan schalen op verschillende DB-servers als dat nodig is, dus per app.

In bovenstaand geval krijg je dus een flinterdunne userDB welke eigenlijk geen "bestaansrecht" heeft, maar om iedere user nu ook weer per app toe te voegen is wat overdreven.

oAuth heb ik ook al bekeken, of iets dat ik zelf kan draaien als authDB.

Wat zal ik doen ?

Er was in eerste instantie goed overna gedacht, ik krijg alleen een beetje veel tabellen... dus wil het weer onderverdelen in aparte DB's eigenlijk

[Marcj]

Gaat het over authenticatie of authorisatie? Dit verschil is wel belangrijk, want oAuth is bijvoorbeeld vooral gefocussed op authorisatie en kan nogal overdreven voor jouw gebruik zijn. Je kunt ook eens kijken naar OpenID.

Dit maakt het wel mogelijk om centraal gebruikers te beheren. Als dit niet een vereiste is, dan kun je natuurlijk ook elke applicatie de eigen gebruikers laten beheren.

Staan deze applicaties trouwens dicht bij elkaar? (Zeg op dezelfde server) Of staan ze overal over het internet?

[Verwijderd]

De applicaties staan dicht bij elkaar, zou dat niet het geval zijn dan zou een VPN kunnen volstaan.

Wat je zegt is een goed punt, authenticatie of authorisatie..

In de App zelf ga ik aangeven wat een user mag, dus ik kom alleen op Auth uit... tenzij AuthR meteen beter is om mee te pakken, maar dit lijkt me per app het beste in te stellen.

[Rolfie]

Ik ben van mening dat ik voor schaalbaarheid beter iedere app zijn eigen DB kan laten hebben zodat ik eventueel kan schalen op verschillende DB-servers als dat nodig is, dus per app.

Over hoeveel hebben we het? Want een vrij normale DB met goede indexen, kan al heel wat query's aan.

[Verwijderd]

Rolfie schreef op maandag 05 december 2011 @ 16:55:
[...]


Over hoeveel hebben we het? Want een vrij normale DB met goede indexen, kan al heel wat query's aan.

Aantallen is nog niet bepaald.

Ik weet dat een goed ingerichte database prima kan performen, maar het kan op zich handig zijn de DB's te scheiden... dus vandaar dat de manier van scheiden me interesseert.

[JaQ]

Verwijderd schreef op maandag 05 december 2011 @ 14:24:
De users worden natuurlijk geauth aan de hand van username/password tegen een Database.

Klinkt als iets wat je in ldap wilt stoppen

[Apache]

Je kan ook eens kijken naar atlassian crowd. Die doen iets gelijkaardigs en maken api's beschikbaar.

[Janoz]

Verwijderd schreef op maandag 05 december 2011 @ 17:03:
maar het kan op zich handig zijn de DB's te scheiden... dus vandaar dat de manier van scheiden me interesseert.

Probeer het bold stukje eens te onderbouwen. Ik blijf een heel hoog premature optimization naasmaakje houden.

[cariolive23]

Verwijderd schreef op maandag 05 december 2011 @ 17:03:
[...]


Aantallen is nog niet bepaald.

Er is dus geen probleem en je kunt dus ook geen probleem oplossen. Je kunt zelfs niet testen of je het probleem hebt opgelost, er is namelijk geen probleem.

Dit wordt een lastig verhaal.

Ik weet dat een goed ingerichte database prima kan performen, maar het kan op zich handig zijn de DB's te scheiden... dus vandaar dat de manier van scheiden me interesseert.

Even een paar cijfers van mijn situatie:
- 2 miljoen unieke bezoekers per dag
- 100 miljoen webpagina's per dag
- 500 concurrent users
- 1 database, PostgreSQL. (met nog een slave, die niet wordt gebruikt door bezoekers)
- connection pool (pgPool)

Dankzij die ene database is beheer lekker eenvoudig, ik zou er niet aan moeten denken om hier tientallen, honderden of zelfs 2 miljoen databases te moeten gaan onderhouden. Dat wordt een dagtaak, nu is het niet meer dan in een paar minuten wat controles uitvoeren en een bak koffie drinken.

We gebruiken stevige hardware, 4x6core Opteron en 128GB RAM, maar dat zijn (gezien het aantal klanten) de kosten niet, +/- 15.000 euro (5000 per jaar).

Gebruik de database op een slimme manier en laat deze voor jou werken: Dan hoef je zelf minder te doen.

[creator1988]

Het hebben van een losse database met users kan overigens ook een goed idee zijn. Als voorbeeld de situatie die we bij funda gebruikten (gesimplificeerd). Aan de voorkant hebben ze twee rollen.

- Frontend databaseservers, puur read performance, schaalt horizontaal eenvoudig.
- Profielen store, per website een (funda in business, funda.nl, etc.)

Alle websites praten tegen dezelfde frontend databases aan. De profielen stores moeten gescheiden zijn per site, en door losse databases hiervoor te hebben kan je hetzelfde schema gebruiken. Ergo: code reusage binnen de sites, alleen de connection string moet anders. Bovendien kan je ook nog eens overstappen op een andere database store als je verder wil schalen (MongoDB f.e.) zonder het uit elkaar te trekken.

Alle externe applicaties, zowel van 3rd parties (Layar, leveranciers, etc.) als intern (mobiele site, iPhone app) praten via OAuth (extern) of xAuth (intern) tegen de API aan, die fungeert als losse Auth module. Wat heel transparant is. Bovendien kan je alle tokens revoken mocht een van de databases van deze applicaties worden gehackt.

[kwaakvaak_v2]

Ik krijg een heel sterk PDF dejavu bij dit topic, het lijkt erop dat Rutger vooral druk is met theoritisch oplossen van problemen die er eigenlijk niet zijn. Kan het mis hebben.... Maar ik vrees dat de uitkomst gaat zijn dat ie toch geen lib wil gebruiken en alles zelf wil maken.

Voor de rest ben ik het deels met cariolive eens, beter 1 DB die goed opgezet is dan 50.000 splinter DB's waarbij het onderhoud er niet makkelijker op wordt.

[Verwijderd]

Ik ben het opzich wel met Creator1988 eens. Als je nog geen probleem hebt, moet je er wel vanuit gaan dat je die kunt krijgen als je zaken niet "schaalbaar" oplost.

De manier van Creater1988 kan je vergelijken met een "bolted-on" systeem waarbij je basis fungeert om andere "plugins" te gebruiken. Vallen die plugins weg dan trek je niet alle andere plugins mee.

Dat is niet theoretisch problemen op willen lossen die er niet zijn, dat is mijn inziens toekomst-visie.

[Voutloos]

|--praktijkKorteTermijn---------theorieLangeTermijn-------|     *
                                                                ^ You are here

Je opent wekelijks een topic over iets waar je een maand bezig kan zijn, ergo kan je app nooit af komen.

En al komt die af, dan nog moet je maar hopen dat het echt zo populair wordt. Prima om een beetje lange termijn te denken en dingen netjes op te lossen, maar imo verlies jij de praktijk teveel uit het oog. Daar word je aardig genoeg in bijna elk topic wel op gewezen, dus blijkbaar ben je te koppig om van GoT iets te leren.

[Verwijderd]

Voutloos schreef op woensdag 07 december 2011 @ 12:49:

|--praktijkKorteTermijn---------theorieLangeTermijn-------|     *
                                                                ^ You are here

Je opent wekelijks een topic over iets waar je een maand bezig kan zijn, ergo kan je app nooit af komen.

En al komt die af, dan nog moet je maar hopen dat het echt zo populair wordt. Prima om een beetje lange termijn te denken en dingen netjes op te lossen, maar imo verlies jij de praktijk teveel uit het oog. Daar word je aardig genoeg in bijna elk topic wel op gewezen, dus blijkbaar ben je te koppig om van GoT iets te leren.

Ik denk dat je hier niet over kan oordelen gezien het feit dat niet niet inzichtelijk hebt om wat voor omvang het gaat.

Overigens hoeft iets dat nodig is niet populair te zijn. We leven niet allemaal met Facebook aan onze zijde.

[SvMp]

Ik heb met een vergelijkbaar probleem te maken gehad.
In mijn geval was het zo dat de apps sommige data delen, dus was een centrale database gerechtvaardigd. Deze is ook uitgerust met de user-tabellen.