rubenvdlinde
commented
2 years ago Oke my two thoughts
Vanuit de structuur die we hebben gekozen loopt bijna alle data door de gateway heen. Vanuit snelheid en cashing overwegingen houdt de gateway van een aantal onderliggende bronnen reeds een interne index bij die in sync wordt gehouden met onderliggende bronnen.
Deze tabel wordt nu al gebruikt voor zoekopdrachten binnen de gateway waarbij het gedrag is dat daar altijd naar 1 index word gekeken, maaaaaaar dat is afgedwongen. Als we dat niet afdwingen kijkt die naar alle indexen tegelijkertijd.
Dat betekend dat het leveren van een algemene zoek functionaliteit op de gateway eigenlijk neer komt op twee primaire stappen. • Naast het alles of éen scenario een mogelijkheid creëren voor het opgeven van meerdere specifieke bronnen • Een endpoint maken waarop we deze functionaliteit beschikbaar stellen. • Een autosuggestie functionaliteit
Wierdly enough is dat niet een zo heel vel werk. Mijn voorstel is dan ook om dit eerst een poging te geven voordat we een volledig nieuw search component gaan onboarden.
Om het te kunnen vergelijken met overige voorstellen heb ik hem even lang de lijst met gezocht kenmerken uit het issue gehaald.
1. Voldoet de oplossing aan de functionele eisen: • Moet kunnen integreren in KISS interface (hebben ze een api of een whitelabel oplossing) De gateway heeft een lopgen integratie met de kiss interface via API • Zoeken in meerdere bronnen (website / smoelenboek / kennisbank / VAC) De gateway beschikt over de bronnen, of heeft adaptors daarvoor op de roadmap staan • Detailinformatie tonen in het zoekresultaat (niet doorklikken) De gateway zou in theorie de bron objecten kunnen teruggeven als zoek resultaat • Resultaten uit meerdere bronnen in een zoekresultaten overzicht De gateway beschikt over de bronnen, of heeft adaptors daarvoor op de roadmap staan • Kunnen filteren op bron De gateway beschikt over de bronnen, of heeft adaptors daarvoor op de roadmap staan • Kunnen zoeken op meerdere trefwoorden Dit ondersteund de huidige zoek functionaliteit al (inclusief wildcards, stukken van woorden etc) • Automatisch aanvullen van zoekopdrachten Dit ondersteund de gateway nog niet, zouden we dus moeten toevoegen. Maar is technisch relatief simpel. • Stapgewijs kunnen verfijnen van de zoekopdracht De gateway laat nu al het filteren op verschillende object properties, taxonomieën en zelf gegevens binnen sub objecten toe • Snelle responstijd onafhankelijk van het achterliggen de systeem (caching) Teschnisch zou de functionaliteit een SQL bevragen op de reeds bestaande index tabel zijn, het aanlegen van een nieuwe index tabel voor zoekwoorden (autocompleet) en het optimaliseren van de indextabel. Dat zijn allemaal gateway interne tabelen die niet afhankenlijk zijn van onderligende bronnen. • Continu geactualiseerd In de huidige setup wordt de gateway al continu geactualiseerd op onderliggende bronnen • Eerdere zoekopdrachten kunnen terugzoeken Hiervoor hebben we het search object toegevoegd • Log van de zoekgeschiedenis kunnen teruggeven Dit word zowel afgedekt door het search object als de reeds bestaande logging • Aanknopingspunt bieden voor feedback geven op de content Dit is onder een los reviewe en notificatie issue in de huidige sprint in ontwikkeling • Presenteren van een zoekresultaat als een kennisartikel (detail inhoud van meerdere bronnen combineren) De gateway kan vanuit haar index rijke bron objecten terug geven OF gestandaardiseerde objecten • Zoeken op basis van skill (Skill = een onderwerp bv bouwen) Dit zit in de reeds uitgewerkte taxonomie oplossing • Profielinformatie (skill) uit KIS meenemen in het zoekresultaat Dit zit in de read uitgewerkte taxanomie oplossing
2. Impact van inzet van de nieuwe oplossing op de kosten Dit lijkt een van de belangrijkste voordelen, omdat we de dataset al in tabel vorm hebben kan dit relatief snel en daarmee goedkoop worden gerealiseerd. Daarnaast hebben we het hier dan over eenmalige kosten ipv vaste en of licentie kosten. Op dit moment heb ik op de radar. • Aanpassen zoek functionaliteit (8 uur) • Toevoegen extra endpoint voor nieuwe search functionaliteit (8 uur) • Bouwen van Autocompleet functie aan de hand van zoekwoorden index (8 uur) • Toevoegen extra endoint voor autocompleet functionaliteit (8 uur) • Gemeenschappelijke sessie Conduction en Icat voor testen integratie (32 uur) • Integratie website crawler (32 uur) • Verwerken resultaten, schrijven documentatie, en open source beschikbaar stellen plugin (32 uur)
Totaal: 128 uur
3. Impact van de inzet van de nieuwe oplossing op de doorlooptijd
Doordat het een uitbreiding is op zaken die we al doen en er geen volledig nieuw component hoeft te worden toegevoegd waarover ook kennis moet worden opgebouwd. Kijken we naar een relatief snelle doorlooptijd. Het zou mijn voorkeur genieten om hiervoor komende week maandag/dinsdag tijd te maken in de sprintplanning van Conduction. En dan Woensdag met ICATT de integratie te beproeven. Dan weten we volgende week donderdag al of deze richting hem gaat worden.
4. Onze ervaring of het ontbreken daarvan met de nieuwe oplossing Voordeel van deze oplossing richting is natuurlijk dat zowel conduction als ICAT reeds ervaring hebben met deze tool, en dat we toegang hebben tot de codebase om eventueele problemen tekortkomingen op te lossen
5. Voordelen Dit is een route met extreem veel grip omdat we de codebase beheren, hij is snel en daarmee goedkoop, levert minder project verstoring op in de trant van afhankelijkheden die in de praktijk toch weer anders blijken te werken. Het toevoegen van deze oplossing als open source plugin voor de gateway betekend tevens dat die beschikbaar komt voor andere commonground en dimpact projecten waarin de gateway wordt toegepast.
6. Nadelen Het is eigen ontwikkeling en daarmee per definitie risicovol (de vraag is wel of het meer risico’s oplevert dan het implementeren van een onbekend zoek component). Het drukt enigszins op de ontwikkel capaciteit ten opzichte van de rest van het project.
7. Risico's Het project bestaat feitelijk uit drie delen
- Uitbreiden bestaand zoek functionaliteit op reeds beschikbare index, dit is zeer te overzien
- Ontwikkelen zoekwoorden index ten behoeve van auto compleet, dit is echt iets nieuws maar er is een redenlijk goed beeld bij. We leggen een apparte tabel aan voor zoekwoorden ordenen deze op occurences in de index tabel en passen hier een partial match op toe. Is wat werk maar goed te scopen
- Indexeren externe websites, dit is het grootste risico (was het overigens al bij elastic search). Gut feeling is dat hier open source tools of libaries voor beschickbaar zijn die we kunnen integreren (we kennen er in ieder geval één) maar daar zouden we echt nog even in moetne duiken om dit risico af te dekken.
sytskevanhasselt
Als Dimpact wil ik een alternatief voor Elastic of de metaindex van Elastic omdat we volgens de principes van Common Ground niet met closed source willen werken.
Toelichting
We gebruiken meta-indezering van elastic om de index van verschillende bronnen in een zoekoverzicht te laten zien. We gingen uit van 125 euro per maand licentie voor meta-index. Het blijkt dat 10K is voor de on-premise variant die wij gebruiken. We ondersoeken de volgende alternatieven:
Maak een hoogover rapport met de volgende onderdelen:
Functionele eisen vanuit KISS (hst 3 van de userstories):
Acceptatiecriteria
Functionele teststappen
Taken Conduction
Taken ICATT
Taken DIMPACT
Discussie