tag:blogger.com,1999:blog-1231019583108692890.post1778810140283815056..comments2013-09-08T11:21:11.978+04:00Comments on Журнал Александра Костырко: О цене и ценности информацииUnknownnoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1231019583108692890.post-4608994850185566922013-09-08T11:21:11.978+04:002013-09-08T11:21:11.978+04:00Гриша, ты прав в отношении того, что в цену хранен...Гриша, ты прав в отношении того, что в цену хранения нужно обязательно учитывать и стоимость лицензий, и стоимость персонала, и амортизацию, и много всякого. Больше того, я разговаривал как-то с ценовиком, то он мне очень много интересного рассказал о том, как они считают стоимость хранения информации. Разработка методик под конкретную организацию - дело трудоемкое, но иногда (когда информация - это основной актив, и ее много) дает серьезный эффект в части бухучета.<br />И в части стоимости хранения на мейнфрейме - тоже во многом прав. Но не во всем. Дело зависит от ОС. Вот MVS делалась тогда, когда понятия СУБД не было, и масса базовых механизмов ОС были придуманы и сделаны как раз для того, чтобы программист мог комфортно хранить много данных и быстро и легко их обрабатывать. Поэтому мы и можем сейчас в обычном MVS без всяких дополнительных ухищрений хранить более 5 млн плоских наборов данных, без снижения времени доступа к данным. А есть еще всякие вкусные VSAM-ы с индексами и так далее, почти готовая СУБД внутри системы, пиши-ищи-храни что угодно.<br />Но, с другой стороны, MVS стоит много денег. VM дешевле, и там таких возможностей нет. Так что старушка zOS просто стоит своих денег в этом смысле. И она не так уж продуманна и не совсем небольшая. Она просто затачивалась под это, под хранение и работу с данными на базовом уровне.<br />Я тоже считаю, что реляционная структура избыточна и неоптимальна для хранения данных в очень и очень многих случаях. С другой стороны, оценить это сложно, ибо ценность информации может оправдывать избыточность - если это, например, принципиальная финансовая аналитика или истории болезни, где важно быстро и правильно искать данные для последующего анализа и цена этого анализа будет общественно-значима, то и плевать на цену хранения...<br />В общем, все неоднозначно.akosthttps://www.blogger.com/profile/03224430653411892308noreply@blogger.comtag:blogger.com,1999:blog-1231019583108692890.post-11678959224953461152013-09-07T22:26:17.106+04:002013-09-07T22:26:17.106+04:00Хорошая тема.
И правильная, и своевременная.
Компа...Хорошая тема.<br />И правильная, и своевременная.<br />Компании стонут от проблем управления хранением демятков терабайт данных...<br />Большая часть которых никому никогда не потребуется.<br />Про логи всяких веб серверов даже говорить не хочу, по большей своей части &овно, из которого некоторые умудряются делать деньги, однако...<br />Вот, к примеру, телеком и хранение CDR (Call Details Record). С одной стороны, зачастую законодательство (СОРМ). Хотя, при наличии известной доли паранои, логи вебсерверов тоже... Превращаются в данные долговременного хранения.<br />И вопрос стоимости хранения стоит в полный рост.<br />Но стоимость хранения складывается из многих параметров... Меньше всего мне интересны те составляющие, которые касаются аппаратуры.<br />А больше всего - софтовая составляющая.<br />И здесь интересный момент.<br />Если уже много лет назад я писал на sql.ru, что хранение таких данных в РДБМС очень дорого, и никто на это не обращал внимания, то теперь уже появились готовые коммерческие решения для хранения телекомовских данных, не использующих РДБМС, и обходящихся и дешевле, и эффективнее.<br />Что интересно, я до сих пор полагаю, что старушка z/OS, в целом, и VSAM (extended format & extended addressability) в частности могут быть очень выгодной и эффективной платформой для хранения всякого мусора по принуждению. Небольшая софтовая надстройка, продуманная структура....<br />Нет?Anonymoushttps://www.blogger.com/profile/00198369546743622273noreply@blogger.com