Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Проектирование таблицы на 100 Гб или INSERT? 
:(
    Опции темы
fafnir08
Дата 25.1.2016, 22:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 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 Гб.





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


PM MAIL   Вверх
tzirechnoy
Дата 25.1.2016, 23:27 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1173
Регистрация: 30.1.2009

Репутация: 0
Всего: 16



Цитата
Использую партицирование на 1024 партиции.


Зачем? У вас есть 1024 жёстких диска?

Цитата
таблицу с готовыми 1 073 741 824 полями,


С готовым миллиардом чем? Поле -- это элемент строки таблицы, грубо говоря.

Цитата
Плюс: Индексы и количество строк не меняются (не исп. INSERT, DELETE вообще).


Например, постгрэссу будет вообще пофиг на этот факт. То есть он всегда делает DELETE/INSERT.

С InnoDB кажэтся не так, но и не то чтобы всё совсем так просто.

В общем, не страдайте фигнёй. делайте как обычно.
PM MAIL   Вверх
Angel666
Дата 28.1.2016, 02:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 0
Регистрация: 8.9.2011

Репутация: нет
Всего: 1



TECDOK наверное имеет такое же количество значений, посмотри как они решали такую проблему, ну или BigData https://habrahabr.ru/company/bitrix/blog/275455/

Этот ответ добавлен с нового Винграда - http://vingrad.com
PM MAIL   Вверх
Romikgy
Дата 28.1.2016, 17:09 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Любитель-программер
****


Профиль
Группа: Участник Клуба
Сообщений: 7325
Регистрация: 11.5.2005
Где: Porto Franco Odes sa

Репутация: нет
Всего: 146



Цитата(fafnir08 @  25.1.2016,  21:18 Найти цитируемый пост)
 1 073 741 824 возможных вариантов ключей


Цитата(fafnir08 @  25.1.2016,  21:18 Найти цитируемый пост)
Создать таблицу с готовыми 1 073 741 824 полями

имхо это показывается неправильный вариант создания БД , т.к. варианты ключей это не поля...


--------------------
Владение русской орфографией это как владение кунг-фу — истинные мастера не применяют его без надобности. 
smile

PM   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Общие вопросы по базам данных"
LSD
Zloxa

Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:

  • вопросам по СУБД для которых нет отдельных подфорумов
  • вопросам которые затрагивают несколько разных СУБД (например проблема выбора)
  • инструменты для работы с СУБД
  • вопросы проектирования БД
  • теоретически вопросы о СУБД

Данный форум не предназначен для:

  • вопросов о поиске разлиных БД (если не понимаете чем БД отличается от СУБД то: а) вам не сюда; б) Google в помощь)
  • обсуждения проблем с доступом к СУБД из различных ЯП (для этого есть соответсвующие форумы по каждому ЯП)
  • обсуждения проблем с написание SQL запросов, для этого есть форум Составление SQL-запросов
  • просьб о написании курсовой, реферата и т.п., для этого есть Центр помощи или фриланс биржа
  • объявлений о найме специалистов, для этого есть раздел Объявления о найме специалистов

Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение. ;)


Полезные советы:

При написании сообщения постарайтесь дать теме максимально понятное название. В теме максимально подробно опишите проблему. Если применимо укажите: название базы данных и версии (MySQL 4.1, MS SQL Server 2000 и т.п.); используемых язык программирования; способа доступа (ADO, BDE и т.д.); сообщения об ошибках.

Для вставки кода используйте теги [code=sql] [/code].

Литературу по базам данных можно поискать здесь.

Действия модераторов можно обсудить здесь.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | СУБД, общие вопросы | Следующая тема »


 




[ Время генерации скрипта: 0.1201 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.