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

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

Интересно а svn тута не поможет?

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

загнется

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

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

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

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

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

вариант с файловой системой - самый медленный будет

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

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

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

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

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

BDB && GDBM не перегружены sql-em.

а sqlite таки имеет поддержку sql

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

естественно

просто его можно сильно упростить ро сравнению с обычными ФС

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

сравнил.

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

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

Как кто-то уже не раз замечал: Москва, Загородный, д.2.

а поближе?

>а поближе?

в принципе, есть шанс что и по телефону объяснят. Наберите 03, изложите проблему, может Вас на Загородный даже на спец. машинке отвезут.

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

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

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

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

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

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

thanks