Ось питання ...
Зважаючи на 192 трлн записів, якими мають бути мої міркування?
Моя головна турбота - швидкість.
Ось стіл ...
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`)
);
Ось запити ...
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")
Ось кілька приміток ...
- SELECT буде робитися набагато частіше, ніж ВСТУП. Однак час від часу я хочу додати кілька сотень записів одночасно.
- По мірі завантаження, годинами нічого не буде, можливо, кілька тисяч запитів відразу.
- Не думаю, що я більше не можу нормалізувати (потрібні значення p у комбінації)
- База даних в цілому дуже реляційна.
- Це буде найбільша таблиця на сьогоднішній день (наступна найбільша - близько 900 к)
ОНОВЛЕННЯ (11.11.2010)
Цікаво, що мені дали другий варіант ...
Замість 192 трлн я міг би зберігати 2,6 * 10 ^ 16 (15 нулів, тобто 26 квадрильйонів) ...
Але в цьому другому варіанті мені потрібно буде зберегти лише один bigint (18) як індекс у таблиці. Це все - лише одна колонка. Тож я би просто перевіряв наявність цінності. Іноді додаючи записи, ніколи не видаляючи їх.
Тож я змушує думати, що повинно бути краще рішення, ніж mysql для простого зберігання номерів ...
З огляду на цей другий варіант, чи варто його взяти чи дотримуватися першого ...
[редагувати] Щойно отримали новини про тестування, яке було зроблено - 100 мільйонів рядків із цією установкою повертає запит за 0,0004 секунди [/ редагувати]