ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Подбор железа под MySQL Сервер
9 сообщений из 34, страница 2 из 2
  2  все
Подбор железа под MySQL Сервер
    #39123649
unutcon Mephi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unutcon Mephi
Гость
miksoft,

Спасибо за ссылку - наглядно и... пугающе :).
Вариант с файлами действительно хорош, попытаюсь его тщательно обмозговать и обсудить с начальником.
По крайней мере он позволяет тот же физический размер бд сильно уменьшить.
Вот DDL таблицы "Значение", которая на данный момент хранит значения файлов.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE `znachenie` (
  `ID` bigint(12) unsigned NOT NULL AUTO_INCREMENT,
  `id_afx` int(10) unsigned NOT NULL,
  `kod_amplitud` tinyint(4) NOT NULL DEFAULT '-1',
  `kod_fazi` tinyint(4) unsigned NOT NULL,
  `amplituda` float NOT NULL,
  `faza` float NOT NULL,
  PRIMARY KEY (`ID`),
  KEY `key_id_afx_znachenie_idx` (`id_afx`),
  CONSTRAINT `key_id_afx` FOREIGN KEY (`id_afx`) REFERENCES `afx` (`ID`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;



Если одна строка в текстовом файле( полностью соответствующем загружаемым значениям в эту таблицу) занимает 30 байт, то , при занесении в БД, одна запись занимает уже 45байт данные и 17 байт индексы = 62 байта
Код: plaintext
(SHOW TABLE STATUS LIKE 'znachenie')

Miksoft, позвольте еще у вас спросить есть ли смысл смотреть в сторону BLOB полей?

И по поводу "холодных" и "горячих" данных не совсем понятно. Т.е. холодные, те что хранятся в БД, но используются редко или давно,а горячие это актуальные?. Если это так, то как можно это использовать? Все что мне в голову пришло, это хранить "горячие" данные в виде характеристик,а холодные при определенном сроке простоя переводить в вид строки, содержащей пути к файлу( как и предложено). Но в любом случае, при удалении "холодных" характеристик место InnoDB зарезервирует - хоть и данных не будет в таблице, но физическое место не освободится - или же это все таки ускорит выборки и операции загрузки?.
Много вопросов и букв, спасибо за терпение!
...
Рейтинг: 0 / 0
08.12.2015, 21:25:23
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39123652
unutcon Mephi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unutcon Mephi
Гость
Прошу прощения , редактировать нельзя...

Нашел приблизительную информацию про "горячие" и "холодные" данные.
Вот только не понимаю, как средствами MySQL физически реализовать хранения горячих данных в RAM, а холодных на HDD.
Если есть возможность, подскажите направление, где можно более детально с этим вопросом ознакомиться.
...
Рейтинг: 0 / 0
08.12.2015, 21:32:15
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39123673
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
netwind
Участник
unutcon Mephi, это вопрос оценки базы, а не попытки программировать педально-шаговую систему с учетом разделения данных на горячие и холодные.
Там все автоматически происходит : оценивают как работает база, ставят памяти чтобы оно все влезало и выставляют innodb bufer pool size соразмерно горячим данных.

Можно много чего выдумать, но вам пока не надо.
...
Рейтинг: 0 / 0
08.12.2015, 22:07:23
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39124397
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
unutcon MephiВот DDL таблицы "Значение", которая на данный момент хранит значения файлов.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE `znachenie` (
  `ID` bigint(12) unsigned NOT NULL AUTO_INCREMENT,
  `id_afx` int(10) unsigned NOT NULL,
  `kod_amplitud` tinyint(4) NOT NULL DEFAULT '-1',
  `kod_fazi` tinyint(4) unsigned NOT NULL,
  `amplituda` float NOT NULL,
  `faza` float NOT NULL,
  PRIMARY KEY (`ID`),
  KEY `key_id_afx_znachenie_idx` (`id_afx`),
  CONSTRAINT `key_id_afx` FOREIGN KEY (`id_afx`) REFERENCES `afx` (`ID`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;

Если одна строка в текстовом файле( полностью соответствующем загружаемым значениям в эту таблицу) занимает 30 байт, то , при занесении в БД, одна запись занимает уже 45байт данные и 17 байт индексы = 62 байтаЧто-то не сходится. Прямым подсчетом получается 8+4+1+1+4+4=22 байта на запись в таблице и 4+8=12 байт на запись в индексе. Конечно, накладные расходы присутствуют, но не в два же раза.
Если в таблице удалялось много записей, то попробуйте сделать ей OPTIMIZE TABLE.
...
Рейтинг: 0 / 0
09.12.2015, 18:59:14
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39124400
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
unutcon MephiИ по поводу "холодных" и "горячих" данных не совсем понятно. Т.е. холодные, те что хранятся в БД, но используются редко или давно,а горячие это актуальные?. Если это так, то как можно это использовать?Например, у нас, есть таблица с документами/накладными/счетами. Обычно наши сотрудники работают с документами, сделанными в последние несколько дней. Документы старее недели нужны уже редко, обычно для разбора каких-то косяков. Старее месяца документы уже почти никого не интересуют и используются только в какой-нибудь статистике, которая обсчитывается ночью.
Физически это одна таблица, с точки зрения СУБД записи в ней ничем не отличаются друг от друга, но некоторые записи используются значительно чаще, чем другие. Вот это и есть "горячие данные". Поскольку быстродействие при работе с холодными данными никого не интересует, то для приемлемой работы пользователей достаточно выделить памяти на кэш только под "горячие данные". Т.е. в моем примере на документы за последнюю неделю-месяц.

Существуют методы раздельного хранения холодных и горячих данных, но обычно они применяются только в очень больших системах и когда деление данных вводится формально.
...
Рейтинг: 0 / 0
09.12.2015, 19:10:26
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39124431
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
unutcon MephiДобрый день, уважаемые знатоки.

Необходим дельный совет по поводу подбора конфигурации железа сервера для MySQL( тип таблиц InnoDB).
К сожалению, дельной информации по этому поводу найти не удалось, поэтому вынужден обратиться сюда( за любые ссылки и пинки в какую-либо дельную сторону огромное спасибо)

Сервер будет выделенной машиной, к которой будут иметь доступ сотрудники отдела по локальной сети.
Предварительный объём хранимых данных 2-3ГБ.
Собственно , следуя тем данным которые я смог найти, а именно: оперативная память, процессор, жесткие диски; являются ключевыми в данном вопросе. ( в некоторых книжках написано что для комфортной работы необходимо около 30% ОП от объема данных. Также планируется использовать аппаратный RAID10.

Не могли бы вы дать советы по поводу данных комплектующих, чтобы этот вопрос можно было решить более рационально.

За любые ответы,советы,указания огромное спасибо и низкий поклон.

C железом под СУБД всё очень просто, оно должно удовлетворять только трём главным критериям:
Иметь быстрые процессоры

Иметь много оперативной памяти

Иметь хорошую подсистему ввода-вывода.


И всё.

Памяти тебе надо размер твоей БД, плюс под накладные СУБД, плюс под накладные операционки, плюс лог.
8Гб в твоём случае будет выше крышы. Может хватить и 4-х (но по современным меркам это -- несерьёзно для сервера).

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

Диски -- как можно быстрее.

Вот и всё...
...
Рейтинг: 0 / 0
09.12.2015, 20:05:35
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39124435
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
unutcon Mephimiksoft,netwind
Прошу прощения за глупейшую ошибку. Только сейчас увидел что написал про обьёмы в 2-3 ГБ
На самом деле Речь идет о 2-3 ТБ. Извиняюсь

Блин, вот это фейл....

Ну, такие объёмы в память не лезут по определению, поэтому там уже нужно глядеть по задаче,
обычно у задач есть т.н. рабочий набор данных, который сидит в кэше, и именно под него нужно
иметь память.

Но это естественно ты только решишь...
...
Рейтинг: 0 / 0
09.12.2015, 20:08:56
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39124439
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
unutcon Mephinetwind,

Я правильно понял, вы советуете посмотреть в сторону BigData?

Неправильно.
...
Рейтинг: 0 / 0
09.12.2015, 20:10:11
| Ответить | Цитировать | Написать  
Подбор железа под MySQL Сервер
    #39124483
unutcon Mephi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unutcon Mephi
Гость
Miksoft, netwind ,MasterZiv.

Спасибо Вам большое.
...
Рейтинг: 0 / 0
09.12.2015, 22:34:34
| Ответить | Цитировать | Написать  
9 сообщений из 34, страница 2 из 2
  2  все
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Подбор железа под MySQL Сервер
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&msg=39124435&tid=1832392]:
 0ms
get settings:
 8ms
get forum list:
 19ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 35ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 38ms
get tp. blocked users:
 1ms
others: 203ms
total:  321ms
созд. / загр.: 321ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]