fafnir_08
Новичок
Господа, день добрый. Очень нужен толковый совет по проектированию БД.., а то у меня уже mozg.dll кипит…
Все вроде ничего, но вылез вопрос по одной из таблиц.
Среда:
Проектирую БД под mysql (база для веб-ресурса), при необходимости c дальнейшим переходом на PostgreSQL (Oracle шибко дороговатый выходит).
Использую партицирование на 1024 партиции. Репликация и горизонтальный шардинг тоже планируется, если СУБД не будет справляться с задачей так, но это в будущем.
Таблица InnoDB. Содержит небольшое количество (7-10) колонок типа INT. Ключ составной.
Задача:
Существует 1 073 741 824 возможных вариантов ключей, которые могут (будут) использоваться, к которым нужно хранить набор свойств.
Из них (свойств), заполнено в один момент времени примерно 52 428 800 строк.
Обновления и изъятие данных будет происходить постоянно. SELECTов будет гораздо больше, чем UPDATEов. Более точно сказать на этом этапе сложно.
Решение 1:
Создать таблицу с готовыми 1 073 741 824 полями, и работать с таблицей оперируя только UPDATE, SELECT, COUNT(..). Работа будет происходить с отдельными строками (массовых обработок пока не предусматривается).
Минус: Довольно “тяжелая” таблица, а если еще добавить индексацию - может выйти порядка 100 Гб.
Плюс: Индексы и количество строк не меняются (не исп. INSERT, DELETE вообще).
Решение 2:
Создать таблицу с пустым содержимым, заполнять данные по-необходимости INSERTом и удаляя уже устаревшие.
Минус: Частые вставки строк при SELECTах.
Плюс: Вес таблицы в порядке всего 5-10 Гб.
Подскажите, пожалуйста, что из этого будет быстрее работать т.к. скорость (ну, и целостность данных
)- ключевое требование к этой системе. Про оптимизацию запросов, индексации и пр. я в курсе - мне сейчас нужно решить именно вопрос проектирования.
Все вроде ничего, но вылез вопрос по одной из таблиц.
Среда:
Проектирую БД под mysql (база для веб-ресурса), при необходимости c дальнейшим переходом на PostgreSQL (Oracle шибко дороговатый выходит).
Использую партицирование на 1024 партиции. Репликация и горизонтальный шардинг тоже планируется, если СУБД не будет справляться с задачей так, но это в будущем.
Таблица InnoDB. Содержит небольшое количество (7-10) колонок типа INT. Ключ составной.
Задача:
Существует 1 073 741 824 возможных вариантов ключей, которые могут (будут) использоваться, к которым нужно хранить набор свойств.
Из них (свойств), заполнено в один момент времени примерно 52 428 800 строк.
Обновления и изъятие данных будет происходить постоянно. SELECTов будет гораздо больше, чем UPDATEов. Более точно сказать на этом этапе сложно.
Решение 1:
Создать таблицу с готовыми 1 073 741 824 полями, и работать с таблицей оперируя только UPDATE, SELECT, COUNT(..). Работа будет происходить с отдельными строками (массовых обработок пока не предусматривается).
Минус: Довольно “тяжелая” таблица, а если еще добавить индексацию - может выйти порядка 100 Гб.
Плюс: Индексы и количество строк не меняются (не исп. INSERT, DELETE вообще).
Решение 2:
Создать таблицу с пустым содержимым, заполнять данные по-необходимости INSERTом и удаляя уже устаревшие.
Минус: Частые вставки строк при SELECTах.
Плюс: Вес таблицы в порядке всего 5-10 Гб.
Подскажите, пожалуйста, что из этого будет быстрее работать т.к. скорость (ну, и целостность данных
)- ключевое требование к этой системе. Про оптимизацию запросов, индексации и пр. я в курсе - мне сейчас нужно решить именно вопрос проектирования.