|
|
|
| Господа, день добрый. Очень нужен толковый совет по проектированию БД.., а то у меня уже 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 Гб.
Подскажите, пожалуйста, что из этого будет быстрее работать т.к. скорость (ну, и целостность данных ;) )- ключевое требование к этой системе. Про оптимизацию запросов, индексации и пр. я в курсе - мне сейчас нужно решить именно вопрос проектирования. | |
|
|
|
|
|
|
|
для: fafnir_08
(25.01.2016 в 22:12)
| | Таблица с 1 073 741 824 полями - плохая затея, СУБД не предназначены для работы в таком режиме. Просто работайте с InnoDB, по возможности выделите побольше оперативной памяти. Если на сервере есть 16Гб оперативной памяти, то никаких проблем быть не должно, InnoDB довольно легко загоняется полностью в оперативную память (прямо назначайте innodb_buffer_pool_size 10Гб, по размеру вашей таблицы).
Обновление записей идут в журнал транзакций, и лишь потом от туда распределяются в фоновом режиме в табличное пространство. Если есть возможность файлы журнала транзакций можно разместить на SSD или на разделе в оперативной памяти - будет быстрее.
InnoDB проектировалась для поддержки больших таблиц с интенсивной записью, если её настроить, да хотя бы просто выделить оперативной памяти, она будет довольно сносно работать. Скорости Redis или MongoDB не получите (хотя бы из-за транзакций), но данные не потеряете.
Плюс, если у вас операции чтения превалируют над обновлениями, то вам может быть выгодна репликация. Т.е. можно поставить рядом несколько дополнительных серверов, которые будут читать данные с мастер-сервера, а запросы на чтение распределить между всеми серверами поровну. Единственное, проблема - это отставание, возможно в вашем случае это может быть критичным. Запись вставляешь, а она доступна лишь спустя несколько секунд. | |
|
|
|
|
|
|
|
для: cheops
(31.01.2016 в 17:33)
| | >Таблица с 1 073 741 824 полями - плохая затея
тредстартер, очевидно, имел в виду таблицу с таким количеством строк, заранее созданных - в противовес варианту с таблицей с пятьюдесятью миллионами строк, которые постоянно ротируются (добавляются и удаляются). | |
|
|
|