it-swarm-eu.dev

Který DBMS je vhodný pro velmi rychlé čtení a jednoduchou strukturu dat?

Vyvíjím produkt, který jako součást své činnosti musí sledovat velké množství souborů/adresářů. Záměrem je ukládat informace o statu do databáze a při spuštění vytvořit hodinky pro každý soubor. Soubory, které se změní, budou zařazeny do fronty (v databázi) pro skupinovou synchronizaci se vzdálenou databází. Budou synchronizovány v pořadí podle priority, číslo mezi 1-10.

Informace o databázi:

  • <100 000 záznamů statistik
  • Celá databáze čtená při spuštění, je nutná pouze cesta k souboru
  • Soubory ve frontě budou mít prioritní pole (není třeba hledat nic jiného)
  • Vložení může být pomalé

Našel jsem pár databází, o kterých si myslím, že budou fungovat, ale nejsem si jistý, která by byla nejlepší:

  • Redis - uložit cestu k souboru jako klíč, stat data jako hodnotu; fronta by byl seznam
  • MongoDB - více možností dotazů než Redis, ale stále rychlé

Domnívám se, že nejlepším řešením by byla databáze NoSQL, protože zde není příliš mnoho relační logiky a celková velikost dat není příliš velká (něco jako <100 mb, blíže k <30 mb). Podíval jsem se na SQLite, protože se zdá být dost jednoduchý na vložení do instalovatelné aplikace.

Protože se jedná o distribuovanou aplikaci pro koncové uživatele a ne o vysokorychlostní server, databáze nemusí podporovat mnoho současných uživatelů. Hlavní prioritou je nalezení databáze, jejíž model má největší smysl.

Takže otázka, která databáze by byla pro tuto situaci nejvhodnější?

Existují také nějaké jiné databáze, které by pro takovou aplikaci dávaly větší smysl?

16
beatgammit

První věc, která mi přijde na mysl, je konkrétní RDBMS, který je mi známý. Uznávám však, že pro tuto aplikaci nemusí být nejlepší.

Moje rada je tedy jít s databází, která je vám známá. Pokud znáte Redis nebo MongoDB, pak jděte s jedním z nich. Pokud znáte SQLite, vyberte si to.

V databázi této velikosti bude všechno rychlé. Dokonce i databáze, které jsou těžší na disku, budou používat určitý druh ukládání do mezipaměti, takže rychlost disku nebude příliš znepokojena.

9
Richard

Pokud se netýkáte relační logiky, chcete opravdu rychlou rychlost čtení a jste ochotni pracovat s RDBMS, rozhodně bych se rozhodně rozhodl říci MySQL. Proč ???

Úložný modul MyISAM má možnost, která umožňuje rozšířit fyzickou strukturu tabulky pro lepší výkon. Jaká je tato možnost? Možnost ALTER TABLE ROW_FORMAT.

Například kniha MySQL Database Design and Tuning doporučuje používat ROW_FORMAT = FIXED na stránkách 72,73. Tím interně převedete všechna pole VARCHAR na CHAR. Zvětší tabulku MyISAM, ale provedené SELECTy proti ní budou mnohem rychlejší. Mohu to osobně doložit. Jednou jsem měl stůl, který byl 1,9 GB. Změnil jsem formát pomocí ALTER TABLE tblname ROW_FORMAT = FIXED. Tabulka skončila 3,7 GB. Rychlost SELECTů proti ní byla o 20-25% rychlejší, aniž by došlo k vylepšení nebo změně nic jiného.

Co když již máte tabulku MyISAM, která je naplněna údaji? Měli byste získat metriky pro doporučené definice sloupců na základě údajů v tabulce MyISAM. Jaký dotaz tyto metriky představuje?

SELECT * FROM tblname PROCEDURE ANALYSE();

POSTUP ANALYZE () Data se nezobrazí. Přečte hodnotu každého sloupce a doporučí definice sloupců. Například, pokud máte typový sloupec, jehož hodnoty jsou 1-4, doporučuje se použít ENUM těchto 4 hodnot. Poté můžete použít TINYINT nebo CHAR (1), protože zabírají stejné množství místa (1 bajt).

Zde je ještě něco, co byste měli zvážit: Protože jste přemýšleli o použití NoSQL DB, přemýšleli jste někdy o použití MyISAM způsobem NoSQL? To je docela možné. Strana 175 téže knihy, kterou jsem zmínil navrhuje použít struktury HANDLER ke čtení tabulky bez relačního zavazadla . Ve skutečnosti stránka 175 uvádí tento příklad:

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;

Tato tabulka obsahuje miliony řádků. Předpokládejme, že musíte vytvořit aplikaci pro analýzu dat, která má následující požadavky:

  • Musí co nejrychleji získat bloky informací.
  • Na základě vstupu uživatele nebo jiných faktorů bude pravděpodobně „skákat“ v tabulce.
  • Nezabývá se souběžností nebo jinými problémy s integritou dat.
  • Uzamčení tabulky napříč aplikacemi není nutné.

Tyto příkazy umožňují rychlé a špinavé čtení z tabulky:

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;

Doufám, že to dá jídlo k zamyšlení. Prosím, podívejte se na to.

CAVEAT

Co je pro mě velmi ironické, když píšu tento konkrétní příspěvek, je to, že jsem napsal dřívější příspěvek o tom, jak se HANDLER používá v binárních serverech Percona a myslí si, že jeho používání bylo zastaralé . Od tohoto postu jsem nikdy nenapadlo, že budu psát něco na podporu struktur HANDLER. Nyní jsem opraven.

12
RolandoMySQLDBA