Opbouw website met grote database

Pagina: 1
Acties:

Vraag


Acties:
  • 0 Henk 'm!

  • nigeej
  • Registratie: Februari 2014
  • Laatst online: 06-10 06:57
Mijn vraag

Wij zijn aan de gang met een website met een database van minimaal 4 miljoen regels waar frequent doorheengezocht moet worden.

We willen starten met bouwen met het bouwen van de applicatie in javascript of wellicht een andere taal.
Het belangrijkste is dat er vlug door de database gezocht kan worden.

Welke API's zijn voor ons relevant? en hoe pakken we ons project het beste aan?

Relevante software en hardware die ik gebruikk

Op het moment runnen we het in JAVA EE, met JSP, maar dit is voor de client uiteindelijk niet handig.
De database is op het moment in Mysql.

Wat ik al gevonden of geprobeerd heb

we zijn aan het kijken naar oplossingen front end met:
react.js
elasticsearch.js
node.js

Voor back-end hebben we nog geen idee wat er het efficientste en relevantste is.

Beste antwoord (via nigeej op 19-02-2016 19:17)


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Wij zijn aan de gang met een website met een database van minimaal 4 miljoen regels waar frequent doorheengezocht moet worden.
Definieer "regels" (3 velden? 400 velden? Welke types? Indices? Etc. etc.), definieer "frequent" (100 keer per dag of 100 keer per seconde?), definieer "doorheengezocht" (simpele 'where foo = bar' of facetted search etc. etc.).
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
We willen starten met bouwen met het bouwen van de applicatie in javascript of wellicht een andere taal.
Het belangrijkste is dat er vlug door de database gezocht kan worden.
Hoe zijn die twee in hemelsnaam gerelateerd? JS heeft niets met je DB te maken en omgekeerd (tenzij je node.js gebruikt, maar da's een ander verhaal). Dus érgens zul je toch een stukje server-side 'middleware' moeten hebben die het gedoe met je DB afhandelt en wat Json o.i.d. uitspuugt. Wat zijn de mogelijkheden, welke talen/frameworks beheers je (of je programmeurs), wat is 't platform waar 't op moet gaan draaien (datacentertje vol met servers of een enkele raspberry pi?), etc. etc.
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Welke API's zijn voor ons relevant?
Hoe moeten wij daar in hemelsnaam een zinnig antwoord op geven? We hebben toch geen kristallen bol? De API's die voor jullie relevant zijn zijn voor jullie relevant. Definieer 'relevant'.
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Op het moment runnen we het in JAVA EE, met JSP, maar dit is voor de client uiteindelijk niet handig.
Huh? Hoezo is dat voor de client niet handig? Definieer "niet handig". Het draait niet op de client nee, maar het zal je browser toch roesten welk framework/taal/whatever er server-side draait? Als 'ie z'n Json (of XML of...) maar krijgt.
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Wat ik al gevonden of geprobeerd heb

we zijn aan het kijken naar oplossingen front end met:
react.js
elasticsearch.js
node.js

Voor back-end hebben we nog geen idee wat er het efficientste en relevantste is.
Hier noem je echt een paar totaaaaaal verschillende dingen; node.js is backend (dus waarom die in je lijstje met front-end staat...?), react.js is een UI framework, elasticsearch.js is een Elasticsearch client library voor Node.js en je browser. Zijn dit gewoon random termen die uit google kwamen fietsen of heb je je ook daadwerkelijk ingelezen in de materie?

Ik heb hier een behoorlijk klok-en-klepel gevoel bij; sorry.

Maar goed: als je nu eens wat opties opnoemt en, doe eens gek, daar de pro's en cons van uiteen zet en dat aan ons voorlegt als je het lastig vindt een keuze te maken. Als je dan concrete eisen (MOSCOW comes to mind, requirements uitschrijven ook) uiteenzet en aangeeft wat 't uiteindelijke doel is dan kunnen we, met de rest van de informatie waar ik om vroeg eerder in deze post, misschien iets zinnigs zeggen. Er staat werkelijk niets concreets in je topicstart anders dan "4 miljoen regels in MySQL", "Nu Java EE met JSP" en zelfs die twee zijn op z'n zachts gezegd nogal "breed".

In essentie is je topicstart nu niet veel meer dan "Ik wil een wit voertuig bouwen dat snel moet zijn, uitzicht naar buiten biedt en gebouwd is met schroeven". Dan moet je 't niet gek vinden als je antwoorden krijgt die uiteenlopen van dit naar dit naar dit naar dit naar dit. En dan heb je, vanwege al die vaagheden, altijd nog mensen die komen aandraven met dit en dat kan ik ze nog niet kwalijk nemen dan ook ;)

[ Voor 17% gewijzigd door RobIII op 19-02-2016 18:48 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Alle reacties


Acties:
  • Beste antwoord
  • +2 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Wij zijn aan de gang met een website met een database van minimaal 4 miljoen regels waar frequent doorheengezocht moet worden.
Definieer "regels" (3 velden? 400 velden? Welke types? Indices? Etc. etc.), definieer "frequent" (100 keer per dag of 100 keer per seconde?), definieer "doorheengezocht" (simpele 'where foo = bar' of facetted search etc. etc.).
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
We willen starten met bouwen met het bouwen van de applicatie in javascript of wellicht een andere taal.
Het belangrijkste is dat er vlug door de database gezocht kan worden.
Hoe zijn die twee in hemelsnaam gerelateerd? JS heeft niets met je DB te maken en omgekeerd (tenzij je node.js gebruikt, maar da's een ander verhaal). Dus érgens zul je toch een stukje server-side 'middleware' moeten hebben die het gedoe met je DB afhandelt en wat Json o.i.d. uitspuugt. Wat zijn de mogelijkheden, welke talen/frameworks beheers je (of je programmeurs), wat is 't platform waar 't op moet gaan draaien (datacentertje vol met servers of een enkele raspberry pi?), etc. etc.
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Welke API's zijn voor ons relevant?
Hoe moeten wij daar in hemelsnaam een zinnig antwoord op geven? We hebben toch geen kristallen bol? De API's die voor jullie relevant zijn zijn voor jullie relevant. Definieer 'relevant'.
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Op het moment runnen we het in JAVA EE, met JSP, maar dit is voor de client uiteindelijk niet handig.
Huh? Hoezo is dat voor de client niet handig? Definieer "niet handig". Het draait niet op de client nee, maar het zal je browser toch roesten welk framework/taal/whatever er server-side draait? Als 'ie z'n Json (of XML of...) maar krijgt.
nigeej schreef op vrijdag 19 februari 2016 @ 18:01:
Wat ik al gevonden of geprobeerd heb

we zijn aan het kijken naar oplossingen front end met:
react.js
elasticsearch.js
node.js

Voor back-end hebben we nog geen idee wat er het efficientste en relevantste is.
Hier noem je echt een paar totaaaaaal verschillende dingen; node.js is backend (dus waarom die in je lijstje met front-end staat...?), react.js is een UI framework, elasticsearch.js is een Elasticsearch client library voor Node.js en je browser. Zijn dit gewoon random termen die uit google kwamen fietsen of heb je je ook daadwerkelijk ingelezen in de materie?

Ik heb hier een behoorlijk klok-en-klepel gevoel bij; sorry.

Maar goed: als je nu eens wat opties opnoemt en, doe eens gek, daar de pro's en cons van uiteen zet en dat aan ons voorlegt als je het lastig vindt een keuze te maken. Als je dan concrete eisen (MOSCOW comes to mind, requirements uitschrijven ook) uiteenzet en aangeeft wat 't uiteindelijke doel is dan kunnen we, met de rest van de informatie waar ik om vroeg eerder in deze post, misschien iets zinnigs zeggen. Er staat werkelijk niets concreets in je topicstart anders dan "4 miljoen regels in MySQL", "Nu Java EE met JSP" en zelfs die twee zijn op z'n zachts gezegd nogal "breed".

In essentie is je topicstart nu niet veel meer dan "Ik wil een wit voertuig bouwen dat snel moet zijn, uitzicht naar buiten biedt en gebouwd is met schroeven". Dan moet je 't niet gek vinden als je antwoorden krijgt die uiteenlopen van dit naar dit naar dit naar dit naar dit. En dan heb je, vanwege al die vaagheden, altijd nog mensen die komen aandraven met dit en dat kan ik ze nog niet kwalijk nemen dan ook ;)

[ Voor 17% gewijzigd door RobIII op 19-02-2016 18:48 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij