"Nu - hoe zou u het beschreven probleem aanpakken?"
Met eenvoudige platte bestanden.
Dit is waarom
Je hebt 2.000.000 entiteiten. Partitie op basis van entiteitsnummer:
level1= entity/10000
level2= (entity/100)%100
level3= entity%100
Elk gegevensbestand is level1/level2/level3/batch_of_data
U kunt dan alle bestanden in een bepaald deel van de map lezen om voorbeelden terug te sturen voor verwerking.
Als iemand een relationele database wil, laad dan bestanden voor een bepaalde entiteit_id in een database voor gebruik.
Bewerken Op dagnummers.
-
De
date_id/entity_iduniciteitsregel is niet iets dat aangepakt moet worden. Het is (a) triviaal opgelegd aan de bestandsnamen en (b) niet relevant voor het opvragen. -
De
date_id"rollover" betekent niets -- er is geen zoekopdracht, dus het is niet nodig om iets te hernoemen. Dedate_idmoet gewoon groeien zonder gebonden te zijn vanaf de epoch-datum. Als u oude gegevens wilt wissen, verwijder dan de oude bestanden.
Aangezien geen enkele zoekopdracht afhankelijk is van date_id , er hoeft nooit iets mee gedaan te worden. Het kan de bestandsnaam zijn voor alles wat er toe doet.
Om de date_id op te nemen in de resultatenset, schrijf het in het bestand met de andere vier attributen die in elke rij van het bestand staan.
Bewerken bij openen/sluiten
Voor het schrijven moet u de bestanden open laten. Je voert periodieke flushes uit (of sluit/heropent opnieuw) om er zeker van te zijn dat dingen echt naar de schijf gaan.
Je hebt twee keuzes voor de architectuur van je schrijver.
-
Zorg voor één enkel 'schrijver'-proces dat de gegevens van de verschillende bron(nen) consolideert. Dit is handig als vragen relatief vaak voorkomen. U betaalt voor het samenvoegen van de gegevens tijdens het schrijven.
-
Zorg dat er meerdere bestanden tegelijk open staan om te schrijven. Voeg bij het opvragen deze bestanden samen tot één resultaat. Dit is handig omdat zoekopdrachten relatief zeldzaam zijn. U betaalt voor het samenvoegen van de gegevens tijdens het opvragen.