Хранилище больших данных

OF 17.05.2004 - 09:52 | Задача следующая: создать программу для ведения архива бумажных документов. Собираюсь делать на IB\Ya. В самом простом виде это - просто таблица с определнными полями (атрибутами), по которым будет вестись поиск. Проблема Сам документ представляет собой... отсканированное(ные) изображение(ия) этого документа (формат мой - тут тоже нет проблем). Так вот, каждый документ может иметь любой размер (может быть и 300 и 3000 листов, и даже больше), т.е. может быть как 100 кб так и 100 мб. Проблема: КАК это хранить и где? Я считаю, что в Блобах хранить такой объем информации - это просто безумство.. Сначала я решил сделать через UDF, т.е. где-то на сервере эти данные лежат в файлах, а я через UDF могу их считать.... но в данном случае проблема возникла при записи данных - как-то у меня не получилось мультипотокового/потоковобезопасного UDF :) Может есть какое-то красивое решение? Или можно все-таки все в Блобы пихать? Или все-таки двигаться в сторону UDF. Или, наконец, скрепя зубами бацать трехзвенку? Спасибо! :)
Тупой ламер 1 - 17.05.2004 - 10:49 | зачем хранить документы как картинки? Нет возможности их разобрать/структурировать? А как потом с ними работать?.. как редактировать? сжатие/редукция цвета и прочеие заморочки для уменьшения размера задействовано? Если же действительно так НАДО и хранить нужно именно картинки, и размеры у них будут по сотни метров (а размер самой базы пойдёт на гигабайты/терабайты), и нужна транзакционность и прочие прелести БД, то, imho, следует обратить внимание на серъёзные БД типа Оракла. Мы там работали и с терабайтными файлами. К тому же там есть спец. методы работы с файлами. ps. а трёхзвенка от больших данных не спасёт - просто работать с ними будет проще.
OF 2 - 17.05.2004 - 11:19 | Вопрос о сжатии картинок и прочем не идет.. Не имеет значения, что будет храниться, просто ДОЛЖНО поддерживаться хранение ЛЮБЫХ данных ЛЮБОГО размера. Что туда запихнут - это не моя проблема. Но должна иметься возможность запихнуть ЧТО УГОДНО. Потому что нельзя, чтобы появлялись сообщения типа "Вы отсканировали на 1 страницу больше.. Выдерните ее из дела и попробуйте еще раз" :)) Да я тоже думал в сторону Оракла, но... Просто всю жисть рабтаю с IB, а с Ораклом.. Просто сам знаешь как сейчас работают программеры - написал под Оракл, вот его и администрируй.. А я его не знаю на таком уровне :)
Bronya 3 - 17.05.2004 - 11:24 | Я решал подобную задачу. Советую хранить в базе только пути к картинкам, а сами картинки хранить в виде файлов - т.к. файловая система тоже своего рода база данных, но работает на порядок быстрее, чем IB\Ya. Кроме того, легко можно в случае надобности реализовать левой пяткой базу на основе IIS + PHP + MSIE...
silly sad 4 - 17.05.2004 - 12:15 | "А как потом с ними работать?.. как редактировать?" - да да ! редактировать ! начальник написал приказ, а я его отредактирую. пришел счёт от поставщика, а я и его отредактирую !
sad dirty fingers junior 5 - 17.05.2004 - 12:19 | ты с блобами оракла поимеешь секса ещё больше чем ИБ если реально хочешь избавиться от файловой системы в своём приложении, то используй постгрес. правда там тоже есть физическое ограничение на размер полей (2Гб) но думаю тебе хватит.
ИгорьК 6 - 17.05.2004 - 13:16 | типа постгрес совсем не сексуальный сервер ;-)
Тупой ламер 7 - 17.05.2004 - 14:14 | to silly sad: если начальник написал приказ, то он в любой момент может захотеть его отредактировать. Постфактум. Так же и бухгалтера имеют вредную привычку редактировать первичные документы задним числом. И не надо ля-ля про законодательство - мы его знаем... просто если система такого не будет позолять (на определённом уровне доступа) - то бумажный документооборот вы не замените электронным никогда. Но если нужно просто хранилище, и если редактирование не ставится как задача (просто архив), то лучшим вариантов будет как раз связка файловых объектов + БД (Оракл такое позволяет на ура). Безо всяких блобов (с блобами в Оракле проблем не больше, чем с другими БД, просто тонкости есть свои, хотя и возможностей побольше). Просто нужно определится с примерным объёмом базы эдак через годик-два. Если по прикидкам выйдет гиг на 500 и более - то уже имеет смысл думать о Оракле.
VaS 8 - 17.05.2004 - 14:23 | Если предполагается редактирование блобов и не хочеться постоянно делать бэкап-ресторе, то IB не подходит.
OF 9 - 17.05.2004 - 15:11 | Вот и получается - Блобы - геморрой.. Файловая система - не правильно, т.к. пользователь должен будет иметь доступ к сетевому ресурсу, хранящему эти файлы, а если редактировать нужно, то еще вместе с распределением прав в базе еще и надо будет а эту шару раздавать права.. А тот кому разрешено будет редактирование зайдет на эту папку и случайно F8 раз 100 нажмет и усе... Короче неправильно это.. Сейчас у меня зреет один вариант - Веб сервер :)
silly sad 10 - 17.05.2004 - 16:22 | "и случайно F8 раз 100 нажмет и усе..." - dolche vita FAT NC rulezz fareva
OF 11 - 18.05.2004 - 09:26 | Кстати, "...Но если нужно просто хранилище, и если редактирование не ставится как задача (просто архив)..." - но ведь добавление нового документа - это же тоже редактирование?... Ведь документы должен кто-то заводить :)
asn 12 - 18.05.2004 - 10:34 | Согласен с sad, хочешь меньше секса пользуй PostgreSQL, хочешь больше(существенно) большее время разработки и призрачные качество-бытродействие-производительность бери Oracle. В принципе там можно ооочень серьезные вещи делать. А вот оценят ли, тот еще вопрос?
OF 13 - 18.05.2004 - 11:07 | Епрст.. А куды я ентот PostgreSQL ставить буду? Одни винды везде, линухом никто не занимается..
Hook 14 - 18.05.2004 - 11:51 | А чем PostgreSQL кардинально отличаеться от IB? Я бы наверное сделал бы трехзвенкой, дабы если что - мигрировать с одной бд на другую не меняя при этом клиентского приложения. зы:Олег, ты зачем опять ник сменил?:)
OF 15 - 18.05.2004 - 14:11 | >>зы:Олег, ты зачем опять ник сменил?:) Нууу.. Для разнообразия :) >>Я бы наверное сделал бы трехзвенкой Лениво мне.. Много чести для такой проги.. :)
asn 16 - 18.05.2004 - 14:18 | >>А чем PostgreSQL кардинально отличаеться от IB? Ну если серьезно то много всего, а если по простому то ничем, тоже СУБД. :-) >>Я бы наверное сделал бы трехзвенкой Ну вообще конечно можно и многозвенной, нет предела совершенству. А смысл? Судя по задаче, люди (которые заказчики) вообще не совсем представляют, что им надо. Прежде всего наверное стоит проработать задачу. Например вместо программирования кучи всего, просто нанять девочку-студентку которая будет набивать эти декументы в простенькую базу. Я так подозреваю, что в этом случае IB/FB/Ya хватит с потрохами.
OF 17 - 18.05.2004 - 17:20 | Сузим задачу: есть необходимость сохранять и извлекать данные больших объемов. Возьмем стандартную демку biofile. И теперь представим такую задачу - необходимо, чтобы фотки рыбок были в формате bmp размером 10000 на 10000 в труколоре и т.п. Как это сделать? :)
OF 18 - 18.05.2004 - 17:28 | Теперь относительно разных баз и прочего.. Даже если бы IB и поддерживал бы 2Гб в поле (как сказали в 5 посте), то все равно я не пойму как эти 2Гб запихать в поле??? Ведь прежде чем послать запрос на сервер, он грузится в память.. Вместе с параметрами.. А когда я BLOB (или BYTEA) пихаю в базу, то его содержимое и есть один из параметров.. Таким образом, при пихании данных размером мегабайт 500, они грузятся в память!!! На обычной клиентской машине со средним объемом оперативки в 64мб сия операция вызовет у Виндов нервный шок :) Такая же фигня и с селектом такого поля - он весь должен загрузиться память!! Ведь нельзя параметры читать с диска и писАть на него напрямую?!?! Надеюсь, я ясно изложил свою мысль....
Hook 19 - 19.05.2004 - 08:17 | >> Таким образом, при пихании данных размером мегабайт 500, они грузятся в память!!! Хм, даже если через TIBBlobStream?
OF 20 - 19.05.2004 - 09:48 | Ну а как же??? А как делается через TIBBlobStream?? Ты делаешь сначала туда CopyFrom или просто пишешь туда а потом Exec кверю.. Где оно по-твоему хранится ДО выполнения запроса???
OF 21 - 19.05.2004 - 09:50 | То же верно и в обратную сторону - ты воплняешь запрос, а потом из поля, представленного TIBBlobStream-ом делаешь Read или что-то там еще.. Думаешь оно во время чтения из этого потока соединяется с сервером и начинает качать данные? НЕТ! Они уже все в ПАМЯТИ! .... :(
Hook 22 - 19.05.2004 - 09:53 | Именно так и есть(должно быть в нормальных компjнентах). Когда ты делаешь запрос на получение блоба тебе в ответ приходит blobid а содержимое качаеться уже позже. сниффер тебе в помощь :)
ИгорьК 23 - 19.05.2004 - 10:43 | Hook прав! Так и делается! Вообще если хочется хранить блобы такого объема в базе, то ИМХО нужно выбирать не версионный сервер, иначе запаришься собирать мусор! И желательно чтобы сервер позволял разделить файл БД на файл с блобами и файл с "обычными" полями. Под это подходять Oracle, MSSQL, DB2. Вот из этих я бы и выбирал. Все остальное при таких размерах не стоит рассматривать. Есс-но все ИММХО.
silly sad 24 - 19.05.2004 - 11:42 | "А чем PostgreSQL кардинально отличаеться от IB?" RTFM
_van 25 - 19.05.2004 - 11:45 | ребята объясните мне, ламеру№2 чем файловая система не устраивает? чтобы в базе хранить только ссылки на сами файлы любого размера. ` Понимаю что транзакции это очень приятно, но для задачи хранить и извлекать данные любого размера достаточно будет регулярного архивирования и raid массива 80гб 80$*4(не нужен scisi) для хранения.
sad dirty fingers junior 26 - 19.05.2004 - 11:46 | "то все равно я не пойму как эти 2Гб запихать в поле???" ИНСЕРТОМ !!! - P.S. вот здесь то и кроется источник секса в оракле.
silly sad 27 - 19.05.2004 - 11:50 | "чтобы сервер позволял разделить файл БД на файл с блобами и файл с "обычными" полями. Под это подходять Oracle, MSSQL, DB2" - и, увы, тебе грешному, PostrgeSQL тоже так делает.
ИгорьК 28 - 19.05.2004 - 12:09 | 27- а выше прочитать не судьба - "ИМХО нужно выбирать не версионный сервер" Насколько я помню Postgres версионник. Или что-то поменялось?
OF 29 - 19.05.2004 - 13:50 | Смотрите.. Есть сервер IB.. Есть к нему компоненты FIB (на данный момент считаются самыми лучшими)... Теперь я залазю в исходники FIB-ов и смотрю, как присходит чтение блобов.. А вот так: он полностью загружается в буфер! Просто и нагло создается буфер под именем FBuffer и делается ReadBlob в этот FBuffer!!! А потом уже, когда идет обращение как к потоку, просто читается из этого буфера! (Весь процесс проверки и тестирований обсуждался с Hook-ом по аське). Получается, они даже не подумали о таком варианте, что блоб может быть ЛЮБОГО размера!! Ну что за глупость делать GetMem(FBuffer, РАЗМЕР_БЛОБА)!! И это, повторюсь, в одной из лучших компонент, разрабатываемой давно, и по пожеланиям большого круга пользователей! Т.е. у них НИКОГДА не возникало такого вопроса, что блоб может быть ОЧЕНЬ БОЛЬШИМ.. И вот мы с Hook-ом пришли к выводу, что надо исправить исходники и добавить загрузку блоба прямиком в файл, а не в память... А теперь PostgreSQL.. Сомневаюсь я что-то в том, что там иная ситуация.. Но с IB я давно и поправить могу если что, а с Postgres-ом хрен я что сделаю, особенно если через ODBC драйвер - то ваще кирдык..
OF 30 - 19.05.2004 - 13:52 | _van, смотри пост №9, особенно в части нажатий на кнопку F8 :)
silly sad 31 - 19.05.2004 - 14:37 | to 28 ну так и что с того, что мусор ? документы обычно неудаляют , ну или чаще делай вакуум. хотя имхо для очень крупных блобов, ничего лучше файловой системы ещё не придумали :-)
OF 32 - 19.05.2004 - 14:44 | ААААААААААААААААААААААААА
Hook 33 - 19.05.2004 - 15:05 | Ну а если файловая система.... Как вариант - по запросу сервер извлекает файл из блоба в файловую систему(локальную но доступную по сети), ползатель с ним работает, потом по другому запросу закачивает обратно. Таким образом перекладываем реализацию на UDF-фильтры. А вот что там будет с памятью - хз. Хотя можно даже и не хранить в базе а просто копировать файлы из одного каталога(недоступного) в публичный с переименованием его с учетом ID подключения. Ну и соответственно шедуллер ночной который будет удалять во публичном каталоге "зависшие" файлы.
Hook 34 - 19.05.2004 - 15:10 | Из другой конфы: >Коваленко Дмитрий: >В IBProvider можно запросить Storage-объект (с COM интерфейсом >ISequentialStream) и считывать данные BLOB поля кусочками. >Наоборот тоже можно - писать из файла напрямую в BLOB.
Delphist 35 - 19.05.2004 - 16:31 | Если файловая система не подходит, то эмулируй ее своими силами. Создай таблицу - аналог FAT. Создай другую таблицу из BLOB-ов. При записи документа в базу, режь документ на куски (например, по 1 Мбайт) и пиши в базу insert-ом. Получаешь массив записей, с которыми уже проще разобраться. Даже если исходный документ 2 Гбайт. . Насчет Оракла - не работал, попробуй спросить у знающих людей (например, www.sql.ru).
x77 36 - 19.05.2004 - 17:55 | что-то я не пойму. ведь речь о документах? какими такими средствами планируется сканить документ с конечным весом в два гига? мне слабо верится, что реальный размер блобов будет больше 10 мб, какие бы там не были документы. даже если для каких-то единичных случаев больше - хранить по частям. вы пытаетесь решать универсальную задачу для файла произвольного размера, но здесь то задачка вполне реальная - документы... а если уж заморачиваться на общее решение, то есть для этого специальные средства - хранилища данных и пр.
OF 37 - 19.05.2004 - 19:19 | Насчет кусков - я уже об этом думал.. Но это я отложил на самый конец, если уж совсем ничего не получится.. По поводу размеров - никто не говорил про 2Гб.. Скажу реальную задачу - это дело, обыкновенное дело Краснодарского краевого суда. Простой расчет: ~50 кб(одна страница)*300 (количество страниц в одном томе) * 10 (среднее количество томов в деле) получаем ... 150 мегабайт :) .... Короче, я уже сделал через IB API прямое чтение и запись BLOB-ов минуя память :) Все ОТЛИЧНО работает, быстро и память не жрется. Остается такой момент - на каком размере базы посыпется IB? :)
x77 38 - 19.05.2004 - 21:12 | если заранее предусмотреть вторичные файлы (каждый - менее 2 Гб), то тоеретически - на 130 терабайтах (макс кол-во файлов - 65...). реально у нас на объекте в Челябинске база в 1,5 гига чувствует себя нормально. меньше гига - вообще не вопрос. думаю, что стоит продумать архивацию. причём не в самой базе, а тупую отсечку месячных (как минимум) данных на cd с последующим sweep'ом рабочей копии.
x77 39 - 19.05.2004 - 21:18 | OF, а откуда такая цифра, 50 килобайт? чёрно-белое изображение в jpeg c 75% сжатием 10 кило максимум, при 96 dpi (787x1181).
Delphist 40 - 19.05.2004 - 21:25 | ИМХО, для отсканированных текстов JPEG не есть good, т.к. он ведет к ПОТЕРЕ и ИСКАЖЕНИЮ информации. Тут уж лучше TIFF или GIF с оптимизированной палитрой.
x77 41 - 19.05.2004 - 22:29 | оптимизированная монохромная палитра - это как? :) я специально взял jpeg, как не самый оптимальный вариант. насчёт гифа - да, он сжимает вертикально. т.е. для интервалы между строками у него вообще уйдут в нули. (код цвета, кол-во повторений).
ИгорьК 42 - 20.05.2004 - 08:55 | 37 - на NTFS размер 1 файла до 4 Гб. Знаю, что Yaffil тестируют на БД размером 10 ГБ и вроде ничего, живая.
OF 43 - 20.05.2004 - 09:14 | 50 кб - это страница А4 в ТИФЕ, с копресией LZW в 200 dpi с 70% заполнением текстом. Самый ЛУЧШИЙ результат. В 96 dpi вообще прочитать ничего невозможно, а уж особенно распечатать. Архивирование на СД невозможно, т.к. архив для того и задумывается, чтобы судья (или кто-нибудь еще) смог в любой момент найти необходимое дело, даже если оно рассматривалось в 1980 году. 10Гб данных это одно, 10Гб блобов.... Это, наверняка, другое..
ИгорьК 44 - 20.05.2004 - 09:58 | При всем уважении у IB я все-таки думаю, что это задачка не для IB. Дабы не получить в последствии себе головную боль, я бы взял что-то посерьезней.
Mda.... 45 - 20.05.2004 - 10:58 | Поддержу Игоря. Если это, действительно, для Суда, то мало того, что сейчас огромный объем, этот объем будет быстро нарастать. Нужна серьезая БД для этих работ. Иначе быстро все переделывать придется. Немного непонятна заморочка с прямым чтением-записью, минуя память. Как чисто теоретическое знание, на всякий случай, это, конечно, полезно, но в контексте данной конкретной задачи - создай таблицу страниц, в которой страницы будут связаны, с таблицей томов, в которой тома будут связаны с таблицей дел. И все. 50k на страницу, для записи-чтения, думаю, выделить не сложно будет.
Hook 46 - 20.05.2004 - 11:16 | 42 - не вводи людей в заблуждение. Размер файла базы на NTFS практически не ограничен(в последних версиях). я думаю IB вполне это потянет, ведь тут нету сложных вычислений по этим N-цать гигов, а только получение информации и сохранение ее. Тут скорость будет ограниченна скорее файловой систмой, нежели движком СУБД.
OF 47 - 20.05.2004 - 11:20 | Еханый.. Я же не прошу у Вас рассказать мне структуру моей базы.. Структура будет такая и все тут. Будет организовано что-то типа древовидной структуры хранения дел. Каждое дело может состоять из разных "файлов", это может быть отсканированный том в формате PDF, это может быть приказ в формате Ворд, это может быть таблица присяжных в Экселе.. Я НЕ ЗНАЮ какого размера будет каждый "файл". Это может быть и 50кб и 50 мегабайт. Добавлять их буду не я а девочки операторы, которым ваще насрать на размер и они не знают что это такое. Они могут туда забабахать 10 фоток места преступления в 5000dpi в БМП формате и им не объяснишь про оптимизацию и прочее.. Короче, должен поддерживаться ЛЮБОЙ ФАЙЛ ЛЮБОГО РАЗМЕРА. Как организовать хранение таких файлов - вот что я спрашивал. Мулька с прямым чтением как раз и нужна, чтобы весь этот файл не писался в ПАМЯТЬ, потому что памяти может просто не хватить... Ладно, всем спасибо. Я уже сделал на IB - связка прямого чтения с UDF-ом, который берет файл с диска, без хранения в BLOB-е.. Вот и все..
AndyBox 48 - 20.05.2004 - 11:34 | OF, скажи это ВЫ сами (я имею ввиду КрайСуд) хотите себе такую программу. Ты слышал о ГАС "Правосудие"? http://erussia.prime-tass.ru/news/73/20040225/404395.shtm Если начнётся принудиловка, и всем придётся переходить на неё? Есть смысл вести две программы?
OF 49 - 20.05.2004 - 12:26 | Смысл есть.. Потому что 3 заявленных года умножь на 3.. И даже если и сделают, то все-равно будет не то, что НАМ нужно :)
AndyBox 50 - 20.05.2004 - 12:32 | У Вас в суде используется своя программа? Насколько я помню у же были попытки сторонних разработчиков, например "Агора". У нее даже вроде с Департаментом был договор и они даже что-то писали. И насколько я знаю используется Московскими (или одним) судами? А с другими судами у которых допустим что-то стоит, как происходит связь? Дела то передают?
silly sad 51 - 20.05.2004 - 15:24 | они их потом на струйнике на "фотобумаге" печатают

>>