Господа, день добрый. Очень нужен толковый совет по проектированию БД.., а то у меня уже 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 Гб.




Подскажите, пожалуйста, что из этого будет быстрее работать т.к. скорость (ну, и целостность данных ;) )- ключевое требование к этой системе. Про оптимизацию запросов, индексации и пр. я в курсе - мне сейчас нужно решить именно вопрос проектирования.

авторрешение 2 очистка устаревших по крону (ночью)

Данные должны быть актуальны в каждый момент времени. Т.е. "лишние" или те, которы стали не актуальны будут сразу стираться (или удаляться значения свойств в строке).

miksoftНасколько фундаментально это число? Есть вероятность, что в процессе эксплуатации системы оно изменится?

Нет - оно на всю жизнь системы.

miksoftЕсть мысль, что, возможно, плоский файл окажется эффективнее, чем СУБД.

В этом случае, я так думаю, становится сложнее репликация при кластеризации на несколько серверов.

miksoftВпрочем, вы не описали ни запросы, ни требований к их времени выполнения.

В основном - запросы SELECT от 1 до 1024 записей за один запрос, скорость - чем быстрее тем лучше, но не дольше 0,5 - 1 сек.

авторВ основном - запросы SELECT от 1 до 1024 записей за один запрос, скорость - чем быстрее тем лучше, но не дольше 0,5 - 1 сек.

Прошу прощения - 0,05 - 0,1 сек.

miksoftЕсли недолго, то имеет смысл подумать про in-memory СУБД.

Хранение постоянное, как и использование таблицы - она будет ведущей в базе. Спасибо за совет насчет in-memory СУБД, покопаюсь в мануалах.

ScareCrowавторМинус: Частые вставки строк при SELECTах.
а почему это минус?

Ключ у меня не автоинкриментный. Т.е. придется использовать INSERT INTO .... ON DUPLICATE KEY UPDATE ...
С моей точки зрения, это вызовет очереди из за блокировки строк при INSERT и увеличит время запросов (UPDATE все-таки малость быстрее).

Поправьте меня, если ошибаюсь.

MasterZivо чем топик?

Если в двух словах - о моих тупняках при проектировании БД :)

miksoftЕсли недолго, то имеет смысл подумать про in-memory СУБД. При экономном проектировании возможно целиком разместиться в оперативке.

Подойдет ли для этого вот такая штука - The MEMORY (HEAP) Storage Engine ?
https://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html

Естественно, с репликацией, в свою очередь, данных в нормальную таблицу на SSD для повышения отказоустойчивости. Отключение питания в нормальных датацентрах ОЧЕНЬ большая редкость, но все-же бывает.