| Внимание! В связи с устареванием топика эта страница была взята из кэша.
|
 Pentarh
Зарегистрирован: 05.04.03
Сообщения: 1376
|
 Добавлено: 15/09/03 в 22:41
|
|
Обращаюсь к тем, кто имеет хороший опыт по теме.
В общем дело касается BLOBов в мускуле. Есть таблица, в которой есть одно поле блоба (MEDIUMBLOB) и пять полей с характеристиками блоба. Все это дело стоит на мускуле, который в свою очередь стоит на дедике. Т.е. можно сказать, что он стабилен. Размеры этой таблицы, по моим подсчетам, будут измеряться в единицах-десятках гигабайт именно из-за поля типа BLOB. Количество строк - ну до 10к. Работа с таблицей не очень активная. Почти не активная.
Вопрос: Мускулю/дедику плохо не станет?
ЗЫ: не секрет, что я буду хранить там графику.
|
|
K началу
|
|
| |
Stek
Зарегистрирован: 24.10.02
Сообщения: 719
|
|
Добавлено: 15/09/03 в 23:19
|
|
Если ты поиск по блобу делать не будешь, то выдержит 
Только такую базу тебе придется делать в innoDB девайсе.
Правда как ты будешь решать проблему с бакапом ....
|
|
K началу
|
|
| |
sAx
Зарегистрирован: 07.06.00
Сообщения: 1826
|
|
Добавлено: 16/09/03 в 00:17
|
|
Плохо не станет, проверено.
Как я понял, ты крутиндель (баннеров или тумбов) делать будешь.
Так вот, бэкап решается тоже несложно, если картинки паралельно сгружать в какой-либо каталог на диске и забить в строке базы поле с именем картинки. Поле Блоба не бэкапить. Выйгрыш в обьеме бэкап-базы офигенный. При процедуре восстановления дополнительно понадобится всосать в базу файлы из каталога.
|
|
K началу
|
|
| |
Pentarh
Зарегистрирован: 05.04.03
Сообщения: 1376
|
|
Добавлено: 16/09/03 в 16:41
|
|
| Stek писал: | Если ты поиск по блобу делать не будешь, то выдержит
Только такую базу тебе придется делать в innoDB девайсе.
Правда как ты будешь решать проблему с бакапом .... |
Расскажи подробнее плз, шо за девайс? Читал когда-то где-то. Но щас не вспомню.
Поиск делать не буду :-)
| sAx писал: |
... если картинки паралельно сгружать в какой-либо каталог на диске и забить в строке базы поле с именем картинки...
...дополнительно понадобится всосать в базу файлы из каталога.
|
Уй-й-й. Как больно ты говоришь. :-)
А вобще, спасибо за ответы.
|
|
K началу
|
|
| |
Alexus
Зарегистрирован: 07.11.02
Сообщения: 722
|
|
Добавлено: 16/09/03 в 16:52
|
|
| sAx писал: | Плохо не станет, проверено.
Как я понял, ты крутиндель (баннеров или тумбов) делать будешь.
Так вот, бэкап решается тоже несложно, если картинки паралельно сгружать в какой-либо каталог на диске и забить в строке базы поле с именем картинки. Поле Блоба не бэкапить. Выйгрыш в обьеме бэкап-базы офигенный. При процедуре восстановления дополнительно понадобится всосать в базу файлы из каталога. |
здесь истина. именно так по идее и надо делать. иначе заебешся или раззоришся на железе.
|
|
K началу
|
|
| |
Pentarh
Зарегистрирован: 05.04.03
Сообщения: 1376
|
|
Добавлено: 16/09/03 в 16:58
|
|
Все бы было так просто, если бы не одно обстоятельство.
Вобщем там
| Код: |
PRIMARY KEY('image_category','image_name')
|
INT и VARCHAR соответственно. Двойной ключ короче. Так просто их в одну папку не сбросишь. Хотя конечно нет ничего невозможного.
|
|
K началу
|
|
| |
Stek
Зарегистрирован: 24.10.02
Сообщения: 719
|
|
Добавлено: 16/09/03 в 18:15
|
|
innoDB - это таблицы такие
Т.е. ставишь последнюю версию mysql , создаешь нужное колличество хранилищ с нужным размером, а потом и создаешь таблицы с типом innoDB
А то есть шанс, что линукс не поймет файла размером свыше двух гиг. Хотя эти действия лучше отдать админу, пускай настраивает.
Но факт фактом, mysql такое потянет без проблем.
| Цитата: | | INT и VARCHAR соответственно. Двойной ключ короче. Так просто их в одну папку не сбросишь. Хотя конечно нет ничего невозможного. |
А сделать так :
/backup_dir/[image_category]/соответствующие_имена_файлов
Тогда все будет аккуратненько
|
|
K началу
|
|
| |
sAx
Зарегистрирован: 07.06.00
Сообщения: 1826
|
|
Добавлено: 16/09/03 в 19:29
|
|
| Pentarh писал: | Уй-й-й. Как больно ты говоришь. :-)
А вобще, спасибо за ответы. |
Зато коротко, ассоциативно и понятно... Как серпом по яйцам
| Stek писал: | А сделать так :
/backup_dir/[image_category]/соответствующие_имена_файлов |
и это правильно.
|
|
K началу
|
|
| |
Pentarh
Зарегистрирован: 05.04.03
Сообщения: 1376
|
|
Добавлено: 16/09/03 в 20:03
|
|
Да, все это правильно, и это я понял.
Хотелось бы узнать отклики об иннодб этом. Уж характеристики я-то найду.
Система стоит Фри-Бзда. Она поймет такие большие файлы?
Как сисадмин я не очень чес говоря. Да и не мое это дело сисадминить :-)
|
|
K началу
|
|
| |
Dragon
Зарегистрирован: 09.02.03
Сообщения: 160
|
|
Добавлено: 17/09/03 в 05:45
|
|
Все-таки немогу понять, чем плохо хранить файлы изображений as is, а в таблице держать только статистику? Если только картинки в браузер скриптом отдавать...
|
|
K началу
|
|
| |
Stek
Зарегистрирован: 24.10.02
Сообщения: 719
|
|
Добавлено: 17/09/03 в 09:16
|
|
| Цитата: | | Все-таки немогу понять, чем плохо хранить файлы изображений as is, а в таблице держать только статистику? Если только картинки в браузер скриптом отдавать... |
Ну картинки не всегда только для браузера преднозначены
|
|
K началу
|
|
| |
Pentarh
Зарегистрирован: 05.04.03
Сообщения: 1376
|
|
Добавлено: 17/09/03 в 17:46
|
|
| Dragon писал: | | Все-таки немогу понять, чем плохо хранить файлы изображений as is, а в таблице держать только статистику? Если только картинки в браузер скриптом отдавать... |
Ну эт смотря еще для чего. есть случаи, когда бывает необходимо. А если хранить as is, то это дополнительный синхронизатор писать надо, который бы следил за целостностью данных.
Кстати, вот за что не люблю мускуль - у него constraint'ов нету. Целостность данных надо обеспечивать на программном уровне.
|
|
K началу
|
|
| |
Stek
Зарегистрирован: 24.10.02
Сообщения: 719
|
|
Добавлено: 17/09/03 в 20:42
|
|
| Цитата: | | Целостность данных надо обеспечивать на программном уровне. |
Товарищ, уже года два как mysql это умеет
Включи поддержку innoDB , и жить станет легче
InnoDB - его возможности и отзывы.
| Цитата: | Peter Zaitsev, CTO of Mytrix writes:
Currently Mytrix provides extended statistics for more than 200 000 web resources, accounting for more than 70 million events per day. The "raw" gathered data is stored in a self-implemented data warehouse, and statistics of it are stored in MySQL databases.
MySQL is used for extensive analysis of the data. For a couple of years MyISAM tables were used to store the processed data. We found that the InnoDB support for transactions, row level locks, and fast automatic crash recovery gives us an advantage, so we have migrated to InnoDB.
Totally we have about 30 servers (mostly Dual PIII with 1-2 GB of RAM) which have in total more than 1 TB of data stored in MySQL databases. The number of tables is more than 100 000 (small tables were used with MyISAM to overcome concurrency problems in table level locking used with MyISAM). The tables contain more than 20 000 000 000 rows in total.
|
|
|
K началу
|
|
| |
Pentarh
Зарегистрирован: 05.04.03
Сообщения: 1376
|
|
Добавлено: 18/09/03 в 00:23
|
|
Действительно рульная весч.
Я просто на своей прежней работе имел дело только с MS SQL 2000 и Oracle из СУБД. Юникс-программингом вобще не занимался, хотя имел опыт.
Этот иннодб не на каждом же хосте поставят. А я стараюсь делать, чтобы на большинстве.
Как у него вобще с распространенностью?
|
|
K началу
|
|
| |
Текстовая реклама в форме ответа
Заголовок и до четырех строчек текста
Длина текста до 350 символов
Купить рекламу в этом месте! |
Внимание! В связи с устареванием топика эта страница была взята из кэша.
|
