Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Проектирование таблицы на 100 Гб или INSERT?
 
 автор: fafnir_08   (25.01.2016 в 22:12)   письмо автору
 
 

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





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

  Ответить  
 
 автор: cheops   (31.01.2016 в 17:33)   письмо автору
 
   для: fafnir_08   (25.01.2016 в 22:12)
 

Таблица с 1 073 741 824 полями - плохая затея, СУБД не предназначены для работы в таком режиме. Просто работайте с InnoDB, по возможности выделите побольше оперативной памяти. Если на сервере есть 16Гб оперативной памяти, то никаких проблем быть не должно, InnoDB довольно легко загоняется полностью в оперативную память (прямо назначайте innodb_buffer_pool_size 10Гб, по размеру вашей таблицы).

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

InnoDB проектировалась для поддержки больших таблиц с интенсивной записью, если её настроить, да хотя бы просто выделить оперативной памяти, она будет довольно сносно работать. Скорости Redis или MongoDB не получите (хотя бы из-за транзакций), но данные не потеряете.

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

  Ответить  
 
 автор: Trianon   (02.02.2016 в 11:20)   письмо автору
 
   для: cheops   (31.01.2016 в 17:33)
 

>Таблица с 1 073 741 824 полями - плохая затея

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

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования