Все новости от 22 мая 2005 г.

Переосмысление роли реляционных БД

Конечно, столь безапелляционное суждение оправдано, так как системы управления реляционными базами данных (СУРБД) обеспечивают мощные инструменты, средства для манипуляции часто меняющейся информацией, поддержку большого числа одновременно работающих пользователей и много других возможностей.

Однако практически все эти достоинства СУРБД не соответствуют характеру большей части тех данных, которые генерируются на современном предприятии. Это несоответствие наглядно проявляется в контексте управления жизненным циклом информации (Information Lifecycle Management, ILM), или выбора способа манипуляции данными с момента их создания до выхода из употребления. ILM быстро завоевывает популярность среди корпоративных ИТ-подразделений как эффективный метод архивирования при быстро растущих объемах данных.

Рассмотрим две насущные проблемы, составляющие первоочередные задачи для каждого предприятия — требования технологии RFID и акта Сарбанеса-Оксли. В отношении исходных данных у них много общего с другими, более специальными задачами ИТ, такими как учет информации операторами мобильной связи или учет продукции на промышленных предприятиях.

Гигантские объемы данных, генерируемые такими источниками, относятся к прошлым бизнес-событиям. Эту категорию данных отличают три ключевых характеристики:

1) Записи генерируются с высокой скоростью (как правило, автоматически), что приводит к большим объемам сохраняемых данных.

2) После создания записей они больше никогда не изменяются.

3) Записи должны сохраняться главным образом с целью архивного хранения, и обращаться к ним будут редко (если вообще будут).

Регистрация мобильных звонков в течение двух недель легко заполняет базу данных объемом в четыре терабайта и больше, а так называемые мобильные сети 3G увеличат этот объем в десять-двадцать раз. Что касается регистрации меток RFID, то ожидается, что крупные ритейлеры и дистрибьюторы будут генерировать десятки терабайт, а по некоторым невероятным оценкам, даже миллионы терабайт записей ежедневно.

Здесь-то и зарыта собака. Функциональность реляционных баз данных — с их транзакционными, динамическими и многопользовательскими возможностями — значительно богаче потребности в простой сортировке и доступе для однократной записи и в редких случаях прочтения бизнес-информации. Эта избыточная функциональность требует ощутимых инвестиций в оборудование и ПО, которые растут пропорционально объему регистрируемых данных. Затраты могут легко вылиться в семизначные цифры, так что даже самому обильно финансируемому вычислительному центру будет нелегко решить эту проблему.

Ответ, вероятно, лежит в дополнении СУРБД технологией, отвечающей требованиям регистрации и хранения больших объемов однократно записываемых данных. По иронии судьбы, таким требованиям сегодня и в будущем превосходно отвечает технология, изначально предназначенная для журналов регистрации событий: неструктурированный файл.

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

Индексация базы данных ускоряет доступ к большим объемам информации, создавая указатель на положение соответствующих записей по каждому полю (имя пользователя, номер телефона и т. п.) Неструктурированный файл, снабженный таким индексом, представляет собой очень легкодоступное хранилище данных — в гораздо большей степени, чем библиотека на магнитной ленте, — которое можно быстро задействовать для нужд корпоративной отчетности. Более того, делается это на сравнительно маломощном серверном оборудовании. В сочетании с постоянно снижающейся стоимостью дисковых накопителей применение неструктурированных файлов обеспечивает высокоэкономичный подход.

Не менее важно и то, что перенос больших объемов данных о бизнес-событиях из СУРБД в дополнительное решение на основе неструктурированных файлов приводит к повышению производительности СУРБД в таких задачах, на которые они рассчитаны. В то же время при таком подходе исполняется обещание ILM о размещении нужных данных в нужном месте при подобающих затратах без ущерба для бизнеса.

Настало время подумать о том, как предотвратить нависшую над нами угрозу взрывного роста объемов данных. Реляционные базы данных — это впечатляющая технология, но это самый дорогостоящий способ хранения больших объемов статической информации, которая нужна лишь на тот случай, если она понадобится когда-нибудь в будущем.

Часто ссылаются на то, что 80% данных, записанных в реляционные БД, больше никогда не извлекаются. Для данных о цифровых бизнес-событиях этот процент гораздо выше, причем заранее известно, что созданные записи вряд ли вообще когда-нибудь понадобятся, и уж точно не будут редактироваться пользователями.

Короче говоря, реляционная база данных — слишком большой молоток для гвоздя регистрации цифровых бизнес-событий.

Об авторе:
Кейт Митчелл — генеральный директор компании CopperEye. До этого она работала старшим вице-президентом по маркетингу и развитию бизнеса в фирме SeeBeyond Technology.

 В продолжение темы:

Обсуждение и комментарии

	ммм 22 May 2005 1:36 PM
все-таки слово XML так и не было сказано :-))
	Michael - wq43564zahav.net.il 22 May 2005 2:05 PM
2MMM При чем здесь XML? Действительно, в XML можно хранить любые объекты, включая графические, только в текстовой форме. Посмотрел-бы я на чудака, извлекающего информацию из XML файла обьемом 100-200MB. Вспотеешь ждать. Дело в другом. Судя по статье этой дамы существует потребность в БД (как реляционных, так и OODB (object oriented, типа FastObjects, например)), которые работают только на запись и поиск данных. И автор об этом пишет.
	Прохожий 22 May 2005 4:03 PM
Интересно, а кто мешает во время записи данных отключить всяческие там триггеры, ограничения целостности, журнал регистрации транзакций и т.п.? Конечно, СУРБД тратит какое-то время на то регистрацию поступающего потока данных. Накладные расходы есть. Интересно только насколько такие накладные расходы перевесят накладные расходы на запись данных в индексированный файл? Если уж говорить о регистрации звонков у операторов, то такая регистрация необходима не только для того, чтобы вести историю. Такие данные впоследствие можно анализировать вдоль и поепрек с тем, чтобы предложить клиентам более оптимальные пакеты. Почему-то Кейт Митчелл предпочла об этом умолчать.
	ммм 22 May 2005 4:11 PM
Да нет, вопрос вообще в том, чтобы использовать неструктурированный формат записей. При технологии "сохранил - и забыл". Чтобы, если захочется поднять старые записи, на это ушло бы раз в десять больше времени.
	ммм 22 May 2005 4:16 PM
2 прохожий: хотел бы я посмотреть в глаза тому админу, который согласится отключить журнал транзакций для более-менее серьезной БД :-))
	AT 22 May 2005 5:07 PM
ммм: Хотел бы я посомтреть на того программиста который писал бы в журнал аудита что-то в пределах транзакции :-)) Аудит на и то он аудит - что откатывать ничего не надо. Если ты теряешь информацию какую-то - то должен знать об этом.
	AT 22 May 2005 5:13 PM
Прохожий: Предлагать надо самые неоптимальные пакеты - за которые больше всего платить будут :-)
	ммм 22 May 2005 6:01 PM
2 AT: ты процитировал меня или какого-то другого ммм? :-) если ты теряешь информацию, то ты об этом знаешь всегда. Вопрос в том, что с журналом транзакций информация восстанавливается легче и быстрее.
	Michael - wq43564zahav.net.il 22 May 2005 6:20 PM
2MMM -> При технологии "сохранил - и забыл"... Сохранение данных в произвольном формате, имитирующем XML, возможно. На уровне реляционной базы данных это удовольствие требует не более 3-х - 4-х таблиц. Просто моделируется запись (а потом и поиск, естественно) иерархических обьектов типа Composite. Но это требует дополнительных ресурсов. За все приходится платить. А за гибкость доступа тем более.
	ммм 22 May 2005 7:57 PM
2 Michael: > За все приходится платить. А за гибкость доступа тем более. Надо Елашкина спросить, насколько реально организовать такой сервер БД - без особых потерь в производительности. При современном уровне развития железа, ессно.
	dr-Wicked 23 May 2005 9:16 AM
А вот я как то сразу переосмьіслил. Вот например код пишу в VisualStudio а храню в файловой системе, по старинке. А ведь мог в СУБД. О как!
	xfs 23 May 2005 9:43 AM
ну ветка 3.x MySQL как специально под такие надобности писалась =) жаль что они с триггерами и прочим связались.
	Мимо прыгал 23 May 2005 9:57 AM
А подсветку добавили?
	ЛИСС 23 May 2005 12:38 PM
Хорошая трава уродилась в штатах ? Вся разница только в том что: "контекст управления жизненным циклом информации" это просто литр слюней разбавленых пиаром. А реляционная алгебра, это математическая теория. Дамочка об этом и думать забыла.
	V - free_V_Vyahoo.com 23 May 2005 12:58 PM
Мне тоже реляционный подход к выборке данных не нравится. Отсутствует возможность в существующих базах данных что либо изменить, дополнить. Обработка данных не должна быть ограничена SQL запросами и встроенным языком.
	fi 23 May 2005 1:14 PM
Почитал, подумал и понял - права Катя, мы это уже прошли, выкинув из базы сырые данные, производительность их обработки в бинарном в виде возрасла в 20 раз!!!
	Коляныч - kolanychmail.ru 23 May 2005 3:40 PM
>Ответ, вероятно, лежит в дополнении СУРБД технологией, отвечающей требованиям регистрации и хранения больших объемов однократно записываемых данных. По иронии судьбы, таким требованиям сегодня и в будущем превосходно отвечает технология, изначально предназначенная для журналов регистрации событий: неструктурированный файл.< бред. при чем тут формат хранения? ответ на этот вопрос - новые дешевые носители с большими объемами, будь то блюрэй или что-то еще плюс поддержка таких носителей субд. последнего, насколько я понимаю, пока нет ни у кого...
	Николай В. 24 May 2005 9:18 AM
http://sybase.ru/Syb/products/dataware/index.htm - тоже ничего....
	Сергей 24 May 2005 11:54 AM
Еще можна базы использовать, которые только в памяти работают, не обращаясь к диску (ну, ПОЧТИ не обращаясь). У нас Timesten стоит - как раз для регистрации всяких звонков. Причем интересна эволюция системы - начинали они тоже под лозунгом: "в этой области все должно быть просто, как двери" (мы чуть ли не с первой версией еще работали) А сейчас уже и user management добавили, и локировки усложнили, сейчас вот планируют поддержку PL-SQL прикрутить.
	one more Прохожий 25 May 2005 8:03 PM
Повторение велосипеда, или я чего-то не понял? Я к чему - неужели автоматически генерируемые бизнес данные имеют настолько хитрый формат что он не уложится в обычные текстовые поля с переменной длинной, а обычная индексация и запрос на поиск, с ключами только чтение и только вперед, в любой известной РБД дадут скорость поиска ниже чем нечто новопридуманное? А?
	fi 26 May 2005 10:36 AM
то one more Прохожий В общем да, накладные расходы СУБД на таких данных заметно больше. Обычное последовательное чтение файлов будет быстрей.
	Андрей Рогашевский - donixcgok.dp.ua 26 May 2005 5:02 PM
Простое решение таких задач это MySQL - быстрая, бесплатная, nolegacy (без тяжелой наследственности) СУБД . И велосипед изобретать не надо!
	Прохожий 26 May 2005 10:39 PM
Для Андрея Рогашевского MySQL - это тоже РСУБД, хотя и очень урезанная по функционалу по сравнению с более взрослыми "сородичами". Для fi Обычное последовательное чтение файлов будет быстрей. --- А как насчет произвольного чтения? Для V Мне тоже реляционный подход к выборке данных не нравится. Отсутствует возможность в существующих базах данных что либо изменить, дополнить. --- В смысле?
	fi 27 May 2005 7:19 AM
то Прохожий ключивые слова "на таких данных"!!!
	Михаил Елашкин - imhoelashkin.com 27 May 2005 10:07 AM
2 V >Мне тоже реляционный подход к выборке данных не нравится. Отсутствует возможность в существующих базах данных что либо изменить, дополнить. Обработка данных не должна быть ограничена SQL запросами и встроенным языком. Это сильно. И что же тебе не хватает?
	ggv 27 May 2005 11:04 AM
да во VSAM их, и все делов то :)
	Денис Кошкин - k5yandex.ru 28 May 2005 5:06 AM
Реляционный базы как раз плохи тем что хорошо подходят только для примитвных структур данных больших объемов. Если они и для этого становятся плохими - я тогда вообще не понимаю зачем рынок востребовал СУРБД
	Михаил Елашкин - imhoelashkin.com 28 May 2005 7:36 PM
2 Денис Кошкин На самом деле вопрос в специализации против универсальности. РСУБД могут и умеют многое, но вот если мы точно знаем, что нам никогда не понадобиться делать select for update, а только на чтение, причем чтение от одного "юзера", то можно кое что выбросить. А... "баба с возу - кобыле легче" :) Т.е. если сделать специализированную СУБД, которая только для таких операций, то она окажется быстрее. Вот собственно и смысл. Ну пусть делают...
	V - free_V_Vyahoo.com 30 May 2005 11:21 AM
2 Михаил Елашкин : >И что же тебе не хватает?< ОК. На мой взгляд, SQL впервые был применен для того чтобы, чтобы не программисты, используя язык запросов, могли строить отчеты - это тупиковая ветвь развития. Для программистов необходим иной подход, более обьектно ориентированный. Данные должны иметь интерфейс, который программист может описать, а индексы, view, должны быть вспомогательными ( стандартными) средствами но не основными. Например у меня есть файл данных, известной мне структуры, мне может быть выгодно не перегонять данные из этого файла в базу, а просто подключить файл в пространство базы данных, описать интерфейс к данным с необходимым мне вариантом поиска, построением индекса ( частный случай всегда быстрее общего). База данных должна реализовывать только общие принципы управления пространством, позволяя мне менять организацию хранения информации. Вероятно это должно быть похоже на C++. Если я хочу, чтобы мои данные имели вид таблицы, я должен описать интерфейс таблицы для своих данных, индекс тоже должен иметь интерфейс и т.д. и т.п. Соответственно я смогу вводить свои операции над данными, удаление, умножение матриц/блоков/пространств, управление архивированием (соответствующий интерфейс), резервированием памяти. Возможность переключения между версиями алгоритмов ... все времени нет, пора работать ;)
	Сергей 30 May 2005 11:48 AM
Для многих проектов подход V может быть действительно удобным - в частности, однопользовательские приложения или приложения с ограниченным числом функций, небольшие объемы данных etc Если же речь идет о большом количестве данных, которые обрабатываются десятками различных приложений, да еще и приложения разрабатываются разными организациями... Тут уже описание интерфейса для каждой таблицы и каждого индекса обернутся изобретением велосипеда в надцатой степени (не говоря уже о стоимости такого "изобретения")
	ggv 30 May 2005 1:42 PM
да есть такой способ работы с _внешними_ данными из базы На вскидку - некоторые продукти (типа Excalibrus) базирующиеся на Informix DataBlade, а также интерфейс IBM DataLink
	Денис Кошкин - k5yandex.ru 30 May 2005 7:00 PM
>2 Михаил Елашкин Все понятно, юзеры не хотят платит бабки за излишнии возможности современных СУБД как таковых. А реляционные они или ОО безразницы. Глупая эта баба, и название статьи у нее не по теме.
	Михаил Елашкин - imhoelashkin.com 30 May 2005 9:00 PM
2 V Тут только один вопрос. Зачем вам СУБД для таких задач? Судя по всему вам не нужна ее функциональность вообще. Ну и не используйте. А все остальное вы же сами собрались написать :)
	Михаил Елашкин - imhoelashkin.com 30 May 2005 9:01 PM
2 ggv Да этого добра море и в Oracle и в DB2 и в Informix. А можно вообще в BLOB все накидать. Вопрос только в том - зачем таким данным СУБД?
	Михаил Елашкин - imhoelashkin.com 30 May 2005 9:02 PM
2 Денис Кошкин Абсолютли.
	V - free_V_Vyahoo.com 31 May 2005 11:29 AM
2 Михаил Елашкин : >Зачем вам СУБД для таких задач?< Например обработка телефонных переговоров ( думаю вряд ли можно найти что то более крупное по обьему данных). Как правило данные о переговорах снимают с телефонной станции в виде шестнадцатиричных файлов (при загрузке таких данных в базу обьем данных может увеличиваться от 5 до 10 раз, т.к. часто один байт может хранить данные нескольких полей). Для финансовых отчетов нет необходимости использовать все данные ( за ненадобностью и по причине значительного обьема), интерфейс помог бы выделить необходимое, а не грузить все в базу. В то же время, иногда после выдачи счетов у клиентов бывают претензии ( они утверждают что таких переговоров не вели), соответственно необходима возможность доступа к оставшимся шестнадцатиричным данным (для выяснения технических причин), причем допустимо рассмотрение жалоб в течении недели или месяца т.е. быстродействие здесь не критично. Что касается BLOBов, то вам придется каждый раз считывать всю информацию из базы и производить парсинг каждой записи, хотя вам необходима лишь часть данных. Генерирование финансовых расчетов используется уже написанными компонентами, которые умеют работать только с таблицами. Таким образом можно разделить общую функциональность отчетов и частные случаи представления исходных/конечных данных.
	V - free_V_Vyahoo.com 31 May 2005 11:43 AM
Едем дальше. Предположим в базе сотни миллионов записей о разговорах, мне необходимо оперативно выдать пользователю данные. Как правило используются индексы, но после их установки на таблицу скорость вставки ( и размер индекса соответственно) значительно падает ( 10-20 раз), что недопустимо. Частный случай - поиск с использованием зоны, т.е. набор индексов по зонам ( что быстрее и меньше по размерам соответственно), ведь вся информация поступает/выдается по зонам. Думаю "Сергей" больших обьемов данных и не видел никогда ;)
	V - free_V_Vyahoo.com 31 May 2005 11:46 AM
Надеюсь я "рассеял" вашу уверенность в существующих СУБД ;)
	V - free_V_Vyahoo.com 31 May 2005 11:49 AM
Как говорилось в одной рекламе Оракла "Мы храним гигабайты данных". Очень точно сказано, "храним". Потому что на своевременную выборку/обработку при таких обьемах сложно рассчитывать ;)
	Кораблёв Игорь 31 May 2005 12:05 PM
Бред. Всё бред. Однозначно. OLAP дамочка ещё не привела в пример. XML - это тоже нерациональное использование объёмов тары и хранимой информации. Бред!...
	Кораблёв Игорь 31 May 2005 12:11 PM
Я в работе использовал BLOB (тип Oracle) с упаковкой в модуле сервера приложений. Всё "стреляет"! Информация АСУТП хранится 5 лет. Т.е. BLOB используется как буфер для накопления и квант записи информации. Ещё раз, статья - бред!
	fi 31 May 2005 2:12 PM
то Кораблёв Игорь А вы внимательней прочитайте, внимательней. Есть определенный тип даных которые можно хранить в СУБД, но это крайне НЕ удобно. Я приводил реалный пример, когда скорость обработки повышается в разы, если их хранить в виде бинарных файлов разложеных по каталогам.
	Кораблёв Игорь 31 May 2005 3:18 PM
Если вы что - то мыслите в структурах БД, то в Oracle, например, верхушка данных("свежая" информация) хранится в открытых курсорах, в ОЗУ сервера. И можно гибко настраивать этот объём информации, увеличивая ОЗУ. Проблема больших архивных объёмов решается путём использования кластерных технологий. Эта статья - это поверхностный дилетаннтский взгляд, это попытка изобрести велосипед. Эта статья для тех кто не писал ни строки на ассемблере! :)
	ggv 31 May 2005 4:02 PM
сьало ясно, что Кораблев Игорь, разрабатывая приложения на Oracle, пишет на асме. А если серйозно - то следующие 7 лет ожидаеться рост трафика телефонных операторов в 27 раз. Мое мнение - индутсрия не готова пока. Вопрос поднят своевременно. Если бы не лицензионная политика IBM, то VSAM был бы единственное решение удовлетворяющее по производительности и надежности, из всех существующих. Учитывая возможность при необходимости иметь его присоединенным к DB2, и оптимизатор опять же. Но это уже вторично
	Кораблёв Игорь 31 May 2005 4:40 PM
Я понимаю сарказм ggv и полностью с ним согласен! Любая современная СУБД может хранить бинарную информацию, пользовательские объекты, всё что угодно. В реляционной базе данных можно хранить вовсе не связанную (реляционную) информацию. Всё что угодно! А вот встроенные механизмы СУРБД вы хрен реализуете сами на обычных плоских файлах - не хватит ни сил ни терпения.
	ggv 31 May 2005 5:55 PM
Вопрос Кораблеву - вы имеете представление об интерфейсе DataBlade? многое сделать можно, я не говорю все, но посмотреть стоит
	ggv 1 Jun 2005 11:02 AM
Михаил Елашкин - вопрос и к вам тоже :) DataBlade это, по-моему, уникальная вешь, не имеющая аналогов.
	Сергей 2 Jun 2005 12:16 PM
V, Ваше предположение, о том, что я видел, не соответствует действительности :-)
	V - free_V_Vyahoo.com 3 Jun 2005 2:54 PM
2 Сергей : Если бы вы работали с большими базами данных, то не писали глупостей ;)
	Сергей 7 Jun 2005 7:55 PM
не хочется занудствовать, но... в вашем оригинальном сообщении говорилось следующее: > Если я хочу, чтобы мои данные имели вид таблицы, я должен > описать интерфейс таблицы для своих данных, индекс тоже должен > иметь интерфейс и т.д. и т.п. Вот к нам такие бойцы и приходят. И давай, значит, описывать интерфейсы таблиц - занимает это у них обычно порядка 4-5 месяцев. (После чего бойцы замечают, что на оставшийся проект времени не остается). Тут к ним подсоединяются комбатанты из организации номер 2 - эти пишут Очень Важное Приложение для Большого Шефа. И вместо того, чтобы использовать стандартные штуки (или хотя бы наработки команды номер один), они тоже (да-да!) разрабатывают "стандартные интерфейсы". Затем закупается за много денег (Сто евров. Или даже двести) Большая Считательная Программа. Со своими собственными стандартными интерфейсами. И тут уж все это богатство сопрягать можно просто бесконечно...
	V - free_V_Vyahoo.com 9 Jun 2005 12:02 PM
2 Сергей : >Вот к нам такие бойцы и приходят.< Видите ли, дворников и сантехников, которые называют себя "IT специалистами" очень много ( по причине относительно больших доходов), а профессионалов единицы. К вам приходят такие же, как и вы сами, потому что вы не в состоянии отличить специалистов от лохотронщиков, до того как заплатите деньги ;)
	Сергей 9 Jun 2005 1:02 PM
Увы, манией величия страдают и программисты одиночки, и большие фирмы. Будучи не в состоянии нормально освоить существующий инструментарий, они начинают придумывать "интерфейсы для таблиц и индексов". PS Наш телеком все равно больше вашего (он вообще самый большой), так что нам виднее :-)
	Весельчак У 9 Jun 2005 1:55 PM
2 Сергей: Не нервничайте, такие как V бывают не так уж редко - на всех валерьянки не напасешся. Очивидно, что V - специалист с балшой буквы, исключительный профессионал. То что у V манька по полной программе - видно невооруженым взглядом даже неспециалисту в области психиатрии. За многие годы работы сталкивался с подобными гениями неоднократно - когда для решения вобщем-то элементарных задач разрабатывалисть немыслимо сложные конструкции, под грудой которых погребались проекты. Согласен с тем, что статья совершенно дилетанская или пиаровская - расчистка пространства под какой-нибудь шедевер. Я сам 10 лет работаю с оракулем и могу сказать, что всегда главной (а часто - единственной) причиной медленно работающего приложения СУБД (по крайней мере оракуля) есть кривые мозги разработчика или несоответствие способа решения проблематике задачи (что в общем-то тоже производная от кривых мозгов. Ну а решать задачи несвойственные СУБД с помощью СУБД - тоже в большой степени маразм.
	V - free_V_Vyahoo.com 10 Jun 2005 12:34 PM
2 Весельчак У : Ну вот, снова. Не специалист в психиатрии, а диагнозы выставляете. Вот все у вас так, "пироги печет сапожник ..." ;) 2 Сергей : >Наш телеком все равно больше вашего< Старая история, про это даже песни были. Вспомните песню Высоцкого, про жирафа ;)
	V - free_V_Vyahoo.com 10 Jun 2005 12:49 PM
2 Весельчак У : Может вы поделитесь информацией о своем месте работы, разработанных программах, решением нижеперечисленных проблем ?
	Dr.X 14 Jun 2005 6:55 PM
если звонки можно "категоризировать" более, чем одним способом, я бы сделал так: звонки хранятся в одном файле, записи добавляются в конец. Для каждого способа категоризации есть файл, в котором хранятся индексы записей в файле со звонками, но при добавлении запись добавляется не в конец, а становится на своё место, в соответствии с сортировкой. Вобщем, внешние индексы уже были бы... Со временем добавил бы ещё пару фишек.. Получилась бы субд... Сначала она была бы быстрая, На неё бы обратило внимание коммьюнити, народ бы её хвалил, но с каждым разом возлагал всё новые и новые задачи на неё... Появились бы хранимые процедуры, транзакции, многопользовательность... Потом бы опять вышла статья, подобаня этой... И нашёлся бы ещё какой-нибудь крендель, который не воспользовался бы субд, а хранил бы данные в файле... Через какое-то время я стал бы конкурентом Oracle, но потом бы нас по очереди выкупил какой-нибудь Microsoft и сделал из нас одну фирму. К тому моменту тот крендель, который пользовался файлом для хранения записей, оттяпал бы у нас 30% рынка, потому что у него хранимые процедуры можно было бы писать на любом языке программирования, главное потом их откомпилировать в байт-код виртуальной машины, которая интегрирована в его субд... Вобщем, как говорится в анекдоте: "да пошла ты, соседка, со своим утюгом!" P.S. "Издавна связываемый с внутренними базами данных приложений и настольными программами, неструктурированный файл, перенявший у реляционной базы данных ключевую функцию — индексацию" -- фиговато звучит, получается, что реляционные базы данных появились раньше, чем файлы? :-) Кто у кого что перенял? :-) P.P.S. не воспринимайте слишком серьёзно :-)
	Tolik 16 Jun 2005 8:39 AM
Советую поклонникам специализированных решений посмотреть на логику развития индустрии. Сейчас уже никому в голову не приходит для решения большинства специализированых задач разрабатывать свой, уникально подходящий для них микропроцессор, компьютер, язык программирования. берется стандартная плата. стандартная операционка общего назначения. компилятор из магазина - и получается возможно не до конца оптимальное, но рабочее решение, дешево и быстро. Дальше случается забавный эффект. Потребление этих самых плат/процессоров/операционок становится настолько большим (за счет отсутствия специализированных решений), что их цена падает ниже всяких разумных рамок. Компьютер общего назначения за 300 долларов сейчас имеет просто неправдоподобные по меркам десяти лет назад возможности. Специализированные решения могут делаться только для совсем уж уникальных случаев и пользователь, не готовый переплачивать за "избыточные" возможности стандартной РСУБД и некоторую избыточную мощность оборудования - заплатит за ПОЛНУЮ разработку специального под него решения - и будет оно ему дороже самолета.
	Петр Савельев - savelievpetrmail.ru 16 Jun 2005 7:03 PM
Судя по количеству комментариев, статья удалась ;) Неплохо было бы автору гонорар заплатить.
	V - free_V_Vyahoo.com 17 Jun 2005 1:20 PM
2 Dr. X : > Для каждого способа категоризации есть файл, в котором хранятся индексы записей в файле со звонками, но при добавлении запись добавляется не в конец, а становится на своё место, в соответствии с сортировкой.< Возможно я не совсем понял ваши решения. То есть, вы предлагаете, скажем 10Гбайтый файл, после добавления записи в начало ( где записи место) переписывать его снова ? ( Я бы не назвал ваше решение умным ;)
	V - free_V_Vyahoo.com 17 Jun 2005 1:30 PM
2 Tolik : >Советую поклонникам специализированных решений посмотреть на логику развития индустрии.< Ну например я видел, что программы, написанные на C++ ( в свое время я их писал, они позволили отказаться от ЕС), работали на десяти 486 процессорах и обеспечивали обработку месячного обьема данных за несколько часов. С переходом на ваши стандартные Оракл и несколько многопроцессорных серверов, система едва успевает обрабатывать данные, при увеличении персонала на порядок и постоянных проблем. Одна из многих - ошибки операторов. Ну ошибается человек иногда, а времени на повторную обработку и поиск искаженных данных уже нет ;)
	Весельчак У 17 Jun 2005 3:24 PM
2V Может, еще и деньгами поделиться? Читайте документацию, изучайте матчасть. (Этот совет - бесплатный)
	V - free_V_Vyahoo.com 20 Jun 2005 11:37 AM
2 Весельчак У : >Может, еще и деньгами поделиться?< Я сомневаюсь что у вас вообще есть деньги, куда уж вам делиться ;)
	V - free_V_Vyahoo.com 20 Jun 2005 12:05 PM
2 Весельчак У : >Читайте документацию, изучайте матчасть. (Этот совет - бесплатный)< Вероятно вы матчасть уже изучили, так докажите что вы не "Бендер, из села Великие Васюки". Приведите решение нижеперечисленных проблем на основе вами освоенной матчасти, стандартной системы ;)
	Dr.X 20 Jun 2005 6:18 PM
2 Tolik: классно написал, согласен полностью :-) Как правило, использовать что-то готовое выгоднее. Во-первых, у повторно изобретённого велосипеда придётся повторно исправлять баги. Во-вторых, что такое рост аппаратных требований по сравнению со сроками сдачи продукта, ростом сложности понимания и сопровождения? Вобщем, это вопрос, скорее, для тех людей в фирме, которые принимают экономические решения -- посмотреть, что окажется дешевле сегодня и будет ли это так же дёшево завтра... 2 V : V> Возможно я не совсем понял ваши решения. То есть, вы предлагаете, скажем 10Гбайтый файл, после добавления записи в начало ( где записи место) переписывать его снова ? ( Я бы не назвал ваше решение умным ;) Нет, не так. Новые записи в текстовый файл с непосредственными данными добавляются в конец, а не в начало. Запись в середину производится для других -- индексных -- файлов. В каждом таком файле находятся только индексы (int'ы) записей, отсортированных по тому или иному критерию. Для поиска нужной позиции при вставке нового индекса в такой файл используется двоичный поиск. > скажем 10Гбайтый файл а если индексов наберётся на 10 Гб, то тут уже пора переходить на нормальную бд :-)
	Кораблёв Игорь 21 Jun 2005 12:22 PM
Да!... Статья собрала шквал... не аплодисментов - критики! Отзывов хоть отбавляй. :) С экономическим обоснованием... Про стоимость самолёта мне особенно понравилось! Точное сравнение: и по сложности , и по стоимости! Про плаские файлы- ведь на них уже стандарты выходят. Я был приятно удивлён узнав ,что "1С" выпускает стандартные шаблоны документов (финансовая и бухгалтерская отчётность) в формате XML. Классно! Ну, конечно, может и я поздно узнал, но решение отличное! Вывод - изобретать велосипеды всё сложнее!... :)
	V - free_V_Vyahoo.com 21 Jun 2005 3:36 PM
2 Dr.X : >а если индексов наберётся на 10 Гб, то тут уже пора переходить на нормальную бд :-) < Обсуждали ведь уже, ну не работает (точнее очень медленно работает) на вашей "нормальной" базе индекс в 10Г ( в Оракле вроде и говорят, что их решения для малого и среднего бизнеса, а не для телекомов ;)
	fi 21 Jun 2005 5:44 PM
то Tolik > Советую поклонникам специализированных решений посмотреть на логику развития индустрии. Смотрим и видем: "специализированных решений", когда речь заходит об крупной системе, полно - ну не выгодно универсальное решение, в лучшем случаи будет стоить как ядерный реактор, а чаще вообше неработоспособно. Взять теже СУБД, "Библиотека Конгресса США", собственная система - ну не потянет там "универсальное решение".
	Dr.X 23 Jun 2005 1:47 AM
V> Обсуждали ведь уже, ну не работает (точнее очень медленно работает) на вашей "нормальной" базе индекс в 10Г а если аппаратную часть апгрейднуть? или есть другие варианты? V> в Оракле вроде и говорят, что их решения для малого и среднего бизнеса, а не для телекомов ;) это где это они такое говорят? ;-O