|
Модераторы: LSD |
|
fafnir08 |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 25.1.2016 Репутация: нет Всего: нет |
Господа, день добрый. Очень нужен толковый совет по проектированию БД.., а то у меня уже 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 Гб. Подскажите, пожалуйста, что из этого будет быстрее работать т.к. скорость (ну, и целостность данных ;) )- ключевое требование к этой системе. Про оптимизацию запросов, индексации и пр. я в курсе - мне сейчас нужно решить именно вопрос проектирования. |
|||
|
||||
tzirechnoy |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1173 Регистрация: 30.1.2009 Репутация: 0 Всего: 16 |
Зачем? У вас есть 1024 жёстких диска?
С готовым миллиардом чем? Поле -- это элемент строки таблицы, грубо говоря.
Например, постгрэссу будет вообще пофиг на этот факт. То есть он всегда делает DELETE/INSERT. С InnoDB кажэтся не так, но и не то чтобы всё совсем так просто. В общем, не страдайте фигнёй. делайте как обычно. |
||||||
|
|||||||
Angel666 |
|
|||
Новичок Профиль Группа: Участник Сообщений: 0 Регистрация: 8.9.2011 Репутация: нет Всего: 1 |
TECDOK наверное имеет такое же количество значений, посмотри как они решали такую проблему, ну или BigData https://habrahabr.ru/company/bitrix/blog/275455/
Этот ответ добавлен с нового Винграда - http://vingrad.com |
|||
|
||||
Romikgy |
|
|||
Любитель-программер Профиль Группа: Участник Клуба Сообщений: 7325 Регистрация: 11.5.2005 Где: Porto Franco Odes sa Репутация: нет Всего: 146 |
имхо это показывается неправильный вариант создания БД , т.к. варианты ключей это не поля... -------------------- Владение русской орфографией это как владение кунг-фу — истинные мастера не применяют его без надобности. |
|||
|
||||
Правила форума "Общие вопросы по базам данных" | |
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |