2014-11-23 6 views
5

tworzę plik do półek z sekwencji genomowej pliku FASTA:półek rozmiar słownika jest> 100GB do pliku tekstowego 2Gb

# Import necessary libraries 
import shelve 
from Bio import SeqIO 

# Create dictionary of genomic sequences 
genome = {} 
with open("Mus_musculus.GRCm38.dna.primary_assembly.fa") as handle: 
    for record in SeqIO.parse(handle, "fasta"): 
     genome[str(record.id)] = str(record.seq) 

# Shelve genome sequences 
myShelve = shelve.open("Mus_musculus.GRCm38.dna.primary_assembly.db") 
myShelve.update(genome) 
myShelve.close() 

sam plik jest 2,6 GB, jednak gdy próbuję i odłożyć go, tworzony jest plik> 100 Gb, a mój komputer wyrzuci wiele skarg dotyczących braku pamięci i zapełnienia się dysku startowego. Wydaje się, że dzieje się tak tylko wtedy, gdy próbuję uruchomić to pod OS X Yosemite, w systemie Ubuntu działa zgodnie z oczekiwaniami. Wszelkie sugestie, dlaczego to nie działa? Używam Python 3.4.2

+0

których wersji Pythona używasz? – Daniel

+0

@ Daniel Python 3.4.2 – jma1991

+0

Czy może być on powiązany z tym? http://stackoverflow.com/questions/26574954/virtualenv-fails-on-os-x-yosemite- with-oserror – Ashalynd

Odpowiedz

2

Sprawdź, jaki interfejs jest używany dla dbm przez import dbm; print(dbm.whichdb('your_file.db') Format pliku używany przez shelve zależy od najlepszego zainstalowanego pakietu binarnego dostępnego w twoim systemie i jego interfejsach. Najnowszym jest gdbm, a dumb jest rozwiązaniem awaryjnym, jeśli nie znaleziono pliku binarnego, ndbm jest czymś pomiędzy.
https://docs.python.org/3/library/shelve.html
https://docs.python.org/3/library/dbm.html

To nie jest korzystne, aby wszystkie dane w pamięci, jeśli stracisz wszystkie pamięci dla systemu plików pamięci podręcznej. Aktualizacja za pomocą mniejszych bloków jest lepsza. Nawet nie widzę spowolnienia, jeśli elementy są aktualizowane jeden po drugim.

myShelve = shelve.open("Mus_musculus.GRCm38.dna.primary_assembly.db") 
with open("Mus_musculus.GRCm38.dna.primary_assembly.fa") as handle: 
    for i, record in enumerate(SeqIO.parse(handle, "fasta")): 
     myShelve.update([(str(record.id), str(record.seq))]) 
myShelve.close() 

Wiadomo, że bazy danych DBM stały rozdrobniony jeśli aplikacja padł po aktualizacji bez wywoływania bazy close. Myślę, że to była twoja sprawa. Teraz prawdopodobnie nie masz żadnych ważnych danych w dużym pliku, ale w przyszłości możesz zdefragmentować bazę danych przez gdbm.reorganize().

0

Miałem ten sam problem: na systemie MacOS z półką o 4 megabajtach danych wzrosła do ogromnego rozmiaru 29 gigabajtów na dysku! To oczywiście miało miejsce, ponieważ wielokrotnie aktualizowałem te same pary wartości klucza w regale.

Ponieważ moja półka bazowała na GNU dbm, mogłem użyć jego podpowiedzi na temat reorganizacji. Oto kod, który przyniósł mi plik odłożyć z powrotem do normalnego rozmiaru w ciągu kilku sekund:

import dbm 
db = dbm.open(shelfFileName, 'w') 
db.reorganize() 
db.close() 

Nie jestem pewien, czy ta technika będzie pracować dla innych (poza GNU) DBMS również. Aby przetestować system dBm zapamiętać kod pokazany przez @hynekcer:

import dbm 
print(dbm.whichdb(shelfFileName)) 

Jeśli GNU dbm jest używany przez system ten powinien wypisać „dbm.gnu” (który to nowa nazwa dla starszych gdbm).