Który DBMS jest dobry do superszybkich odczytów i prostej struktury danych?

Opracowuję produkt, który w ramach jego działania musi śledzić dużą liczbę plików / katalogów. Chodzi o to, aby przechowywać dane statystyczne w bazie danych, a następnie przy rozruchu tworzyć zegarki dla każdego pliku. Pliki, które ulegną zmianie, zostaną umieszczone w kolejce (w bazie danych) w celu synchronizacji grupy ze zdalną bazą danych. Zostaną zsynchronizowane w kolejności priorytetów, liczby od 1 do 10.

Informacje o bazie danych:

• <100 000 wpisów informacji o statystykach
• Cała baza danych odczytywana przy starcie, potrzebna jest tylko ścieżka pliku
• Pliki w kolejce będą miały pole priorytetowe (nic więcej nie będzie przeszukiwane)
• Wstawianie może być powolne

Znalazłem kilka baz danych, które moim zdaniem będą działać, ale nie jestem pewien, który byłby najlepszy:

• Redis - przechowuj ścieżkę pliku jako klucz, dane statystyki jako wartość; kolejka byłaby listą
• MongoDB - więcej opcji zapytań niż Redis, ale nadal szybko

Myślę, że baza danych NoSQL byłaby tutaj najlepszym rozwiązaniem, ponieważ nie dzieje się za dużo logiki relacyjnej, a całkowity rozmiar danych nie jest zbyt duży (coś w rodzaju <100 mb, bliżej <30 mb). Spojrzałem na SQLite, ponieważ wydaje się on wystarczająco prosty, aby osadzić go w instalowalnej aplikacji.

Ponieważ jest to aplikacja rozproszona dla użytkowników końcowych, a nie serwer o wysokim obciążeniu, baza danych nie musi obsługiwać wielu jednoczesnych użytkowników. Głównym priorytetem jest tutaj znalezienie bazy danych, której model ma największy sens.

Pytanie, która baza danych byłaby najbardziej odpowiednia w tej sytuacji?

Czy istnieją też inne bazy danych, które mogłyby mieć sens w przypadku takiej aplikacji?

Pierwszą rzeczą, jaka przychodzi mi na myśl, jest znany mi RDBMS. Rozumiem jednak, że ta aplikacja może nie być najlepsza.

Tak więc, radzę wybrać znaną Ci bazę danych. Jeśli znasz Redis lub MongoDB, wybierz jeden z nich. Jeśli bardziej znasz SQLite, wybierz to.

W bazie danych tego rozmiaru wszystko będzie dość szybkie. Nawet bazy danych, które są bardziej obciążone na dyski, używają pewnego rodzaju buforowania, więc szybkość dysku nie stanowi większego problemu.

Jeśli nie interesuje Cię logika relacyjna, chcesz naprawdę dużej prędkości odczytu i chcesz pracować z RDBMS, zaryzykowałbym stwierdzenie MySQL. Dlaczego ???

Silnik pamięci masowej MyISAM ma opcję, która umożliwia zwiększenie fizycznej struktury tabeli w celu uzyskania lepszej wydajności. Co to za opcja? Opcja ALTER TABLE ROW_FORMAT.

Na przykład książka Projektowanie i dostrajanie bazy danych MySQL zaleca użycie ROW_FORMAT = FIXED na stronach 72,73. Spowoduje to wewnętrzną konwersję wszystkich pól VARCHAR na CHAR. Sprawi to, że tabela MyISAM będzie większa, ale wykonanie na niej SELECT będzie znacznie szybsze. Mogę osobiście to poświadczyć. Kiedyś miałem stół o pojemności 1,9 GB. Zmieniłem format za pomocą ALTER TABLE tblname ROW_FORMAT = FIXED. Tabela skończyła się 3,7 GB. Szybkość WYBORÓW przeciwko niemu była o 20-25% większa bez poprawy lub zmiany czegokolwiek innego.

Co jeśli masz już tabelę MyISAM wypełnioną danymi? Można uzyskać dane dla zalecanych definicji kolumn na podstawie danych obecnych w tabeli MyISAM. Jakie zapytanie przedstawia te wskaźniki?

SELECT * FROM tblname PROCEDURE ANALYSE();

ANALIZA PROCEDURY () To nie wyświetla danych. Odczyta wartość każdej kolumny i zaleci definicje kolumn. Na przykład, jeśli masz kolumnę typu, której wartości wynoszą 1-4, byłoby najbardziej podejrzane przy użyciu ENUM tych 4 wartości. Możesz wtedy użyć TINYINT lub CHAR (1), ponieważ zajmują tyle samo miejsca (1 bajt).

Oto jeszcze jedna rzecz do rozważenia: skoro zastanawiałeś się nad użyciem bazy danych NoSQL, czy myślałeś kiedyś o użyciu MyISAM w sposób NoSQL? Jest to całkiem możliwe. Strona 175 tej samej książki, o której wspomniałem, sugeruje użycie struktur HANDLER do czytania tabeli bez relacyjnego bagażu . W rzeczywistości strona 175 podaje ten przykład:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

Ta tabela zawiera miliony wierszy. Załóżmy, że musisz utworzyć aplikację do analizy danych, która ma następujące wymagania:

• Musi jak najszybciej odzyskać bloki informacji.
• Na podstawie danych wprowadzonych przez użytkownika lub innych czynników prawdopodobnie „przeskoczy” w tabeli.
• Nie dotyczy to współbieżności ani innych problemów z integralnością danych.
• Blokowanie tabel między aplikacjami nie jest wymagane.

Te polecenia pozwalają na szybkie i brudne odczytywanie z tabeli:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

Mam nadzieję, że to da do myślenia. Proszę spojrzeć na to.

CAVEAT

Ironiczne jest to, że piszę ten konkretny post, ponieważ napisałem wcześniejszy post o używaniu HANDLERA w plikach binarnych serwera Percona i uważam, że użycie go było nieaktualne . Od tego starszego postu nigdy nie myślałem, że kiedykolwiek napiszę coś na poparcie struktur HANDLER. Teraz stoję poprawiony.