powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Документооборот. Хранение больших объемов данных. Как лучше?
16 сообщений из 16, страница 1 из 1
Документооборот. Хранение больших объемов данных. Как лучше?
    #32877507
Van
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Van
Гость
Предполагается создание системы документооборота на php. Для начала простенькая публикация файлов в свои папки и в папки групп, ну с учетом прав и т.д.
В перспективе, объемы крутящейся информации (в основном конечно файлы MSOfiice, OpenOffice.org, картинки, текстовики и прочее в таком духе) могут значительно вырасти. Хочется заранее подготовиться к возможным проблемам, поэтому хочется узнать мнению людей, которым приходилось работать с большими объемами подобной информации.

Собственно нужен совет, что лучше использовать в таком случае для хранения файлов: файловую систему, либо Blob в мускуле, либо может такая задача вообще не уровня MySQL?

При каком объеме информации такая систем может стать ужасно тормозной либо вообще рухнуть? Стоит ли вообще юзать blob? Почему?
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32877521
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VanПредполагается создание системы документооборота на php. Для начала простенькая публикация файлов в свои папки и в папки групп, ну с учетом прав и т.д.
В перспективе, объемы крутящейся информации (в основном конечно файлы MSOfiice, OpenOffice.org, картинки, текстовики и прочее в таком духе) могут значительно вырасти. Хочется заранее подготовиться к возможным проблемам, поэтому хочется узнать мнению людей, которым приходилось работать с большими объемами подобной информации.

Собственно нужен совет, что лучше использовать в таком случае для хранения файлов: файловую систему, либо Blob в мускуле, либо может такая задача вообще не уровня MySQL?

При каком объеме информации такая систем может стать ужасно тормозной либо вообще рухнуть? Стоит ли вообще юзать blob? Почему?
ну так ты протести свою базу. загони туда пару гиг картинок хотя бы

я (обоснованно) думаю - блобы, но тебя заклюют за такую идею щас
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32878088
Фотография Dinky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хранить все в БД просто удобнее ;) в плане выборки и бэкапа восновном.... Рухнуть не рухнет, но на больших объемах (десятки гиг) таки будут проблемы с производительностью, прийдется придумывать как разносить по разным серверам или еще чего, т.е. мороки будет на порядок больше, чем с файловой системой

--
Dmitry
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32879303
Van
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Van
Гость
2 Dogen:
Да, протестить надо будет обязательно, спасибо за совет...

2 Dinky:
Впринципе разнести, я думаю, будет не большая проблема.
Юзера будут поделены на группы, и, если вышеупомянутые проблемы действительно начнут проявляться, можно будет под каждую группу завести свой сервак.
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32879690
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dinkyхранить все в БД просто удобнее ;) в плане выборки и бэкапа восновном.... Рухнуть не рухнет, но на больших объемах (десятки гиг) таки будут проблемы с производительностью, прийдется придумывать как разносить по разным серверам или еще чего, т.е. мороки будет на порядок больше, чем с файловой системой

--
Dmitry
как раз бэкапить базы в которой есть парочка таблиц объемом несколько гигабайт хреново :))

куда удобнее бэкапить каталоги файл-сервера

но уж если хранить документы, то в одном хранилище. Те кто будет советовать держать все на диске, а в базе только ссылки - это имхо еще дети :) в прошлом веке наслушались глупостев
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32883285
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dogen Dinkyхранить все в БД просто удобнее ;) в плане выборки и бэкапа восновном.... Рухнуть не рухнет, но на больших объемах (десятки гиг) таки будут проблемы с производительностью, прийдется придумывать как разносить по разным серверам или еще чего, т.е. мороки будет на порядок больше, чем с файловой системой

--
Dmitry
как раз бэкапить базы в которой есть парочка таблиц объемом несколько гигабайт хреново :))

куда удобнее бэкапить каталоги файл-сервера

но уж если хранить документы, то в одном хранилище. Те кто будет советовать держать все на диске, а в базе только ссылки - это имхо еще дети :) в прошлом веке наслушались глупостев
Зачем же так категорично...
Единственно реально проще реализуемое свойство системы, при хранении в базе, это жёсткое разграничение доступа к документам. Причём в ином случае сложности возникают только в ограничении доступа на чтение. Что далеко не всегда критично. В остальном же, от хранения в базе пользы ноль, одни убытки:
база разрастается, её и бакапить сложнее становится, и работает она медленнее.
Масштабируемость? Так довольно сложно себе представить такую загрузку выделенного вебсервера, чтобы он не мог сервить статический контент, для того кластеры не нужны, максимум что нужно -- быстрая дисковая система.
Да и вообще, хранение в базе информации, по которой невозможно сделать выборку, выглядит малоосмысленно.
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32884462
Van
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Van
Гость
Ну блин.. С вами каши не сваришь... 8(
Походу буду оба механизма параллельно реализовывать, а потом уже смотреть, что удобнее и лучшее получится...
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32888237
abonent113
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Параллельный вопрос по этой теме.

Какой максимальный объем файла допускается в допускается в связке MySQL - Linux? Насколько я понимаю неприятности начнуться при достижении критического объема таблицы содержащей BLOB поля, именно по объему, а не количеству записей.

Александр
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32888301
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зависит от используемой файловой системы.
Eсли ext3, то до 4ТБ, думаю, мало кому не хватит)
http://dev.mysql.com/doc/mysql/en/table-size.html
Но проблемы начнутся раньше -- таблицу же надо читать...
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32889706
Welly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
хранение в базе информации, по которой невозможно сделать выборку, выглядит малоосмысленно.
Вполне осмысленно - это же данные, а для выборки есть специальные поля, типа название, автор, дата и другие атрибуты. Достаточно их проиндексировать грамотно.

как раз бэкапить базы в которой есть парочка таблиц объемом несколько гигабайт хреново
Не стоит создавать таблицу, описывающую документ и содержащую само тело документа, лучше выделить тела документов в отдельную таблицу, связь один-к-одному. Тогда и поиск по атрибутам документа будет шустро работать, и доставать блобы по уникальному идентификатору легко. Кроме того, MySQL бэкапит таблицы по одной, и вообще каждая таблица лежит отдельными файлами, если это MyISAM. Чаще всего проще просто упаковывать папку /mysql/data архиватором.
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32890658
Han Yuriy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
По документообороту. Я как раз реализовал в хранение файлов в БД. Использую MS SQL Server пока все окей, для файлов создал две таблицы, в первой содержится информация о файлах, а во второй сами image. Вот только я тоже не сплю ночами, база разрастается при 200 записях она имеет размер 70 мб. на серваке места около 10 Гб. что делать когда места на сервере не хватит ???? Может кто нибудь мне ответить на этот вопрос ? И как производить архивирование записей ? В ручную, выбирая архивируемые записи, создавая для них таблицы а потом полученную БД архивировать зипом или раром. Тогда что делать если вдруг понадобится достать документ из архива ? Разархивировать архив влить данные в базу ? идиотизм :) Заранее благодарю каждого ответившего ... Спасибо.
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32890680
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Solution: докупить диск.)
За вполне, думаю, подъёмные, для конторы, хранящей в 10+Гб базе докуметооборот 100 баксов можно докупить 160гиговый винт.
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32890940
abonent113
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
для файлов создал две таблицы, в первой содержится информация о файлах, а во второй сами image. ... база разрастается при 200 записях она имеет размер 70 мб. на серваке места около 10 Гб. что делать когда места на сервере не хватит ????

Я делаю так image архивирую на рабочей станции и в BLOB загружается уже сжатые данные и делается обратная операция при чтении. Клиентская часть на VFP. У нас храняться электронные версии документов различных форматов HTML, Word, CorelDraw, PDF, TXT
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32891973
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Welly хранение в базе информации, по которой невозможно сделать выборку, выглядит малоосмысленно.
Вполне осмысленно - это же данные, а для выборки есть специальные поля, типа название, автор, дата и другие атрибуты. Достаточно их проиндексировать грамотно.

как раз бэкапить базы в которой есть парочка таблиц объемом несколько гигабайт хреново
Не стоит создавать таблицу, описывающую документ и содержащую само тело документа, лучше выделить тела документов в отдельную таблицу, связь один-к-одному. Тогда и поиск по атрибутам документа будет шустро работать, и доставать блобы по уникальному идентификатору легко. Кроме того, MySQL бэкапит таблицы по одной, и вообще каждая таблица лежит отдельными файлами, если это MyISAM. Чаще всего проще просто упаковывать папку /mysql/data архиватором.
Не уверен в достаточной надежности MyISAM. Хотя в innoDB нет полнотекстового индексирования, надежность на порядки выше.
Про вынос блобов в отдельную таблицу разумно, тем более что вложений в документ может быть много. В основной таблице можно оставить блоб под описание документа (все равно туда много не напишут).
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32891986
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
abonent113для файлов создал две таблицы, в первой содержится информация о файлах, а во второй сами image. ... база разрастается при 200 записях она имеет размер 70 мб. на серваке места около 10 Гб. что делать когда места на сервере не хватит ????

Я делаю так image архивирую на рабочей станции и в BLOB загружается уже сжатые данные и делается обратная операция при чтении. Клиентская часть на VFP. У нас храняться электронные версии документов различных форматов HTML, Word, CorelDraw, PDF, TXT
Ага. А у нас JPEG.
Так что надо серверы проектировать под запланированный объем БД... и еще раза в 3-4 больше.
...
Рейтинг: 0 / 0
Документооборот. Хранение больших объемов данных. Как лучше?
    #32892543
Welly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Не уверен в достаточной надежности MyISAM. Хотя в innoDB нет полнотекстового индексирования, надежность на порядки выше.
Ну, тут все зависит от объемов. Если объем маленький, то и MyISAM сойдет, только бэкапиться почаще придется... Но для больших объемов InnoDB, конечно, будет лучше.



Про вынос блобов в отдельную таблицу разумно, тем более что вложений в документ может быть много. В основной таблице можно оставить блоб под описание документа (все равно туда много не напишут).
Вообще, если уж делать полноприводный документооборот, то напрашивается такая схема - документ, версия документа, каталоги версии документа, файлы, привязаные к каталогам и их тела. Собственно, большинство систем документооборота этого как раз и не имеют, за редким исключением. Но я говорил лишь о разделении атрибутивной информации и тела файла на пару таблиц.
...
Рейтинг: 0 / 0
16 сообщений из 16, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Документооборот. Хранение больших объемов данных. Как лучше?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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