LINUX.ORG.RU

Вопрос по файловым системам.


0

0

Есть данные (~2Tb/год). Данные хранятся в хранилище (машина, в которую регулярно добавляются жёсткие диски)

Единица данных, которую можно конкретизировать вручную и с которой есть смысл работать имеет размер ~100Gb.

Данные представляют из себя набор переменных, меняющихся во времени.
Всего ~100000 переменных. Хранятся данные в виде: (время, значение). Соответственно новое значение пишется только в случае, если произошло его изменение (так называемая запись с апертурами).

Надо реализовать:
1) Функцию, возвращающую значение переменной на конретном временном интервале.
2) Функцию, возвращающую все 100000 переменных на конкретный момент времени.

Причём вторая функция должна работать относительно быстро. Минимальная скорость: 1 полное состояние в секунду, желательно намного быстрее.

Также могут создаваться новые единицы данных на основе старых. Т. е.:
за базу берём данные за время с a по b, но переменную X задаём вот такую.

Т. е. требуется реализовать что-то вроде версионного контроля.

Идеи по реализации:
1) Всё это складировать в огромные файлы и во всю по ним прыгать.
2) заморачиваться с СУБД.
2) (Нравится больше) Реализовать всё это дело в файловой системе.
Т. е. каждая переменная - отдельный файл. Более высокие уровни иерархии - каталоги.

Возникают конкретные вопросы по третьему варианту:
1) Какую ФС лучше взять за основу (ext3 или jfs например)
2) Есть ли в ФС какие-нибудь механизмы, позволяющие индексировать имена файлов для быстрого открытия? В идеале функция, которая открывает файл не по имени, а по иноду? Индексацию запускать например вручную, а результат хранить в файле.
3) как лучше: открывать сразу много файлов на чтение или по очереди или есть какая-то золотая середина?


Re: Вопрос по файловым системам.

reiserfs, zfs, xfs, scsi, масимальное распараллеливание процесса

yantux ()

Re: Вопрос по файловым системам.

Лично я бы считал, что стоит заморачиваться с СУБД. В PostgreSQL, например, хранят данные об астрономических объектах и различных ГИС. Также в PostgreSQL есть достаточно много нестандартных функций, которые может тебе помогут.

Macil ★★★★★ ()

Re: Вопрос по файловым системам.

У тебя получается что-то типа ключ->значение. Можно ключи+оффсеты хранить в BDB, а сами данные в большом файле.

Reset ★★★★★ ()

Re: Вопрос по файловым системам.

Да кстати задача поставленна довольно размазано :-)

или я уже отвык от таких задач...

>2) заморачиваться с СУБД.

хотя Приведённой выще инфы недостаточно чтобы нормально сориентироватся, но я бы при реализации на БД выбирал гдето между Berkley DB, gdbm && sqlite

cvv ★★★★★ ()
Ответ на: Re: Вопрос по файловым системам. от cvv

Re: Вопрос по файловым системам.

Всё что связано с SQL запросами не нужно.

Ничего сложнее, чем "дай одну переменную за такой-то временной интервал" или "дай все переменные в такой-то момент времени" не будет.

ksicom ()
Ответ на: Re: Вопрос по файловым системам. от kto_tama

Re: Вопрос по файловым системам.

чтобы он побыстрее был, я и хочу индексировать заранее иноды. Т. к. база в основном будет статической, такая индексация по идее должна значительно ускорить процесс поиска нужного файла.

ksicom ()
Ответ на: Re: Вопрос по файловым системам. от kto_tama

Re: Вопрос по файловым системам.

Сильно зависит от кривизны рук. у него будет максимальная масштабируемость и простота распаралеливания.

ну а воспользоватся этими преимуществами сильно нетривиально так что обычные/тривиальные реализации на ФС действительно проигрывают БД.

cvv ★★★★★ ()

Re: Вопрос по файловым системам.

Интересная задача, случаем не оцифровка трубопроводов?

PostgreSQL не загнется, но если только правильно его использовать, MySQL думаю помрет. Из коммерческих можно взять MSSQL либо Oracle, но не вижу преимуществ (IMHO) если только не вбухать несколько сотен K$ в покупку готовой системы хранения таких данных.

Если делать самим, то для начала нужно ознакомится с приемами работы (алгоритмы, структуры, нормализированные формы (не SQL)) с такими данными. Например, как минимум знать как это пару вариантов реализации внутри СУБД. Сразу станет более-менее понятно как строятся такие системы (например какие индексы вам нужны).

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

Я бы рекомендовал хранить данные непосредственно на дисках (т.е. читать-писать /dev/*), а PostgreSQL использовать для хранения "навигационной" информации. Если все это посадить на распределенную систему хранения данных через оптику с уже готовой lib-ой нижнего уровня (есть такие решения), то можно сделать технологическую "конфетку".

ly ()
Ответ на: Re: Вопрос по файловым системам. от ly

Re: Вопрос по файловым системам.

>Я бы рекомендовал хранить данные непосредственно на дисках (т.е. читать-писать /dev/*), а PostgreSQL использовать для хранения "навигационной" информации. Если все это посадить на распределенную систему хранения данных через оптику с уже готовой lib-ой нижнего уровня (есть такие решения), то можно сделать технологическую "конфетку".

Выжать преимущества raw девайсов не такая уже и простая задача. Даже оракл рекомендует такое решение только для некоторы часных случаев...

cvv ★★★★★ ()
Ответ на: Re: Вопрос по файловым системам. от ly

Re: Вопрос по файловым системам.

Нет, не оцифровка трубопроводов.
Но "объект" абсолютно энергетический :) С объекта идёт поток данных. Причём на самом объекте стоит программа условно "самописная" (всё-таки несколько организаций писали :) ) Её задача - принимать и записывать данные с датчиков за гарантированное время. Работает прекрасно. Реализована на огромных бинарных сплошных файлах с одним разработчикам понятным форматом. Она в общем-то умеет отдавать данные, но очень медленно и неудобно. Годится только для маленьких неторопливых выборок (какой-нибудь простенький график построить). Пытались модернизировать, не очень получилось. Слишком много в программе мест с пометками "исторически сложилось" :) да и вообще изначально под запись данных затачивалась.

Сейчас возникла потребность в полномасштабном моделировании на основе записанных на объекте данных и проведении сложных сравнений.

Использовать СУБД в чистом виде пробовали (проприетарная СУБД отечественной разработки). Как-то не сложилось (завтра спрошу почему конкретно, но причины были чисто технические :) )

Работа с устройством напрямую тоже рассматривается, но как ни крути - получается придётся в том или ином виде реализовывать функционал ФС.

ksicom ()
Ответ на: Re: Вопрос по файловым системам. от cvv

Re: Вопрос по файловым системам.

>Выжать преимущества raw девайсов не такая уже и простая задача. Даже оракл рекомендует такое решение только для некоторых частных случаев...

Задача не сложнее, чем решить примитивное диф.уравнение. Надо только понимать принцип записи/чтения и движения головок, а также знать "настоящую" геометрию носителя.

Если мне не изменяет память, то консультанты Oracle как раз говорили о трудностях выяснения настоящей геометрии и о незначительности даваемых этим преимуществ для общего случая конкурирующих запросов.

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

ly ()
Ответ на: Re: Вопрос по файловым системам. от ly

Re: Вопрос по файловым системам.

>Задача не сложнее, чем решить примитивное диф.уравнение. Надо только понимать принцип записи/чтения и движения головок, а также знать "настоящую" геометрию носителя.

сравнил.

кстати не подскажите где можно найти геометрию SANnet II SATA от Dot Hill?

cvv ★★★★★ ()
Ответ на: Re: Вопрос по файловым системам. от ksicom

Re: Вопрос по файловым системам.

>Всё что связано с SQL запросами не нужно.

И кака разница? Значит будет легко эти самые запросы писать.

У BDB какая-то мутная лицензия, запрещающая коммерческое использование, в противном случае лицензировать. А стоит она нехило. Всякие GDBM, немножко не то.

Кстати говоря, у BDB есть тип БД "очередь", что-то похожее на твою задачу.

А насчет "неперегруженности" BDB SQL'ем замечу следующее: "перегруженность" наступает тогда, когда запросов очень много - сотни в секунду т.е. каждый запрос разбери, оптимизируй, исполни. Здесь же такого не будет никогда.

Главный вопрос - подойдет ли реляционная модель данных для данной предметной области.

Macil ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.