Oto pytanie ...
Biorąc pod uwagę 192 biliony rekordów, jakie powinny być moje rozważania?
Moją główną troską jest szybkość.
Oto tabela ...
CREATE TABLE `ref` (
`id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
`rel_id` INTEGER(13) NOT NULL,
`p1` INTEGER(13) NOT NULL,
`p2` INTEGER(13) DEFAULT NULL,
`p3` INTEGER(13) DEFAULT NULL,
`s` INTEGER(13) NOT NULL,
`p4` INTEGER(13) DEFAULT NULL,
`p5` INTEGER(13) DEFAULT NULL,
`p6` INTEGER(13) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY (`s`),
KEY (`rel_id`),
KEY (`p3`),
KEY (`p4`)
);
Oto pytania ...
SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"
SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"
INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")
Oto kilka notatek ...
- WYBÓR będzie wykonywany znacznie częściej niż WSTAW. Czasami jednak chcę dodać kilkaset rekordów na raz.
- Pod względem obciążenia nie będzie nic przez wiele godzin, a może kilka tysięcy zapytań naraz.
- Nie sądzę, że mogę już normalizować (potrzebuję wartości p w kombinacji)
- Baza danych jako całość jest bardzo relacyjna.
- To będzie jak dotąd największy stół (następny największy to około 900 tys.)
AKTUALIZACJA (08.11.2010)
Co ciekawe, dostałem drugą opcję ...
Zamiast 192 trylionów mógłbym zapisać 2,6 * 10 ^ 16 (15 zer, co oznacza 26 biliardów) ...
Ale w tej drugiej opcji musiałbym przechowywać tylko jeden bigint (18) jako indeks w tabeli. To wszystko - tylko jedna kolumna. Chciałbym więc po prostu sprawdzić, czy istnieje wartość. Czasami dodając rekordy, nigdy ich nie usuwając.
Dlatego myślę, że musi istnieć lepsze rozwiązanie niż mysql do przechowywania liczb ...
Biorąc pod uwagę tę drugą opcję, powinienem ją wziąć lub trzymać się pierwszej ...
[edytuj] Właśnie otrzymałem wiadomość o przeprowadzonych testach - 100 milionów wierszy z tą konfiguracją zwraca zapytanie w 0,0004 sekundy [/ edit]