Hej,

min ansøgning (faktisk bibliotek) indekserer en fil af mange GB producerer tabeller (arrays af offset-og længden af data indekseret) til senere genbrug. Tabellerne produceret er temmelig store også så store, at jeg løb tør for hukommelse i min proces (3 GB grænse), når indeksering mere end 8GB af filen eller deromkring. Selv om jeg kunne gaffelgreb en anden proces til at fungere omkring hukommelse begrænse størrelse, ville det ikke løse problemet, så jeg vil gerne dump tabellerne til en fil for at frigøre hukommelse, og undgå at re-indeks samme fil mere end én gang.

Huske på, at i øjeblikket, de skemaer, der holdes i hukommelsen i et enkelt-linked liste, der deles med en anden tråd, at bruge det til at producere en anden liste over filtrerede data. Så jeg vil hellere ikke ændre dette skema. Den anden tråd kun få adgang til listen, når hele filen er indekseret.

Nu er de spørgsmål, jeg spørger mig selv, er:

- Hvornår og hvordan er det bedste tidspunkt til at dumpe de tabeller, som en fil?

Dumping en tabel, som den får fuld lyder ikke særlig effektiv til mig. Vil jeg holde mig intet i hukommelsen? Den er knyttet liste vil altid være tom? Hvis jeg beslutter at holde N tabellerne i hukommelsen, og dump hvert N, hvordan kan jeg undgå at foretage en kontrol for, hvor mange tabeller jeg har
i hukommelsen på alle cyklus?

- Hvem skal dump metadataene fremstillet til fil? Forskellige tråd? Samme tråd, at indeksere data? Jeg også vil ikke gerne producere metadata filer, når filen er forarbejdet, er mindre end en giga (lille fil tilfældet), men samtidig ville jeg ikke ønsker at komplekse koden i indekseringen, at der lige nu er ret enkelt: parse, finde de data, skal du oprette en post tabellen, skal du tilføje det. Hvis bordet er fyldt op, skabe et andet og føje den til forbundet listen.

- Lad os sige, Jeg regnede ud (tak til dig) den bedste måde (i mit tilfælde) til at dumpe de metadata. Hvilken politik skal jeg bruge til at indlæse data med henblik på at lade den anden tråd
filtrering indekset data uden radikalt ændre den måde, det fungerer nu (f.eks gennem forbundet liste)?

En løsning, der kommer efter min mening at ville undgå en drastical ændre i mit skema er at skabe en "list manager", som ville give et interface til at tilføje og hente element fra listen. Denne enhed (enten en tråd eller en proces) ville tage sig af at holde nogle data i hukommelsen (forbundet liste) og nogle andre i filen.

Please deler med mig dine evner og erfaring! :-)

Thanks in advance.

Hilsen,
S.

Wow, hvad et spørgsmål. Er du re-engineering en database system?
Den lidt mindre end gigabyte grænser. Actually, 256 kB blokke også arbejde meget godt.
Hvis det i en anden tråd, what's the point? Man kan ikke bare fri hukommelsen, hvis den anden tråd, stadig har en lås på det.
Jeg tror ikke, der er ansvarlig, medmindre man virkelig kender din eksisterende software-arkitektur.

Nope. I'm just forsøger at skrive en ansøgning så effektiv som muligt, som er nødt til at dumpe indekserer bordet, og jeg gerne vil vide så meget som muligt af denne erfaring.

Mener du at fuldbyrde en fwrite af en 256KB buffer? I øjeblikket har jeg en liste, hvor hvert element (tabel) er det en bred vifte af N indrejse, til en samlet størrelse på 4KB pr array, og jeg dumper hver tabel i gang med en enkelt fwrite.

Grundlæggende en tråd (A) indekserer filen, mens en anden tråd (B) venter, at den er færdig, for at bruge produceret tabeller (som jeg brugt til at holde i hukommelsen) til at behandle oplysningerne i filen. Problemet er, at filen er indekseret er enorme (~ 30GB) og producerer mere end 4 GB data, som jeg ikke kan holde i hukommelsen (grænse på 3 GB pr processen), så på et eller andet punkt har jeg til at dumpe de producerede data i en fil for at frigøre hukommelse.

Den anden tråd (B), der er baseret på et flag, enten læse tabeller fra filen eller listen i hukommelsen.

Tak for din hjælp,
S.

Jeg kan ikke hjælpe andet end at citere en gammel software design maksime:

Du mener jeg skal bruge en database til at afholde de tabeller, som SQLite?

Som database primært afhænger af, hvordan du mange indekserbare og unikke kolonner du har, om forholdet mellem læsere til forfattere. SQLite? LOL. Jeg tænkte mere i retning af MySQL eller BerkelyDB / SleepyCat DB.

Derfor ville jeg ikke ønsker at bruge en database. Det arbejde er involveret, og afhængighed produceret, er ikke det værd i mit tilfælde (IMHO).

Jeg har kun en forfatter, og en læser.

Data skrives sekventielt, og aldrig ændres. Skriv en gang, kan du læse mange.

En ad hoc-løsning, jeg troede ville være mit bedste vej at gå.

Jeg værdsætter dine tanker om dette.

Tak,
S.